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

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

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

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

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

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

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

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

Мені, з іншого боку, зараз відомо, що я є дупою для вказування на проблеми із скоєним кодом.

Я не думаю, що мої стандарти занадто високі.

Мій контрольний список на даний момент:

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

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

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

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

Приклад коду Огляд

Гей Джо,

У мене є запитання щодо ваших змін у класі "Бібліотека \ ACME \ ExtractOrderMail".

Я не розумів, чому ви позначили "TempFilesToDelete" статичним? На даний момент другий дзвінок на "GetMails" буде кидати виняток, оскільки ви додаєте до нього Файли, але ніколи не видаляєте їх після видалення. Я знаю, що функція просто викликається один раз на запуск, але в майбутньому це може змінитися. Чи можете ви просто зробити його змінною екземпляра, тоді ми могли б мати кілька об'єктів паралельно.

... (Деякі інші моменти, які не працюють)

Незначні бали:

• Чому "GetErrorMailBody" приймає виняток як параметр? Я щось пропустив? Ви не викидаєте винятку, ви просто передаєте його разом і дзвоните "ToString". Чому так?
• SaveAndSend Не є хорошою назвою методу. Цей метод надсилає повідомлення про помилки, якщо обробка пошти пішла не так. Чи можете ви перейменувати його на "SendErrorMail" чи щось подібне?
• Будь ласка, не коментуйте старий код, видаліть його прямо. У нас це все ще є в підривній роботі.

Як знайти позитивні речі в огляді коду?

Після серйозних проблем з якістю в останній рік моя компанія нещодавно представила огляди коду.

Чудово, у вас є реальна можливість створити цінність для вашої фірми.

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

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

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

Мені, з іншого боку, зараз відомо, що я є дупою для вказування на проблеми із скоєним кодом.

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

Критикуйте код, а не автора

Ви наводите приклад:

У мене є запитання щодо ваших змін

Не використовуйте заміни слів "ти" і "ваш", скажімо, "".

Я щось пропустив? [...] Чому так?

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

Можливо, ви приховуєте власне его за чужі кошти. Тримайте це лише факти.

Піднімайте планку, даючи позитивні відгуки

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

Як знайти позитивні речі в огляді коду?

є хорошим, і варто звернутися до нього.

Ви можете вказати, де код відповідає ідеалам практик кодування вищого рівня.

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

Найкращі мовні практики

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

• Чи відповідає він власним стандартам керівництва мовними стилями?
• Чи відповідає вона найавторитетнішому посібнику зі стилю для мови (який, мабуть, суворіший, ніж внутрішній - і, таким чином, все ще відповідає внутрішньому стилю)?

Найкращі загальні практики

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

Шукати:

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

Функціональне програмування

Якщо мова є функціональною або підтримує функціональну парадигму, шукайте наступні ідеали:

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

Об'єктно-орієнтоване програмування (ООП)

Якщо мова підтримує OOP, ви можете похвалити відповідне використання цих функцій:

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

в рамках OOP також є принципи SOLID (можливо, деякі надмірності функцій OOP):

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

Принципи програмування Unix :

Принципи Unix - це модульність, чіткість, композиція, відокремленість, простота, парситизм, прозорість, стійкість, представництво, найменше здивування, тиша, ремонт, економічність, покоління, оптимізація, різноманітність та розширюваність.

Загалом ці принципи можна застосовувати в багатьох парадигмах.

Ваші критерії

Вони є занадто банальними - я б поблажував, якби за це похвалили:

• Код складеться.
• Існує принаймні один спосіб роботи коду.
• Код буде працювати в більшості звичайних випадків.

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

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

Списання правил для проходження перевірки коду?

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

Єдине правило, яке я можу придумати для відхилення коду, - це ніщо не настільки кричуще, що я б його не випускав із виробництва. Дійсно погана назва - це те, що я хотів би утриматись поза виробництвом, але ви не можете зробити це правилом.

Висновок

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

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

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

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

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

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

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

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

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

Єдиний спосіб уникнути цього - записати правила проходження огляду коду.

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

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

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

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

На мою думку, найкраща практика - завжди орієнтуватися на код і ніколи на автора.

Це огляд коду , а не огляд розробника , тому:

• "Цикл циклу може ніколи не закінчитися", а не "Ваш цикл може ніколи не закінчитися"
• "Тестовий випадок потрібен для сценарію X", а не "Ви не написали тест, щоб охопити цей сценарій"

Також дуже важливо застосовувати те саме правило, розмовляючи про огляд з іншими:

• "Енн, що ти думаєш про цей код?", А не "Енн, що ти думаєш про код Джона?"

Перегляд коду - не час для огляду ефективності - його слід робити окремо.

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

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

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

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

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

З цим робочим процесом огляди коду стають набагато більш модульними та менш згуртованими. Рядок із огляду коду може просто сказати:

Приємний підхід, втілюючи це в спеціальну функцію!

Або може сказати:

Ця назва об'єкта насправді не відповідає призначенню об'єкта; можливо, ми могли б замість цього використати ім’я типу "XYZ"?

Або якщо з секцією є великі проблеми, я можу написати:

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

(Приклад: Функція ABC насправді робить тут три речі: лежачи на футі, забороняючи boz і обробляючи zorf. Це все можуть бути окремими функціями.)

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

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

Навіть якщо запит на злиття - це повний сніданок собаки, окремі коментарі можуть бути простими. Їх буде просто більше. Тоді короткий коментар може сказати:

Вибачте, але цей код насправді не придихається. Існує дуже багато кращих випадків (детально описаних в окремих коментарях), які будуть розглядатися неправильно і даватимуть поганий досвід користувачеві або навіть пошкодження даних в одному випадку. (Див. Коментар до комісії 438a95fb734.) Навіть деякі випадки звичайного використання призводять до вкрай поганої продуктивності програми (специфіки, зазначені в окремих коментарях до diff для somefile.c).

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

Я закриваю запит на об'єднання, очікуючи повного переписування.

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

Я дуже здивований, що ніхто не взяв цього, але в огляді зразка є щось не так.

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

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

Ось приклад переформулювання із вмістом, взятим з вашого огляду:

• Перш ніж ми вносимо зміни до класу Бібліотека \ ACME \ ExtractOrderMail, нам потрібно виправити кілька проблем.
• Якщо я щось не пропустив, "TempFilesToDelete" не повинен стати статичним.
• Надалі ми можемо викликати функцію не один раз на пробіг, саме тому нам це потрібно (що тут потрібно зробити).
• Мені потрібно зрозуміти, чому "GetErrorMailBody" приймає виключення як параметр. (і я тут прикордонний, тому що до цього часу ви вже повинні мати висновок )
• SaveAndSend слід перейменувати, щоб краще відповідати його поведінці, як, наприклад, на "SendErrorMail"
• Коментований код слід видалити з метою читабельності. Ми використовуємо підрив для можливих відкатів.

Якщо ви сформулюєте такий огляд, незалежно від того, наскільки читач вас ненавидить особисто, все, що він може побачити тут, - це примітки про вдосконалення, які хтось повинен продовжити. Хто? Коли ? Всім все одно. Що ? Чому? ЩО ти повинен сказати.

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

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

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

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

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

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

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

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

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

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

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

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

Ще одна річ; може бути захисне повітря, тому що вони відчувають, що вони не мають думки. Чому б не дозволити їм переглядати код один одного? Задайте їм конкретні запитання та спробуйте залучити їх. Це не повинно бути ти проти них; це має бути зусилля команди.

1. Що ви змінили б у цьому коді, якби мали час?
2. Як би ви покращили цю область кодової бази?

Запитайте це зараз, і запитайте це через півроку. Тут є досвід навчання.

Головний момент - не хваліть коду, якщо це не гарантовано, але визнайте зусилля та обов'язково визнайте вдосконалення. Спробуйте зробити огляди командними вправами замість змагальних.

Якість без напруги

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

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

Проблеми зверху вниз ваших організацій

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

Навіщо запитати нас, що вам потрібно зробити, щоб ваша команда була щасливою? Ви розглядали питання про свою команду?

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

Побудова культури якості

Культуру якості потрібно виховувати, щоб рости знизу вгору.

Нехай ваш начальник знає, що ви стурбовані якістю, не поліпшується досить швидко, і ви хочете спробувати скористатись порадами Harvard Business Review .

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

Скажіть щось на кшталт: «Як ви знаєте, ми [колеги] мали завдання забезпечити якість коду, щоб не допустити подібних виробничих проблем, яких ми зазнали останнім часом. Я особисто не думаю, що я вирішив цю проблему. Я думаю, що моя найбільша помилка на початку не була залучення всіх вас більше. [колега] і я все ще відповідальний перед керівництвом за якість коду, але, рухаючись вперед, ми всі разом намагаємося зробити якість. "

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

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

Колективні огляди кодексу

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

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

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

Якість - подорож

Ще одне, що потрібно зробити, - це викреслити будь-яке уявлення про те, що огляд коду - це щось із пропуску / відмови. Кожен повинен розраховувати внести деякі зміни після огляду коду. (І твоя робота - забезпечити їх.)

Але якщо це не працює ...

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

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

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

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

Так само "я би зробив це по-іншому ..." також конфронтаційний, тому що безпосередня думка розробника матиме: " Ну я це зробив так ... У вас проблема з цим? " І знову це конфронтація, ніж це потрібно і відвертає дискусію від вдосконалення коду.

Приклад:

Замість того, щоб запитувати "Чому ви вирішили не використовувати константну змінну для цього значення?", Просто констатуйте "Це жорстко закодоване значення слід замінити на константу XYZу файлі Constants.h". Задаючи питання, це означає, що розробник активно вирішив не використовувати вже визначена константа, але цілком можливо, що вони навіть не знали, що вона існує. Маючи достатньо велику базу коду, кожен розробник не знає багатьох речей. Це просто хороша можливість навчання для цього розробника ознайомитися з константами проекту.

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

Добре:

• "Ім'я цієї змінної потрібно змінити, щоб відповідати нашому стандарту кодування."

• "В цьому імені функції 'b' потрібно використовувати великі літери, щоб бути PascalCase."

• "Код цієї функції не відведений належним чином."

• "Цей код є дублікатом коду, який можна знайти ABC::XYZ(), і він повинен використовувати цю функцію замість цього."

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

• "Цю функцію потрібно відновити, щоб відповідати нашим стандартам складності n-шляху."

Погано:

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

• " Можливо, було б краще використовувати пробний ресурс, щоб правильно закрити речі в цій функції"

• " Можливо, хочеться ще раз поглянути на всі умови цієї функції. Складність N-шляху перевищує максимально допустиму складність нашого стандарту."

• "Чому відступи тут 2 проміжки замість 4 стандартного?"

• "Чому ви написали функцію, яка порушує наш стандарт складності n-шляху?"

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

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

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

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

"Чому метод повинен мати розумну назву, я знаю, що він робить?" це щось, що мені здається особливо тривожним. Він знає, що це робить, або, принаймні, так говорить, але я цього не роблю. Будь-який метод не повинен мати просто розумне ім'я, він повинен мати ім'я, яке дає зрозуміти читачеві коду відразу, що він робить. Можливо, ви захочете зайти на веб-сайт Apple і подивитися відео WWDC про зміни від Swift 2 до Swift 3 - величезна кількість змін, внесених просто для того, щоб зробити все читабельніше. Можливо, подібне відео може переконати ваших розробників у тому, що розробники, які набагато розумніші за них, вважають назви інтуїтивних методів дуже важливими.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Технічні керівники повинні зібратися поза сеансом огляду та викласти Посібник з кодування / Контрольний перегляд коду, і його потрібно дотримуватися та посилатись під час огляду. Це має бути живим документом, який можна оновлювати та удосконалювати в міру розвитку процесу. Ці зустрічі Tech Lead також мають відбуватися, коли обговорення "Шлях, який ми завжди робили", порівняно з "Нові та вдосконалені способи вчинити справи", не переглядаючи розробника, відчуваючи, що незгода є результатом їх коду. Після того, як початкова інструкція була більш-менш виправлена, ще один спосіб позитивно підкріпити розробників - це попросити їх відгуків, а потім реально вжити заходів щодо цього і розвиваючи процес як команда, це робить чудеса, щоб наблизити їх до швидкості, щоб почати перегляд коду на бортах, щоб ви не зациклювались робити огляди, поки теж не вийдете на пенсію.

Приміщення ...

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

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

Комп'ютерні повідомлення про помилки рідко ставляться під сумнів і ніколи не приймаються як особисте загроза.

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

Висновки ...

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

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

Приклад коду Відгук відгуків ...

Перепишіть даний приклад, що включає ці методи:

• Тема:

  • Бібліотека \ ACME \ ExtractOrderMail клас.

• Випуск принципу ...

  • TempFilesToDelete є статичним
    • Подальші дзвінки на GetMails кидають виняток, оскільки до нього додаються файли, але після видалення ніколи не видаляються. Хоча зараз лише один заклик, ефективність може бути покращена в майбутньому за допомогою певного паралелізму.
    • TempFilesToDelete як змінна інстанція дозволить паралельно використовувати кілька об'єктів.
• Вторинні питання ...
  • У GetErrorMailBody є параметр винятку
    • Оскільки він не викидає виключення, а просто передає це ToString, чи потрібно?
  • Ім'я SaveAndSend
    • Електронна пошта може або не може використовуватися для повідомлення про це в майбутньому, і цей код містить загальну логіку зберігання стійкої копії та повідомлення про будь-які помилки. Більш загальна назва дозволила б передбачити такі очікувані зміни без зміни залежних методів. Одна з можливостей - StoreAndReport.
  • Коментуючи старий код
    • Залишення коментованого рядка та позначення OBSOLETE може бути дуже корисним при налагодженні, але "стіна коментарів" також може затьмарити помилки в сусідньому коді. У нас це все ще є в Subversion. Можливо, просто коментар, який саме стосується Subversion?

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

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

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

• Це досить некрасиво, але, мабуть, воно відповідає всім нашим іншим неприємним кодам. Очистимо це пізніше (в патчі, в ідеалі, без функціональних змін).

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

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

В ідеалі план (про те, як можна протестувати виправлення, або що робити рефактор і коли) слід обговорити до того, як робота буде виконана, щоб вони не доклали чимало зусиль, перш ніж з’ясувати, що у вас є проблема.

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

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

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

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

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

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

[1] Це не вирішено лише тому, що люди сказали «добре» або перестали з цим боротися. Ніхто не хоче бути хлопцем, який скаже, що X просто не практично для наших {інтелект, досвід, сила людини, терміни і т.д.}, але це не означає, коли мова йде про якийсь конкретний екземпляр виконання X ...

Огляди коду повинні бути взаємними. Усі критикували всіх. Нехай девіз: «Не злівайся, нехай навіть». Всі роблять помилки, і як тільки люди сказали на гарячому кадрі, як виправити свій код, вони зрозуміють, що це просто нормальна процедура, а не напад на них.

Бачити код інших людей є навчальним. Розуміння коду до моменту, коли можна вказати на його слабке місце та пояснити, що слабкість може багато чого навчити !

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