Время действительно пролетело за год с тех пор, как я оставил государственную службу, чтобы отправиться в новое путешествие в качестве бэкэнд-разработчика программного обеспечения в Grab, и я подумал, что должен выкристаллизовать несколько мыслей за свое короткое пребывание в Grab.
Как писать производственный код
Возможно, вы слышали поговорку о том, что создание программного обеспечения похоже на попытку заменить двигатель самолета в полете или, может быть, на замену шин на машине во время ее движения. Это, как ни странно, было чем-то, с чем я могу связать в прошлом году: добавление новых функций продукта, завершение миграции с 8-летней чат-платформы на более новую, исправление проблем и сбоев по вызову, и все это при попытке снизить затраты на облако. системы! Итак, что я узнал о создании сложных систем разработки программного обеспечения?
Во-первых, разработка программного обеспечения — это создание системы, которую можно поддерживать и расширять. Есть хорошая цитата из книги Разработка программного обеспечения в Google о том, что разработка программного обеспечения — это не просто программирование, а программирование во времени. Код программного обеспечения часто переживает инженеров, которые его написали, и несколько поколений инженеров обычно годами работают над системой, и каждый инженер привносит свой собственный вкус и стиль в способ написания кода. Я не ожидал, что на самом деле потрачу больше времени на чтение существующего кода, чем на его написание! Следовательно, на самом деле важнее сосредоточиться на удобочитаемости кодовой базы, чем придумывать высокооптимизированный, но запутанный алгоритм, для понимания которого требуется время. Существует много таких способов написания чистого кода, и одним из таких примеров может быть самодокументирующийся код с правильно названными функциями и именами переменных, чтобы чтение кода не вызывало путаницы.
Я также понял, что разработка программного обеспечения — это не просто ванильное кодирование, и на самом деле я трачу менее 50% своего времени на кодирование, что обычно удивляет людей, когда я им об этом говорю, поскольку они представляют себе хакерский стереотип человека, сгорбившегося впереди. из трех мониторов с экраном кода. На самом деле, чтобы создавать хорошие программные системы, мы в Grab также в значительной степени опираемся на многие другие блестящие инструменты, такие как техническая документация (например, внутренние вики, документы Google), инструменты мониторинга в реальном времени для оценки состояния системы (например, ELK). , Datadog), инструменты для отслеживания истории изменений кода (например, Github), инструменты тестирования для поиска ошибок в новом коде до того, как они попадут в рабочую среду (например, модульные тесты, надежная промежуточная среда), и этот список можно продолжить. Поэтому неудивительно, что разработка программного обеспечения — это гораздо больше, чем просто штамповка кода.
Как решить инженерную проблему
Разработчикам программного обеспечения также часто бросают нечеткие формулировки проблем или требования к продукту, и наша работа состоит в том, чтобы разбить эти формулировки проблем на конкретные и действенные элементы. Например, если мне нужно уменьшить задержку моего API на 25% с 200 мс до 150 мс, это может означать:
- Инструментирование API для сбора данных о том, какие типы запросов занимают больше всего времени
- Затем я могу решить, следует ли нам написать более эффективный запрос к базе данных.
- Может быть, я мог бы отказаться от некоторых ненужных вычислений или запустить несколько процессов одновременно
- Или, может быть, даже прийти к выводу, что API уже хорошо оптимизирован, а преимущества для бизнеса не оправдывают инженерных затрат на сокращение этих нескольких миллисекунд.
Всегда есть компромиссы для каждого решения, и каждая новая функция или требование обычно увеличивает затраты либо напрямую из-за затрат на инфраструктуру, либо косвенно из-за инвестиций в инженерные часы или усилий по обслуживанию системы с течением времени. Задача инженера — придумать несколько возможных решений, перечислить их плюсы и минусы, обсудить компромиссы с другими продуктовыми или бизнес-командами, чтобы прийти к консенсусу, и все это до того, как приступить к написанию одной строки кода!
Неудивительно, что все это означает, что коммуникативные навыки необходимы для работы, и иногда инженерам приходится участвовать в большем количестве дискуссий, чем они фактически тратят на кодирование и создание решений. Верно и то, что большая часть времени, затрачиваемого на решение инженерных задач, может быть отнесена на устранение различий во взглядах между людьми и достижение консенсуса. Корпоративная культура и командная динамика играют огромную роль в разработке программного обеспечения, поскольку ни один инженер-программист, каким бы талантливым или трудолюбивым он ни был, не может самостоятельно построить хорошо функционирующую сложную систему. Мне очень повезло, что моя команда в Grab имеет отличную инженерную культуру, состоящую из талантливых и скромных людей, которые отложили в сторону свое эго для решения инженерных задач.
Всегда учись
Наконец, упоминать об этом кажется банальным, но мир программного обеспечения постоянно развивается и растет, и невозможно знать все, что нужно знать. Всегда есть новый язык программного обеспечения, инфраструктура или технология, которые появляются каждый год, и даже опытным инженерам, присоединяющимся к новой компании, потребуется время, чтобы понять кодовую базу, инфраструктуру и инженерные процессы, которые поначалу могут быть действительно ошеломляющими! Смирение действительно важно, так как невозможно расти и учиться, если ты считаешь себя экспертом во всем. Для меня было много вещей, с которыми я впервые столкнулся в Grab:
- Язык программирования Go
- Использование Gitlab и проверка кода
- Развертывание с использованием конвейеров CI/CD собственной разработки в инфраструктуре AWS
- Terraform для инфраструктуры как кода
- Базы данных No-SQL с высоким трафиком, такие как DynamoDB и Redis
Я уверен, что этот список будет пополняться с годами, но мне нравится быть в состоянии роста и постоянно сталкиваться с проблемой выхода из моей зоны комфорта! Мои руководители в Grab также были готовы рискнуть и доверить мне несколько сложных, но важных проектов, которые были амбициозными. Только получив новый опыт и получив возможность работать над решением новых проблем, мы можем продолжать расти и оттачивать свои навыки инженеров-программистов.
В заключение, я не знал, чего ожидать, когда начал свой путь инженера-программиста, и мне очень понравился прошлый год работы в Grab. Если кто-то из моих коллег читает это, спасибо вам, ребята, за то, что поделились своим опытом и направили меня, а также за то, что вы справились с моими недостатками! Для тех, кто подумывает о переходе на программную инженерию в середине своей карьеры, если что-то из того, что я сказал, находит отклик в вас, и вы думаете о том, чтобы совершить прыжок, свяжитесь со мной, и я буду рад поделиться чем-то еще за чашкой кофе!
