Неписані правила переписування коду іншого члена команди [закрито]

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

А як щодо повного переписування коду від розробника, який все ще є в команді? Потрібно спочатку запитати його? Яка найкраща практика?

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

Увійти та переписатись без попереднього спілкування - це рецепт поганої волі.

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

1. Ви абсолютно впевнені, що говорите про переписування, а не про рефакторинг? За визначенням, зміни стилю або структури коду, які призводять до вдосконаленої (або просто іншої) реалізації без змін зовнішньої поведінки, є рефактором, а не перезаписом. Введення монолітного 500-рядкового режиму в набір 50 підпрограм може спричинити написання нового коду, але це не перезапис. Термін перезапис означає викидання цілого продукту чи функції та початок з нуля; це не те, що слід сприймати легковажно.

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

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

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

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

5. У цьому пункті в першому абзаці зазначено питання any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs. Чи переписування цього не зробить? Або це зробить щось зайве - і якщо так, то що? За суті, то , що є ваші причини для бажаючих зробити рерайт, і як ви впевнені, що вони будуть приносити користь продукту або команди? Вам не потрібно відповідати за мене, але краще мати деякі об’єктивні моменти, якщо і коли ви вирішите обговорити це з командою.

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

Чому ви редагуєте код?

Чи є помилки чи це більш фундаментальний недолік дизайну?

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

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

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

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

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

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

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

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

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

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

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

Яка сфера застосування?

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

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

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

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

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

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

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

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

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

Моя практика - коментувати це, замінюючи його. (В основному для довідок.) Потім видаліть його під час остаточного виконання робочої зміни. (Для цього потрібно контролювати версії та розуміти, як відновити зміни.)

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

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

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

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

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

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

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

З іншого боку, є й інші часи, коли перезапис вимагає:

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

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

У цих випадках я, мабуть, не переймався б розмовою.

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

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

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

У командному середовищі розробників вам не доведеться (і може не мати можливості) спілкуватися з оригінальним кодером, все повинно бути зрозуміло з коду.

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

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

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

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

Часто код пишеться певним чином з причини. Донесення змін до автора завжди працює найкращим чином.