Чи потрібно наполягати на тому, що ми виконуємо перевірку коду, перш ніж об'єднатись назад до магістралі?

Запрошена повторна публікація від StackOverflow:

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

Моя проблема полягає в тому, що я вже протягом року наполягаю на перегляді коду, перш ніж об'єднатися назад до магістралі. Всі погодилися з цим, але все-таки переглянуто лише мій код. Повертаючись із тривалої відпустки, я повертаюся до багажника з коментарями коду, оскільки "це некрасиве рішення - якнайшвидше видаліть" та "швидке виправлення". Що також нового, це те, що хлопець призначив відповідальність за інструмент. (Роль, яка вперше була запропонована мені, але я відмовився через причину, що не стосується роботи.) І він вважає, що це нормальний спосіб роботи: Оскільки у нас є такий обмежений час на розвиток, ми повинні скоротити такі кути.

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

Чи потрібно наполягати на тому, щоб ми виконували перевірку коду, перш ніж об'єднатися назад до багажника, чи я просто сука якості коду?

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

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

Читаючи це:

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

Я думаю, що ваша проблема більша, ніж просто огляди коду. Здається, вам не вистачає декількох вказівок та / або вони не реалізовані. Відсутність / кілька одиничних тестів може бути поганою ідеєю, але залежить від конкретного випадку. Однак breaking encapsulation, writing huge classes, ...дійсно зробіть схильний до помилок код так, що його слід напевно виправити.

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

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

Те, що я намагаюся сказати, - вам потрібно вибирати свої битви. Це нормально, щоб програти битву за якийсь незначний клас корисності, щоб виграти війну доставки (або ВІДЗНАЧНО ВАЖЛИВУ війну підсистеми, з цього питання).

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

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

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

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