Comments 12
Подводя итог – на видео мы скорее всего видим архитектора или тим лида который забрел к команде разрабатывающей систему по SDLC стандартам прошлого века и нечаянно инициировал им радикальную трансформацию архитектуры и процессов.
На видео мы скорее видим миддла или даже джуна, который решил что он умнее других :)
То есть если вас наняли "сделать аудит или провести какие-то эволюционные изменения" для какой-то системы заказчика, то это одно и тут действительно надо всё "потрогать, потрясти, поменять настройики, удалить, попробовать на зуб и посмотреть как это отразится на поведении всей системы".
А если вас наняли "клепать формочки", то в такой ситуации не особо хорошая идея "улучшать" вещи, которые вас не просили улучшать :)
>А если вас наняли "клепать формочки", то в такой ситуации не особо хорошая идея "улучшать" вещи, которые вас не просили улучшать
Это довольно сильно противоречит современным понятиям о том как должна работать команда. Прям начиная с Agile Manifesto и далее пол best practices.
Но как я сказал если работа проекта устроена по лекалам конца 20-го века, то да. Но тут уже надо решать с кем вам больше по пути
Вы конечно извините, но "Agile Manifesto и далее по best practices" и подобные вещи подходят далеко не всем фирмам. Мягко говоря. И нет ничего такого ужасного в том чтобы работать не по аджайлу. Я бы даже сказал что если есть возможность работать по обычному водопаду, то это удобнее любых аджайлов.
И даже в аджайле вещи вроде "улучшения кода" выходящие за рамки актуальной задачи стоит как минимум обсудить с командой. А не просто брать и улучшать втихаря.
Тут дело не в аджайле как таковом. Точнее не в процессной его части.
Просто ритирика `вас наняли "клепать формочки"` она прям токсичная и сильно противоречит тому как сейчас принято строить команды. Да так тоже можно - особенно этим грешит кондовый советский (и как это не парадоксально кондовый американский) менеджмент.
Так тоже можно работать, не очень эффективно и очень не гибко. Но человечество придумал более эффективные способы организации команд. Основная проблема такого линейго военно-квадратно-гнездового подхода - это дыры в построении систем. Если начальник чего-то не знает или не предусмотрел, то как на видео - все обрушится от случайно зашедшего чувака.
Оба полярных подхода имеют плюсы и минусы, но это тема для отельной статьи
И даже в аджайле вещи вроде "улучшения кода" выходящие за рамки актуальной задачи стоит как минимум обсудить с командой. А не просто брать и улучшать втихаря.
я как раз и говорю что в данном случае улучшения втихаря спокойно тормознулись бы на этапе ревью PR
Просто ритирика вас наняли "клепать формочки" она прям токсичная и сильно противоречит тому как сейчас принято строить команды.Это была гипербола.
я как раз и говорю что в данном случае улучшения втихаря спокойно тормознулись бы на этапе ревью PR
Проблема в том что "идеального аджайла" я пока нигде не видел. А вот ситуации когда в том же скраме человек решал "а давай ка я заодно вот здесь подправлю" встречал неоднократно. Обычно без особых последствий или даже с положительными. Но пару раз было что потом появлялись баги и нужно было тратить кучу времени чтобы понять откуда.
Поэтому я бы лично сказал что "If it works, don't touch it" правило скорее полезное чем вредное. Особенно для людей, которые обращают внимание на такие правила. То есть джуны или даже миддлы. Потому что по моему опыту сениоры-техлиды-архитекты обычно уже на такие правила особого внимания не обращают и/или имеют достаточно ума/опыта чтобы понят когда их стоит или не стоит применять :)
Блин, ну так и вся часть "Подводя итог" тоже гипербола :-)
>Поэтому я бы лично сказал что "If it works, don't touch it" правило скорее полезное чем вредное.
Может быть у нас просто субъективный опыт разный. Я видел ситуации когда несколько команд из 8+ человек годами вращались вокруг гигантских монолитив в парадигме "не будем трогать потому, что не понимаем и понимать не хотим, но чтобы решить задачу - напостылим тут сбоку ад и треш"
Способность команды менять продукт в любом произвольном месте, если потребуется, для меня заметно важнее страховки от дятла.
Как с дятлом справиться с знаю и умею, а вот как справится с группой из 20 типа разработчиков которые годами пишут код, используя для этого спинной мозг вместо головного - я не знаю.
UPD - сори - много опечаток - меня уже работой затигивает, голова не о том думает
Я видел ситуации когда несколько команд из 8+ человек годами вращались вокруг гигантских монолитив в парадигме "не будем трогать потому, что не понимаем и понимать не хотим, но чтобы решить задачу — напостылим тут сбоку ад и треш"
На мой взгляд это уже не "If it works, don't touch it". Как минимум не в контексте именно программирования-разработки на уровне команды или отдельного человека. Это уже скорее проблема на уровне менеджмента-начальства. Которое как раз и должно принимать решения о том что делать с "гигантскими легаси монолитами". По крайней мере в моём понимании это точное не вопросы, которые команда должна решать сама для себя.
Там основная проблема была именно в "не трогай". Это прям длинная, грустная история. В комментариях ее так просто не рассказать.
Но в целом в современной индустрии есть большая проблема с проактивностью. Чуваков готовых 8 часов на работе клепать формочки по шаблону не задумываясь о том как оно работает "работает не трожь" - на порядки больше тех кто понимает как оно работает или готовых разобраться в этом. Поэтому я привествую любое проявление любопытства - с этим гораздо проще справлятся и менеджить, чем с безволием и апатией.
Там основная проблема была именно в "не трогай".
Так а кто принимал это решение? Ну то есть неужели начальство сказало "нам надо разобраться с эти монолитом", а команда разработки ответила "не будем трогать потому, что не понимаем и понимать не хотим"?
Поэтому я привествую любое проявление любопытства — с этим гораздо проще справлятся и менеджить, чем с безволием и апатией.
Да это сколько угодно. Но "If it works, don't touch it" это уже про нечто большее чем просто любопытство. Это уже изменения в системе. И лично для меня худшее что может быть это именно "инициативный дурак" :)
Вообще забавное совпадение, я как раз в сентябре в одну контору собеседовался, у них как раз начальник такой квадратно гнездовой.
И потом мне коллеги за чашкой чая про проблемы конторы рассказывали - так оно прям идеально по учебнику совпало "симптомы - проблемы".
Но времени слишком мало прошло, эту историю рассказывать еще нельзя :-)
Смешались в кучу кони, люди...
Провести аудит существующей системы, добавить функционал для работающей системы или разработать с 0 по каким-то стандартам - вроде бы не одно и то же. Как, собственно заголовок поста и то, о чем в нем прочитал. Тема про "не трогай" это не раскрыта
Не трогай это