Чи володіє кодом запах коду?

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

Ваша робота - звільнитися від роботи.

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

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

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

І це було обговорено трохи в інших питаннях, таких як цей , але я хотів піднести це ще раз, щоб обговорити з точки зору "точки зору запаху !! " - яка насправді не висвітлена. ще в глибині.

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

Звичайно, очевидна проблема в цьому полягає: що робити, якщо людина виїжджає або "потрапляє в автобус"? Або на командному рівні: що робити, якщо вся команда потрапить на харчове отруєння, коли вони виходять на обід своєї команди, і всі вони вмирають? Чи зможете ви порівняно безболісно замінити команду свіжим набором нових випадкових розробників? - У кількох своїх минулих робочих місцях я не уявляю, що це взагалі відбувається. Системи були настільки насичені хитрощами, що ви « просто повинні знати », що будь-яка нова команда, яку ви наймаєте, зайняла б набагато більше часу, ніж прибутковий бізнес-цикл (наприклад, нові стабільні випуски), щоб знову почати роботу. Коротше кажучи, я не здивуюсь, якщо від продукту доведеться відмовитися.

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

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

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

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

Я думаю, що ми повинні змінити власність коду:

• з точки зору відповідальності,
• з точки зору стилю коду / хакі тощо.

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

Право власності на код може дуже допомогти як менеджерам, так і розробникам, особливо розробникам. Якщо я знаю, що 80% помилок у продукті були в моєму коді, поки ми були трьома розробниками, які працювали над проектом, і що 75% цих помилок були пов’язані з ін'єкцією SQL, я буду ретельніше писати код наступного разу, і докладіть додаткових зусиль, щоб правильно написати запити до бази даних.

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

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

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

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

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

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

Спочатку нам потрібно визначити, що таке "власність коду".

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

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

Зазвичай для кожного завдання є один власник. Для парного програмування можливі подвійні власники. Це не було б практично без жодних вузько визначених «код-прав».

Примітка:
Будь ласка , дивіться @ MainMa в відповідь на інші питання , в процесі розробки. У цих випадках "володіння кодом" є симптомом більших проблем, тобто: неоптимального вибору архітектури, невідповідності стилю кодування та взагалі відсутності якості коду.

Після того, як фрагмент буде записаний і прийнятий у базу коду ("зроблено"), з'являється більш загальне питання "володіння кодом".

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

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

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

Це не означає, що існування "експертів" є поганим: вважайте експертів "кешем" письмових знань. Експерти часто можуть відповідати на питання швидше, ніж шукати і засвоювати письмові знання.

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

• Хто може внести зміни до цього фрагмента коду?
  • Щоб виправити явні помилки?
  • Щоб код задовольнив деякі інші вимоги?
  • Повністю переписати код на свій смак?

Є хороші і погані бар'єри:

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

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

Нарешті, @Graham Лі відповідь вказує на фрагментацію знань і архітектури , що обумовлено departmentalization.

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

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

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

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

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

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

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

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

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

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

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