Федор Борщев

Какие технологии выбрать для нового проекта?

Эта заметка — для менеджеров, которые принимают решение о выборе технологического стека. Если вы CTO, программист или просто готовы поговорить о различиях языков программирования — бросьте чтение, дальше скучно.

За пару дней до Нового Года я решил выбрать робот-пылесос. На рынке есть десятки брендов — iClebo моет полы, iRobot лучше всех строит карту помещения, Дайсон — мощный, а Сяоми вроде бы самый крутой, и стоит в 5 раз дешевле. Объединяет всех производителей одно — нихуя не понятно, какую из характеристик нужно выбрать, чтобы конкретно в моей квартире стало всегда чисто.

Когда руководитель не может делегировать выбор технологий для нового проекта, он оказызывается в такой же ситуации, как я на Новый Год. Проект нужно было начать еще вчера, а чем Руби отличается от Питона и Раста, и как эти отличия отразятся на сроках и целях — непонятно.

Выбор технологий с точки зрения менеджера

Ответ про пылесос я в итоге нашел на вечнозеленом ixbt. Но с языками программирования так не получается — вменяемых материалов нет. Даже если вы неделю будете изучать реддит, то узнаете только как правильно троллить ПХПшников или что наследование в Го лучше чем в Джаве. Какое это имеет отношение к срокам и целям — непонятно.

А ответ простой — новый проект нужно начинать на стеке, с которым работает команда, способная гарантировать результат. Вы же не обсуждаете с дантистом диаметр бура, а с дворником виды метел? С дантистом вы договариваетесь о том, чтобы не болели зубы, с дворником — чтобы во дворе не валялся мусор.

Начинайте новый проект на стеке, с которым работает команда, способная гарантировать результат

Вы же менеджер, вот и управляйте проектом: договоритесь с командой о несдвигаемом дедлайне, узнайте что они будут делать, когда поймут, что не успевают. Найдите, наконец, запасную команду — пойдете к ним, если текущие ребята вас обманут. Но выбор технологий оставьте профессионалам.

Еще раз — подойдет любой язык программирования (кроме JS, конечно). Главное, чтобы те, кто на нем пишет, гарантировали результат. И у вас было, кем их заменить.

Если остались вопросы про выбор — пишите на почту.

Писать тесты — вежливо

Самое важное в общении распределенной команды — писать так, чтобы не переспрашивали. Когда коллега из Гонконга в следующий раз выйдет на связь — никто не знает, а значит в сообщении должно содержаться все необходимое для выполнения задачи.

Полный пиздец начинается, когда общаются распределенные программисты, и глючит переданный код. Из-за разных часовых поясов начинаются ночные посиделки, а десятиминутная задача растягивается на неделю.

Если работаете над задачей вдвоем — используйте тесты для документирования. Написал новый эндпоинт в АПИ — дай ссылку на тесты ключевых возможностей. Исправил ошибку — выложи тест, который это проверяет.

Хорошая передача эстафетной палочки — 3 ссылки на тесты
Хорошая передача эстафетной палочки — 3 ссылки на тесты

Не пишете тесты? Откройте лучше автомойку, или завербуйтесь к газовикам на север.

Автоматизация рутины программиста

Год назад я вернулся к программированию и начал присматриваться, что изменилось в окружающей среде за последнее время. Оказалось, ничего — современный стек технологий до сих пор доступен только крупным компаниям, все остальные так и живут в каменном веке.

Программисты по-прежнему не пишут тесты, не измеряют качество кода и занимаются обновлением серверов вместо бизнес-логики. Хорошо, если хоть файлы на сайте по ФТП не правят. Руководство, видимо, привыкло к плохому — так и живут с проебывающимися сроками и десятком багов на боевом сервере.

6 сервисов для автоматизации рутины программиста

В хорошей команде рутиной занимается робот, а программисты думают только о полезном действии. Рутина выматывает, а хорошо отлаженная автоматизация — наоборот, заставляет концентрироваться на важном.

Если рядом с вами программируют хоть что-нибудь сложнее сайта-визитки на вордпрессе — проверьте эти 6 направлений:

  • Непрерывная сборка и запуск. Решает проблему с выкатыванием софта — программисту достаточно отправить коммит в репозиторий, дальше все случается без его участия — запускаются тесты, собирается фронтенд, снимаются метрики. Если код в коммите рабочий, продакшн обновляется автоматически. Хороший сервис — CircleCI.
  • Замер качества кода. Ключевые метрики — покрытие тестами, сложность, читаемость, наличие копипейста. Хороший сервис — Code Climate.
  • Отдельным пунктом — процент покрытия. Это соотношение кода, который выполняется во время прогона тестов к общему количеству кода в приложении. Если у вас проверяется меньше 80%, значит вы пишете плохой код. Если покрытие меньше 50%, а вы работаете над новыми фичами — вы работаете зря. Хороший сервис — Codecov.
  • Обработка ошибок. Хранит журнал ошибок и позволяет анализировать продакшн на основе реальных цифр, а не жалоб пользователей. Хороший сервис — Sentry, есть клиенты для всех языков, включая браузерный JS.
  • Мониторинг производительности. APM снимет трейсы самых долгих запросов прямо с продакшена, нарисует графики скорости и подскажет узкие места, которые приводят к тормозам. Для каждого фреймворка нужен свой APM, для Джанго я использую Datadog. Еще есть New Relic и куча других.
  • Облачный хостинг. Если на вашем проекте есть жужжащая железяка с сисадмином в комплекте — смело избавляйтесь. Дешевле и проще взять ресурсы в аренду и исключить человеческий фактор, чем владеть коробкой, которая не приносит денег. Идите в Azure или хотя бы в Digital Ocean.

Что-то забыл? Пишите в комменты. Интересуетесь автоматизацией? Начните с free-for-dev.