Рубрика #мюсли
Меня стали часто спрашивать: как я все успеваю? Как у меня получается поддерживать столько продуктов практически в одиночку? Ответ прост: нормальные технологический стек и автоматизация. Про свой стек я четко все объяснил
вот тут.
Понимаю-понимаю, сразу появится сотня ко-ко-ко, которые вам четко разложат, почему мой стек вредный и почему я "не прав". Мол, под каждую задачу свой инструмент и на любом языке и фреймворке можно написать плохо и хорошо.
Ну вот эти ко-ко-ко пускай и дальше кудахтают в Интернете, а мне не до них — у меня на руках поддержка 25+ полезных продуктов с 40кк+ пользователями. Каждую секунду, которую я трачу на что-то, я сознательно не трачу на что-то другое. А еще у меня семья есть, друзья и социальная жизнь. Как умудриться уследить за всем и везде преуспеть?
Выбрав нормальные технологии и автоматизировав все. Приведу пример.
Написали в чат поддержки ботов, мол, там в одной из команд — баг. Я открыл код, нашел команду,
добавил пару строк, запушил код в репозиторий, он автоматически развернулся на сервере.
Мне не пришлось ничего вспоминать, я четко видел, где может быть ошибка, просто посмотрев в главный файл бота. Мне не пришлось читать доки, за меня TypeScript автодополнил необходимое выражение и указал на необходимые типы. Мне не приходится танцевать с бубном с CI, потому что я использую свой
ci-ninja, который работает настолько просто и прямо со встроенными в Linux сервисами, что ломаться там просто нечему.
Что бы сделали другие программисты, которые делают все "правильно"? Настроили бы Travis, который нужно бесконечно обновлять, танцевать с бубном и следить за тем, чтобы он не сломался на новой версии операционки. Все, кто хотя бы раз настраивал Travis и апгрейдил его, понимают, о чем я.
И так у меня везде: если я вижу, что какая-то технология заставляет меня слишком много париться по поводу ее конфига или последующей поддержки — мне не нужна такая технология. Отчасти, поэтому я не использую тот же Докер в своих проектах — хоть на это есть еще 99 причин. Мне гораздо проще использовать уже встроенные в Linux или ЯП с фреймворками технологии.
Я стараюсь максимально автоматизировать вообще все повторяющиеся процессы. С деплоем кода я показал пример выше. Но у меня еще есть скрипты, которые бекапят все мои базы данных автоматически, еще есть сбор статистики с серверов, есть триггеры "здоровья" серверов, есть сценарии работы со "сломанными" серверами, есть деплой экстеншенов, мобильных приложений, JS бандлов, фронтендов, бекендов, десктопных приложений — все автоматизировано и делается максимум одной командой.
И ничего никогда не ломается, потому что у всего этого минимум зависимостей, все это настолько просто, что ломаться там нечему, а апдейтить это не нужно вовсе. Как и с запуском продуктов, я подхожу к разработке внутренних сервисов очень просто: нужна только одна самая главная функция. Так проще писать, а потом поддерживать код.
Так что да, есть "правильный" технический стек и есть "неправильный" технический стек. "Правильный" позволяет без головняка писать и поддерживать код. "Неправильный" заставляет вас часами (а то и днями) разбираться, что сломалось, если внезапно что-то изменилось: будь то документация, версия зависимости — или просто свою операционку обновили.
Поэтому да, не используйте технологии, которые заставляют вас писать больше кода, чем нужно. Бойлерплейт, я сейчас говорю про бойлерплейт.