Чи перегляд коду є хорошою практикою?

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

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

Які переваги від цього і чи є недоліки?

Огляди коду - чудова практика.

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

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

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

До додаткових переваг щодо оглядів коду (як це коментується в цьому питанні), включають:

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

Огляди коду є дуже корисним інструментом для навчання , особливо коли у вас є новий член команди. Ну, це також відомий як процес експертного огляду :)

Існують різні типи оглядів коду:

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

Є лише одна, associated disadvantageде офіційні огляди коду вимагають значних вкладень у підготовку до події огляду та час виконання.

Нижче наведено більше посилань (для більш глибоких читання занурень)

• MSDN - Огляд коду
• Знайдіть і виправте вразливості перед вашими заявними кораблями
• Посилання Wiki

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

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

Ми робимо огляд коду кожного фрагмента коду до його переміщення до QA. Кожен шматок. Він, як правило, включає лише рецензента коду та розробника. Він не переходить до якості, поки рецензент коду офіційно не передає його. Тож розробник повинен внести зміни. Ми знайшли та швидко виправили багато проблем, які QA, можливо, не було знайдено (вони знаходять і те, що ми також не бачимо в огляді коду). Крім того, це дозволяє зменшити кодування ковбоя та швидко визначити тих людей, які недостатньо добре працюють, щоб ми могли виправити їхні проблеми та навчитись або позбутися від них, перш ніж вони завдадуть шкоди нашій програмі. Час перегляду коду є частиною нашої оцінки часу при плануванні робіт, тому він зовсім не впливає на термін. Насправді це економить час у довгостроковій перспективі, оскільки чим раніше буде виявлена ​​проблема, тим легше її виправити.

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

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

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

Потрібно вирішити кілька питань:

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

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

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

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

Перегляд коду є чудовою практикою, особливо якщо розробники розробляються для обміну знаннями, а основні правила встановлюються заздалегідь, що пропозиції та зауваження мають бути КОНСТРУКТИВНИМИ, а не використовувати окремого розробника для цільової практики.

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

Якщо ви хочете продемонструвати, що розробники хорошої роботи роблять в управлінні, то "огляд коду" має інше значення, і він не повинен бути настільки детальним, як огляди коду, які робляться для інструктажу / покращення якості коду серед розробників. Цей вид презентації може бути корисним для демонстрації того, що роблять розробники, якщо презентація може бути вищого рівня та менш специфічною для коду, орієнтуючись на те, що розуміють менеджери (значення, рентабельність інвестицій тощо). Це може змусити менеджерів зрозуміти, що Джо додав вагому цінність компанії, будуючи X, що ми можемо показати, що економить Y-кількість часу, або Z доларів за замовлення і т. Д. Я думаю, що варто докласти зусиль, щоб показати цінність особи члени вашої команди. Однак пам’ятайте, що вам потрібно бути обережними, щоб не переповнити свою аудиторію жаргоном чи занадто великим рівнем деталізації.

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

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

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

Для нашої команди ми робимо, як згадував @ElYusubov, і використовуємо інструмент спеціально для Code Review - Crucible. Люди переглядають, коментують та виходять із коду. Щотижня ми сідаємо і переглядаємо цікаві та / або складні фрагменти коду.

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

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

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

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

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

У моїй компанії ми намагаємось переглянути якийсь код. Але занадто багато часу витрачається на «переслідування за кроликом» (створення можливостей).

Сьогодні багато інструментів перевірки стилю та базового синтаксису виявляються за допомогою інструментів (FXCop тощо).

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

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

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

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

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

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