Що мені робити, чекаючи перегляду?

Перш ніж ставити своє запитання, я повинен пояснити ситуацію.

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

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

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

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

EDIT: доповнення до питання. Мені цікаво ще одне питання.

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

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

Тож мій код теж запізнюється.

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

І до вашого редагування:

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

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

У хорошій команді у вас повинна бути черга завдань розвитку, призначена вам у трекері випуску .

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

• ^{Якщо у вас немає такої "черги", обговоріть це з вашим менеджером, а ще краще з рецензентом. Якщо ваша команда не має достатньо зручного інструмента для відстеження подібних питань, розгляньте можливість вивчення дощок для роботи або внутрішніх можливостей компанії, щоб знайти кращу команду (ви також можете обговорити це з менеджером / рецензентами, але не очікуйте, що це допоможе - не вистачає Хороший трекер проблеми часто є симптомом того, що в команді щось сильно порушено).}

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

Щоб це дізнатися, спочатку потрібно зрозуміти мету огляду коду. Ви згадали про довіру - це хороше «наближення», але не зовсім точне.

• ^{Наприклад, в одному з моїх останніх проектів розробка була проведена міні-командою мене та мого колеги. Ми повністю довіряли один одному і поважали один одного, але, незважаючи на це, ми переглянули 100% коду. Ми робили це, тому що це дозволило нам знайти та швидко виправити деякі помилки, і це також дуже важливо, оскільки огляди не забирали багато часу і не блокували нашу роботу.}

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

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

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

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

Тут є кілька можливих відповідей, залежно від конкретної проблеми.

• Якщо ваша найбільша стурбованість - "у мене відсутні терміни", ні. Ви двоє спільно пропускаєте терміни. Чи можете ви (з упевненістю) сказати: «Я закінчусь через годину, ми можемо зробити перевірку коду»? Цього може бути достатньо. Чи можете ви заповнити код за день до граничного терміну? Це повинно бути рясним буфером. Ви заповнюєте свій код з великою кількістю буфера між "будь ласка перегляньте" та крайнім терміном? Якщо останнє, я б навіть не винна спільна.

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

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

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

Інша справа: чи справді ваш старший керівник перевіряє кожен код, який ви робите? Якщо так, ви також можете виконати парне програмування.

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

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

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

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

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

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

Сторінка Вікіпедії про програмування пар

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

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

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

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

Не повна відповідь сама по собі, а лише доповнення до відмінних відповідей вище ...

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

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

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

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

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

Я думаю, що перевірка ручного коду - це ... ну ... Ну, може, 90-ті.

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

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

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

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

Atlassian Crucible
JetBrains TeamCity
повернув
круїз-контроль

Якщо ви збираєтеся отримати сервер CI, ви також повинні серйозно задуматися про тестові рамки блоку. Якщо ви C # Dev, погляньте на щось на зразок NUnit, щоб почати.

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