четверг, 13 мая 2010 г.

Совместная работа над кодом в компании Google

Во второй главе книги «Coders at Work», Брэд Фицпатрик (Brad Fitzpatrick) — автор Live Journal, а сейчас сотрудник компании Google, помимо всяких интересных баек о создании Live Journal, об учебе и о многом другом, рассказывает и о принципах владения кодом и о совместной работе над ним в компании Google.

SharedSources

Как известно, в Google существует возможность использовать двадцать процентов своего рабочего времени в целях, отличных от целей текущего проекта (но в целях и интересах компании в целом). Это явление называется групплеты (grouplet) (об этом можно почитать в замечательной статье «The Google Way: Give Engineers Room», или в переводе этой статьи здесь), соответственно, у каждого разработчика может появиться дикое желание порыться в чужом коде и поучаствовать в каком-то проекте. А поскольку таких проектов, мягко говоря, много, то требуются некоторые формальные правила, которые позволят поддерживать весь код в актуальном состоянии и не позволят его качеству опускаться ниже определенного уровня.

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

Для того, чтобы исправленный код попал обратно в репозиторий должны быть выполнены два требования. Во-первых, вы должны получить «одобрение» от владельца кода (code owner), а во-вторых, одобрение от сертифицированного специалисти по тому языку программирования, который используется в этом проекте (readability approved person) (кстати, совершенно не обязательно, чтобы это были два разных человека, две эти роли вполне могут ужиться и в одном человеке).

Владельцев у кода должно быть как минимум два (это уменьшает вероятность того, что код не будет закоммичен в репозиторий по причине того, что владелец кода заболел, уволился или женится), а за readability по определенному языку программирования в целом отвечает капитан (readability captain), заботой которого является поддержание достаточного количества специалистов по соответствующему языку программирования. Если вы или один из ваших прямых рецензентов являетесь readability expert, то все хорошо, в противном случае вам придется найти такого человека и привлечь его в качестве рецензента. Каждый человек может сдать соответствующий экзамен и стать тем самым readability expert-ом и либо участвовать в ревизии кода других сотрудников, либо же это позволит ему устранить один из этапов при сохранении собственного кода в репозиторий.

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

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

Кстати, а как обстоят дела дела в вашей компании с владением кода и совместной работой над ним?

Дополнительные ссылки:
Code readability

9 комментариев:

  1. У нас дела обстоят категорически плохо :(
    Никаких проверок перед комитом, за все отвечает программист.
    А до недавнего времени и систем контроля версий не было - еле заставил перелезть с архивов.

    ОтветитьУдалить
  2. Ну хоть архивы были, у меня на предыдущем месте работы папки проектов копировали и называли OLD, OLD_2, New и т.п. У кого на что фантазии хватает.

    ОтветитьУдалить
  3. @Eugene: да и потом, когда программист уходит руководство с удивлением узнает, что за несколько лет его работы он наделал кучу хрени, которую поддерживать никто вообще не собирается, поскольку гораздо проще тупо переписать все заново? :) И так происходит по цепочке. Приходят люди, пишут ерунду (поскольку некогда проверять и смотреть на результаты их работы), уходят, на их место приходят другие и переписывают то, что написано до них, и так до бесконечности:)

    ОтветитьУдалить
  4. @Alex: я когда пришел на текущее место работы, то тоже ходили примерно такие названия папок: Last, LastLast, LastLastPlus, LastLastPlusPlus, до сих пор (а это уже 6 лет прошло) периодически вспоминаем об этом.

    ОтветитьУдалить
  5. Да-да, "The Last" тоже были. Но повлиять на руководство не удалось. Хотя я даже не знаю, как можно на них повлиять, если использование ms ajax и/или javascript фреймворков было признано сложным и все пишется по старинке - document.getElementById()...

    А потом представилась возможность работы над интересным проектом в другом месте. И сейчас, вместе с руководством, осваиваем tfs. Пока все довольны.

    P.S. Прочитал Ваш ответ для Eugene. Признавайтесь, работали у нас в конторе? ;-)

    ОтветитьУдалить
  6. @Eugene
    У нас тоже нет проверок перед коммитом - но это прелесть Mercurial ;) Проверка перед коммитом - это необходимость SVN ;))))
    Системы контроля версий, доступ всех ко всем проектам - это категорически правильно. Конечно если позволяют условия договоров с заказчиками для использования кода в других проектах.

    ОтветитьУдалить
  7. @Alex: у вас в конторе я точно не работал, но ведь не зря существует огромная польза от чтения книг, блогов и других форм заимствования чужого опыта: проблемы в нашей индустрии очень похожи, не зависимо от названия фирмы, в которой вы работаете:)

    ОтветитьУдалить
  8. У нас в команде практикуется общее владение кодом. После решения задачи код инспектируют 2 члена команды. После их проверки, обсуждения замечаний и исправлений, код чикинется.

    ОтветитьУдалить