Организация некомментированного, грязного кода?

22

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

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

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

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

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

Саливан
источник
Это нужно разделить на два или три вопроса, на данный момент они слишком широки.
Джон Хопкинс
2
Этот проект находится под контролем версий?
JBRWilkinson
2
Текущий код в производстве?
JeffO
Да, Джефф Это производство, проект управления для решения финансовых вопросов!
Саливан
Извините, JBR, они не слышали о такой вещи. Простое копирование копий-вставок по всему жесткому диску - это их методы для контроля версий.
Саливан

Ответы:

36

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 5: Обзор

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

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

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


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

haylem
источник
Отличное предложение - не имеет значения, какой урон вы нанесете, если у вас есть тесты, которые могут выявить проблемы. Конечно, мы все предполагаем, что у них уже есть контроль версий ..
JBRWilkinson
@JBRWilkinson: хороший момент на самом деле! Действительно, полностью предположил, что они сделали.
Хайлем
2
Сначала запустите контроль версий; лучше поздно, чем никогда.
JeffO
@ Джефф О: да, это уже то, что я добавил в ответ.
Хайлем
Переписано, чтобы сделать более понятным после правок. Оставленные атрибуции :)
хайлем
15

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

Джейсон Бейкер
источник
1
+1 за использование обширной внешней ссылки, которая говорит обо всем.
Хайлем
К сожалению, здесь люди не имеют представления о чтении книг. Только разработка проекта, который работает, это все, что им нужно. Я начал читать упомянутую вами книгу, и CODE COMPLETE 2 тоже. Позвольте мне сказать, что они прекрасно написаны.
Саливан
1
@Salivan - Возможно, у них просто не было никого, кто бы убедил их, что такие книги стоит читать. Если бы только был человек, который работал с ними, кто был заинтересован в чтении таких книг ...
Джейсон Бейкер
1
@Salivan - главное найти быстрый выигрыш или два. Сделайте что-то, что почти мгновенно окупится. Как и контроль версий, поэтому в следующий раз, когда кто-то скажет «как это произошло», вы можете посмотреть его. Затем приведите несколько советов по прочтению вашей копии WELC. Не просто бросить книгу в них.
2
@Salivan Вы можете читать книги для них и давать им информацию в качестве совета. Вы можете стать командным гуру.
MarkJ
8

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

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

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

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

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

Uberto
источник
Я также предложил бы написать модульные тесты для соответствующих методов, если это возможно. Они помогут четко определить, что код должен делать в первую очередь, что поможет процессу рефакторинга.
Майкл К
2
Само собой разумеется ... Я считаю, что TDD является необходимым условием для любого хорошего кода (он же новый).
Uberto
Писать с самого начала очень хорошая идея. Но для начала нужно иметь некоторые схемы работы. Но что вы будете делать, если вам придется анализировать код для извлечения отношений? Кроме того, размер проекта делает невозможным, или это заставит нас нанимать некоторых других программистов.
Саливан
Разработка через тестирование приветствуется!
Саливан
«Но что вы будете делать, если вам придется анализировать код для извлечения отношений?» -> если это так, значит, проект не крошечный и не сломанный. Ака, я начну делать рефакторинг по одной части за раз. Смотрите также метод Микадо. danielbrolund.wordpress.com/2009/03/28/…
Uberto
2

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

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

Duros
источник
Сколько будет стоить переписать его полностью, а не итеративно улучшить? Какой подход даст результаты быстрее?
JBRWilkinson
@JBRWilkinson Это зависит. Итеративный подход хорош, когда у вас есть рабочий код.
Duros
1
@duros, для неработающего кода, да. Этот код работает в производстве.
2

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

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

Маной Р
источник
2
Начиная новый проект, в то же время обновляя / отлаживая старую версию (и вы не можете избежать этого, поэтому не мечтайте об этом), вы пытаетесь стрелять по нескольким движущимся целям.
JeffO
«Атака одной части кода за раз» не сработало, Манджо. с глубокой скорбью, код содержит много ошибок. Это всегда превращается в что-то другое. Мы должны атаковать и уничтожить одну часть кода и затем создать ее. Я однажды предложил эту мысль менеджеру, но кодировщикам не нужно писать какие-либо новые коды.
Саливан
@Salivan ... нужно писать новые коды . Я уверен, что руководство говорит это. Но первое, что нужно сделать, когда вы находитесь в яме, это прекратить копать (не продолжайте делать те же ошибки). Позволить создавать больше в этих условиях - значит продолжать копать яму. Трудная часть состоит в том, как заставить руководство и кодеров понять проблемы.
SeraM
1

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

user281377
источник
2
Предложение "полностью стереть весь код" особенно бесполезно - есть ли у вас более конструктивный ответ?
JBRWilkinson
СМЕШНО. Я полностью согласен с вами, ammoQ!
Саливан
Дж. Б. Уилкинсон: Скорее всего, новый перезапуск лучше, чем пытаться заставить беспорядок работать и вычищать. Компания, в которой я работал, попробовала это, и год за годом они тратили много ресурсов и ни к чему не привели.
user281377
@ammoQ, вам нужен старый код, чтобы увидеть, что он на самом деле сделал, когда вы ошиблись.
1
Торбьерн: Мы говорим о коде, который не работает , верно? Анализ некомментированного, грязного кода, который не делает правильных вещей, говорит мне больше о психическом состоянии его создателей, чем что-либо еще.
user281377
1

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

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

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

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

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

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

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

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

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

Jiew Meng
источник