Чи є огляд коду суб'єктивним чи об'єктивним (оцінюється)?

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

Ми використовуємо TFS для управління джерелами (ми також використовували його для завдань / відстеження помилок / управління проектами, але ми перенесли це на JIRA ) з Visual Studio 2008 для розробки.

Які речі ви шукаєте під час перегляду коду?

• Це речі, які я придумав
  1. Застосування правил FxCop (ми - магазин Microsoft)
  2. Перевірте працездатність (будь-які інструменти?) Та безпеку (подумайте про використання OWASP - гусеничного коду ) та безпеку потоку
  3. Дотримуйтесь умовних імен
  4. Код повинен охоплювати крайові регістри та умови меж
  5. Чи слід поводитися з винятками правильно (не ковтати винятки)
  6. Перевірте, чи функціональність дублюється в інших місцях
  7. Тіло методу має бути невеликим (20-30 рядків), а методи повинні робити одне і лише одне (відсутність побічних ефектів і уникати тимчасової зв'язку -)
  8. Не передавати / повертати нулі методами
  9. Уникайте мертвого коду
  10. Документ відкритих та захищених методів / властивостей / змінних

На які ще речі слід звернути увагу?

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

Або огляд коду дуже суб'єктивний (і відрізняється від одного рецензента до іншого)?

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

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

Довідник книги: Чистий код: Довідник про гнучку майстерність програмного забезпечення Роберта Мартіна .

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

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

Будь-які автоматизовані інструменти, які можна прийняти без подальшого аналізу або судження, є гарними - вказівки на C, C ++, Java. Регулярне складання. Компілятори дійсно хороші в пошуку помилок компілятора. Документування відхилень в автоматизованих чеках звучить як тонке обвинувачення автоматизованих чеків. Директиви щодо коду (як це робить Java), які допускають відхилення, є досить небезпечними, IMHO. Прекрасно підходить для налагодження, щоб дозволити швидко отримати серце. Не так добре знайти в погано задокументованому, 50 000 блоку коду рядків без коментарів, за який ви стали відповідальними.

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

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

Я вважаю ці речі корисними:

1) Без війн стилів . Там, де відкриті фігурні фігурні дужки переходять, слід лише перевірити послідовність у заданому файлі. Усе те саме. Це добре тоді. Глибина відступу Ditto ** s та ** табл . Більшість організацій виявляють, що їм потрібен загальний стандарт для вкладки, який використовується як великий простір.

2) `Ірваний

   looking

текст, який не відповідає

   line up is hard to read 

для змісту. "

BTW, K&R з відступом п'яти проміжків (ПЯТЬ), тому звернення до авторитету є марними. Просто будьте послідовними.

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

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

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

6) Формат файлів, що не належать до ASCII , є прийнятним, якщо створення, показ, редагування тощо, інструменти існують або створюються на початку розвитку. Це мій особистий ухил, але в світі, де домінуюча ОС не може вийти з власного шляху з менш ніж 1 гігабайт оперативної пам’яті, я не можу зрозуміти, чому файлам менше, ніж, скажімо, 10 мегабайт має бути що-небудь крім ASCII або іншого формату, що підтримується комерційно. Існують стандарти для графіки, звуку, фільмів, виконуваних файлів та інструментів, які йдуть разом з ними. Немає виправдання для файлу, що містить двійкове представлення деякої кількості об'єктів.

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

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

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

Якщо ви зможете базувати тести на вимогах , ну, як каже леді в "Коли Гаррі зустрів Саллі" , я буду мати те, що у неї є!

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

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

Багато в чому я вважаю, що технологія - це стільки як культура, скільки очікування, як і певний інструмент. Подумайте про всі імпровізації " Швейцарської родини Робінсона " / Флінтстоуни / Макгівера, які радують серце та кидають виклик розуму. Ми хочемо, щоб наші речі працювали . До цього не існує єдиного шляху, більше, ніж був "інтелект", який міг би якось абстрагуватися та автоматизуватися програмами AI 1960-х років .

Більшість описаних вами пунктів - це лише питання формування коду або "поверхневого" матеріалу:

• Дотримуйтесь умовних імен
• Уникайте мертвого коду
• Документ
• ...

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

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

Автоматизований інструмент може:

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

Електронну пошту можна надіслати будь-якій команді, або хлопцеві, який вчинив код, який не пройшов тест - або ви можете скористатися деяким веб-інтерфейсом для звітування ( така ж примітка про .NET та PHP)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Загальний формат, який я люблю приймати:

1. Що ми фіксуємо?
2. Що це було причиною? (подивіться на код)
3. Як ми це виправляємо?
4. Покажіть мені новий код
5. Покажіть мені код працює

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

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

Цикломатична складність (CC) - це один із способів оцінювання коду, який є «непоганим».

У фактичному коді, що має високий КС, у мене високий фактор "що тут відбувається, я не пам'ятаю". Нижній код CC простіше зрозуміти.

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

Огляди коду є як суб'єктивними, так і об'єктивними. Такі правила, як "метод методу повинен бути 20-30 рядків", є суб'єктивними (деякі люди можуть вважати, що 100 рядків добре), але якщо ваша компанія вирішила, що 20-30 рядків є межею, це нормально, і ви можете це виміряти. Я думаю, що точкова система, яку ви придумали, - чудова ідея. Вам потрібно буде періодично переоцінювати її, коли ви виявите, що певні правила повинні мати більшу чи меншу вагу в оцінці, але поки всі знають правила, це виглядає як хороша система.

Інші речі, які я б шукав:

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

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

Якість коду:

• Автоматизовані чеки:
  • Відповідність стилю: чи правильна умова іменування, чи всі коди правильно відведені тощо.
  • Стандарт ефективності: перевірка на наявність витоків пам'яті, перевірка складності, зайвих змінних тощо.
• Фактичний експертний огляд:
  • Проста прогулянка по дизайну
  • пояснення відхилень від автоматизованих перевірок
  • Простота обслуговування, поговоріть про те, як ви можете її підтримувати та все
  • Заповітність: як легко перевірити цей код? Маєте план?

Відповідність функції:

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

Якщо ви можете розкрити ці два аспекти огляду коду, ви золоті.

Я міг би написати декілька абзаців, але я б лише промальовував те, що пояснює Карл Вігерс у "Peer Reviews of Software: Practical Guide" . Я думаю, що його книга містить чіткі та стислі відповіді на ваше запитання (та багато іншого).

Це залежить.

Деякі частини огляду легко піддаються кількісній оцінці (відсутність проблем FxCop, відсутність помилок StyleCop , відсутність помилок CAT.NET тощо)

Стиль, однак, може бути суб'єктивним - але, як ви кажете, як тільки ви почнете бути більш конкретним (без методу> 20 рядків), ви можете його виміряти, і такі інструменти, як NDepend, можуть робити це автоматично. Хоча деякі речі ніколи не будуть автоматичними - перевірка обробки кращих справ вимагатиме тестів, що дозволяє охопити код, і 100% є недосяжним ідеалом у багатьох випадках. Перевірка копіювання важко зробити автоматично. Нульові перевірки, добре, не впевнений, що я з вами згоден, але ви, можливо, зможете написати правила NDepend або правила FxCop для цього.

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

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

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

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

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

• Якщо машина може це перевірити, люди не повинні.
• Тільки один елемент контрольного списку: чи скрізь правильно обробляється кожен випадок помилок?
• Використовуйте огляди коду для покращення якості та передачі знань.
• Не використовуйте огляди коду для ідентифікації "поганих" розробників.
• Дії Его ефективніші, ніж явні моменти.
• Нехай це буде коротким - 90 хвилин і 500 ліній - ВЕЛИЧЕЗНО.