Является ли владение кодом запахом кода?

Это то, о чем я думал с тех пор, как прочитал этот ответ в ветке противоречивых мнений о программировании :

Ваша задача - убрать себя с работы.

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

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

Интересно, что я обнаружил, что достижение этой цели сделало меня более ценным для моих работодателей. Чем больше я стремлюсь быть одноразовым, тем более ценным я становлюсь для них.

И это уже обсуждалось немного в других вопросах, таких , как этот , но я хотел , чтобы привести его снова , чтобы обсудить с более точки заготовки « это код запах !! » точка зрения - которая на самом деле не были охвачены в глубине еще.

Я был профессиональным разработчиком в течение десяти лет. У меня была одна работа, где код был написан достаточно хорошо, чтобы любой новый разработчик смог относительно быстро его освоить, но в большинстве случаев в отрасли кажется, что очень высокий уровень владения (как индивидуальным, так и коллективным) норма. Кажется, что большинству баз кода не хватает документации, процессов и «открытости», которые позволили бы новому разработчику быстро их освоить. Кажется, всегда есть много неписаных маленьких хитростей и хаков, о которых знал бы только тот, кто очень хорошо знает кодовую базу («владеет» ею).

Конечно, очевидная проблема заключается в следующем: что, если человек уходит или «попадает в автобус»? Или на командном уровне: что, если вся команда получает пищевое отравление, когда они выходят на командный обед, и все они умирают? Сможете ли вы сравнительно безболезненно заменить команду новым набором случайных разработчиков? - В некоторых из моих прошлых работ, я не могу себе представить, что это вообще происходит. Системы были настолько полны хитростей и хитростей, что вам « просто необходимо знать », что любая новая команда, которую вы нанимаете, займет гораздо больше времени, чем прибыльный бизнес-цикл (например, новые стабильные выпуски), чтобы все снова заработало. Короче говоря, я не удивлюсь, если от продукта придется отказаться.

Очевидно, что потерять всю команду сразу будет очень редко. Но я думаю, что во всем этом есть более тонкая и зловещая вещь - именно этот момент заставил меня задуматься о начале этой темы, поскольку я не видел, чтобы это обсуждалось в этих терминах ранее. В основном: я думаю, что высокая потребность в владении кодом очень часто является индикатором технического долга . Если в системе не хватает процесса, коммуникации, хорошего дизайна, множества мелких хитростей и хитростей, о которых вы «просто должны знать» и т. Д., - это обычно означает, что система все больше и больше углубляется в техническую задолженность.

Но дело в том, что владение кодом часто представляется как своего рода «лояльность» к проекту и компании, как позитивная форма «принятия ответственности» за свою работу - поэтому непопулярно осуждать ее. Но в то же время техническая долговая сторона уравнения часто означает, что кодовая база постепенно становится менее открытой и с которой труднее работать. И особенно по мере того, как люди уходят и новые разработчики должны занять их место, стоимость технического долга (то есть технического обслуживания) начинает расти.

Так что в некотором смысле я действительно считаю, что для нашей профессии было бы хорошо, если бы высокий уровень потребности в владении кодом был открыто воспринят как запах работы (в воображении популярного программиста). Вместо того, чтобы воспринимать это как «принятие ответственности и гордости» в работе, его следует рассматривать скорее как «укрепление себя и создание искусственной защиты рабочих мест посредством технического долга».

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

Я думаю, что мы должны сделать разницу между владением кодом:

• с точки зрения ответственности,
• с точки зрения стиля кода / хаков и т. д.

Первый должен поощряться. Если никто не несет ответственности за некачественный код и ошибки, произойдут плохие вещи . Это не означает, что ошибка, связанная с вашим собственным кодом, должна быть назначена вам каждый раз: если код написан правильно, любой может исправить ошибку в любой части кода. Но если у вас нет отзывов об ошибках, которые вы делаете, вы будете снова и снова создавать одни и те же ошибки .

Владение кодом может сильно помочь как менеджерам, так и разработчикам, особенно разработчикам. Если бы я знал, что 80% ошибок в продукте были в моем коде, в то время как мы работали над этим проектом тремя разработчиками, и что 75% этих ошибок были связаны с SQL-инъекцией, я был бы более осторожен при написании кода в следующий раз, и приложить дополнительные усилия, чтобы правильно писать запросы к базе данных.

Второй (владение кодом из стиля кода / хаки и т. Д.) В основном плохой. Что это приносит к продукту? Это не повышает качество продукта, но снижает однородность исходного кода и затрудняет его поддержку в последнее время .

Во многих крупных проектах люди не остаются на всю жизнь, работая над одним и тем же фрагментом кода. И здесь я даже не говорю о таких ужасных вещах, как то, что разработчик столкнулся с шиной: я не думаю, что владение кодом является первой проблемой в этом случае. Но случается много второстепенных мыслей: люди переходят от разработки к управлению или другим работам, или выбирают другие проекты, или работают над другими вещами, или начинают использовать другой язык (если в проекте используется несколько языков) и т. Д.

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

Это запах кода? Ну, это зависит от того, что вы подразумеваете под запахом кода. Для меня все зависит от общей согласованности проекта и правильного управления . В хорошем проекте

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

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

Сначала нам нужно определить, что такое «владение кодом».

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

• В начале нет четких спецификаций или требований, и разработчик (и) должен будет собирать информацию самостоятельно. Между сбором и документированием этих выводов существует временной разрыв.
• Избегайте конфликтующих изменений, когда фрагмент кода активно изменяется.
• «Владельцы» - это лица, которые могут сообщать о ходе разработки функции.

Обычно для каждой задачи есть один владелец. Двойные владельцы возможны с парным программированием. Было бы нецелесообразно делать это без какого-либо узко обозначенного «владения кодом».

Примечание:
Пожалуйста, смотрите ответ @ MainMa для других вопросов во время разработки. В этих случаях «владение кодом» является симптомом более серьезных проблем, а именно: неоптимального выбора архитектуры, несоответствия стиля кодирования и, как правило, отсутствия качества кода.

Как только часть написана и принята в базу кода («выполнено»), возникает более общий вопрос «владения кодом».

• Кто является экспертом, который может ответить на все вопросы об этой части кода / этой части функциональности?
• Были ли эти знания отражены в материальных артефактах, таких как документ с требованиями, модульные тесты, приемочные тесты, журналы изменений, вики проекта и т. Д.?

Всегда будет некоторая часть знаний о предметной области (молчаливое понимание требований клиентов, проблемы совместимости с тайными системами и т. Д.), Которые трудно формализовать в письменные спецификации. Следовательно, когда происходит событие бедствия, следует ожидать некоторой потери знания предметной области.

Наряду с потерей знаний о предметной области вы также потеряете экспертов-ответчиков, которые могут объяснить детали системы. В этом аспекте потеря специалиста является повсеместно плохой вещью. Знания должны были быть получены ранее.

Это не означает, что существование «экспертов» является плохим: считают экспертов «тайником» письменных знаний. Эксперты часто могут отвечать на вопросы быстрее, чем искать и усваивать письменные знания.

Однако иногда «владение кодом» относится к барьерам, установленным активными разработчиками проекта для предотвращения изменения кода посторонними лицами.

• Кто может внести изменения в этот кусок кода?
  • Чтобы исправить очевидные ошибки?
  • Чтобы код удовлетворял некоторым другим требованиям?
  • Чтобы полностью переписать код на свой вкус?

Есть хорошие и плохие барьеры:

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

В этом случае право редактировать исходный код другого проекта не должно основываться на владении кодом, а должно основываться на достоинствах.

Наконец, @Graham Ли ответ указывает на фрагментацию знаний и архитектуры , что обусловлено departmentalization.

В этом случае «владение кодом» является одним из симптомов департаментализации. Вторым симптомом является «отсутствие интереса к проектам других команд». Как организация, менеджеры должны будут предпринять шаги, чтобы поощрить передачу знаний и сотрудничество между командами и отделами.

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

Это проблема? Это если архитектура является или становится субоптимальной. Невозможно сказать (например), что установщик работал бы лучше или был бы дешевле в разработке, если бы это был просто пример использования клиента, потому что это отнимает контроль у команды и ее менеджера. Разделение между функциональными модулями стало фактом о том, как работает инженерный отдел, и чтобы изменить эти факты, нужно много потрясений.

[Между прочим, в случае, если вышеупомянутое обсуждение не проясняет, мой ответ на ваш вопрос - да. Владение кодом - это запах кода, потому что он может помешать умелым людям с хорошими идеями или даже людям, которые доступны, когда они вам нужны, работать над кодом. Очевидно, что иметь средства управления для остановки капризных изменений - это хорошо, но если у вас есть инженер, который может понять, как исправить ошибку, и у него есть время на это, вам не следует блокировать этого инженера только потому, что кто-то другой написал ошибочный код. ]

Решая ваш вопрос с несколько иной точки зрения, владение кодом НЕ является запахом кода. Это запах управления и ресурсов .

Подумайте, что означает запах кода. Это метафора, которая говорит вам, когда вы смотрите на код, что что-то не так с кодом и / или дизайном программного обеспечения, но проблема может быть не столь очевидной, чтобы иметь возможность понять, что точная проблема может быть, но у вас, вероятно, есть хорошая идея. В вашем доме, если что-то плохо пахнет, вы следуете за носом, пока не найдете источник проблемы, а затем что-то делаете с этим. Таким же образом, если в коде есть проблема, вы исследуете ее и изменяете до тех пор, пока она не станет менее проблемной или, как некоторые скажут, красивой или хорошо продуманной .

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

Я думаю, что хорошо описывать другие бизнес-проблемы как запахи , но, конечно, не подразумевать, что это связано только с запахом , связанным с кодом.

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

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

По вашему определению владения кодом, я согласен, что плохо иметь код, в котором может работать только автор.