Як боротися з відсутністю оглядів коду в моєму новому місці, коли я приїхав з цієї практики?

Команда моєї нової компанії не має процесу перегляду коду.

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

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

• Як я можу показати, що огляд коду - це не витрата часу, а економія часу?
• Чи можна пропустити огляд коду, якщо у вас є одиничні тести?

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

Але чому?

Основна роль експертної оцінки - не виловлювати помилок.

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

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

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

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

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

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

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

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

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

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

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

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

Я взяв з деяких випадкових слайдів, які я знайшов , але важкі дані походять з Кодексу Стіва Макконнелла Повна книга:

Чи корисні відгуки про код?

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

Джефф Етвуд з кодування жахів за адресою http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html

---

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

Стів МакКоннелл, кодове повне 2-е видання, стор. 485

Цей показник 60% походить з документа IEEE від Shull et al 2002, Що ми дізналися про боротьбу з дефектами, який містить розділ під назвою:

"Експертна оцінка вловлює 60% дефектів"

Відмова: Ця відповідь - це мій особистий досвід :)

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

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

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

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

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

Переконайтеся, що ваш код добре написаний і перевірений перед оглядом.

Коли я був керівником команди, я раніше робив огляди коду нових співробітників, поки (через деякий час) я не перестану знаходити помилки чи що-небудь інше, щоб критикувати їхній код, і в цей момент я перестану робити перевірки коду з ними; це станеться, коли:

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

Огляди коду мають кілька цілей:

• Пошук дефектів у коді
• Передача знань між членами команди

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

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

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

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

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

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

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

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

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

В основному, щоб отримати те, що ви хочете тут, вам потрібна зміна культури на робочому місці - і це ніколи не просто і легко. Не забувайте, що навіть якщо ваше робоче місце на 100% переконане, що огляди коду є чудовими, і вони хочуть їх прийняти, фактично перехід на новий спосіб роботи все одно вимагатиме значних вкладень часу, енергії та продуктивності. Ця інвестиція повинна окупитися - але для інвестицій потрібно мати викуп, а не лише для окупності. Дивіться відео Роя Ошерова "Тестування блоку та TDD - як зробити це сталося" - проблеми прийняття оглядів коду дуже схожі з проблемами прийняття одиничного тестування.

Тим часом зробіть все можливе, щоб отримати стільки, скільки зможете:

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

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

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

Дотримуйтесь рекомендацій щодо стилю (або просто стилю), якими користуються всі інші. Скористайтеся своїм досвідом, щоб вирішити, що потрібно коментувати, які імена про іменування використовувати тощо.

Потім протестуйте все, перш ніж перевірити це. Найголовніше - це правильно працювати.

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