Code Ownership

Допустим, вы прошли собеседование в крупную компанию. Фанфары отгремели, шампанское выпито. А что будет после принятия офера? Как преуспеть в корпорации и построить успешную карьеру разработчика?

Придётся упорно трудиться, прокачивать навыки коммуникации, учиться понимать продукт и его пользователей. И конечно, писать понятный, поддерживаемый и надёжный код. Но не только 😜

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

Я работаю в Фейсбуке в Лондоне. До этого — Toptal, Klarna, Яндекс. Несмотря на очевидную специализацию, каждый день мне приходится взаимодействовать с разными системами, написанными на TypeScript, React, Electron, CG/SQL, C++, Hack/PHP. Кроме использования совершенно разных платформ и языков, нужно хотя бы поверхностно разобраться со всеми компонентами стека, а ещё лучше — понять архитектуру всей системы и детали реализации.

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

Раз так, почему крупные компании не поощряют strong code ownership, когда за развитие и надёжность каждого модуля отвечает отдельный человек? Разработчики были бы счастливы, код был бы чист, а техдолг канул бы в небытие.

Тем не менее, за 15 лет моей карьеры — столько же прошло с момента публикации Фаулером классической статьи про code ownership — ни в одной из компаний я не сталкивался с единоличным владением кодом. Каким бы естественным ни казался такой подход начинающим разработчикам, бизнес стремится уменьшить риски при потере ключевых сотрудников — чем больше людей знает, как работает система — тем лучше.

Чем больше людей знает, как работает система — тем лучше.

Можно подобрать и исключения. Например, библиотечный код: важные для архитектуры сервисы и модули, которые обычно создаются и поддерживаются отдельными командами, но не конкретными людьми. По Фаулеру, это не единоличное владение кодом, а скорее weak code ownership, когда за систему и код отвечает группа разработчиков.

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

А как в Facebook?

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

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

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

Главный навык

Получается, главный навык программиста в современной крупной компании с shared code ownership — не просто писать понятный, поддерживаемый и надёжный код, но и обязательно уметь делать это внутри любой системы, даже той, которую он видит впервые. А свой код проектировать максимально очевидным образом, чтобы будущие изменения минимально влияли на архитектуру и непротиворечивость.