Вы когда-нибудь участвовали в БОЛЬШОМ переписывании? [закрыто]

Джоэл Спольски сказал в одном из своих известных постов:

Единственная худшая стратегическая ошибка, которую может совершить любая софтверная компания: переписать код с нуля.

Чад Фаулер написал:

Вы видели видео, публикации в блогах и ажиотаж, и вы решили, что собираетесь повторно реализовать свой продукт в Rails (или Java, или .NET, или Erlang и т. Д.).

Осторожно. Это более длинный, сложный, более подверженный ошибкам путь, чем вы ожидаете.

Вы когда-нибудь участвовали в БОЛЬШОМ переписывании?
Мне интересен ваш опыт в этой трагической теме и, в частности, в любом большом переписывании, которое было успешно завершено (если есть).

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

• Требуется огромная недооценка усилий: каждый раз, когда кто-то хочет переписать, это потому, что старая система использует старые технологии и их трудно поддерживать. Чего они не учитывают, так это того, что из-за его возраста в него может быть вложено 30-40 человеко-лет. Думать, что вы можете переписать все это за 6 месяцев с командой из 5 человек, глупо.
• Утраченные знания: старая система существует так давно, она делает много вещей и привязана ко всему. Там нет современной документации и нет единой точки власти, которая на самом деле знает все, что делает система. Там будут знания с конкретными пользователями в конкретных отделах, и найти их все сложно или невозможно.
• Плохие управленческие решения. У тех переписчиков, в которых я принимал участие, были аналогичные ожидания от руководства: новая система должна быть «сделана», а старую систему можно просто отключить в определенный день, период. Никакой другой вариант не был приемлемым. Я думаю, что они понимают это, потому что они тратят все эти деньги, чтобы нанять новых людей для этого огромного проекта. В действительности, лучшая стратегия снижения риска - переписать основные функции старой системы, скажем, взять 50-75% старой системы для первого выпуска, а затем посмотреть, как она работает! Из-за № 1 и № 2, описанных выше, это, вероятно, сработает гораздо лучше, поскольку мы обнаружим некоторые из упущенных функций и то, что необходимо для фактического отключения старой системы.

Переписывания могут быть очень успешными, если вы правильно их охватите. Я не знаю, соответствуют ли они вашему порогу "БОЛЬШИХ" (ТМ) проектов, но позвольте мне описать вам несколько наиболее успешных переписываний.

Проект 1

Компания, в которой я работал, имела систему печати на полочных полосах, которая использовалась для создания этикеток, которые вы видите на полках магазинов, из так называемой планограммы . Планограмма была сгенерирована в стандартном программном обеспечении, и наши инструменты читают этот документ, чтобы создать планки полки, используя шаблон для целевого магазина. Программное обеспечение для шаблонов представляло собой беспорядок с вложенными конечными автоматами, охватывающими несколько классов и 3 библиотеки DLL. Когда пришло время реализовать (тогда) патентный подход к созданию колышек, стало ясно, что текущий кодекс не может поддерживать то, что мы хотели сделать.

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

Проект 2

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

Решение: нашей команде понадобилось 3 месяца, чтобы закончить - это было не тривиально. Конечный продукт был быстрее, более масштабируемым и более приятным для конечных пользователей. Мы превзошли ожидания наших клиентов. Тем не менее, нам пришлось разделить нашу команду так, чтобы более быстрые исправления ошибок и исправления бинтов были сделаны в существующей системе, в то время как другая половина работала над новой системой. Мы провели обширное тестирование и включили его в самом начале. Причина, по которой это сработало так хорошо, заключается в том, что мы хорошо знали это приложение и нашего клиента.

Проект 3

Я должен включить сбой здесь. Мы поддерживали клиента, который нуждался в инструменте управления информацией для использования в чрезвычайных / кризисных ситуациях. Мы унаследовали приложение Java Swing, написанное первоначальными разработчиками, не понимая Swing. Под этим я подразумеваю, что они не следовали рекомендациям Sun по работе с Swing и правильному управлению пользовательским интерфейсом, в результате вы попадете в бесконечные циклы событий и другие странные и трудные для отслеживания проблемы. В результате он был загружен ошибками, проблемами пользовательского интерфейса и т. Д. Это было очень сложное приложение. Чтобы сохранить наше здравомыслие, мы попытались переписать плохо написанное приложение Swing в хорошо написанное приложение Swing.

Решение: Мы завершили переписывание примерно через 4,5 месяца, когда мы оценили 3 месяца. Приложение работало лучше, как в пользовательском интерфейсе, так и в том, сколько данных оно может обрабатывать. Затем произошло цунами в 2004 году. Огромное количество людей, которых они должны были отслеживать, продемонстрировало, что Swing - это не та технология, которая им действительно нужна. Мы не могли идти в ногу с нашей настройкой производительности, и в итоге они отказались от инструмента в пользу мощного веб-приложения, созданного командой Oracle, которая у них была в доме. Конечно, мы могли оправдать то, что мы делали, основываясь на знаниях, которые у нас были в то время, но переписывание было недостаточно агрессивным, и мы не смогли сказать нашему клиенту, что их требования к количеству людей, которые, возможно, нужно было отслеживать, были слишком низкий.

Заключение

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

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

Я был связан с несколькими переписываниями, которые были от VB6 до .NET. В 2 случаях переписывание прошло гладко, и мы были фактически закончены досрочно. Другое переписывание заняло больше времени, чем ожидалось, но завершилось без каких-либо серьезных проблем.

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

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

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

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

Цель: внедрить корпоративную систему идентификации, которая могла бы аутентифицировать учетные записи в 4 доменах и полностью управлять (с самообслуживанием) учетными записями в 1 из доменов. Поскольку .Net уже был реализован на спутниках, классический сайт asp, который служил «вводным пунктом», должен был быть переписан, добавлено управление идентификацией, и все сайты должны были бы пройти регрессионное тестирование, чтобы убедиться, что никакие сервисы не были затронуты.

Ресурсы: 3 основных архитектора - программист, управление идентификацией, менеджер проекта. Приблизительно 20 разработчиков, 10 аналитиков, 10 тестеров.

Время до завершения (от начала до конца): 1,5 года

Успех запуска: почти без сбоев

Долголетие Успех: Потрясающе

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

После нескольких месяцев сбора требований примерно с 50 разными людьми из разных отделов нашей корпорации нам удалось прояснить логическую архитектуру и приступить к созданию кода. Из-за характера изменений нам пришлось переписать наш собственный веб-сайт и все функции, которые он содержал, в .Net. В некоторых случаях это был просто вопрос рефакторинга. Во многих случаях это включало полное переписывание процессов, окружающих его. В 2 случаях мы просто отказались от оригинальной функции как не важной. Мы пропустили 2 крайних срока в процессе (но закончили тем, что достигли первоначального крайнего срока, который я предложил - едва). В день запуска ничего не получалось. Мы начали в субботу, поэтому влияние было минимальным, но я провел весь день, просматривая журналы, переписывая фрагменты и оценивая нагрузки на сервер. Больше испытаний, возможно, помогло.

К концу первого дня все сайты были запущены и работали, и все работало (я бы сказал, номинальный успех). За последние 2,5 года все было потрясающим успехом. Наличие всех наших сайтов на общей архитектуре с общей базой фреймворка значительно упростило работу разработчиков и разработчиков. Функции, которые я написал на нашем сайте 2,5 года назад (во время переписывания), с тех пор были замечены / приняты парой сателлитов.

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

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

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

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

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

Это было внутреннее приложение - главное бизнес-приложение.

Мы сохранили старую систему, когда писали версию 2. Если я правильно помню, это заняло у нас около года (два программиста, а затем третий). Нам не нужно было трогать базу данных, поэтому, по крайней мере, миграция данных не была проблемой.

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

Плохая стратегия: я руководил группой из 4 студентов, чтобы:

• Студент № 1 - переписал доступ к базе данных / запросы, чтобы сделать их безопасными
• Студент № 2 - перенес все css "вверх"
• Студент № 3 - сделал все страницы совместимыми с w3c
• Студент № 4 - решены все ожидающие ошибки
• Я: удалил все php-предупреждения и дрянные вещи (дублирующий код и т. Д.)

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

Хорошая стратегия:

• Изучите весь сайт, составьте хороший «Документ с требованиями к продукту».
• Перепроектировать должным образом базу данных
• Начните с нуля с моей собственной структурой (которая уже работает)
• Перепроектировал сайт.
• У мультиязычности.

Время заняло бы: два месяца ( может быть, меньше ).

• Хороший код
• Хорошее обслуживание.
• Производительность.
• Нет ответов типа «мы не можем сделать это, веб-сайт не может обрабатывать такие продукты».

Итак, мои последние слова: все зависит от сложности материала, который вы должны переписать .

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

Оливье Понс

Компания, в которой я работал, основала крупный рефакторинг кодовой базы.

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

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

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

Но в конечном итоге это стало крахом компании.

Я переписываюсь последние 3 года. Первоначально мы оценили проект в 2 года. Основная идея состояла в том, чтобы заменить аппаратное обеспечение, использовать существующую ОС, переписать бизнес-логику (с c на CPP), создать новую карту ввода-вывода и написать новый пользовательский интерфейс.

По пути мы приняли несколько ужасных решений. У нас не было реального опыта в CPP и не было наставника, чтобы научить его хорошо. Мы сами пытались создать фреймворк на основе win32. Аппаратное обеспечение было дешевым, а BSP - ошибками. Программное обеспечение было очень гибким, но сложным в обслуживании. В прошлом году мы выбросили домашний пользовательский интерфейс и разработали пользовательский интерфейс в .net. Мы также полностью переписали наш механизм персистентности и протокол передачи данных.

Потребовалось много дополнительных усилий, но сейчас проект практически завершен, и первые агрегаты проходят испытания в полевых условиях. У проекта был большой риск, чтобы иметь какие-либо изменения, чтобы быть успешным. В этом проекте было несколько положительных моментов: мы начали использовать SVN (вместо VSS), мы потратили время на написание модульных тестов и реализовали ночную сборку. Мы также начали использовать scrum, чтобы улучшить процесс.

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

На самом деле я начинаю большой рефакторинг. 4MLocs, вероятно, должен быть сокращен до 800KLocs или меньше. В этом проекте много копий и вставок, непонимание языковых функций, множество повторяющихся бесполезных комментариев, неправильные решения, временные взломы и другие взломы, ставшие постоянными (включая обходные пути), полное отсутствие знаний об основных принципах информатики или разработки программного обеспечения. Вероятно, после рефакторинга команда поддержки из 32 плохих программистов будет заменена на 2 хороших.

Я написал блог-движок через 3 недели. Я переписал это через 8 часов.

Планирование наперед является ключом к успешному переписыванию. Знание системы внутри и снаружи - это тоже выгода.

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