Как исправить проект практически без структуры?

Я работаю над программным проектом в основном соло более 5 лет. Для начала это был беспорядок (я - третий или четвертый разработчик, который работает над этим), и хотя теперь он не такой беспорядок, он все еще невероятно дезорганизован. Уровень прогресса в установлении контроля над ним является ледниковым, и я начинаю чувствовать себя подавленным из-за состояния, в котором он находится. Как мне действительно начать это исправлять?

Особенности проекта: Это программа продаж, написанная почти полностью на Visual Basic Classic (VB6) с серверной частью MySQL и механизмом отчетности, написанным на C #. С модулем отчетности C # приятно работать, он только что был написан в последние пару лет, и до этого все отчеты были сделаны в Crystal Reports 9 (да, у нас все еще есть некоторые отчеты, которые полагаются на него).

Сама программа, однако, является полной катастрофой. Всего не совсем 90 тыс. LOC и около 10 тыс. Комментариев (в основном это не документация, а старый закомментированный код). 158 файлов форм и 80 файлов модулей. Я понятия не имею, сколько из них фактически используется, потому что некоторые функции программы просто устарели и (иногда) отмечены как таковые без удаления связанного кода из программы. Я предполагаю, что только 50% кода находится в реальном продуктивном использовании.

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

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

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

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

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

Обновить

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

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

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

Я начал здесь в аналогичной ситуации (приложение 80KLOC VB6 без управления исходным кодом, без реальной структуры, почти все сделано в обработчиках событий).

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

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

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

Я действительно считаю, что лучше всего придерживаться следующего подхода:

1. Узнайте все до мельчайших деталей. Это снижает вероятность того, что вы случайно что-то сломаете.
2. Рефакторинг беспощаден для улучшения разделения и структуры, но не пытайтесь использовать новую методологию, такую ​​как объектно-ориентированное программирование, так как VB6 просто отстой.
3. Относитесь к этому как к опыту обучения. Как бы вы узнали, что другой путь лучше, если бы вы никогда не видели низший путь?
4. Не беспокойтесь о переписывании на новом языке / фреймворке / платформе, если у вас нет основного модуля для написания. Даже тогда тщательно обдумайте.

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

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

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

На ум приходит одно правило из « Отладки » Дэвида Агана : бросьте думать и смотрите. У вас есть машина, способная обрабатывать огромное количество текста. Используйте его, чтобы точно определить, какой код больше не используется, и удалите его без жалости. Если вы допустили ошибку, вот для чего нужен контроль версий.

Это легкая часть. Что нужно подумать о следующем, как вы едите слона? Один укус за раз. Возьмите « Рефакторинг » Мартина Фаулера и возьмите его функцию за функцией, файл за файлом. Не полностью отбрасывайте что-либо и переписывайте это, исходя из того, что вы считаете нужными. Работайте как альпинист, никогда не удаляя свою прежнюю безопасность, пока следующая не будет на месте.

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

Ненавижу это говорить, но я бы пошел с «совершенно безнадежным», а не просто продолжал делать бесконечный цикл патчей / улучшений и надеюсь, что ничего не сломается. Я видел слишком много проектов VB6, подобных тому, который вы описали, и попытки реорганизовать / переписать / повторить их в C # /. NET ужасно терпят неудачу, часто с людьми, ответственными за попытку увольнения.

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

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

Некоторые хорошие ответы уже здесь, я хотел бы добавить одну вещь. Вместо того, чтобы пытаться все переписать, возможно, у вас будет возможность портировать хотя бы некоторые из этих модулей, в основном 1: 1, на VB.NET (конечно, вы должны быть очень осторожны при этом)? По моему опыту, такое портирование может быть выполнено с ~ 5-10 раз меньшими усилиями, чем попытка восстановить всю существующую функциональность с нуля. И после того, как вы перенесли его, то вы можете начать рефакторинг - все эти инструментами , доступными в .NET мире, как хороший инструмент модульного тестирования, автоматические инструменты рефакторинга, реальный объектно - ориентированное программирование и т.д.

Я был в подобной ситуации, когда нам пришлось перенести старую 16-битную программу C ++ (150k LOC) в 32-битный мир, где исходная используемая среда графического интерфейса больше не была доступна. Нам потребовалось некоторое время, чтобы понять, что переписывание было нереальным, но после того, как мы решили перенести эту штуку в мир .NET, используя C ++, C ++ / CLI и C #, нам потребовалось всего около 9 месяцев, чтобы это произошло (примерно с 1 разработчиком полный рабочий день работаю над этим проектом). И у нас не было модульных тестов для части GUI, все тестирование этих частей выполнялось вручную.

Хотя в нем много внимания уделяется модульному тестированию вашего приложения, которое, хотя и очень важно сделать, но в VB6 сделать это довольно сложно, Стивен Макконнелл написал отличную книгу о том, как справиться с таким проектом.

Посмотрите на это:

Стивен МакКоннелл: Эффективная работа с устаревшим кодом, второе издание. Microsoft Press, июнь 2004 г.

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