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

Ошибки программистов проходят через очень хороший контроль: автотесты, отделы QA, тестовая аудитория. Даже когда ошибка добирается до продакшена, остается еще несколько слоев защиты от дурака: Kubernetes не заведет больной контейнер, дежурный инженер откатит непрошедшую миграцию.

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

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

На таких страхах вырастают неуклюжие, плохо пахнущие классы с копипастой, которые постепенно превращаются в легаси.

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

Если вы задаетесь этим вопросом, значит вам — не нужен.

Проблема докера — в пороге вхождения. Уметь докер — это как уметь HTML: чтобы его применить, нужно учить еще вагон технологий: CSS, JS, и еще бекенд желательно. У докера этот вагон состоит минимум из swarm (а лучше k8s), чтобы запускать контейнеры, prometheus, чтобы их мониторить, и кучи самописных скриптов, чтобы все это деплоить.

Такие сложности имеют смысл, когда ваша команда дорастает до разделения на разработку и эксплуатацию, или вы начинаете БЫСТРО масштабироваться. Тогда докер становится удобным языком общения между командами и хорошим помощником, чтобы моментально поднимать инфраструктуру на любой площадке.

Если вы до этого еще не доросли, то используйте докер «как все» — чтобы быстро разворачивать куски инфраструктуры на машине разработчика.

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

У вас появился выделенный тестировщик. Тестировщикам нужно окружение для каждой новой задачи. Если задача упала тестировщику — рядом с ней должна лежать ссылка на песочницу, в которой ее можно потыкать.

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

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

Сначала эта заметка вышла на моем телеграм-канале. Подписывайтесь, чтобы читать быстрее и больше.

Есть два режима жизнедеятельности — производство и потребление.

Производство — это когда после вас остаются артефакты: код, письма, идеи, макеты. Потребление — все остальное. Написать программу — производство, посмотреть фейсбук — потребление.

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

В увеличении производства в первую очередь заинтересованы вы сами. Чем больше вы делаете (или другие, с вашей помощью) — тем быстрее достигаете целей.

Человечество изобрело кучу инструментов для потребления — телефоны, торговые центры, push-уведомления, шаурма у метро.

Инструментов для производства, вроде скетча, макбука и молескина — наоборот, мало. На самом деле, можно производить больше, чем 95% людей, имея только сильное желание и блокнот, но это тема для отдельного разговора.

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

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

Самая большая ошибка — вместо тестового задания давать абстрактные задачи на знание алгоритмов. Часто ли в работе ваши программисты обходят графы или вручную реализуют шейкерную сортировку?

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

Такое задание — как открытый вопрос. Поймет ли новенький наш стиль для названий тестов? Не испугается ли сложности? Дополнит ли документацию? Напишет ли переиспользуемый код? Не постесняется задавать вопросы? Выдержит ли дедлайн, который сам назовёт?

Если вдруг проект не получается отдать из-за НДА-шных причин — отдаю специально хранимый для этих целей pet project.

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

Самое главное правило — не обманывать себя при планировании и помнить, что планы без запаса не сбываются.

Свой запас я держу в буфере, который называется «можно проебать» — это прям такой лейбл в трекере. Лейбл ставится на задачи, которые мы будем делать только, если успеем закончить более важные.

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

Если спринт спланирован хорошо, то примерно половина из буферных задач успешно закрывается. Если плохо — закрываются или все, или ни одной.