Продолжительность программы: как часто вы начинаете с нуля?

Я слышал, что люди говорят, что средний срок службы программного обеспечения составляет около 3 лет, но это кажется мне ужасно низким. Я не покупаю его.

В конце концов, некоторые из моих клиентов имеют огромные мэйнфреймы, которые существуют уже 20 лет, и они настолько укоренились, что могут жить вечно.

Я лично склонен говорить о серьезном рефакторинге, когда платформа становится настолько старой, что это плохо для наших навыков (мы являемся подрядчиками), и в противном случае неэффективно продолжать поддерживать проект. Я думаю об ASP Classic здесь. Это может быть окно от 5 до 8 лет, и его даже не нужно переписывать.

Конечно, я также видел проекты, которые понесли большой технический долг, потому что кто-то слишком часто обращался к заинтересованным сторонам, или разработчик не знал, как планировать изменения. Или проект был запущен на слабой платформе, которая плохо масштабировалась. Это значительно сокращает срок службы.

Возможно, те проекты, которые, как правило, живут 3 года. Или меньше.

Последняя мысль: некоторые исследования доказали, что дешевле поддерживать старый код, чем писать новые, и я верю в это. Переписывание больших систем всегда намного сложнее и дороже, чем кажется.

Все ли это связано с тем, что разработчики склонны переписывать слишком рано и, возможно, наивно? Я думаю, да, и я вижу, как это легко сделать.

Каковы ваши впечатления здесь?

Ответ 1

Команда, над которой я работаю, разрабатывает одно и то же веб-приложение в течение 6 лет, и нет конца. В то время он перешел от классического ASP к ASP.NET 1.1 к ASP.NET 2.0, поэтому различные модули подверглись инкрементным переписываниям, но никогда ничего подобного переписывать с нуля. Каждый так часто кто-то скажет, как хорошо было бы, если бы мы могли начать все сначала, но у нас есть 60 000 пользователей: нет способа, которым они будут ждать от 12 до 18 месяцев, которые потребуются, когда их обновленная функциональность или функции сидят на полки.

У меня была только возможность дважды переписать запись. В обоих случаях причина, по которой у нас было время, и покупка, заключалась в том, что у нас была довольно небольшая группа клиентов, использующих уже стабильную версию. Когда мы пошли к ним с новым продуктом, все согласились, что это лучше старой системы, но очень немногие из них купили его, потому что они уже были довольны тем, что у них было. Это было очень весело для программистов, но в конечном итоге это было потерей для бизнеса.

Итак, из личного опыта вещи, которые вы начинаете с нуля каждые три года, вероятно, не будут использоваться многими людьми. Когда у вас широко используется приложение или услуга, особенно в корпоративной среде, достаточно сложно получить бай-ин для постепенного обновления, не говоря уже о перезаписывании.

Ответ 2

Чем реже, тем лучше.

Но, честно говоря, 3 года очень короткие. Особенно для среднего.

Реальность заключается в том, что вы, как правило, начинаете все сначала, когда вы абсолютно не можете расти, когда у вас технический долг настолько высок, что лучше идти технически банкротом. И даже тогда вы можете часто реорганизовать свой долг.

Ключом к долгосрочному успеху является попытка сохранить технический долг до минимума.

Ответ 3

это зависит от того, насколько хорошо бизнес был смоделирован, включая ожидаемые будущие области изменений, как задействованы заинтересованные стороны/пользователи, и особенно насколько хорошо поддерживается программная система.

Например, первая полная система автоматизации бизнеса, которую я когда-либо писал "по-моему" (то есть, когда заинтересованные стороны слушали меня, и я слушал их, и мы нашли время, чтобы опросить всех пользователей и действительно сделать это правильно) 21 год спустя. В течение следующих двух лет он будет постепенно переписан не потому, что что-то не так с программным обеспечением, а потому, что ИТ-директор думает (и я согласен, хотя он и не спрашивал меня), что было бы лучше перенести приложения из DataFlex к .NET.

Многие из прикладных систем, которые я написал или внесли в них, все еще остаются сильными 5, 10, 15 и 20 лет спустя. Без исключения именно потому, что заинтересованные стороны/пользователи активно участвовали в этом процессе, мы ожидали будущих изменений в бизнесе, мы потратили время, чтобы сделать это правильно, и мы сделали так, чтобы команда технического обслуживания сделала то же самое.

С другой стороны, из того, что я видел, средний срок службы плохого программного обеспечения составляет около 3 лет, потому что, как долго требуется, чтобы пользователи действительно болели, менеджеры устали слышать о это, и руководители решили "сделать что-то" об этом. К сожалению, многие "переписывания" предусматривают "поддерживать один и тот же интерфейс", чтобы избежать переподготовки, что приводит к другой плохой системе и начинает новый трехлетний цикл; -)

Ответ 4

Конечно, это зависит от области технологий, но три года кажутся немного низкими. Некоторые говорят, что до тех пор, пока зреет хорошее программное обеспечение, требуется десять лет.

Я видел несколько проектов, в которых заинтересованные стороны говорят: "Мы можем переписать/заменить [большую систему] через шесть месяцев", и они все еще пытаются несколько лет спустя.

Ответ 5

Часто невозможно оправдать полную переписку, если вы не можете точно определить, какие преимущества будут для конечных пользователей. В противном случае вы оставляете их с одним и тем же программным обеспечением в течение 2 лет, пока вы уходите и перепроектируете свои. Тем временем ваши конкуренты заняты добавлением новых функций вместо воссоздания существующих функций с новыми ошибками. Возможно, сокращение расходов на техническое обслуживание сделает его в долгосрочной перспективе, но в то же время вы рискуете большими потерями на рынке.

Я думаю, вам лучше с небольшими безопасными рефакторингами, которые могут возникать одновременно с разработкой новых функций. Вы, возможно, не сможете достичь всего, чего хотите, но по крайней мере у вас будет что-то отгружаемое тем временем.

Изменить: в ответ на "Что делать, если платформа умирает? Как и в ASP Classic снова" - ну тогда вы не переписываете свой код каждые X лет. Ваша платформа была прекращена. Это не означает, что внезапно все серверы ASP классифицируются там, это просто означает, что на платформе больше не будет обновлений. Затем вам нужно взвесить стоимость перепрограммирования приложения и затраты на его труднее привлечь/поддержать людей для работы над ним. Cobol можно считать тупиком, но есть еще много приложений Cobol, которые люди поддерживают, потому что компания считает экономически более выгодной, чем переписывать их. Таким образом, выбор переписать или нет - это все еще бизнес-решение.

Ответ 6

Мой первый работодатель, которого мы начали строить в 2000 году, приложение по-прежнему существует через 8 лет на одном и том же архитекторе. Они начали процесс перезаписи, который застопорился; однако приложение теперь считается устаревшим, а все новые функции построены на новой платформе.

3 года кажутся очень короткими.

Ответ 7

Я не думаю, что трехлетняя оценка - это время между полными перезаписываниями. Это, скорее, измерение времени между основными выпусками одного и того же программного обеспечения (например, я думаю о Windows и MS-Office). Следующая важная версия, вероятно, не будет полной перезаписи, просто обновление.

Ответ 8

Причины, по которым я думаю, 3 года, вероятно, правы.

Внедрена новая крупная система (ERP, CRM и т.д.) и у нее есть "интегрированный" модуль для замены старого приложения.
То же, но не интегрированное приложение, но существующее приложение не адаптируется (люди ушли, изменились технологии, изменились текущие ИТ-политики, пользователям не понравилось существующее приложение.)
Компания, с которой вы приобрели основное приложение, чтобы настроить его для своих нужд, исчезла.
Или вы не хорошо ладите с ними.
Технология существующего приложения "устарела" (в соответствии с разработчиком среды/Microsoft/консультантом/экспертом по отрасли/новым ИТ-менеджером, у которого есть управление ухом.)
"Мы прекращаем работу (Windows 95/Windows 98/Windows 2000/Windows XP/NT), и нам нужны соответствующие технологии в наших приложениях".
"Мы многое узнали из (версия приложения n), и мы сделаем намного лучше второй/третий/четвертый/n + 1-й раз".
Обоснование работы для разработчиков/ИТ-менеджера/отдела VP/консалтинговой компании.
Пользователи ненавидят его.
Мы объединили/приобрели конкурента/были приобретены конкурентом, а их лучше.

Это просто начало.

Есть очень мало приложений, чьи основные функции были неудовлетворительно реализованы давно в dBASE, работающем на DOS. Что могло быть перенесено и доступно сегодня через Foxpro. (И, черт возьми, они бегут быстро.) Обратите внимание, что Foxpro здесь не придумал - он просто держится в фоновом режиме. (Отказ от ответственности - я не коснулся рамки xBase через 15 лет.)

Ответ 9

Все зависит от того, что вы делаете. Для делового программного обеспечения более длительное время ожидания почти всегда хорошо. Тем не менее я создаю браузерные MMO, и я обнаружил, что с огромным объемом редактирования и переписыванием большого количества кодов, которые я всегда делаю, чтобы улучшить игры, он помогает переписывать с нуля или почти с нуля на почти ежегодной основе.

Конечно, будучи парными парнями, работающими над относительно небольшими проектами, у нас почти нет проблем с масштабированием, которые многие из вас делают. Это значительно облегчает его повторное использование.

Кроме того, не нужно сообщать менеджерам, вероятно, тоже помогает нам.

Ответ 10

Кодовая база, с которой я работаю, началась в 1980 году; в 1984 году все еще есть доказательства кода, если вы знаете, что ищете. У меня мало сомнений в том, что некоторые, возможно, даже большинство из этого кода должны быть улучшены (и, без сомнения, его можно было бы улучшить). Но трехлетний цикл очень короткий по сравнению с 30-летним периодом. С тех пор некоторые коды были выброшены; скорее, должно быть. Но планировать перезапуск каждые три года казаться мне расточительным. Для сложной системы - подумайте о Perl, Python, Ruby, компиляторе C, компиляторе С++, СУБД - вы бы посмеялись из-под контроля с трехлетним циклом броска по всему миру. В конце 3-х лет у вас может быть умеренно приличная система, которая еще 5 лет принесет хороший блеск. Итак, по крайней мере, в моей части мира вам нужно думать о жизненном опыте кода в циклах более 10 лет.

Ответ 11

У меня есть 19-летний код, все еще в производстве, хотя и с тяжелыми модификациями по дороге.

В действительности это должно было быть отменено, по крайней мере, 5 лет назад, поскольку оно выросло FAR за рамки оригинального дизайна и ограничено дизайнерскими решениями, которые имели смысл, когда они были изначально написаны, но теперь являются орехами.

Ответ 12

Я бы сказал, никогда.

Написание приложения намного больше, чем кодирование. Когда вы переписываете все, это никогда не с scrtch, поскольку у вас есть Xp из предыдущего анализа, производственного прогона, отчетов об ошибках, повседневного использования и т.д.

У вас также есть данные, которые вы также должны будете переносить.

С нуля? Неа. Большая часть работы уже выполнена, что упрощает ее работу, и необходимо выполнить большую часть предыдущей работы, что затрудняет ее работу. В конце концов, это занимает столько времени, чтобы создать это в первый раз, но вы не сделали это ex nihilo.

Ответ 13

Кажется, что разговор здесь сосредоточен вокруг среднего времени между переписываниями. Но многие системы терпят неудачу или устаревают по причинам бизнеса и никогда не переписываются. Многие веб-сайты пересматриваются каждые 2-3 года. Сообщается, что у мобильных приложений период полураспада составляет всего 6 месяцев.

В моем веб-поиске, посвященном жизненному циклу программного обеспечения, я мог найти только одно авторитетное исследование по этому вопросу. Исследование показало среднюю продолжительность жизни 9-10 лет, но первоначальный опрос был проведен в 1991 году. Темпы изменения базовых бизнес-драйверов и основных технологий, безусловно, ускорились с тех пор.