Меня зовут Антон. Я архитектор веб проектов и инженер. Проектирую решения для бизнеса, участвую в реализации. Делюсь получаемым опытом. Разработкой как осовной работой занимаюсь с 2011 года. Начинал на фрилансе, затем прошел путь от разработчика/тимлида до архитектора на разных и интересных проектах, например Skyeng. В настоящий момент архитектор хайлоад проекта в компании ВсеИнструменты.

Тут буду делиться:

- Полезными знаниями о php/golang программировании
- Опытом внедрения и использования различных решений и технологий, с которыми довелось поработать
- Полученным опытом в управлении командами
- Интересными новостями в сфере веб-разработки

Контакты:
telegram: @antgubarev

Должен ли тимлид писать код?

Общаясь с коллегами и читая тематические каналы выявил, что большинство тимлидов код не пишут. Они часто загружены менеджерскими задачами на столько, что на код времени просто не остается. В некоторых компаниях руководство запрещает код писать, чтобы тимлиды не отвлекались от главной задачи - управления.
Я же всегда старался придерживаться баланса кода и менеджера в равных пропорциях. Объясню почему.
Во-первых, я люблю писать код) Мне это нравится делать и я его пишу даже в нерабочее время частенько (для себя, сайд проекты, но это отдельная тема)
Во-вторых, мне всегда хотелось быть в курсе того, что происходит. И непросто хотелось, это была насущная необходимость. Так как от меня требовалось принятие архитектурных решений. От меня требовалось обсуждать с бизнесом новый функционал, а для этого я должен знать насколько быстро мы можем его внедрить и сколько нам на это может потребоваться ресурсов.
В-третьих. Кому как не тимлиду задавать вектор технического развития проекта. Контролировать следование ему. Контролировать качество кода.
И если я перестал бы писать код, то стал бы просто менеджером, который только и делает что редактирует задачи в жире (на самом деле далеко не только это конечно, я утрировал).
За время моей работы в качестве тимлида я поработал в командах от 3 до 10 человек. И везде я выделял время на то, чтобы кодить. Чаще всего старался влезть в какой-то самый больной вопрос, который больной не просто так конечно же. Если что-то приносит страдания проекту, значит это не могут пофиксить. Если это не могут пофиксить, значит там либо дикий говнокод и кривая архитектура, либо нет ни тестов ни документации и все бояться сломать что-нибудь. Работа с такими участками кода, помогает глубоко погрузиться в проект и лучше его понять, так как тянет за собой изучение многих связей с другими частями проекта. А команда получает пользу что наконец-то кто-то в это влез и пытается решить. Очень редко когда получается решить проблему разом. Чаще всего приходилось составлять план рефакторинга и покрытия тестами. Но даже это уже дает некоторое облегчение.
Все это огромная польза для всех. Тимлид не теряет технический скилл и глубже вникает в проект. Команда получает облегчение от надоевшей проблемы. Проект получает улучшение ну или начало к улучшениям.
Также хотел бы отметить важную вещь. Позволить себе кодинг можно только при хорошо отлаженых и работающих процессах, когда ты можешь уйти в отпуск на 2 недели и ничего без тебя не сломается. И вот это как раз и есть главная, основная и самая сложная задача тимлида)

Немного о выборе инструментов

Хочу поделиться опытом, полученным мною довольно давно, но урок из него я усвоил крепко.
Возникла у меня на одном из проектов необходимость развернуть приложение в контейнерах. Сервисов было немного - три или четыре штуки всего. Вероятность резкого масштабирования в будущем также была очень мала. Но по условиям задачи необходимо было раскидать сервисы по 2 машинам, на одной всякого рода фоновые ресурсоемкие задачи, а на другой машине все остальное, что должно отвечать максимально быстро на запросы от пользователей.
До этого было уже достаточно опыта в использовании docker swarm и был некоторый опыт с kubernetes. Для текущий задачи kubernetes был сильным оверхедом, в то время как в docker swarm не хватало некоторых возможностей (например не было аналога helm) и отпугивали многочисленные баги, с некоторыми из которых довелось ранее дела поиметь и самому тоже.
Ну и решил я обратить внимание на Nomad. Прочитал документацию, посмотрел доклады на тему его внедрения и использования, пообщался с теми, у кого уже опыт был (а таких нашлось аж целый один человек), почитал различные статьи, поигрался с кластером несколько вечеров. В целом впечатление создалось, что все должно быть намного проще, чем в кубе и удобнее чем в docker swarm.
Поскольку на проекте не было выделенного devops, то внедрение предполагалось своими силами. Ну и начали строить новую инфраструктуру на базе Nomad (Consul кстати говоря уже был внедрен до этого, поэтому времени немного сэкономили).
Ну и конечно же очень быстро начали попадаться подводные камни и ломать пальцы на ногах. Сначала развалился кластер, и поднять его по официальной документации не выходило. В итоге потеря времени, данных, пусть и тестовых, но завтра это могут быть реальные. Затем выяснилось, что нет настройки частной сети. Способы решения проблемы есть, но они костыльные и не всегда работают. Отсутствует возможность запускать задачи в нужном порядке, что оказалось крайне сложным в нашем проекте, так как некоторые сервисы зависели от других. И еще менее значительные но многочисленные проблемы, которых по условиям задачи, как раз и хотели избежать. В итоге, потратив неделю, мы решили от Nomad отказаться.
Какой главный вывод отсюда? Самый подходящий инструмент - это тот, по которому есть экспертиза в команде. А если все же нужен другой, неизведанный, то ищите эту экспертизу или будьте готовы потратить время на ее приобретение.

Проводя собеседования, каждый раз задаю вопросы по git. И как показывает практика подавляющее большинство "синьоров", не говоря уже о миддлах, очень смутно представляют как git работает. Ну да, выучили несколько самых часто используемых команд, успешно их применяют и радуются жизни. И от недостаточных незнаний часто допускают ошибки, которые могут приводить к страданиям всей команды. Когда встает вопрос сделать что-то сложнее git checkout/commit/merge/push начинают плавать и в лучшем случае говорят что не знают как сделать, а в худшем начинают творить всякое.

Ниже несколько статей, которые позволят получить важнейшие основополагающие знания о git. Данные материалы обязательны к изучению.

Это для тех, кто с git почти не знаком
[https://habr.com/ru/company/intel/blog/344962/](https://habr.com/ru/company/intel/blog/344962/)

А это для тех, кто уже имеет с ним дело ежедневно
[https://habr.com/ru/post/157175/](https://habr.com/ru/post/157175/)
[https://habr.com/ru/post/313890/](https://habr.com/ru/post/313890/)