Це гарна ідея запланувати регулярний час для очищення коду? [зачинено]

Я керую невеликою командою розробників. Кожен так часто ми вирішуємо, що ми збираємось витратити день чи два, щоб очистити наш код.

Було б гарною ідеєю запланувати регулярний час, скажімо, 1 тиждень кожні 2 місяці, щоб просто очистити нашу кодову базу?

Немає.

Виправте це, працюючи над ним:

• Якщо ви будете чекати, щоб переробити фрагмент, над яким ви працюєте, ви забудете про нього багато, і вам доведеться витратити час, щоб ознайомитися з ним знову.
• Ви не закінчите "позолоченням" коду, який не використовується, оскільки змінилися вимоги

Моя особиста думка: Це абсолютно потрібно для 90% проектів.

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

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

Зазвичай існує два типи питань, що створюються таким чином:

• Невеликі, які легко виправити, але можуть бути системними, наприклад, неправильно названі параметри, неповне поводження з помилками тощо. Вони, як правило, матимуть невеликий вплив поза блоком коду, де вони з’являються. Найкращий спосіб впоратися з ними - це огляд коду та перевірка коду під час його написання / модифікації. Як заявили інші, не потрібно відкладати спеціальний цикл рефактора для виправлення цих помилок.
• Великі, які можуть виникнути з-за неповних специфікацій або поганих дизайнерських рішень на початку, або два розробника / команди, що створюють два різних рішення однієї проблеми. Зазвичай їх набагато складніше виправити і вимагають узгоджених зусиль для виправлення. В результаті вони зазвичай відкладаються до тих пір, поки не стануть вічною неприємністю. Для таких питань потрібно вирішити певний проміжок часу.

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

У мене розробники прибирають свій код до реєстрації (Subversion) або об'єднання з основною галуззю розробки (Git).

У мене вони роблять наступне:

• Видаліть непотрібні коментарі
• Слідкуйте за тим, щоб їх методи, аргументи та змінні були названі належним чином
• Переконайтесь, що є структура для їхніх класів, а елементи інкапсульовані як слід
• Рефактор для поліпшення читабельності та зменшення будь-яких запахів коду

Що стосується більш великих проектів, то кодекс переглядається офіційно перед об'єднанням із галузі розвитку до основної галузі.

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

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

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

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

1 тиждень кожні 2 місяці, безумовно, недостатньо часто. Це говорить про більшість інших відповідей, які відповіли «Ні» на ваше запитання. Суть більшості цих відповідей полягає в тому, що якщо ви будете чекати занадто довго, ви більше не будете зв’язуватися з кодом, і це зазвичай займає набагато більше часу, щоб виправити / очистити / рефактор.

Це не так зрозуміло, якщо ви мали на увазі додаткову вправу чистого коду раз у раз. У цьому сенсі так. Те, що ми коли-небудь дотримуємось, завжди відбувається деградація.

Не слід використовувати це як привід не робити правильних дій [Застосування принципів SOLID, відповідних тестових одиниць, перевірок тощо].

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

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

• дбайливі однолітки CRing
• написання одиничних тестів разом із самим кодом
• прийняття правил кодування
• за допомогою автоматичних форматів та лінерів (але YMMV)
• тощо.

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

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

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

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

Кожен предмет може здатися не великим, але так само, як і весь борг, він відображається.

Ідеальна відповідь «Ні», оскільки ви вживаєте заходів, необхідних для уникнення необхідності (прибирайте, як ви йдете разом з кількох випадків, які вже були зазначені).

Це може бути метою, врешті-решт, але у вас може бути команда, яка далеко не реалізує це на практиці.

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

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

Врешті-решт, вам не потрібно було встановлювати час.

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

Ні, ви повинні робити це під час кодування. Це називається рефакторинг, якщо ви використовуєте TDD. Проблема, коли ви чекаєте місяць-два, щоб виправити та очистити код, полягає в тому, що ви можете змінити поведінку коду, оскільки ви не пам’ятаєте кожного фрагмента коду.

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