Як збалансувати якість коду та сильних особистостей розробника

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

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

Традиційно, хто має "право вето" на те, що потрапляє на місце і як?

Як код, який працює, але його надто залучений / розумний видалити, не наступаючи на пальці?

Я люблю цю цитату:

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

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

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

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

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

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

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

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

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

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

• Ви знаєте, як скажімо, я знаходжу вихідний файл 31K, що перевищує рекомендований розмір, тобто, 30K. Мої варіанти - або витратити кілька хвилин / годин на боротьбу, щоб змусити власника файлів якось вичавити цей зайвий кілобайт, або витратити день чи два на роздуми та копання, щоб дізнатися, що, скажімо, є якийсь API бібліотеки, який можна використовувати замість усіх код у цьому файлі (щоб його можна було просто видалити).

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

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

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

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

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

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

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

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

Він, ймовірно, відмовиться від смарт-коду на користь найпростішого, як тільки його змусять написати, як приклад.

Навіщо це працювати.

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

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

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

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

Що стосується влади вето, менеджмент, очевидно, має це.
Іноді це команди або комітети, які відповідають за якість коду, і в цьому випадку вони також матимуть цю владу.

Було б також корисно, якщо ви подасте приклад «розумного» шаблону. Можливо, ти просто перебільшуєш ...

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

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

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

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

Кілька спостережень я можу запропонувати:

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

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

3. Я вважаю, що набагато важливіше мати чисті, зрозумілі інтерфейси класів, ніж ніколи не мати "розумного" коду. Наприклад, у нас є клас, який підтримує список записів, які розглядаються 3 різними способами. В даний час він просто використовує лінійний пошук для всіх пошукових запитів, що працює в малому масштабі, але оскільки цей клас знаходиться на дуже низькому рівні, я бачу, що він не дуже масштабує. Я збираюся замінити його на інший клас, який використовує Boost Intrusive контейнери. Кожен елемент буде підтримувати розміщення у кожному з індексів одночасно, і все пошук буде здійснено в O (sqrt (N)). Так, зсередини буде набагато складніше, і багатьом людям не подобається Boost, але зовні він залишиться 3 методу: Add, Remove, Get. Підсумок полягає в тому, що люди можуть писати будь-який код, який вони хочуть (в межах причини),

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

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

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

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

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

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

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

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

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

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

Залежно від методології управління джерелом, код, можливо, доведеться тимчасово вводити в систему управління джерелом (можливо, у гілці), перш ніж ця фаза тестування може розпочатися.

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