Скажімо, один працює в гіпотетичній компанії, яка має декількох розробників, які рідко працювали разом над проектами, і Boss не вірив, що огляд коду вартий часу і витрат.
Які різні аргументи можуть бути представлені в цьому сценарії, що відображатиме перевагу перегляду коду? Крім того, які тут є потенційні аргументи проти перегляду коду та як їх можна протидіяти?
Відповіді:
Якщо вам доведеться виправдовувати себе такими елементарними речами, у вас є більша проблема.
Ви експерт, ваша команда повинна вирішити, якими практиками ви користуєтесь. Можливо, ви повинні почати переконувати свого начальника в тому дуже важливому принципі.
Ваш начальник повинен вирішити, що робити, і що ще важливіше, чому це робити. Ви повинні подбати про те, як будувати його
(це не означає, що ви не можете підказати, що і навіщо, звичайно, робити у вашій компанії). Прекрасний начальник повинен заохочувати своїх працівників брати участь у стратегії підприємства)
Однак ось як я бачу огляди експертних кодів:
Оскільки програмування - це дуже інтенсивна інтелектуальна робота, одна людина не може забезпечити все ідеальним. Тому огляд коду гарантує, що:
Усі беруть пряму користь від цього:
Перегляд коду може отримати декількох розробників, знайомих з одним і тим же кодом. Це гарна річ. Що робити, якщо оригінальний автор вирішить кинути або ще гірше, з ним трапиться щось погане. Якщо перевірки коду проводяться регулярно, інші можуть швидко взяти на себе рішення.
Під час перегляду коду колеги, можливо, зможуть виявити потенційні помилки або проблеми з продуктивністю. Це зменшує якість забезпечення та розробки. Це може компенсувати додаткові витрати, пов'язані з переглядом коду.
Огляди коду сприяють обміну знаннями. Ровесники можуть розповісти про кращі способи чи альтернативні способи роботи. Я сам багато чому навчився від своїх однолітків через огляди коду.
Огляди коду допомагають посилити правила кодування, якими керується команда. Якщо у команди немає, це потрібно виправити. Код повинен писатися один раз і читати багато разів. Вказівки щодо кодування - це крок до читабельного коду. Код призначений для читання однолітками. Що краще, ніж перевірка коду для забезпечення читабельності?
Тут багато чудових відповідей. Я хотів би додати:
Коли вам доводиться пояснювати код комусь іншому, часто в процесі пояснення розробник може раптом зрозуміти, що він має помилку. Я бачив, як це знову і знову трапляється, що диявол зупиняється мертвим у своїх слідах і каже "о, чекай, це неправильно", перш ніж рецензент зрозумів річ досить добре, щоб побачити помилку.
Знання вашого коду інспектує хтось інший, дає вам більше стимулів використовувати стандарти кодування (полегшуючи технічне обслуговування) або використовувати менш "ковбойські" методи, які ніхто, крім вас самих (а іноді навіть і ви самі) ніколи не зрозуміє. Ви не хочете, щоб вас бентежило, коли ви показуєте свій код комусь іншому, тому ви в першу чергу краще справляєтеся з цим. Через фактор збентеження він залишає менше коду, коментованого таким чином: "Я не знаю, чому це працює, але з цим не псуюся". в кодовій базі.
Розробники, які потребують більш широкого нагляду або навчання, легко ідентифікуються. Так є і прямо некомпетентні. Чим раніше ви зможете знайти та вирішити проблеми з продуктивністю, тим краще буде команда в цілому і тим вище буде якість програми. Добре дізнатися цю інформацію, перш ніж взяти нового хлопця, якому потрібна підготовка, і призначити його в найважчій, найважливішій частині вашої заявки.
Іноді це просто питання виправлення помилкового сприйняття, яке врятує помилку в купі інших місць. Наприклад, ми нещодавно переглядали деякі SQL для складних звітів і виявили, що у кількох наших нових розробників було таке ж непорозуміння щодо того, де знайти конкретну інформацію в базі даних (правда, місце, яке вони вибрали, здавалося логічним, що є проблемою дизайну бази даних. також потрібно виправити), що було б критично важливим для правильного написання всіх звітів. Виявивши проблему та виправивши її в перших написаних ними звітах, вона врятувала ту ж помилку, що і в інших звітах. І вийшло щось старше (у той час, коли тут працювали не вікові) диви, настільки звикли, що вони не думали, що потрібно пояснювати.
Юніори можуть вчитися на більш досконалому коді, написаному старшими (які, як правило, краще розуміють відловлювання помилок і випадки крайового випадку), а старші можуть вчитися на нових методах, якими користуються юніори, до яких вони ще не піддавалися.
Іноді люди, які працюють над різними, але спорідненими частинами програми, розуміють, що вони йдуть у двох різних та взаємовиключних напрямках. Ой, зараз простіше виправити.
Не так-то просто прокрастися у важко зафіксовані значення, які з часом змінюватимуться лише для того, щоб справа тепер працювала. Це запобігає безлічі майбутніх помилок, таких як речі, які змінюються на початку кожного фінансового року.
Я іноді зациклювався на тому, як щось зробити, і навчився новій техніці, яка була саме тим, чого я хотів, переглянувши код інших речей.
Якщо ви знайомі з тим, як думають інші члени вашої команди (який огляд коду допоможе вам зрозуміти), то пізніше виправити проблеми буде простіше, тому що ви почнете з розуміння того, як Джо підійшов би до такого типу проблема.
Окрім обміну знаннями, про які згадували інші, знайдіть приклади помилок, які були б знайдені під час перегляду коду, і виміряйте, скільки часу потрібно було виправити - це включає час, витрачений на дослідження проблеми та випуск виправленої версії, а також фактичний час виправлення помилки.
Візьміть цю вартість, яка, ймовірно, потребуватиме мінімум двох днів, і порівняйте її з тим часом, який ви витратили б на перегляд коду та діючи на результати.
Це покаже вашому начальникові, що огляди коду варті витрат.
Огляди коду можуть:
Мінуси
Якщо це правда, то, як нам здається, ми завжди встигаємо робити речі два-три рази для одного і того ж замовника, але у нас ніколи не вистачає часу, щоб зробити це правильно з першого разу.
Якщо вам потрібно посилатися на документ, я б не дивився далі, ніж на оцінений "Кодекс повний". У ній у книзі описано, скільки помилок потрапляє в одиничних тестах та рецензуванні. Це вражає Одиничні тести, якщо пам'ять слугує мені правильно, виловлюють лише ~ 30% всіх помилок, тоді як офіційні експертизи оцінюють ~ 70%.
Візьміть цю інформацію, покажіть його в книзі і зверніться до його фінансової сторони. Це займає набагато довше і набагато дорожче, щоб дозволити помилок, ніж їх рано ловити.
Як щодо запуску демонстраційного проекту (проект на тиждень типу «міккі-миша»), який паралельно виконується двома командами, одна використовує огляд коду, інша - ні.
Наприкінці тижня оцінюйте якість роботи кожної команди, я впевнений, що рецензенти кодів вийдуть як краще.
Від Макконнелл в Construx The Business Case для Better Software Practices і Fruit Software Software Development в низько висить (LHF) адреса цього. З останнього "LHF, якому вищий менеджмент не буде протистояти", перераховує інспекції.
Представляючи його, зосередьтеся на більшій картині.
Перелічіть переваги (кращий код, менше помилок, менше перезаписів тощо) та відзначте перегляд коду як одну з методик, які ви б рекомендували.
Я б зробив це частиною більшого уявлення про те, як робити майстерність програмного забезпечення
Будьте готові зробити багато роботи над просуванням цих принципів.
Більше за все не сподівайтеся, що вмовляння - це "якась зустріч і закінчення".
Слід будувати справу з часом спокійно і послідовно. Коли вас найбільше дратують помилки, які були б усунені кращими методами, часто найгірший час зробити вашу справу, оскільки ви, швидше за все, надмірно емоційні та менш раціональні. Це може здатися дещо протиінтуїтивним, але це те, що я навчився за 30 років програмування. Очевидно ymmv.