2013-10-15
Памела Фокс, программист с опытом работы в Google, Coursera и Khan Academy, делится своими соображениями о том, что важно в командной работе инженеров.
Очень важно найти такое место, где вы можете не только работать над интересным для вас продуктом, но и чувствовать себя комфортно на предлагаемой площадке для совместной работы: чтобы вы не боялись вносить изменения в код и видели процесс внесения изменений.
Итак, о чём нужно спросить работодателя, чтобы понять, как происходит процесс работы над кодом?
Код-ревью
Регулярно ли проводится анализ кода?
До того, как я попала в Google, я никогда не сталкивалась с анализом кода. После того, как я узнала, что это такое, я уже больше не хочу вносить код в общую базу без ревью. Цель анализа кода – не найти в вашем коде недостатки, а убедиться в том, что написанный код соответствует принятой в команде практике, соответствует формату. Код-ревью – это замечательная возможность для новичков компании научиться работать внутри кодовой площадки; а для опытных – научиться новым решениям от своих коллег, которые они применяли, возможно, в других проектах.
В Google мы использовали Mondrian, инструмент, делающий процесс анализа кода очень прозрачным: изменения просто невозможно было принять без «одобрения» ответственного за анализ кода. В Coursera использовался Github, где ревьюер кода просто говорил «как закончите – объединяйте» (если всё было хорошо), а автор кода мог сказать: «посмотрите ещё раз», если в чём-то сомневался.
Правила оформления кода
Следуете ли вы стандартным правилами? Есть ли у вас собственные правила для внутренних фреймворков?
Google выкладывал в публичный доступ свои инструкции по оформлению кода. Внутри компании также была процедура проверки инженера на предмет его высокой компетентности в принятых правилах: вы предоставляете анализ 300-строчного кода назначенному эксперту, и при хороших результатах проверки ваш код получает статус «высокой читаемости», а вы – права на приём изменений. Это очень хорошее подспорье для самообучения, и я лично очень гордилась, когда получила статус высокой читаемости JavaScript.
В Coursera мы документировали все правила, соблюдаемые при написании на каком бы то ни было языке, и старались соответствовать всем существующим стандартам. Инженерам было рекомендовано установить плагины, проверяющие код на наличие нарушений стандартов (например, SublimeLinter с PEP8). Также мы документировали правила для фреймворков (например, для Backbone.js) и для REST API.
По большому счёту, каждый раз, когда какую-либо технологию можно использовать разными способами, и команда договорилась использовать один из них, это должно быть оформлено в качестве регламента. Как инженеру, только-только вступающему в команду, вам нужно будет знать, какие правила уже разработаны в компании, чтобы ваш код как можно быстрее стал частью общего дела.
Комментарии
Комментируется ли сложный код? Есть ли в кодовой базе файлы readme с описанием систем более высокого уровня?
Нам часто кажется, что наш код очевиден, но для читателей это не всегда так. Поэтому при каждом анализе кода ответственный за анализ, сталкиваясь с двусмысленностью или непонятным участком, должен попросить автора добавить к коду комментарий. Системы, состоящие из множества кодовых баз, должны иметь подробные обзоры структуры базы.
Тесты
Есть ли тесты? Какие? Как часто проводятся? Есть ли требования к тестированию новых функций? Есть ли в команде инженер-тестировщик или отдельная команда тестировщиков?
Многие кодовые базы начинают свой путь с прототипов. Поначалу инженеры думают: «Ну, это всего лишь прототип, нам не нужно это тестировать». А потом эти нетестированные базы превращаются в настоящий продукт, и чем дольше кодовая база остаётся без тестов, тем сложнее в принципе запустить процесс тестирования. Когда мы оказывались в такой ситуации в Coursera, мы проводили «Тестатон»: закрывались в комнате и не выходили оттуда, пока не находили решения для тестирования разных частей наших кодовых баз и не писали пробные тесты для каждой части. Потом, при появлении новой функции, вопрос «а есть ли тесты?» становился стандартной частью анализа кода.
К тестированию существуют разные подходы. Некоторые команды предпочитают TDD, когда тесты пишутся до кода, некоторые пишут тесты как часть основного кода (в любом порядке), а некоторые нанимают инженеров-тестировщиков и отдают им бразды правления.
Основное, что вам нужно понять из ответа на эти вопросы: заботится ли команда о тестировании, или просто полагается на то, что программисты сами напишут «нормальный код». Вы же не хотите оказаться в команде, где от вас хотят волшебной суперспособности написать нетестированный код, который никак не повлияет на другие части неизвестной вам системы, и который никогда не сломается кодом другого программиста. Вам нужна команда, которая ценит тесты и хочет сделать их частью внутренней культуры своего отдела.
Процесс релиза
Как часто происходит деплой кода? Как быстро? Как быстро происходит откат? Кто несёт ответственность за деплой?
Когда я работала в команде Google Maps, релизы были еженедельными, и в каждом релизе было достаточно много изменений. Размер команды требовал назначения «билд-мастера», который просматривал каждый релиз, проверял пройденные тесты, решал, какие изменения наиболее важны, и отслеживал процесс выкатывания релиза на серверах.
В релизах Coursera изменения были не такими крупными, и поэтому более частыми – по несколько раз в день. Поначалу приходилось сложно, потому что деплой, как и откат, занимал 45 минут. К счастью, потом команда натолкнулась на Wayland, простой и дружелюбный инструмент, с помощью которого новый код выкатывается на AWS-сервера и обратно за несколько минут. До этого инструмента я каждый раз покрывалась мурашками при выкате обновлений, с ужасом думая, что будет, если сайт упадёт. Но когда знаешь, что откат занимает всего пару минут, дело кажется не таким уж и страшным. Конечно, у нас были и автоматические тесты перед выкатом, результаты которых всегда проверялись.
Процесс деплоя очень отличается в разных компаниях, и даже в разных командах одной компании. Главное, чтобы этот процесс был налажен таким образом, чтобы вы большую часть своей работы занимались написанием кода, а не релизом.
Пост-мортем (анализ ошибок)
Если случается непредвиденная хрень, что делает команда, чтобы избежать этой хрени в будущем?
В Google я по-настоящему оценила пост-мортемы – документы, в которых определялись сроки появления проблемы, «правильные шаги», «неправильные шаги» и предполагаемые действия в случае повторного возникновения. Пост-мортемы писались практически по каждой возникающей проблеме, и это касалось не только разработки.
В Coursera мы делали то же самое. Пост-мортемы были доступны для каждого сотрудника компании, а иногда они анонсировались и среди университетов-партнёров.
Сегодня компании очень часто публикуют пост-мортемы в своих блогах, и это хороший признак: значит, компании становятся всё более прозрачными для своих пользователей.
Для работника, конечно, лучше работать там, где занимаются анализом ошибок, а не заметают грязь под ковёр в надежде, что никто не заметит.
Стабильность стека
Как часто меняется стек? Не слишком ли часто?
Пробовать новые технологии, которые могут значительно улучшить кодовую базу – дело хорошее. Но порой это может раздражать и наводить на мысли о том, что что-то не так в Датском королевстве. Вдобавок, каждый раз, когда команда испытывает новую технологию, обязательно остаётся кусочек кода в старом стеке, который впоследствии исчезает из кодовой базы как устаревший.
В идеале при вступлении в команду хотелось бы услышать следующее: «Мы используем A, B и C. Из-за проблем с X мы пробуем использовать D и думаем, стоит ли совершать миграцию». Если услышанная технология D вам знакома и является проверенной и известной, можете быть спокойны. В обратном случае ваша команда превратится в подопытных кроликов, изучающих поведение капризной D в различных условиях среды.
Что ещё?
Конечно, остаётся ещё множество вопросов, касающихся корпоративной культуры в целом: принципов коммуникации, прозрачности, расстановки приоритетов…
Не стоит рассчитывать, что ожидающая вас построенная культура будет иметь 5 звёзд в рейтинге по всем параметрам. Однако, вам вполне по силам определить, будет ли вам легко и приятно писать код именно в этой компании.
Перевод: Люся Ширшова. По материалам блога Pamela Fox.
