Я хотів би задати вам кілька питань щодо брудного коду. Є деякі початківці, які кодували середній проект. Код - це дуже величезна кулька грязі. Вони не передові програмісти. Вони просто знають, як трохи використовувати клавіатуру щодо Java. Вони щойно написали код з 12 000 рядків у своєму головному класі, хоча 6 000 рядків належить саме NetBeans.

Моя робота - проаналізувати код і запропонувати хороший спосіб зберегти код. Моя ідея - зняти проект і почати новий з методології OOP. Нещодавно я зібрав деякі замітки та ідеї щодо цієї проблеми, з цього сайту та деяких інших.

Тепер у мене є наступні питання:

1. Чи слід ремонтувати код і змінити його на ООП? Зараз ми налагоджуємо це.
2. У коді немає коментарів, жодної документації, конкретного стилю програмування тощо. Міняти це дійсно дорого і забирає багато часу. Що ми можемо зробити з цього приводу?
3. Як я можу навчити їх дотримуватися всіх правил (коментування, OOP, хороша якість коду тощо)?
4. Код помилковий і схильний до помилок. Що ми можемо зробити? Тестування? Ми майже пишемо два-три документи формату А4 для виправлення, але це здається нескінченним.

Я повинен сказати, що я з ними новачок. Я думаю, що я також порушив правила щодо того, що люди занадто пізно додають людей до проекту. Ти думаєш, я повинен їх залишити?

Крок 0: Резервне копіювання в SCM

Тому що, як натякав JBRWilkinson у коментарях, контроль версій - це ваша перша лінія захисту від (незворотної) катастрофи.

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

Крок 1: Перевірте спочатку

Потім почніть з написання тестів :

• для того, що працює,
• і за те, що не вдається.

Незалежно від того, що ви вирішили зробити, ви охоплені. Тепер ви можете:

• починати з нуля і переписувати ,
• або виправити .

Моя порада полягала б у тому, щоб почати загальну архітектуру з нуля , але витягнути з безладу ті частини, які перевіряють контрольно-пропускні пункти, та відновити їх, як вважаєте за потрібне.

Крок 2: Перевірка та моніторинг

Створіть систему безперервної інтеграції (щоб доповнити крок 0 та крок 1 ) та систему безперервної перевірки (підготуватися до кроку 4 ).

Крок 3: Встаньте на плечі велетнів

(як завжди слід ...)

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

Крок 4: Очистити

Такого роду, само собою зрозуміло, але замість того, щоб скидатися, хоча сам код, ви можете просто запустити лінійки / статичні аналізатори та інші інструменти на розбитій кодовій базі, щоб знайти помилки в дизайні та реалізації.

Тоді ви також можете запустити форматформа коду, що вже трохи допоможе в господарстві.

Крок 5: Огляд

Легко представити крихітних помилок шляхом рефакторингу чи очищення речей. Це вимагає лише неправильного вибору та швидкого натискання клавіші, і ви можете видалити щось досить важливе, не розуміючи спочатку. І іноді ефект з’явиться лише через місяці. Звичайно, описані вище кроки допомагають вам уникнути цього (особливо, застосувавши сильний тестовий джгут), але ви ніколи не знаєте, що може і проскочить. Тому переконайтесь, що ваші реконструкції переглянуті хоча б ще однією виділеною парою кульок для очей (і бажано більше).

Крок 6: Підтвердження майбутнього процесу розвитку

Візьміть усе вищесказане і зробіть його невід'ємною частиною вашого звичного процесу розробки, якщо він ще не є. Не дозволяйте цього повторюватися на вашому годиннику, і працюйте разом зі своєю командою, щоб впроваджувати гарантії у вашому процесі та застосовувати це (якщо це навіть можливо) у своїй політиці. Зробіть чистий код пріоритетним.

Але справді, тест . Дуже багато .

Особисто я б не запускав цей проект, доки не маю під рукою копію програми « Ефективно працювати із застарілим кодом» . Серйозно, це було написано саме для такого типу речей. Тут повно стратегій поводження з хитромудрим кодом, і йдеться про набагато більше деталей, ніж я можу дати вам тут.

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

Якщо програмне забезпечення насправді не працює (дуже велика кількість помилок, незрозумілі вимоги тощо), то краще переписати його з нуля. Те саме, якщо він зовсім невеликий.

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

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

Насправді я бачив, як складна процедура двічі переписується з нуля і все ще не працює, як очікувалося.

Я б переписав це повністю. Іноді неможливо відремонтувати такий код. Інший варіант - зробити так, щоб він працював, не додаючи нових функцій. Щоб навчити команду писати хороший код (добре розроблений, задокументований, з тестами), дозвольте їм виправити код, який ви маєте зараз. Нехай усі виправляють помилки / переглядають код інших розробників, а не її / його частину. Після деяких спроб вони зрозуміють, що переглянути / виправити такі коди майже неможливо.

Додавання людей до пізніх проектів допомагає дуже рідко. Зазвичай це порушує терміни. Вам слід зробити все можливе, щоб успішно закінчити проект, а потім подумати про відхід.

Моя порада буде не бракувати весь код повністю. Це питання щоденного життя, з яким стикається кожна команда розвитку. Атакуйте по одній частині коду за один раз. Зафіксуйте, очистіть, документуйте. А потім перейдіть до іншої частини. Головне, завжди тримати під рукою якийсь змінний код. Переписання всього коду з нуля потребує часу, витраченого до цього часу, і не буде жодних гарантій, що він буде приємнішим за поточний.
Але тоді також люди повинні уникати написання коду таким чином. Витратьте ще трохи часу на огляди коду. Адаптується до якогось єдиного стилю кодування. Спершу обговоріть дизайн, а потім напишіть код. Такі прості речі внесуть великі зміни.

Приємний блог, який розповідає, чому Netscape розпущений

Якщо він працює, переробляйте його. Є інструменти, які допоможуть вам це зробити. Якщо це не працює, скористайтеся командою вдосконалення магічного коду, тобто deltreeв Windows Resp. rm -rfна Linux.

Чи слід ремонтувати код і змінити його на ООП? Зараз ми налагоджуємо це. [... містить помилки, відсутні документи ...]

Я там був, у вас є мої симпатії. Я навіть написав статтю з цього приводу, яка може допомогти вам отримати певну перспективу. Але коротше:

Якщо код містить багато дублювання, слід переписати. Якщо немає чіткої структури (немає чітких інтерфейсів, спагетті), рефакторинг не вдасться, і вам, ймовірно, слід переписати.

Як я можу навчити їх виконувати всі правила?

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

Моя пропозиція - це комбінація відповідей @ duros & @Manoj R.

Почніть з нуля, маючи на увазі, щоб створити хороший код / ​​OOP / коментується / тощо цього разу, перегляньте / скопіюйте та вставте зі свого старого коду. Коли ви зустрінетесь із поганими частинами свого старого коду, перепишіть / перефактуйте їх.

Якщо ваші розробники недостатньо навчені, я вважаю, що добре відправити їх на курси. Це важливо для регулярної перепідготовки кадрів у галузі ІТ, що швидко змінюється