Я хотел бы задать вам несколько вопросов о грязном коде. Есть несколько начинающих, которые написали код для среднего проекта. Код очень большой шарик грязи. Они не продвинутые программисты. Они просто знают, как использовать клавиатуру немного о Java. Они только что написали код с 12 000 строк в своем основном классе, хотя 6 000 строк принадлежат самой NetBeans.

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

Теперь у меня есть следующие вопросы:

1. Должны ли мы исправить код и изменить его на ООП? Мы сейчас отлаживаем это.
2. В коде нет комментариев, нет документации, нет определенного стиля программирования и так далее. Менять это действительно дорого и отнимает много времени. Что мы можем сделать по этому поводу?
3. Как я могу научить их следовать всем правилам (комментирование, ООП, хорошее качество кода и т. Д.)?
4. Код ошибочен и подвержен ошибкам. Что мы можем сделать? Тестирование? Мы почти пишем две или три бумаги формата А4 для исправления, но это кажется бесконечным.

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

Шаг 0: Резервное копирование в SCM

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

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

Шаг 1: сначала протестируйте

Затем начните с написания тестов :

• для чего работает,
• и за то, что не удается.

Неважно, что вы решили сделать, вы покрыты. Теперь вы можете:

• начать с нуля и переписать ,
• или исправить это.

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

Шаг 2. Проверка и мониторинг

Настройте систему непрерывной интеграции (для дополнения шага 0 и шага 1 ) И систему непрерывной проверки (чтобы подготовиться к шагу 4 ).

Шаг 3: Встань на плечи великанов

(как вы всегда должны ...)

• Рефакторинг к шаблонам
• Рефакторинг: улучшить дизайн существующего кода .
• Эффективная работа с устаревшим кодом (в соответствии с рекомендациями Джейсона Бейкера )
• Рефакторинг

Шаг 4: Очистить

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

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

Шаг 5: Обзор

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

Шаг 6: Будущее Доказательство вашего процесса разработки

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

Но на самом деле, тест . Много .

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

Я был там несколько раз. Мое правило таково: если программное обеспечение не является тривиальным (более 1 недели работы для имеющегося у вас ресурса) и работает, сохраните его и приступайте к инкрементному рефакторингу.

Если программное обеспечение на самом деле не работает (очень большое количество ошибок, неясные требования и т. Д.), То лучше переписать его с нуля. То же самое, если он довольно маленький.

Смысл рефакторинга (как в книге Фаулера и в книге Кериевского http://www.industriallogic.com/xp/refactoring/ ) заключается в том, что она поддерживает работу системы, возможно, рефакторинг займет двойное время, но риски равны нулю.

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

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

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

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

Мой совет будет не удалять весь код целиком. Это проблема повседневной жизни, с которой сталкивается каждая команда разработчиков. Атакуйте одну часть кода за раз. Исправьте это, очистите это, зарегистрируйте это. А затем перейти к другой части. Главное всегда иметь под рукой какой-нибудь отправляемый код. Перезапись всего кода с нуля займет время, которое было потрачено до сих пор, и не будет никакой гарантии, что он будет лучше текущего.
Но тогда люди также должны избегать написания кода таким образом. Потратьте еще немного времени в обзорах кода. Приспособьтесь к некоторому унифицированному стилю кодирования. Сначала обсудите дизайн, а затем напишите код. Такие простые вещи внесут большие изменения.

Хороший Блог, рассказывающий, почему Netscape потерял

Если это работает, рефакторинг это. Есть инструменты, которые помогут вам сделать это. Если это не работает, используйте команду улучшения магического кода, то есть deltreeв Windows, соответственно. rm -rfв линуксе

Должны ли мы исправить код и изменить его на ООП? Мы сейчас отлаживаем это. [... содержит ошибки, нет документации ...]

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

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

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

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

Мое предложение - это сочетание ответов @ duros & @Manoj R.

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

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