Хочешь сохранить работу в сфере программирования — пиши нечитаемый код, понятный только тебе одному. И чем он хуже, тем лучше. Не делись ни с кем своими знаниями, держи их при себе. Когда ты уволишься, все созданные тобой проекты в одночасье рухнут. Ты незаменим, а значит, не подлежишь увольнению.
Конечно же, это шутка.
Хороший программист владеет знаниями, а лучший — делится ими с другими. Индустрия информационных технологий (ИТ) предполагает совместное использование информации. Чем больше людей ею владеют, тем быстрее развивается организация.
С точки зрения проектирования целого единая точка отказа — это компонент, нарушение работы которого выводит из строя всю систему. Для повышения ее надежности применяется резервирование, которое позволяет избежать выше упомянутой проблемы.
Вряд ли вы захотите оказаться этой самой единой точкой отказа. Скорее всего, вы с коллегами предпочитаете быть дублирующими источниками знаний друг для друга, при этом одинаково достоверными.
Когда все в команде знают то же самое, что и вы, то они легко могут взять на себя решение ваших задач. Так что спокойный отпуск вам гарантирован — никто не потревожит телефонным звонком.
Даже после ухода из компании коллеги будут вспоминать вас добрым словом, поскольку вы не оставляли после себя недомолвок.
В статье я поделюсь 8 ежедневными мероприятиями, которые не позволят вам превратиться в слабое звено в системе.
1. Ротация функциональностей
Ротация позволяет избежать постоянного вовлечения в работу тикетов с одной и тоже функциональностью. В зависимости от частоты назначения или принятия тикетов к исполнению ротация функциональностей должна осуществляться на ежедневной или спринтерской основе.
Если вы занимаетесь какой-то функциональностью сегодня, то завтра ее должен подхватить кто-то другой. Так продолжается до тех пор, пока вся команда не поучаствует в ее разработке. Важно убедиться, что:
- Каждый поработал над разными функциональностями системы и является экспертом в нескольких областях.
- Функциональность разрабатывалась несколькими специалистами. Отсутствие одного никак не отражается на потери контекста.
Не стоит эмоционально привязываться к отдельной функциональности — все они одинаково заслуживают вашего внимания.
2. Создание небольших пул-реквестов
Ревью кода происходит по разным поводам. Самый распространенный из них — пул-реквесты, которые также предоставляют возможность партнерам по команде ознакомиться с вашим кодом.
Исходя из документации Engineering Practices от Google, предпочтение отдается небольшому пул-реквесту (он же список изменений или CL) по следующим причинам.
- Ускоренное ревью. Рецензенту проще выделить несколько раз по 5 минут для проверки небольших CL, чем 30 минут для изучения одного большого.
- Более тщательное ревью. При наличии большого числа изменений ревьюеры и авторы вынуждены перебрасываться многочисленными подробными комментариями. Ничего, кроме раздражения, это не вызывает. В результате велика вероятность пропустить/опустить важные моменты.
Чтобы партнеры по команде поняли и приняли ваши изменения, небольшой пул-реквест должен обладать следующими характеристиками.
- Только одно небольшое изменение. Если в сообщении коммита длиной 80 символов приходится использовать союз “и”, то вы наверняка выполняете в этом коммите более одного изменения.
- Описание изменений. Краткое описание, скриншот, номер тикета или ссылка на сопутствующие пул-реквесты помогают ревьюеру понять контекст проверяемого PR.
- 100 строк. Это лишь предполагаемое число, а не строгое ограничение. Изменение в 200 строк в одном файле еще можно осилить в отличие от 200-строковых изменений, разбросанных по нескольким из них.
Функциональность можно разбить на части, а те в свою очередь на несколько коммитов и пул-реквестов.
3. Совместный разбор крупных пул-реквестов
Если вы исчерпали все возможности разделить объемное изменение на серию небольших фрагментов, то крупный пул-реквест неизбежен.
В этом случае предложите ревьюерам устроить 10–15 минутный сеанс совместного его просмотра. При этом необязательно подключать всех участников команды — достаточно парочки толковых специалистов, способных разобраться с контекстом. В процессе сеанса пройдитесь по всем изменениям и объясните, почему вы реализовали их тем или иным способом.
Во время такого обсуждения у ревьюеров появляется возможность задать более детальные вопросы: “Не проще ли выполнить это другим способом?” вместо “Что делает данная функция?”. Более того, благодаря такому подходу они лучше запомнят рассмотренные изменения.
4. Демонстрация технических результатов спринта
Этап “Покажи и расскажи” (известный еще как Демо) — это один из цикла спринтов в методологии Agile для демонстрации результатов, достигнутых на предыдущем этапе. На этом мероприятии присутствуют не только разработчики проекта, но также заинтересованные лица и другая аудитория, не столь хорошо разбирающаяся в технической стороне вопроса.
Главная цель — поделиться информацией с общественностью вне проекта, но такая демонстрация не добавляет никакой ценности разработке ПО.
Похожее собрание по обзору достигнутых результатов не помешало бы и разработчикам, но с акцентом на технических аспектах. Как только ревьюеры ознакомятся с изменением в пул-реквесте, уместно собрать всю команду и представить отчет по важными итогами проверки.
Необязательно готовить какие-то грандиозные отчеты. Вы можете рассказать о тикете, выполненном в рамках данного спринта, которым вы особенно гордитесь. Например:
- как вы сократили число повторных рендерингов;
- как организовали сквозное тестирование;
- как исправили ошибку и как в дальнейшем ее предотвратить.
Любой разработчик организации допускается для участия в подобных собраниях, тематика которых может быть менее специализированной. Таким образом информация распространяется по всей компании, сотрудники которой не тратят время на изобретение велосипеда, поскольку они уже в курсе, существует ли решение и к кому обратиться за помощью.
5. Парное программирование
Парное программирование — один из приемов экстремального программирования, подразумевающий совместное написание кода двумя разработчиками за одним компьютером. Тот, кто пишет код, — водитель, а его напарник, наблюдающий за процессом и направляющий его ход, — штурман. В течение дня роли могут меняться по нескольку раз.
В каких-то компаниях разработчики практикуют парное программирование на повседневной основе. Кто-то обращается к этой модели периодически. Данная практика отлично подходит для быстрой интеграции новых сотрудников в рабочий процесс. Применима она и при увольнении разработчиков в рамках процесса передачи знаний.
Хотя многим программистам (в том числе и мне) не нравится парное программирование, нельзя не признать, что оно является, вероятно, наилучшим способом обмена знаниями. Ротация пар разработчиков в совокупности с ротацией функциональностей как нельзя лучше позволят сохранить контекст и обеспечить общую осведомленность о рабочих процессах.
6. Создание документации с возможностью поиска
Писать документацию в статичных файлах Word, Powerpoint и PDF — все равно что запереть книги в сейф и бросить его в океан. Во-первых, никому не понятно, как их извлечь. Во-вторых, никто не знает, что они вообще существуют. Наконец, когда их кто-то находит, они уже устаревают.
Используйте для документации подходящие инструменты. Confluence — один из моих любимых, поскольку допускает возможность поиска содержимого. В нем вы можете документировать почти все что угодно, включая архитектуры систем, записи совещаний, отслеживание задач и т. д.
По умолчанию Confluence интегрирован с Jira, еще одним инструментом для отслеживания функциональностей и ошибок с возможностью поиска документации. Находить тикеты Jira можно по краткому описанию, проекту, назначению и т. д.
Сформируйте у себя полезную привычку к ведению документации перед началом работы и в процессе нее. Если откладывать ее за неимением времени, то вряд ли это самое время у вас вообще появится.
7. Переход от личных сообщений к общению в рабочих каналах
Обмен сообщениями должен быть по возможности максимально открытым, за исключением личной или конфиденциальной переписки.
Такие мессенджер-платформы для организации рабочих пространств, как Slack и Teams, позволяют создавать открытые или закрытые каналы (или группы). Они предназначены для опросов и обсуждений, связанных с командной или проектной работой, а также служат своего рода внутренним Stack Overflow.
Любой сотрудник организации может присоединиться к открытому каналу и посмотреть, какие темы обсуждались или какие вопросы поднимались. Таким образом вы экономите много времени, поскольку:
- знаете, к кому обратиться с вопросом;
- не дублируете уже прозвучавшие вопросы;
- не отвечаете на вопросы, ответы на которые уже известны.
Информация, почерпнутая из канала, отличается большей точностью, чем та, что получена от отдельного человека. Если в группе размещаются неверные или устаревшие сведения, то найдутся те, кто сразу же их подкорректирует.
Если кто-то обращается к вам через личные сообщения и интересуется какими-либо проектами, вежливо переместите беседу в соответствующую группу, чтобы не быть единственным источником информации.
8. Рассылка копий писем членам команды
Электронные письма легко пропустить, поскольку у большинства людей насчитываются сотни таких непрочитанных посланий. В отличие от группового чата электронная почта представляет собой закрытый канал, так как никто не осведомлен о происходящем, пока их не внесут в список получателей копий рассылки.
Чтобы сделать почтовый канал более открытым, при отправке письма разошлите его копии членам команды и всем, имеющим отношение к делу. Не бойтесь спамить их почтовые ящики, ведь электронная почта — не самый навязчивый способ общения. Люди могут игнорировать письма, но у них всегда должна быть возможность отыскать нужные из них.
Если кто-то написал вам лично по поводу каких-либо проектов, отправьте копии ответа всем участникам команды.
Краткие итоги
Обобщим рассмотренные выше 8 ежедневных мероприятий, благодаря которым вы гарантированно не станете слабым звеном в общем процессе.
- Ротация функциональностей.
- Создание небольших пул-реквестов.
- Совместный разбор крупных пул-реквестов.
- Демонстрация технических результатов спринта.
- Парное программирование.
- Создание документации с возможностью поиска.
- Переход от личных сообщений к общению в рабочих каналах.
- Рассылка копий писем членам команды.
Конечно же, это не исчерпыващий список мероприятий, которые вы можете предпринять во избежание статуса единоличного обладателя знаний. Делитесь информацией с радостью!
“Залог приобретения силы — в обмене знаниями, а не в их накоплении”, — Мария Кхан.
Читайте также:
- Век программируй, век учись
- Реальный способ стать хорошим программистом
- Как научиться программировать по 8 часов в день
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Meng Taing: 8 Daily Development Routines To Ensure You’re Not the Single Point Of Failure
