Комментарии 42
В мире разработки комментарии — признак плохого кода
Это не так. Например, вы видите ограничение в 24 символа в какой-то функции. Комментарий ответит на вопрос — почему 24, а не, скажем, 32. Почему это изменение было внесено (точнее — в связи с чем). И раскроет ту мысль, которая будет в коммит сообщении. Комментарии — это хорошо.
А вот если ограничение бизнесовое, а пишешь ты на полноценном ЯП, то комментарий тут скорее вреден: гораздо правильнее написать понятный тест, описывающий человеческим DSL'ем конкретный бизнесовый сценарий. И когда это ограничение поменяется, то вместе с ним разработчик будет вынужден поменять и тест, объясняющий зачем это здесь.
Т.е. есть множество способов решить ту же проблему, которую решают комментарии, но без их недостатков. Но чем дальше ты уходишь от высокоуровневых абстракций и чем больше у тебя неподвластных тебе ограничений, тем сложнее эти способы применять, имхо.
Если это ограничение техническое и кроется в сторонней системе, а ты пишешь какой-нибудь баш-скрипт (что очень часто встречается как раз в мире инфраструктуры или каких-то низкоуровневых языках/доменах), то да, комментарий здесь будет полезен.
я рассуждаю с точки зрения разработчика, а не админа.
Хотя даже тут он рано или поздно устареет, но все последующие поколения разработчиков об этом не узнают.
тесты тут не помогут, т.к. если Вы правильно заметили, что ограничение снаружи, то оно просто так не исчезнет. И тест попросту проверяет ограничение, а не говорит почему оно есть.
ОКей, ограничение может быть описано в технической документации, но она деградирует еще быстрее, чем комментарии в коде.
Например, вот объясните наличие этого ограничения без комментария.
Еще вариант, когда комментарий помогает — это docstrings. Или комментарий к хитрому коду на С/C++, который реально когнитивно сложен и делает какую-то магию (например, 0x5f3759df — знаете, что это за константа и зачем она?)
Поэтому говорить, что комментарии есть только в инфраструктурном коде или не нужны в обычном коде (ruby? python?) — это ложный аргумент.
Ограничение внешней системы можно и прокомментировать, только в случае с прикладным кодом таких систем и таких ограничений относительно мало, а в случае с инфраструктурным — на каждом шагу.
Хотя в примере с OpenShift я бы просто вынес «24» в константу с именем OpenShiftMaxNameLength и не потерял бы ничего. Магические константы это еще один code smell наравне с повсеместными комментариями.
А комменты в коде обычно аргументируются: «мне не нравятся когда много методов и длинные имена у методов и переменных/констант», то есть личные предпочтения превышают общие/командные интересы.
Не нужно возводить все в абсолют.
согласен, просто обе позиции (мы никогда не пишем комментарии и мы всегда пишем комментарии) — они пахнут максимализмом и… неверны. Как всегда — правильно — срединный путь ) смотреть по обстановке и целесообразности
Хотя в примере с OpenShift я бы просто вынес «24» в константу с именем OpenShiftMaxNameLength и не потерял бы ничего
это не помогло бы — в следующей версии OpenShift уже такого ограничения нет ) А указывать конкретную версию в названии переменной, ну, то же себе такое. Как известно, одна из фундаментальных проблем программирования — как декомпозировать объекты сущности (это к вопросу о монолит vs микросервисы) и как называть переменные сущности.
Хм, у меня мультиклауд и я счастлив. Сидели на одном Azure — мы пару потеряли много денег, сразу все поняли и завели AWS.
Сейчас 85% в Амазоне, 15% в ажуре.
Точно, АЖУР НЕ НУЖЕН (С) 11111!!!!!!
p.s. я именно с технической точки зрения — они еще долго будут в позиции догоняющих по отношению к Amazon & GC.
По моему опыту, если хочется получать максимум пользы от облачной инфраструктуры и при этом не платить за это космические деньги, то ты вынужден использовать специфичные для конкретного облака сервисы и писать заточенный специально под них код.
Это касается и прикладного софта (мы используем CosmosDB, Kusto, менеджед MySQL базы), так и инфраструктурного: например когда мы брали в стек тот же Terraform, то мечтали абстрагироваться от облачного провайдера, но по факту это конечно не так — для развертывания той же инфраструктуры в другом облаке придется очень много переписывать.
Да, можем. Не все конечно, есть очень специфичные приложение в Австралии, но это единицы. Тут конечно много особенностей и деталей плюс у меня своя специфика — регуляторка разных стран.
MatveyGrigorev — Вы попадали на hardlimit в Azure? Когда просто терминируется BGP сессия и весь регион не доступен :)
команда инфраструктуры даже не знала, что сегодня релизится какое-то приложение
Это как так то?
Само приложение и бекенд к нему выкатывается задолго до публичного анонса: распространяется на небольшую группу лояльных бета-пользователей и постепенно дорабатывается. А в какой-то момент бизнес принимает решение что все ОК – и публикует пост в соцсетях с призывом скачать приложение и получить пиццу в подарок за первый заказ. Profit.
Это сейчас мы все умные и синхронизируем все маркетинговые активности со всеми причастными техническими командами, оцениваем нагрузку и т.п., а тогда, увы, этого не было. Плюс никто не ожидал такого наплыва пользователей именно в приложение: никому и в голову не могло прийти что через несколько месяцев оно станет популярнее сайта.
На время разработки на продакшене был развёрнут один слабый сервер. Перед публичным анонсом приложения его нужно было увеличить.
команда инфраструктуры даже не знала, что сегодня релизится какое-то приложение.
Тогда я вывел для себя очевидное, но важное правило: Если хочешь, чтобы твоё приложение жило долго и счастливо, внимательно следи за тем, где и как оно выполняется на проде. Даже если для этого есть специально обученные люди.
Не хочу вас расстраивать, но вы сделали неправильный вывод. У вас в компании проблемы с бизнес процессами и планированием. Релиз приложения\информационной системы — это не случайно событие, а запланированное, поэтому все заранее осведомлены о его сроках. О релизе всегда знает технический сектор (dev и ops), бизнес сектор с владельцами компании, а также отделы маркетинга и PR.
Они решили, что следить за продакшеном «некритичного» сервиса — обязанность команды приложения. А разработчик бэкенда решил, что в крупных компаниях этим занимаются ребята из инфраструктуры.
Чтобы ops могли поддерживать то, что dev накодили, эти dev должны официально передать систему\сервис коллегам из ops, снабдив всё это необходимой для ops документацией с описанием компонентов и принципов работы. До момента официальной передачи всё, что накодили dev принадлежит dev и поддерживается силами dev.
Инфраструктура пока в прошлом
Очень интересно рассказывать об этом из мира, в котором состояние не является проблемой программиста. Надо хранить данные в таблицах? Отлично, берём учетные данные в СУБД и пишем/читаем, пока не сдохнет. Когда сдохнет — жалуемся DBA, они там задаром, что ли, деньги получают. Надо узнать, по какому IP-адресу находится сервис? Отлично, берём DNS и спрашиваем, пока не сдохнет. Когда сдохнет — жалуемся админам, 1000 вопросов в секунду «где example.com» это даже не хайлоад.
Инфраструктура, тем временем, сделана из состояния почти целиком. И возникает следующий отличный диалог между dev и ops:
Dev: инфраструктуру надо чинить, инфраструктуру.
Ops: на, сам делай!
Dev: мне нельзя, я чатланин фичи пилю.
Вот и появляются отделы DevOps/SRE и прочая ИБД.
У вас же, говорят, принято людей из компании в пиццерию отправлять для ознакомления? Вот отправляйте ещё разработчиков в on-call. Они даже могут ничего не делать руками на проде, просто поднимайте их по любой тревоге, и давайте какую-нибудь несложную обязанность типа внешней связи с пострадавшими и составления короткого отчета об инциденте с их точки зрения.
"мы живем в Azure"
Прям туда персональные данные отъезжают?))
Удвоили количество людей, которые готовы дежурить и сняли нагрузку с текущей команды. Спустя ещё полгода эти люди стали полноценными SRE.
Полноценным SRE не стать за полгода, слишком большой домен знаний. И даже за полтора это сделать очень сложно.
Особенность SRE — это большой домен знаний и очень сильные навыки дебага и пожаротушения вкупе со скилами архитектора. Ну кроме остальных навыков, конечно.
Причём, если более менее сносный код можно научиться писать за эти полтора года, то архитектурные и эксплуатационные скилы развить за это время с ноля можно разве что до уровня «уверенный джун», потому что, как вы очень правильно сказали, в эксплуатации очень много всего, а уж в архитектуре и подавно.
В целом, я могу допустить, что за это время можно дорасти до «SRE конкретного окружения конкретной компании», но потом придётся двигаться и развиваться дальше и несоответствие будет всплывать все чаще и чаще (вот хотя бы история мультиклауда наглядный тому пример).
Так или иначе, удачи вашей команде, это все интересно :)
P.S. Мне довелось поработать с SRE из гугла на протяжении почти года достаточно плотно и к сожалению у меня сложилось впечатление, что они сами не в полной мере соответствуют тому, о чем пишут в собственной книге. Что конечно не исключает существования других команд, где на самом деле есть полноценные SRE которые могут качественно делать все, что предполагается им по роли.
Мне довелось поработать с SRE из гугла на протяжении почти года достаточно плотно и к сожалению у меня сложилось впечатление, что они сами не в полной мере соответствуют тому, о чем пишут в собственной книге. Что конечно не исключает существования других команд, где на самом деле есть полноценные SRE которые могут качественно делать все, что предполагается им по роли.
Плюсую бешено, но гугл, как один из основных работодателей и одна из инфра-образующих компаний, может себе позволить многое — в том числе и создавать прослойку SRE.
А еще очень интересно поговорить за топологию команд. Вот, ня
Идея была в том, что мы получили от новой команды то, что ожидали — и это круто.
При этом у меня лично возникла другая проблема: с одной стороны за суммарно полтора года я капитально растерял навыки работы в привычной среде .NETа, а с другой стороны стал «SRE конкретного окружения конкретной компании» и понимаю что мне еще расти и расти. И это вызывает серьезный психологический дискомфорт.
И это вызывает серьезный психологический дискомфорт.
Решайте его скорее и генерализируйте компетенции, иначе рискуете очень надолго застрять в этой каше и впоследствии огрести много карьерных проблем. Сейчас у вас судя по всему самое время качаться в эту сторону, расширять стек и становиться очень востребованным Azure DevOps/SRE, по крайней мере.
А какая мотивация у разработчиков уходить в "админство"? Я долгое время не могу такими вещами заниматься, полгода, наверное, и выгорать начинаю без реальных фич, которые делаю для пользователей. Причём серьёзных, а не "на отвлекись, перекрась кнопку и поле добавь"
А «админскую» часть здесь я воспринимаю скорее как неизбежное зло для того чтобы получить знания, необходимые для нанесения непоправимой пользы окружающим. Хотя конечно иногда возникают мысли «зачем я в это все вляпался?»)
Если выкинуть модное слово SRE и немного вернуться и поговорить о DevOps подходе (а не человеке), то фактически DevOps — это настойщий полный фул-стек.
С одной стороны — делается продукт, с другой — этот продукт с помощью определенных инструментов катится в прод к клиенту и обратная связь появляется маскимально быстро, модификации идут более точно т.к. часть можно решить инфрой, часть — через изменения продукта и т.д.
Мотивация этого действа полностью бизнесовая. А базовая необходимость в том, что современная инфрастуктура может быть на порядки сложнее большинства приложений, что на ней работают и без общего понимания всего хотя бы на среднем уровне получаются плохо работающие приложения, велосипеды, перерасход ресурсов на поддержку и т.д.
А еще это интересно и хайпово просто:)
Короче одно другому не мешает, проблема только в том, что программистов, умеющих в девопс мало. Очень мало. Как и «девопсов» умеющих в архитектуру и программирование. И даже если их собрать в одной команде, придется еще и все процессы перестроить, а для этого надо очень хорошо знать что ты делаешь, что опять же проблема, потому что найти такого лида тоже сложно и т.д.
Поэтому часто идут перекосы и нормальный процесс превращается в то, что все занимаются не своим делом, но под новой вывеской.
Ну вот я такой фуллстэк, наверное, фичи делал некоторые в одно лицо от UI/UX и фронта на реакте до helm чартов (с попутной контрибуцией в апстрим), да ещё имея в виду, что то, что я сделаю станет неформальным образцом для всех команд как нужно у нас делать.
Интерсно, да. Но ведь речь идёт, как я понимаю, о полном отходе от разработки пользовательских фич. Вот такого я долго выношу.
речь идёт, как я понимаю, о полном отходе от разработки пользовательских фич.
Это как раз то, чего в принципе быть не должно — тот самый перегиб. Сама идея как раз в том, чтобы и пилить фичи, и крутить их. По крайней мере в DevOps.
В SRE действительно надо отказываться от пиления фич, но там свой интересный мир.
Сплошь и рядом отдельные девопс инженеры и целые девопс команды, не очень понятно чем отличающиеся от классических админов, которым ещё и задачу поддерживать CI/CD пайплайнв и прочие кубернетесы поставили. Да и большинство разработчиков в это лезть не горят желанием. А человек 10-15 разработчиков из которых ты один не против немного в этом покопаться, быстро прервщается, что ты становишься таким то ли девопсом, то ли SRE на фуллтайм
Сплошь и рядом отдельные девопс инженеры и целые девопс команды, не очень понятно чем отличающиеся от классических админов, которым ещё и задачу поддерживать CI/CD пайплайнв и прочие кубернетесы поставили.
есть разница. Потому что то, о чем Вы говорите — это платформенные инженеры, который (внезапно!) пилят продукт — внутренний продукт — платформу, куда будут деплоиться приложения других, продуктовых команд. В чем же разница платформенной команды от продуктовых? В том, что продуктовые заточены на бизнес-фичи, а платформенная — именно на унификации процессов деплоя, мониторинга etc., обеспечении стабильности работы платформы и все прочее. Т.е. уже не админы, но еще и не 100% разработчики.
Я вот пошел в SRE в Google именно из желания пощупать руками сотни миллионов QPS и как оно вообще может работать. Оказалось очень познавательно. И проблемы интересные решаются.
При этом рядом сидит команда "разработчиков" этого же продукта, и даже не скажешь, у кого интереснее и "креативнее" что ли работа.
Для меня такой интерес был бы в принципе в Google пойти. Я вот именно про переход из разработчиков в SRE/DevOps без смены компании/продукта.
Путь разработчика в SRE: зачем идти в инфраструктуру и что из этого выйдет