Перевод статьи «6 Productivity Practices for New (or Old) Developers».
Люди — сложные создания, и к работе их мотивируют самые разные вещи. Например, разработчиков к написанию кода побуждает не только финансовая составляющая, но и удовольствие от собственно написания кода или создания программ.
Вы можете быть ориентированы на то, чтобы побыстрее запустить программу в производство и оставшееся время провести с семьей. Такие разработчики стремятся создавать нечто, имеющее ценность, и придерживаются принципа YAGNI.
А ваш коллега, работающий дома на расстоянии двух городов от вас, может быть планировщиком — человеком, который получает удовольствие от создания правильных абстракций и точного дизайна.
У вас двоих может быть разное понимание того, как нужно создавать программы, но вы оба стремитесь к продуктивности работы. Несколько моих бывших менеджеров могли бы со мной поспорить, но я уверен, что большинство людей, безотносительно к их мотивации, стремятся быть продуктивными.
Шесть техник, представленных в этой статье, помогут вам максимизировать вашу продуктивность и ускорить работу.
1. Используйте язык, подходящий для вашей задачи
Был у меня однажды сосед по комнате, который использовал мои плоскогубцы в качестве молотка. Свои картины он, конечно, повесил, но плоскогубцы мне испортил. К тому же, с молотком он управился бы быстрее. Аналогичным образом использование языка программирования, подходящего для вашего приложения, может существенно ускорить вашу работу и сделать ее куда эффективнее.
Например, корни Python лежат в научных вычислениях, и этот язык отлично подходит для науки о данных. Разработчики, ценящие стабильность и последовательность в решении задач, непременно полюбят Python. А вот Ruby прекрасен в деле создания сайтов, к тому же его сообщество допускает множество подходов к решению одних задач.
PHP — отличный вариант для быстрых серверных приложений, да и развернуть его можно где угодно. Этот язык и его экосистема прошли долгий путь. Для работы над вашим проектом вы можете составить команду, выбирая из легионов PHP-разработчиков.
Node.js позволяет веб-разработчикам использовать один язык и на стороне сервера, и на стороне клиента, правда, за счет некоторого усложнения. Но вы можете оптимизировать Node.js, если вам нужен чрезвычайно интерактивный опыт в клиентской части.
Не позволяйте веяниям моды влиять на ваш выбор языка. Используйте те языки и технологии, которые больше всего подходят для вашего конкретного проекта. Десять лет назад мы начали рендерить страницы на сервере при помощи некоторых декораций JavaScript. Лет пять назад мы начали рендеринг на стороне клиента, при помощи REST или GraphQL APIs для данных. В начале 2020 мы вернулись к более простым приложениям, которые рендерятся на сервере при помощи декораций TypeScript.
2. Не разворачивайте вашу собственную систему аутентификации
Я работал над несколькими проектами, в которых команда реализовала в приложении кастомную аутентификацию, включающую хранение хэшей паролей в базе данных. Это было зря. В то время у нас была инфраструктура для делегирования аутентификации Active Directory, благодаря которой пользователи могли бы использовать тот же пароль, что и для входа в Windows. Но в силу закона Конвея и из желания потешить свое эго мы упустили эту возможность.
Подумайте: действительно ли вы хотите решать проблемы, связанные с внедрением собственной системы аутентификации, сейчас, когда есть Auth0 и подобные продукты? Возможно, наилучший инженерный компромисс — делегировать аутентификацию Auth0? Так вы сможете получить MVP, а уж затем, по мере масштабирования, подумать о стоимости модернизации. Вы также получите множество дополнительных функций и лучшую защиту ваших приложений.
Многие люди строят лодки, но мало кто собирает собственные лодочные моторы. Зачем рисковать заглохнуть в море, если можно купить Yamaha и без проблем возвращаться домой?
3. Сначала пишите модульные тесты
Написание тестов похоже на чистку зубов. Чистка зубов определенно лучше, чем кариес. Порой очень хочется приступить к реализации кода, но на пути стоят тесты. Чувствовать некоторое раздражение при этом вполне естественно.
Перейти сразу к реализации, невзирая на тесты, может показаться продуктивным решением, но в результате у вас может получиться дурно пахнущий код: слишком длинные методы и списки параметров — лишь начало. В конечном итоге ваш код будет труднее тестировать и поддерживать. Конечно, иногда код пишется просто для проверки концепции, а после удаляется. Не забудьте в таком случае сделать git reset и реализовать все заново, уже с модульными тестами. Так у вас получится лучший дизайн.
Очень легко понять, когда модульные тесты делаются постфактум. Обычно они очень топорные, поскольку должны проверять крупные классы. Такой подход не позволяет извлечь из тестов максимальную пользу. Хорошо написанный юнит-тест помогает выявлять проблемы и устранять или моделировать зависимости, которые в реальном мире могут послужить причиной того или иного поведения программы. Тестирование кода, имеющего реальные, жизненные проблемы, может быть трудным. А когда вы разделяете проблемы и тестируете все по отдельности, дело обстоит проще.
Если всего этого недостаточно, чтобы вас убедить, могу сказать, что если вы попросите дать вам еще немного времени на написание тестов уже после того, как довели до рабочего состояния непротестированный код (и этот код уже прошел QA), ваш менеджер проекта будет в бешенстве.
Чтобы достичь успеха с модульными тестами, разбивайте функционал на маленькие циклы «красный, зеленый, рефакторинг»:
- Красный. Начинайте с написания провального юнит-теста. Создавайте заглушки для действий из «жизненного» сценария, чтобы иметь возможность запускать эти тесты в любой момент.
- Зеленый. Пишите код, который пройдет ваш модульный тест.
- Рефакторинг. Если вам нужно подчистить ваш код, можете это сделать на третьем этапе, после чего нужно снова запустить модульный тест.
Повторяйте цикл.
Используя этот алгоритм действий, вы будете более уверены в своем коде и сможете смело улыбаться менеджеру, отмечая фичу как готовую.
4. Используйте преимущества, которые дают SaaS, IaaS и PaaS
Когда системные администраторы носили армейские ботинки, постоянно хмурились и размещали серверы в стойках, было понятно, что их работа отличается от работы разработчиков. Сегодня роли не так однозначны. Команды комплектуются не так, как раньше. От нас ожидается наличие большего числа навыков и готовность заняться чем угодно по мере необходимости. В результате разработчики часто тратят слишком много времени на выполнение задач, не связанных с написанием кода (инфраструктура, DevOps, интеграции). Все это очень важно, но не эти вещи делают программы работающими.
Провайдеры IaaS («инфраструктура как сервис»), такие как AWS, берут на себя все задачи по запуску инфраструктуры. С их помощью вы можете развернуть новую версию своего приложения при помощи простого git push. Вам не нужно рассчитывать подсеть, проектировать сетевую архитектуру или спорить с администратором баз данных: провайдер IaaS обо всем этом позаботится сам.
Все улучшается. Сотни компаний берут то, что когда-то было рутинной частью проектов, и предлагают свое программное обеспечение как сервис (SaaS).
Например, вам не нужно настраивать репликацию Logstash и ElasticSearch. Есть по крайней мере полдюжины компаний, которые изымут все логи из вашего приложения и дадут вам возможность удобного поиска по логам и их удаления через 90 дней, чтобы вы не получили штраф GDPR в будущем. Многие компании также доставляют электронную почту и SMS, и для этого нужна только кредитная карта и клиент API. Двадцать лет назад сварливым системным администраторам пришлось бы настраивать Sendmail, читать логи, пить кофе и сыпать проклятиями — и все это одновременно.
Конечно, и сейчас нет универсального решения. Вам нужно научиться находить самых надежных и добросовестных провайдеров всех этих услуг. На этом рынке бывает шумно. Кроме того, оплата услуг всех этих провайдеров вызывает раздражение. В идеале вы не должны указывать кредитную карту своего менеджера в каждом приложении и ежемесячно выполнять танцы с бубном, чтобы получить счета.
Наконец, провайдеры PaaS («платформа как сервис») вроде Heroku провели как минимум последнее десятилетие, изучая, как отправить на аутсорс не только хостинг приложения, но и рынок аддонов. Они берут на себя инфраструктуру и платформу с готовыми инсталляциями самых разных стеков технологий. Вы можете воспользоваться услугами такого провайдера, оплатить один счет и вывести свои идеи на рынок всего за несколько часов.
5. Прислушивайтесь к своей IDE
Из древнегреческой мифологии мы знаем о Кассандре, жрице Аполлона. На ней лежало проклятие: хотя ее предсказания были точными, им никто не верил. Ваша IDE тоже многое предсказывает, например, говорит вам, что у вас слишком высокая цикломатическая сложность, что вот в этом блоке нет итогового дефолтного предложения и т. п. Не прислушиваясь к своей IDE, вы будете тратить много времени на отладку.
Помимо встроенного функционала вашей IDE или вашего редактора существует еще и огромная экосистема линтеров. Особого упоминания заслуживает SonarLint, поскольку он поддерживает большинство популярных IDE (Eclipse, IntelliJ, Visual Studio, VS Code) и дает отличные рекомендации по проблемам безопасности, указывает на едва заметные баги и запахи кода.
Очень хорошо, если ваша команда использует SonarQube для измерения качества кода. Внесение подсказанных изменений гарантирует, что вы отправите в коммите безопасный и поддерживаемый код.
Пускай ваша IDE будет предсказательницей, которой верят. Ее рекомендации снижают риски и уменьшают сложность вашего кода.
6. Создайте процедуру сборки и сделайте ее быстрой
Хороший инструмент сборки это невидимый поезд, на котором ваш код едет в продакшен. Когда вы разработчик-одиночка, вы можете запустить свои тесты и развернуть код в локальной среде разработки прямо из вашей IDE. Это отличный вариант, поскольку у вас, вероятно, будет быстрый цикл обратной связи. Это позволит вам экспериментировать с кодом весь день напролет.
Но когда вы начинаете сотрудничать с другими разработчиками, вам нужно, чтобы код запускался в CI/CD-конвейерах, которые, так уж исторически сложилось, не слишком хорошо ладят с десктопными инструментами разработки. Makefile, build.gradle и другие инструменты сборки, подходящие для вашего языка и среды запуска, позаботятся о том, чтобы ваш код и тесты запускались вне вашего компьютера. Более того, вы также получите место для автоматизации некоторых аспектов деплоймента, таких как миграции базы данных, формирование пакетов и т. п.
Более легкий и быстрый выпуск
Выпускать функциональное ПО для пользователей, которые его оценят, очень приятно. Но есть много факторов, способных снизить вашу производительность и таким образом замедлить выпуск. Это не беда, потому что вы можете предпринять некоторые шаги, чтобы упростить и ускорить свою работу. Я надеюсь, что хотя бы один из шести приведенных мной методов повышения продуктивности сделает вашу работу (и вашу жизнь) немного проще.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
Красивые советы. Правда, как по моему, использование TDD иногда сильно затягивает реализацию. К этому совету надо приписать меру в тестах, часто, при таком подходе, можно зациклился в бесконечном продумывании тест кейсов.