Agile Practices: Перегляд коду - Не вдалося переглянути або не порушити проблему?

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

Інакше завдання відповідає визначенню виконаного.

У нас є два варіанти.

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

Моє запитання: чи є якісь властиві проблеми чи міркування щодо підняття квитка з задньої частини огляду, замість того, щоб його не дати?

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

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

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

в огляді ми виявляємо функцію

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

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

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

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

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

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

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

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

Пропуск / невдача - це по суті бінарний стан , який по суті є все або нічого.

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

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

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

Інакше завдання відповідає визначенню виконаного.

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

В кінці двотижневого спринту та завдання має огляд коду [...] Легка робота рефактора.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Яка мета перегляду вашого коду?
2. Як результати огляду коду відносяться до визначення Виконано для робочого предмета?
3. Якщо огляд коду застосовується як тест на тестування, які проблеми вважаються «блокаторами»?

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

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

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

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

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

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

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

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

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

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

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

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

1. Ви не думаєте про рефакторинг як частину кодування, а як про окрему операцію, яка, в свою чергу, робить можливим потрапляння під тиском.

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

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

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

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

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

Ваше запитання чітко закликає до "спритних практик", тому переглянемо маніфест спритності (акцент мій):

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

• Індивіди та взаємодія над процесами та інструментами
• Працює програмне забезпечення над всеосяжною документацією
• Співпраця з клієнтами щодо укладання договорів
• Відповідаючи на зміни протягом наступного плану

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

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

Почніть співпрацювати. Зупиніть невдачу оглядів коду.

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

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

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

Одне з прислів'їв, які ми маємо, - це "Виберіть прогресивне вдосконалення над відкладеною досконалістю".

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

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

На мою думку, є два способи розглянути цю проблему:

1. Академічний шлях
2. Реальний світовий шлях

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

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

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

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

1. "Функція досить довга". Запишіть: Функції повинні бути меншими за X рядків (я не припускаю, що правила щодо тривалості функції - це добре).

2. Msgstr "Є деякі запахи коду". Запишіть: загальнодоступні функції повинні мати тести одиниць на функціональність та продуктивність, і використання процесора, і пам'яті повинні бути обмежені x та y.

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

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

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

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

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

Re: Неможливо записати правила !!

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

Запишіть правила, які ви можете, і поговоріть над пивом про те, що робить код «хорошим».