Вчера увидел вот этот пост в LinkedIn с фразой «First rule of programming, If it works, don't touch it» и как-то вскипело. Поясню почему.
Когда я анализирую (умозрительно, или на dev окружении, ни в коем случае не на prod) новую систему заказчика, для которой надо сделать аудит или провести какие-то эволюционные изменения, одна из первых вещей которые я рассматриваю – что тут можно потрогать, потрясти, поменять настройики, удалить, попробовать на зуб и как это отразится на поведении всей системы. Анализ через сценарии «what if» очень важный инструмент архитектора.
Отступая на шаг назад если ситуацию с видео метафорически применять к программной индустрии в значении «First rule of programming, If it works, don't touch it», то создатели арт объекта нарушают сразу несколько очень важных правил построения современного процесса разработки ПО.
Под «современного» я имею в виду не только green field проекты, вокруг которых летают розовые единороги и даже прежде всего не такие проекты. Я имею в виду современный подход, используемый как при разработке новых систем, так и при эволюции и рефакторинге существующих решений.
Прозрачность. Все что происходит внутри системы должно быть легко отслеживаемо. Про любую часть системы должно быть понятно, зачем она тут и что будет если ее убрать.
Воспроизводимость. Любая инфраструктура должна быть воспроизводима и данные должны быть восстанавливаемы простым легко доступным способом. Включая prod. Особенно prod.
Ограничение урона (impact): Ни у кого не должно быть легкого, не аудируемого способа сломать что-то важное или дорогое.
Устойчивость: Архитектура систем должна быть устойчива (resilient). Выход из строя по возможности как можно большего количества подсистем не должен приводить к полному отказу системы. Не должно быть единой точки отказа – того самого сервиса, единичный выход из строя которого ломает вообще все.
Разберем эти пункты детально
Прозрачность: Современные системы состоят из сотен тысяч строк строк кода. И еще несколько миллионов строк к ним добавляют используемые библиотеки. Средняя команда разработчиков за день добавляет/меняет в этом всем может быть 1000 строк, на самом деле обычно меньше. При этом часто чтобы поменять одну строку, надо прочитать (и понять, что написано) дюжину строк кода. Если эта дюжина написана не прозрачно и не понятно, что там делается, то шансы разработчика написать качественный код существенно снижаются. Отсюда следует другая цифра, один блок кода пишется один раз и потом за годы жизни проекта он много раз меняется и еще большее количество раз читается.
Из чего следует простое правило, код должен легко читаться, должно быть легко понятно, что в блоке кода делается и модификация не должна вести к непредсказуемым побочным эффектам.
Если проводить параллель с роликом – на вынутом из фигуры драже (это же M&M’s?) должно быть явно написано «если вынешь, все рассыпится, вообще все» и совсем уж хорошо было скрепить соседние драже клеем, на всякий случай.
Воспроизводимость: Люди придумали компьютеры для того, чтобы они делали работу за нас. У компьютеров есть отличное свойство, они умеют (если им не мешать) делать работу быстро и с предсказуемым результатом. Если мы строим инфраструктуру, то нет никакой причины делать это путем кликания мышью. Давно придуман Infrastructure as a code (IaC) подход. Всегда можно построить еще 10 таких же окружений просто запустив, например terraform и накатив на свежее окружение данные получить среду полностью идентичную предыдущей.
Что в современной парадигме происходит, если джун кладет prod, полностью, в клочья.
ПродОпсы запускают пайплайн на создание нового прода.
Минут 10-20 пока прод поднимается они всей командой вежливо, в корректных выражениях просят джуна больше так не делать.
Проверяют, что все нормально поднялось, тесты проходят и все норм.
Идут писать блог пост с извинениями пользователям.
Проводя метафору с видео, создатель скульптуры должен был сказать джуну «Святые пассатижи, опять! Да сколько можно то? Не делай так больше по возможности.» и запустить процесс пересоздания арт объекта.
Ограничение урона: Все действия с системой должны быть аудируемы и видны широкой аудитории. Не должно быть секретной консоли, в которой админ, один, сидя в темной комнате (темной для придания драматического эффекта) производит тонкие манипуляции над пентабайтами данных, в проде, без права на ошибку. Принципы тут простые.
Если какое-то действие можно сделать кодом и автоматизировать, это должно быть кодом. И что важно код должен проходить через механизм Pull request review. Т.е. на код должен посмотреть как минимум еще один человек. Даже если это проект terraform. Особенно если это проект terraform. Плюс, там, где это возможно код должен быть протестирован авто тестами.
-
Если действие нельзя автоматизировать и закомитить в репозиторий в виде кода, то
a) Действия должны явно, подробно, занудно подтверждаться в UI – то самое «Вы собираетесь удалить 3 объекта в ресурсной группе. Объекты будут удалены навсегда без возможности восстановления, введите название ресурсной группы, чтобы совершить действие».
b) В особо важных случаях, например надо что-то срочно поменять в базе данных на prod (к сожалению, такое тоже бывает), собирается звонок, один человек, у которого есть доступ шарит экран и делает изменения, остальные участники звонка смотрят, чтобы он не промахнулся.
Возвращаясь к видео – для вытаскивания драже надо было бы создать PR в main ветку и для его мерджа надо бы было получить апрувы от двух синьеров.
Устойчивость (resilience): По возможности все части системы должны иметь какую степень автономности и сохранять ограниченную работоспособность с как можно меньшим числом зависимостей. Самый простой пример – отказ кэш сервиса не должен приводить к выходу системы из строя. «Нет кэша, ну что ж будем работать медленнее».
В случае с арт объектом можно было ожидать, что часть объекта разрушится, но потом осыпание дойдет до circuit breaker и процесс прекратится.
Подводя итог – на видео мы скорее всего видим архитектора или тим лида который забрел к команде разрабатывающей систему по SDLC стандартам прошлого века и нечаянно инициировал им радикальную трансформацию архитектуры и процессов.
Kanut
На видео мы скорее видим миддла или даже джуна, который решил что он умнее других :)
То есть если вас наняли "сделать аудит или провести какие-то эволюционные изменения" для какой-то системы заказчика, то это одно и тут действительно надо всё "потрогать, потрясти, поменять настройики, удалить, попробовать на зуб и посмотреть как это отразится на поведении всей системы".
А если вас наняли "клепать формочки", то в такой ситуации не особо хорошая идея "улучшать" вещи, которые вас не просили улучшать :)
Semenych Автор
>А если вас наняли "клепать формочки", то в такой ситуации не особо хорошая идея "улучшать" вещи, которые вас не просили улучшать
Это довольно сильно противоречит современным понятиям о том как должна работать команда. Прям начиная с Agile Manifesto и далее пол best practices.
Но как я сказал если работа проекта устроена по лекалам конца 20-го века, то да. Но тут уже надо решать с кем вам больше по пути
Kanut
Вы конечно извините, но "Agile Manifesto и далее по best practices" и подобные вещи подходят далеко не всем фирмам. Мягко говоря. И нет ничего такого ужасного в том чтобы работать не по аджайлу. Я бы даже сказал что если есть возможность работать по обычному водопаду, то это удобнее любых аджайлов.
И даже в аджайле вещи вроде "улучшения кода" выходящие за рамки актуальной задачи стоит как минимум обсудить с командой. А не просто брать и улучшать втихаря.
Semenych Автор
Тут дело не в аджайле как таковом. Точнее не в процессной его части.
Просто ритирика `вас наняли "клепать формочки"` она прям токсичная и сильно противоречит тому как сейчас принято строить команды. Да так тоже можно - особенно этим грешит кондовый советский (и как это не парадоксально кондовый американский) менеджмент.
Так тоже можно работать, не очень эффективно и очень не гибко. Но человечество придумал более эффективные способы организации команд. Основная проблема такого линейго военно-квадратно-гнездового подхода - это дыры в построении систем. Если начальник чего-то не знает или не предусмотрел, то как на видео - все обрушится от случайно зашедшего чувака.
Оба полярных подхода имеют плюсы и минусы, но это тема для отельной статьи
я как раз и говорю что в данном случае улучшения втихаря спокойно тормознулись бы на этапе ревью PR
Kanut
Это была гипербола.
Проблема в том что "идеального аджайла" я пока нигде не видел. А вот ситуации когда в том же скраме человек решал "а давай ка я заодно вот здесь подправлю" встречал неоднократно. Обычно без особых последствий или даже с положительными. Но пару раз было что потом появлялись баги и нужно было тратить кучу времени чтобы понять откуда.
Поэтому я бы лично сказал что "If it works, don't touch it" правило скорее полезное чем вредное. Особенно для людей, которые обращают внимание на такие правила. То есть джуны или даже миддлы. Потому что по моему опыту сениоры-техлиды-архитекты обычно уже на такие правила особого внимания не обращают и/или имеют достаточно ума/опыта чтобы понят когда их стоит или не стоит применять :)
Semenych Автор
Блин, ну так и вся часть "Подводя итог" тоже гипербола :-)
>Поэтому я бы лично сказал что "If it works, don't touch it" правило скорее полезное чем вредное.
Может быть у нас просто субъективный опыт разный. Я видел ситуации когда несколько команд из 8+ человек годами вращались вокруг гигантских монолитив в парадигме "не будем трогать потому, что не понимаем и понимать не хотим, но чтобы решить задачу - напостылим тут сбоку ад и треш"
Способность команды менять продукт в любом произвольном месте, если потребуется, для меня заметно важнее страховки от дятла.
Как с дятлом справиться с знаю и умею, а вот как справится с группой из 20 типа разработчиков которые годами пишут код, используя для этого спинной мозг вместо головного - я не знаю.
UPD - сори - много опечаток - меня уже работой затигивает, голова не о том думает
Kanut
На мой взгляд это уже не "If it works, don't touch it". Как минимум не в контексте именно программирования-разработки на уровне команды или отдельного человека. Это уже скорее проблема на уровне менеджмента-начальства. Которое как раз и должно принимать решения о том что делать с "гигантскими легаси монолитами". По крайней мере в моём понимании это точное не вопросы, которые команда должна решать сама для себя.
Semenych Автор
Там основная проблема была именно в "не трогай". Это прям длинная, грустная история. В комментариях ее так просто не рассказать.
Но в целом в современной индустрии есть большая проблема с проактивностью. Чуваков готовых 8 часов на работе клепать формочки по шаблону не задумываясь о том как оно работает "работает не трожь" - на порядки больше тех кто понимает как оно работает или готовых разобраться в этом. Поэтому я привествую любое проявление любопытства - с этим гораздо проще справлятся и менеджить, чем с безволием и апатией.
Kanut
Так а кто принимал это решение? Ну то есть неужели начальство сказало "нам надо разобраться с эти монолитом", а команда разработки ответила "не будем трогать потому, что не понимаем и понимать не хотим"?
Да это сколько угодно. Но "If it works, don't touch it" это уже про нечто большее чем просто любопытство. Это уже изменения в системе. И лично для меня худшее что может быть это именно "инициативный дурак" :)
Semenych Автор
Ну начальство в больших корпорациях это отдельная история.
Semenych Автор
Вообще забавное совпадение, я как раз в сентябре в одну контору собеседовался, у них как раз начальник такой квадратно гнездовой.
И потом мне коллеги за чашкой чая про проблемы конторы рассказывали - так оно прям идеально по учебнику совпало "симптомы - проблемы".
Но времени слишком мало прошло, эту историю рассказывать еще нельзя :-)