Як я тактовно пропоную вдосконалити погано розроблений код інших людей під час перегляду?

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

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

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

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

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

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

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

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

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

Є слабка пляма для додавання вартості за допомогою рефакторингу. Зміни повинні виконувати три речі:

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

Міркування:

1. Ми знаємо, що чистий код дешевше писати та підтримувати, і працювати веселіше. Ваше завдання - продавати цю ідею людям вашої компанії. Думай як продавець, а не як зарозумілий груповик (т. Е. Не такий, як я).
2. Ви не можете перемогти, ви можете втратити лише менше.
3. Зосередьтеся на додаванні реальної цінності - не тільки краси. Мені подобається, що мій код виглядає красиво, але іноді доводиться більше погоджуватися з недорогими справами.
4. Хороший спосіб знайти солодке місце - це дотримуватися принципу хлопців-скаутів - коли ви працюєте над областю коду, завжди залишайте його в кращому вигляді, ніж ви знайшли.
5. Невелике поліпшення краще, ніж поліпшення немає.
6. Корисно використовувати автоматизовані інструменти. Наприклад, інструменти, які просто очищають формат, можуть змінити світ .
7. Продайте інші ідеї, які до речі покращують чіткість коду. Наприклад, тестування одиниць рекомендує розкласти великі методи на більш дрібні.

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

Огляд коду служить 3 цілям:

1. Перевірка на наявність помилок

2. Перевірка, щоб побачити, де код можна вдосконалити

3. Навчальний інструмент для тих, хто написав код.

Оцінка якості дизайну / коду, звичайно, стосується №2 та №3.

Що стосується №2:

• Зробіть це ДУЖЕ зрозумілим, які вигоди від запропонованих змін та витрат, які потрібно виправити. Як і будь-яке бізнес-рішення, це має стосуватися аналізу витрат / вигод.

  Наприклад, "X-підхід до проектування значно знизить ймовірність появи помилки Y під час зміни Z, і ми знаємо, що цей фрагмент коду кожні 2 тижні зазнає змін типу Z. Вартість обробки відключення виробництва від помилки Y + пошуку помилки + виправлення та звільнення виправлення + можлива вартість від не доставки наступного набору феєрій $A, тоді як вартість прибирання коду зараз та можлива вартість (наприклад, ціна доставки із запізненням або з меншими можливостями) $B. Тепер оцініть - а точніше мати свого керівника / менеджера команди - оцінювати $Aпроти $Bта приймати рішення.

  • Це допоможе розумній команді вести ефективне управління цим. Наприклад, вони приймуть раціональне рішення, використовуючи ПОВНУЮ інформацію

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

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

Щодо №3:

• ДУЖЕ чітко розмежовуйте помилки / проблеми з "треба виправляти" від "Це найкраща практика і насправді потрібно виправити, якщо ми можемо зекономити ресурси - див. Доданий аналіз про-кон" Поліпшення дизайну (прикріпіть матеріали, описані для №2 вище) проти " Це загальні вказівки, які, на мою думку, допоможуть вам покращити надійність коду, щоб ви могли легше підтримувати код "необов'язкові зміни. Зверніть увагу на формулювання - справа не в тому, щоб "зробити свій код таким, як я хочу" - це "якщо ви це зробите, ВИ отримуєте переваги a, b, c". Тон і підхід має значення.

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

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

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

Я також завжди включаю причину.

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

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

Я намагаюся встановити спільну мову з причин; читабельність, DRY, SRP тощо.

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

Але деякі люди все одно не слухатимуть. Тоді я лишаюсь з ранговим званням. Я лідер проектування. Якість коду - моя відповідальність. Ця зміна не відбудеться на моєму годиннику в його нинішньому стані.

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

О, і я нещодавно запропонував купити обід першому в моїй команді, який подав нетривіальну зміну, до якої я не мав жодного коментаря. (Гей, вам теж слід розважитися. :-)

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

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

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

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

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

або

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

Якщо ви сказали будь-яке, ваш начальник, ймовірно, скаже:

Хто що сказав про функцію X?

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

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

Ось кілька принципів, які я вважаю корисними:

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

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

Не забудьте зробити позитивні коментарі. Короткий "приємно!" або "акуратний трюк!" може зробити день молодшого або небезпечного програміста.

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

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

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

Цікаво, чи було б краще ...

або

Чи має сенс ...

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

"Так, це гарна ідея, тому що < ваша очевидна причина тут >."

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

Мені цікаво, чи є спосіб ... <твердження про спільне значення тут>

Це стосується лише справді чутливих людей - з більшістю моїх однолітків я просто даю їм це!

Огляди коду не завжди спрямовані на вдосконалення.

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

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

Ваше запитання "Як кодити переглянути погано розроблений код?":

Відповідь ІМО проста. Поговоріть про ПРОЕКТУВАННЯ коду та про те, як конструкція недосконала або не відповідає вимогам. Якщо ви вказали на недосконалий дизайн або "не відповідає вимозі", розробник буде змушений змінити свій код, оскільки він не робить те, що потрібно робити.

Якщо код є "функціонально достатнім" та / або "відповідає специфікаціям" та / або "відповідає вимогам":

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

Залишилося кілька варіантів:

1. Ви повинні використовувати власний особистий "вплив" (форма "влади", яка є непрямою) та / або вашу здатність бути "переконливим"
2. залучіться до вашої організації групи "процес кодування" і почніть робити "підтримку коду" вищим пріоритетом.
3. Кусайте кулю і навчіться швидше / повільніше читати скажений код, щоб не зациклюватися (це здається, що ви постійно зависаєте або сповільнюєтесь, коли стикаєтеся з хижим кодом) на crappy code.
   • Це також зробить вас сильнішим програмістом.
   • І це дозволить вам виправити шалений код, коли ви працюєте над шаленим кодом.
   • І це також дозволить вам працювати над іншими проектами, тому що в багатьох проектах є хитрий код, який є функціональним ... але багато шаленого коду.
4. Подавати приклад. Зробіть свій код краще ... але не намагайтеся бути перфекціоністом.
   • Тому що тоді ти станеш "повільним хлопцем, який не може дотриматись термінів, завжди критикує і вважає, що він кращий за всіх".

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

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

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

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

Повторіть до крайнього терміну або поки система не стане «досконалою».

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

Один із способів, яким я слідую - це

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

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

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

Ви повинні мати ранні та часті події, а також огляди на рівні комітетів. За допомогою інструментів аналізу коду більшість оглядів будуть швидкими. Автоматизовані інструменти аналізу / огляду коду, такі як FindBugs та PMD , допоможуть вам отримати великий клас помилок у дизайні за двері. Однак вони не допоможуть вирішити проблеми архітектурного рівня, тому ви повинні мати міцний дизайн і судити загальну систему проти цього дизайну.

Підвищити якість оглядів коду.

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

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

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

У питанні є два помітні питання - тактовна частина та частина, що настає в кінцевому порядку. Це окремі питання - перше - питання спілкування та динаміки команди, друге - питання планування та визначення пріоритетності.

Тактовно . Я припускаю, що ви хочете уникати зіпсованих егоїстів та негативних відштовхувань від відгуків. Деякі пропозиції:

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

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

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

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

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

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

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

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