Як боротися з «майже хорошим» кодом молодшого розробника? [зачинено]

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

Зараз, коли щось прямо і очевидно є порушенням належних практик: як порушення SRP, Бог заперечує, неістотні назви методів чи змінних; Я вказую, що він має виправити, і намагаюся пояснити, чому це неправильно.

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

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

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

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

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

• Чи повинен ваш процес CI назвати це?
• Чи є у вас чіткий "посібник для розробників" для посилання (чи все зафіксовано в голові)?
• Чи справді ці коментарі сприяють якості коду?

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

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

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

Але абсолютно не зливайте речі, а потім поверніться і виправте це. Це пасивно-агресивно, і якщо розробник виявить, що ви це робите, ви вб'єте їх мораль.

Тримайте критику щодо коду, а не письменника.

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

Один із способів досягти цього - розумно вибирати свої слова. Хоча люди STEM люблять вважати себе високо логічними, емоції є частиною людської природи. Використовуване багатослів’я може бути різницею між пошкодженими чи пошкодженими почуттями. Скажіть, що "Ця функція буде більше відповідати умовам, якби вона була англійською мовою", краща, ніж "Ви написали ім'я цієї функції неправильно, і воно повинно бути англійською мовою". Незважаючи на те, що остання приборкана і сама по собі здасться прекрасною, у порівнянні з першою її помилки стають очевидними - коли готуєте, що сказати особисто або електронною поштою, вивчіть, чи є ваш контекст, слова та фокус на питаннях, а не особа .

Мова тіла

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

Дайте чесні позитивні відгуки

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

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

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

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

Крім того, якщо ви стримуєтесь, ви не допомагаєте, а опікуєтеся.

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

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

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

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

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

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

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

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

Досить широко відкрите питання, але ось пара ідей.

1. Експертна оцінка (молодшим розробником)

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

2. Ранні відгуки / Огляди завдань

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

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

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

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

Подумайте про прийняття робочого процесу з перегляду коду, коли розробники розміщують запропоновані ними зобов’язання на такий інструмент, як Github Pull Requests або Phabricator Diffusion, і отримайте підпис під одноранговим рівнем перед тим, як внести свої зміни до загальної гілки master.

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

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

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

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

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

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

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

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

Я маю справу з молодшим розробником, який працює віддалено від фабрики кодування.

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

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

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

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

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

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

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

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

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

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