Наиболее ценные уроки программной инженерии я получил из двух источников:
- Неудачные проекты
- Более опытные разработчики
Вот несколько важных уроков, которые я извлек из опыта работы с senior-разработчиками.
Нет только черного или белого, и всегда есть исключения. Только опыт может подсказать вам, когда следует применять правило, а когда его игнорировать.
Давайте начнем.
Не переусложняйте
В девяти случаях из десяти создание большего количества инфраструктуры, функций или абстракций, чем необходимо, является пустой тратой времени.
Это особенно верно, если вы работаете в стартапе, где направление развития продукта может меняться вслед за ветром.
Несмотря на то, что существуют редкие случаи, когда over-engineering был оправдан (например, WhatsApp), для большинства компаний это не лучший подход.
Я знаю это не понаслышке. Проведя большую часть своей карьеры в стартапах, я написал тонны кода, который так и не попал на рынок или вообще не использовался.
Over-engineering имеет две причины
- Неопытные менеджеры, которые не сокращают фичи.
- Разработчики, которые хотят создавать крутые штуки.
Время разработки — это источник жизненной силы технологической компании. Его нужно расходовать с умом и попутно проверять на полезность. В этом вся идея создания MVP.
Пишите просто достаточно кода, минимизируйте технический долг и увеличивайте масштаб только после подтверждения соответствия продукта рынку.
Вопреки распространенному мнению, выполнение краткосрочных целей — это то, что помогает вам выжить в долгосрочной перспективе.
Автоматизируйте все и знайте свои инструменты
Нормально быть ленивым разработчиком.
Разработчики управляют энергией, а не временем. А переключение контекста — самая большая причина потери энергии.
Любая вещь, уменьшающая переключение контекста, большая победа.
- Настройте свою командную оболочку.
- Изучите горячие клавиши в своей IDE.
- Изучите команды Linux.
- Пишите псевдонимы для всего.
- Изучите Git.
Если вы используете инструмент каждый день, нет причин не быть в нем экспертом. Это принесет вам долгосрочную пользу. Это знания, которые вы возьмете с собой, когда смените проекты или компании.
Но не останавливайтесь на достигнутом. Насколько «ленивым» можно стать?
Если вы делаете что-то более одного раза, автоматизируйте это (особенно, если это связано с развертыванием)!
Считайте, что это время — хорошая инвестиция.
Как ни странно, разработчики старшего возраста понимают этот лучше, чем более молодые разработчики.
Никогда не пишите код без планирования
Написание кода сразу после принятия новой фичи — ошибка новичка.
В моей первой роли разработчика я часто делал это только для того, чтобы обнаружить, что написал код, который не работает или уже существует.
Доска отлично подходит для планирования. Но лист бумаги тоже работает.
По крайней мере, нарисуйте компоненты, которых вы планируете касаться на каждом слое в стеке. Это поможет вам уменьшить масштаб и увидеть, как части сочетаются друг с другом.
Это также помогает другим дать вам обратную связь. Я даже не могу сказать, сколько раз я показывал свой план более опытному разработчику и получал ответ: «Это не сработает. Попробуйте вместо этого такое».
Как мы все знаем, написание кода — самая простая часть работы. Труднее понять, что нужно написать.
В конце концов, все сводится к пониманию того, что вам нужно создать еще до того, как вы начнете. Не начинайте строительство дома без чертежа.
Тесты на вес золота
Пишите больше тестов.
Не интеграционные тесты. Просто проложите ими свой путь к счастью. Они медленно пишутся, обновляются и запускаются.
Но юнит-тесты — ваши друзья. Они быстро пишутся и выполняются, разъясняют, что вы создаете, и защищают от регресса.
Меня никогда не перестает удивлять, когда модульные тесты выявляют пограничный случай, который в будущем мог бы вызвать ошибку. Написание тестов заставляет продумывать все варианты использования.
Вы должны поддерживать только определенное количество нетестируемого кода. Я видел, как проекты выходят из-под контроля, а ошибки занимают 50% или более времени разработки на больших непроверенных кодовых базах.
Исправление ошибок — наименее интересная часть работы разработчика. Тесты помогут вам их избежать.
Задавайте больше «глупых» вопросов
Глупый вопрос лучше глупого pull-реквеста.
Никогда не пишите функцию, основанную на неподтвержденной информации. Если вы не уверены, вам нужно спросить. Нет ничего хуже, чем сделать фичу, не решающую исходную проблему.
Это касается как технических знаний, так и знаний предметной области. Но в последнем случае разработчики чаще ошибаются. Очень важно иметь канал связи между инженерами и продажами, чтобы решать возникающие вопросы в предметной области.
Я обнаружил, что если добавить перед вопросом «Это глупый вопрос, но…» мне становится легче, хотя у вас может быть более толстая кожа, чем у меня.
Хотя ваш вопрос может кому-то не понравиться, все равно он лучше, чем часы работы в неверном направлении.
Люди — это указатели, а не словари
Я узнал об этом от своего первого senior-разработчика.
Не тратьте слишком много времени на запоминание методов или алгоритмов. Оставьте запоминание компьютерам. Любая компания, ожидающая энциклопедических знаний о функциях или синтаксисе, не понимает ремесла разработки программного обеспечения.
Но у вас должна быть возможность быстро искать информацию. Забыть синтаксис — это нормально, но знайте, где найти хороший пример. Это приходит с опытом и небольшим пониманием.
Вместо того, чтобы запоминать детали, изучите концепции разработки программного обеспечения более высокого уровня. Знайте принцип единственной ответственности, шаблоны проектирования и взаимодействуют слои вашего стека.
Это поможет вам рассчитать компромиссы для различных реализаций. Это то, в чем люди хороши, а компьютеры — нет (пока).
Держитесь подальше от микросервисов
Ничто так не добавляет сложности, как микросервисы. Это особенно верно, когда транзакции охватывают несколько сервисов.
Когда вы переключаетесь с монолита на микросервисы, ожидайте, что развертывание, отладка и планирование новых функций увеличатся в сложности на порядок.
Придерживайтесь монолитного приложения, пока оно не станет слишком большим для управления. В противном случае вы переусложняете.
Если у вас есть инженерные ресурсы Spotify, дерзайте. Но если вы команда разработчиков из трех человек, подумайте дважды.
В микросервисах нет ничего плохого. Но во многих случаях они решение, ищущее проблемы, а не наоборот.
И напоследок
Нет ничего более ценного для нового разработчика, чем работа под руководством senior инженера, у которого есть время для наставничества.
Я могу проследить свои самые значительные достижения до нескольких избранных людей, с которыми я работал в прошлом и которые заботились о моем росте.
Непопулярное мнение: это важнее, чем технологический стек, который вы используете, или компания, к которой вы присоединяетесь.
О деталях легко забыть, а уроки более высокого уровня останутся с вами.
Получили ли вы какой-нибудь бесценный совет от других разработчиков?