Это то, о чем я думал с тех пор, как прочитал этот ответ в ветке противоречивых мнений о программировании :
Ваша задача - убрать себя с работы.
Когда вы пишете программное обеспечение для своего работодателя, любое программное обеспечение, которое вы создаете, должно быть написано таким образом, чтобы его мог подобрать любой разработчик и понять с минимальными затратами усилий. Он хорошо спроектирован, четко и последовательно написан, четко отформатирован, задокументирован там, где это необходимо, собирается ежедневно, как и ожидалось, регистрируется в хранилище и соответствующим образом корректируется.
Если вас сбивает автобус , увольняют, увольняют или уходят с работы, ваш работодатель должен быть в состоянии заменить вас в любой момент, и следующий парень может вступить в вашу должность, взять ваш код и быть в курсе событий. бег в течении недели топы. Если он или она не могут этого сделать, значит, вы с треском провалились.
Интересно, что я обнаружил, что достижение этой цели сделало меня более ценным для моих работодателей. Чем больше я стремлюсь быть одноразовым, тем более ценным я становлюсь для них.
И это уже обсуждалось немного в других вопросах, таких , как этот , но я хотел , чтобы привести его снова , чтобы обсудить с более точки заготовки « это код запах !! » точка зрения - которая на самом деле не были охвачены в глубине еще.
Я был профессиональным разработчиком в течение десяти лет. У меня была одна работа, где код был написан достаточно хорошо, чтобы любой новый разработчик смог относительно быстро его освоить, но в большинстве случаев в отрасли кажется, что очень высокий уровень владения (как индивидуальным, так и коллективным) норма. Кажется, что большинству баз кода не хватает документации, процессов и «открытости», которые позволили бы новому разработчику быстро их освоить. Кажется, всегда есть много неписаных маленьких хитростей и хаков, о которых знал бы только тот, кто очень хорошо знает кодовую базу («владеет» ею).
Конечно, очевидная проблема заключается в следующем: что, если человек уходит или «попадает в автобус»? Или на командном уровне: что, если вся команда получает пищевое отравление, когда они выходят на командный обед, и все они умирают? Сможете ли вы сравнительно безболезненно заменить команду новым набором случайных разработчиков? - В некоторых из моих прошлых работ, я не могу себе представить, что это вообще происходит. Системы были настолько полны хитростей и хитростей, что вам « просто необходимо знать », что любая новая команда, которую вы нанимаете, займет гораздо больше времени, чем прибыльный бизнес-цикл (например, новые стабильные выпуски), чтобы все снова заработало. Короче говоря, я не удивлюсь, если от продукта придется отказаться.
Очевидно, что потерять всю команду сразу будет очень редко. Но я думаю, что во всем этом есть более тонкая и зловещая вещь - именно этот момент заставил меня задуматься о начале этой темы, поскольку я не видел, чтобы это обсуждалось в этих терминах ранее. В основном: я думаю, что высокая потребность в владении кодом очень часто является индикатором технического долга . Если в системе не хватает процесса, коммуникации, хорошего дизайна, множества мелких хитростей и хитростей, о которых вы «просто должны знать» и т. Д., - это обычно означает, что система все больше и больше углубляется в техническую задолженность.
Но дело в том, что владение кодом часто представляется как своего рода «лояльность» к проекту и компании, как позитивная форма «принятия ответственности» за свою работу - поэтому непопулярно осуждать ее. Но в то же время техническая долговая сторона уравнения часто означает, что кодовая база постепенно становится менее открытой и с которой труднее работать. И особенно по мере того, как люди уходят и новые разработчики должны занять их место, стоимость технического долга (то есть технического обслуживания) начинает расти.
Так что в некотором смысле я действительно считаю, что для нашей профессии было бы хорошо, если бы высокий уровень потребности в владении кодом был открыто воспринят как запах работы (в воображении популярного программиста). Вместо того, чтобы воспринимать это как «принятие ответственности и гордости» в работе, его следует рассматривать скорее как «укрепление себя и создание искусственной защиты рабочих мест посредством технического долга».
И я думаю, что тест (мысленный эксперимент) в основном должен состоять в следующем: что, если человек (или даже вся команда) завтра исчезнет с лица Земли. Будет ли это гигантским - возможно, смертельным - ущербом для проекта, или мы сможем привлечь новых людей, заставить их прочитать документы и файлы справки и поиграть с кодом в течение нескольких дней - и затем вернуться в бизнес за несколько недель (и обратно к полной производительности через месяц или около того)?