Существуют ли какие-либо конкретные практические примеры переписывания показателей успеха / неудач программного обеспечения?

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

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

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

Были ли реальные тематические исследования, которые исследовали это? Я не хотел бы пытаться переписать, не зная передовой практики, подводных камней и успехов, основанных на реальных исследованиях.

Последствия: хорошо, после дополнительных поисков я нашел три интересные статьи о тематических исследованиях:

1. Переписать или использовать повторно . Они изучили приложение Cobol, преобразованное в Java.
2. Другой был по повторному использованию программного обеспечения: опыт и восприятие разработчиков .
3. Повторное использование или перезапись Еще одно исследование стоимости обслуживания по сравнению с перезаписью.

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

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

Я не знаю о конкретных примерах, но я думаю, что стандартный ответ для подхода, вероятно, «добавить модульные тесты и рефакторинг».

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

Если они проводят модульные тесты (должным образом - по-настоящему соблюдая все требования), сложно придумать способ, чтобы рефакторинг привел к настоящей катастрофе. Самое худшее, что может случиться, это то, что вы не делаете столько прогресса, сколько хотите. В то же время, если их кодовая база находится в такой же плохой форме, как и этот вопрос, вполне вероятно, что потребуются серьезные усилия для обеспечения прогресса, независимо от выбранного маршрута.

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

Некоторое время назад я прочитал статью «Эффективная работа с унаследованным кодом » Майкла Фезерса и обнаружил, что она дает хорошее представление о реальной практике поддержки унаследованного кода, включая написание тестов (даже если вы не знаете, для чего этот код) и Курс рефакторинг / переписывание. Это немного устаревший, но высоко оцененный на Амазонке.

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

Эта идея о том, что систему можно разбить на куски и понять индивидуально, ошибочна. В какой-то момент один человек или несколько человек должны были иметь возможность понять всю проблему целиком. Если эта проблема представляет собой ряд проблем бизнеса и технологий, которые их приводят; Человеку в компании может потребоваться несколько лет, чтобы понять все системы до уровня, при котором возможна их замена без сбоев или пропущенных требований. Это, конечно, имело место в моей компании, когда я занял пост директора по технологиям. Если бы я сам не был программистом, я бы не смог медленно понять все детали плохо организованной, тесно связанной, тесно связанной архитектуры и интеграции технологий. Если небольшие скрытые, недокументированные детали, такие как"We put the eBay order number in the "SYSOENT.PO_NUMBER" field in the ERP system because that's what Wendell the VB coder from Florida decided to do" упускаются из виду, что результаты могут быть катастрофическими, и единственный способ узнать это - медленно обнаружить все это.

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

Я предполагаю, что моя главная мысль в том, что система должна быть понята почти во всей ее полноте, и в какой-то момент она должна быть понята во всей полноте, чтобы новая система была должным образом «спроектирована», а не просто «сделана».

Cookies сделаны, программное обеспечение (должно быть) спроектировано.

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

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

Есть несколько очевидных случаев, когда переписывание имеет смысл, и много случаев, когда это не так. Я приготовил небольшой рецепт, чтобы выяснить, будет ли в твоем случае смысл переписывания .

Я думаю, что в настоящее время переписывание имеет больше смысла, потому что мы быстро пишем на плечах постоянно совершенствующихся инвазивных сред, таких как Rails, Grails, AngularJS. Если вы хотите перейти от простого js к Angular, переписать - это все, что вы можете сделать. Это все еще может иметь смысл. Если вы заменяете одну реализацию diy другой (как все примеры в статье Джоэла Спольски ), вы, вероятно, сошли с ума.

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

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

С организационной точки зрения переписывание является явным сбоем только в том случае, если переписанное приложение не работает или проект отменяется до его завершения - в противном случае невозможно узнать, была ли задержка выпуска переписанной версии причиной любой потери, которую вы понесли или просто случайно. Если отменено до завершения, это обычно считается пустой тратой времени и ресурсов. Обновление потенциально может иметь ту же проблему, но вряд ли оно будет иметь тот же масштаб (вы получаете что-то за свои деньги).

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

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