Как увеличить свою продуктивность в небольшой команде
Я разрабатываю приложения для Android уже более десяти лет, работая все это время как разработчик в одиночку или в очень небольших командах. Мой опыт варьировался от создания собственной дорожной карты и отсутствия проверок кода до ежедневных стендапов и блокировок PR на проверках кода. Как разработчик-одиночка, я исправляю все наши ошибки, проектирую и кодирую все наши новые функции, пишу все наши тесты, оплачиваю весь технический долг и управляю нашей системой сборки, CI и выпусками. С более чем 1 миллионом загрузок приложения, над которым я сейчас работаю, у нас есть 100% сеансов без ANR, 99,9+% сеансов без сбоев, мы регулярно устраняем технический долг и предоставляем функции в течение 6 недель. Мы работаем по 40 часов в неделю и очень серьезно относимся к балансу между работой и личной жизнью.
Недавно я разговаривал с мобильным инженером в одной из крупных технологических компаний, который упомянул, что он находит довольно удивительным, что мы можем сделать все это такой небольшой командой. Это заставило меня задуматься о том, что нужно для эффективной работы в небольшой команде или в среде одиночного разработчика. Я хотел бы поделиться некоторыми из этих мыслей с вами здесь.
1. Познай себя
Что вам больше всего нравится в разработке программного обеспечения? Какая ваша наименее любимая часть? Знайте это и постоянно помните о том, как это влияет на ваши наклонности. Лично я не стал бы исправлять ни одной ошибки, если бы мне не пришлось. Мне просто это не очень нравится. Я бы предпочел спроектировать и написать новый код. Это означает, что мне нужно быть слишком преднамеренным при включении сортировки и отладки в мой обычный рабочий процесс. Если я не делаю этого намеренно, то я избегаю этого и перехожу к тем аспектам, которые мне нравятся. Будьте подозрительны всякий раз, когда вы обнаружите, что ваше расписание заполнено частями работы, которые вам нравятся. Возьмите на себя ответственность. А еще лучше попросите кого-нибудь другого привлечь вас к ответственности. Скажите своему менеджеру, что вам не нравится исправлять ошибки, и попросите его использовать сеансы без сбоев или рейтинг в магазине приложений в качестве одного из ваших показателей производительности, чтобы стимулировать вас делать это. Попросите ее регулярно информировать вас о важных исправлениях ошибок и точечных выпусках. Ваш руководитель оценит вашу самосознание и инициативу, ваше приложение будет лучше, и в результате выиграет ваша карьера.
2. Проверка кода
Найти кого-то, кто проверит ваш код в качестве одиночного разработчика, может быть очень реальной и сложной проблемой. Вы можете быть единственным человеком в вашей компании, который знает язык, который вы используете, или экосистему, для которой вы пишете. Мой главный совет: найдите КОГО-ТО, кто проверит весь ваш код, прежде чем он будет объединен с кодовой базой. Если вы разработчик Android, возможно, есть разработчик iOS, который может сделать для вас проверку кода, или, может быть, ваша компания нанимает бэкэнд-разработчика, который может просматривать ваш код. Может быть, парень из отдела ИТ/эксплуатации, имеющий некоторый опыт написания сценариев на Python, сможет это сделать. Любая проверка кода лучше, чем отсутствие проверки кода.
Что вы должны просить в обзорах кода экспертами, не относящимися к предметной области? Чистый код, подозрительные исправления и очевидные ошибки. Попросите их убедиться, что вы назвали переменные, функции и классы четко и правильно и что вы не оставили никакого закомментированного кода. Попросите их отметить любые исправления, которые кажутся подозрительными, например удаление одной строки кода как «исправить» без какой-либо замены — это может быть правильное исправление, но оно должно поднять флаг относительно надежности. Правило № 1 — познайте себя — как следствие этого, знайте, что в спешке вы будете вносить менее качественные изменения, чем хотели бы иметь в своей кодовой базе. Если бы вы были просто техническим руководителем, вы могли бы отклонить изменения. Но когда вы также являетесь тем, кто должен вносить изменения, у вас будет соблазн позволить им скользить по напряженным неделям. Попросите кого-нибудь просмотреть ваш код заранее, чтобы решить эту проблему. Полдела уже проиграно, когда в бар заходит алкоголик. Не ставьте себя в положение, когда вы потерпите неудачу. Запросите код-ревью. А еще лучше настройте защиту веток, чтобы вам НЕОБХОДИМО было проверять код перед его слиянием. А еще лучше попросите вашего менеджера сделать это, чтобы вы не могли просто отключить его в крайнем случае. Проверка кода — это самая важная вещь, которую вы можете сделать как разработчик-одиночка, чтобы улучшить качество своего кода.
3. Здорово
Первое, что нужно сделать в среде одиночной разработки, — это соблюдать гигиену Git. Если вы мне не верите, посмотрите на первые несколько сообщений о коммитах для каждого побочного проекта, который вы когда-либо начинали.
Added UI UI tweaks More changes Reverted changes Checkpoint Removed some classes
Когда вы единственный разработчик в проекте, легко поддаться привычке думать, что вы пишете коммит-сообщения для себя. Это не так. Вы пишете их для будущих разработчиков (включая себя в будущем). Пишите четкие и лаконичные сообщения коммитов. Фиксируйте преднамеренные, работоспособные наборы изменений — не просто фиксируйте «контрольные точки», как если бы вы периодически сохраняли документ Word. Если вы совершаете несколько коммитов WIP, уничтожьте их и напишите описательное сообщение перед отправкой изменений. Попросите рецензентов вашего кода оставить отзыв о ваших сообщениях о коммитах. В дополнение к хорошему совершению, обязательно хорошо разветвляйтесь. Выберите стратегию ветвления и придерживайтесь ее. Не просто вставляйте изменения в main, чтобы избежать хлопот. Процесс имеет значение. Следуйте хорошей стратегии ветвления git.
4. Хорошо управляйте
Если у вас нет никого, кто бы предоставил вам дорожную карту, сделайте ее сами. Не перескакивайте с одного хобби на другое. Потратьте некоторое время, чтобы подумать о том, какие функции, исправления и рефакторинг наиболее актуальны и важны для вашего продукта. Затем составьте дорожную карту и придерживайтесь ее. Укажите время завершения в своей дорожной карте, даже если никто не держит вас за ноги. Это поможет вам не дрейфовать. Отслеживайте проблемы в специальном трекере — не верьте лжи, что потом вспомните. Вы не будете. Когда вы заметите ошибку, зарегистрируйте ее. Когда вы работаете со сложным фрагментом кода, который в какой-то момент необходимо подвергнуть рефакторингу, зарегистрируйте его. Когда пользователь запрашивает разумную функцию, регистрируйте ее. Как разработчик-одиночка, вы можете выполнять функции менеджера по продукту в дополнение к работе в качестве технического руководителя и инженерной группы. Отнеситесь серьезно к своей роли PM, иначе от этого пострадает ваш продукт.
5. Протестируйте хорошо
К сожалению, многие инженеры часто забывают о тестировании. Мысль такова: «Сначала я напишу код, а затем напишу тесты, если у меня будет время». Это особенно заманчиво для одиночного разработчика, где время еще более ограничено, и никто не проверяет наличие тестов (опять же см. № 2 — попросите рецензентов кода проверить наличие тестов, где это уместно). Проблема в том, что времени никогда не будет. Всегда есть еще одна функция, которую нужно написать, и еще одна ошибка, которую нужно исправить. Пишите тесты сейчас, иначе вы никогда их не напишете, и ваш продукт от этого пострадает. В дополнение к автоматическим тестам обязательно хорошо проведите бета-тестирование. Найдите людей в вашей компании, которые могут выполнять функции внутренних бета-тестеров. Дайте им контрольный список вещей, чтобы искать. Проведите открытое бета-тестирование. Используйте поэтапное развертывание, постепенно увеличивая процент пользователей, получающих ваше приложение. Мы всегда надеемся, что с приложением все в порядке, но если (когда) что-то пойдет не так, мы хотим ограничить радиус поражения, доставляя проблему только 5% пользователей вместо 100%. Даже если ваш работодатель этого не требует, будьте профессионалом и хорошо сдайте экзамен.
6. Пишите чистый код
После хороших сообщений о коммитах следующее, что нужно сделать в среде одиночной разработки, — это чистота кода. Слишком заманчиво думать, что вы единственный, кому нужно читать код, и поэтому вам не нужно явно объяснять свои намерения. Это крайне недальновидно. Хорошо назовите, хорошо организуйте и хорошо документируйте. У вашей кодовой базы будут будущие разработчики. У вашей кодовой базы будет будущее «вы». Оба будут благодарны вам за написание чистого кода. И опять же, если кто-то просматривает ваш код, они также будут вам благодарны или, надеюсь, посоветуют вам изменить его.
7. Нести ответственность за технический долг
Как одиночный разработчик, у вас мало ресурсов, поэтому используйте их с умом. Технический долг — один из таких потенциальных ресурсов. Если вы миллиардер, брать кредит на покупку дома за 250 тысяч долларов, вероятно, не имеет смысла. Это плохое использование долга. Если вы зарабатываете 100 000 долларов в год, то это может быть отличным использованием долга, используя ваши текущие ресурсы для увеличения ваших будущих ресурсов. Как одиночный разработчик, могут быть моменты, когда вам придется пожертвовать «лучше» ради «хорошо» и получить что-то за дверь. Может быть, вы просто скопируете и вставите этот класс пару раз, внеся изменения здесь или там, вместо того, чтобы тратить неделю на написание более общего решения. Общее решение было бы идеальным, но решение с копированием прошлого может быть вполне подходящим использованием технического долга в краткосрочной перспективе, позволяя вам получить что-то, что работает сегодня, чтобы сделать это завтра.
Главное, что нужно помнить о техническом долге, это то, что это долг. Вы должны оплатить его. Как и в случае с финансовым долгом, четко определите, какой долг вы берете на себя и какие потенциальные выгоды он предлагает. Некоторый технический долг — это ипотека на дом, но большая часть технологического долга — это потребительский кредит. Не позволяйте ему накапливаться без конкретной причины и конкретного плана погашения. Для одиночного разработчика может быть легко пропустить это, когда никто не жалуется на это. Если вы берете на себя технический долг, зарегистрируйте его (см. № 4) и запланируйте его исправить. Делайте это регулярно. Возможно, это «цикл рефакторинга», когда вы приостанавливаете разработку функций на месяц или два, чтобы погасить технический долг. Может быть, это более итеративный процесс, когда каждую пятницу проводится уборка, или, может быть, последние 2 недели каждого 8-недельного цикла предназначены для полировки и рефакторинга. Выбирайте то, что лучше всего подходит для вас, но не позволяйте техническому долгу накапливаться, иначе вы в конечном итоге обанкротитесь — вам придется полностью переписать, потому что это кажется единственным выходом вперед.
Заключение
В конечном счете, это одни и те же базовые рекомендации, которым должна следовать каждая инженерная команда. Отличие индивидуального разработчика в том, что у вас больше ответственности за технологии, проекты и руководство продуктом. В дополнение к инженеру вы можете быть техническим руководителем, менеджером проекта и менеджером по продукту в любой комбинации. Это требует большей гибкости, большего самосознания и большей самодисциплины. Но с правильными компонентами и правильными процессами индивидуальный разработчик или небольшая команда могут быть удивительно эффективными.
Спасибо за прочтение. Нажмите кнопку «Подписаться», чтобы узнать больше о передовом опыте в Kotlin, разработке для Android и многом другом. Удачного кодирования!
