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

Question

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

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

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

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

Возможно, эти проекты имеют тенденцию жить 3 года. Или менее.

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

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

Какие у вас будут вопросы?

Answer 1

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

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

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

Answer 2

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

3 года кажется действительно коротким.

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

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

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

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

Answer 8

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

1. Новая крупная система (ERP, CRM и т. Д.).), и он имеет «интегрированный» модуль для замены старого приложения.

2. То же, но не интегрированное приложение - но существующее приложение не адаптируется (. Люди ушли, технологии изменились, текущая политика ИТ изменилась, пользователи не любят существующие приложения)

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

4. Или вы не хорошо ладите с ними.

5. Технология для существующего приложения является «устаревшим» (в соответствии с рамочным поставщика/Microsoft/консультант/промышленность эксперт/новый IT-менеджер, который имеет ухо руководства.)

6. «Мы постепенно отказываемся (Windows 95/Windows 98/Windows 2000/Windows XP/NT), и нам нужны соответствующие технологии в наших приложениях ».

7. «Мы многое узнали из (версия приложения n), и мы сделаем намного лучше второй/третий/четвертый/n + 1-й раз».

8. Обоснование работы для разработчиков/ИТ-менеджер/Отдел VP/консалтинговая компания.

9. Пользователи ненавидят его.

10. Мы объединили/приобрели конкурента/были приобретены конкурентом, а их лучше.

Это только начало.

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

Answer 9

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

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

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

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

Answer 10

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

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

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

Answer 11

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

Answer 12

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

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

Answer 13

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

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