Time to Legacy
Как быстро ваше решение превратится в неподдерживаемый мусор. Метрика, чо!
И ложка говна про нейросетки, в этой связи.
По мотивам очередного вяло-срача про Мартина Фаулера. Даже ссылки приводить не буду: там дядя Фаулер топит за прозрачность и понятность технических решений (что вполне здраво и оправданно, он пол-жизни за это топит), но иллюстрирует это настолько вырвиглазными обновленными «примерами», что непонятно, где радоваться.
Поскольку интернет у нас теперь диалоговый, на вопросы аудитории «а что это за пицзец?» автор бодро ответствует — ну ага, я нейросетку припахал.
Как можно догадаться, получилось так себе.
Нельзя сказать, что код там совсем непонятный. Любой код так или иначе можно сделать понятным, если достаточно долго раскуривать. Машина же его как-то понимает, а что один человек собрал, другой завсегда разобрать сможет. А вот понятности и прозрачности для человека как раз не очень получилось; вернее сказать так, если включить человеческую голову на старте — за что, в принципе, и топит автор — и сразу сделать по-человечески, то получилось (бы) в пример лучше.
Нисколечко не секрет в индустрии, что написать какое-то говно, которое будет работать — достаточно дёшево. И есть парк решений, класса rapid development**, которые как раз и позволяют это сделать.
Огребётесь вы тогда, когда время неумолимо пойдет вперед, и окажется, что доработки — это дорого. Развитие — это дорого. Саппорт — это пиздецки дорого. Даже просто оставаться на плаву с тем кадавром из черных ящиков, в которых виднеются палки с говном — это вообще никак не вписывается в экономику. А жить надо, уже всё, подписались.
Вход был копейка, выход — рубль.
Важно также отметить в этой связи, что Фаулер возлагает ответственность за архитектуру и технические решения (в его понимании, первопричину), затем прозрачность, расширяемость, предсказуемость и ремонтопригодность (как следствие) — непосредственно на разработчиков и только на них. Дескать, вот такая ваша моральная обязанность и коммитмент. Назвался профессионалом, соответствуй. А кто нет, тот плохой.
Но дело в том, что разработчики и инженеры на рынке не решают задачу в вакууме. Есть заказчик, есть бизнес, есть требования, есть ограничения — см. про «ЗАКП».
Детская модель «я художник, я так вижу» работает только с известной степенью артистической свободы, и никто не мешает делать красиво, долго и шедеврально: только за свой счет, и в свое свободное время.
Страдать перфекционизмом, даже оправданным и вдумчивым, в наше шустрое время обычно некогда, некому, и не на что. Инженеры в массе своей совсем не против делать фундаментально и шедеврально, вот только время «надо вчера», а из доступных средств только говно и палки. И то, «вы там делайте, начинайте, а палки на следующей неделе подвезут».
В этой ситуации делать костыльное днище в общем-то единственный доступный вариант. Какие условия задачи, такое и решение. Обычно сопровождается мантрой «потом переделаем как надо», которое практически никогда не наступает естественным путем.
Когда наступает момент «проще обоссать, сжечь и переделать»? Именно тогда, когда косты на саппорт, и прочие операционные превышают стоимость переделки заново. Ведь помним, сделать с нуля сравнительно у нас недорого (сарказм)…
** Сноска про RAD. Концепцию rapid application development притащил в индустрию лет 30 назад собственно Borland. Инженеры которого смекнули, что если заказчик сам не понимает (пока что), чего он хочет — то можно дать ему среду, в которой можно запросто сделать хрен пойми что. Главное — быстро. Будет оно работать, или нет, дело пятое; собственно, иногда и надо по условию задачи выяснить, будет оно работать или нет. Исследовательская бизнес-задача, никаких проблем.
Проблема в том, что если в руках молоток для костылей, любая проблема гвозди.
Подход породил линейку «бизнес-средств» именуемых Visual [Something], и на самом деле, на тот момент себя оправдал, стал даже в чем-то глотком свежего воздуха. Visual Basic, Visual Studio, Visual Object Pascal (ставший Delphi), Visual dBase/FoxPro/Clipper (ставшие фундаментом для xBase+ODBC Builders) и так далее.
Потому что именно тогда — очевидно — назрел переход в разработке от инженерной waterfall-based модели к чему-то более шустрому из мира agile. Когда ты просто не имеешь объективной возможности пилить ватерфолл полгода, за полгода твой креатив органически устареет и пойдет в мусорное ведро. Поэтому GUI Builders, говно и палки.
Я не критикую подход как он есть, он хороший. Просто любой инструмент нужно подбирать под задачу.
Вернемся к нашей проблематике, а именно к legacy. Легаси — это когда используемое решение в операционных костах становится дороже, чем потенциальные альтернативы чем нам бы хотелось. В общем-то и всё.
А почему оно становится дороже? Непрозрачность, стоимость изменений, накопление рисков, надежность, предсказуемость, time to market для доработок и развития. Стружка и трение, нагрев и наработка на отказ.
Если косты (пока) никого не парят, то в принципе и проблемы нет; в подтверждение могу привести действительно важные системы, которые до сих пор собраны из элементов эпохи палеолита — финансовые сервисы, инфраструктурные компоненты, итп — которым по кайфу работать на коболе, фортране и windows 3.11 под мейнфреймы давно ушедших с рынка платформ.
Вот когда совсем ляжет, ложноножками кверху, тогда и поговорим.
Поэтому, я ставлю свой вопрос вот каким образом:
— через какое оценочное время ваше решение (код, продукт, система) станет операционно дороже, чем приносимая им польза?
Даже если попробовать посчитать это на пальцах, решения А и Б можно между собой, например, сравнить. Опа.
То есть, осязаемая метрика. Time to legacy, из заголовка. И достаточно очевидно, что мы [возможно?] хотим эту метрику увеличить, сделать так, чтобы время преимущества пользы над затратами было предположительно бОльшим, длинным.
Бывают сферы, где сие не очевидно. И вообще оно не надо, а важнее другие показатели. Если вашему решению жить от силы год — по органическим причинам — то всё, что произойдет через два, три, пять лет, вас тупо не волнует, по условию задачи.
Я тут недавно нашел в продакшне свой код, который там фигачит с 2007 года. И работает, чертяка, 18 лет — ебать, совершеннолетие. При том, что у него горизонт рабочего планирования был лет на 5 в лучшем случае.
Почему нашел? Народ попросил правку (facepalm.jpg)
Перекрестились конечно, но 20 минут возни, и теперь дальше работает, артефакт эпохи блин.
Гнаться за метрикой я не призываю. Это вообще-то дорого. Но оценить вы ее можете?
К примеру, у нас есть ряд новомодных технологий и вообще даже отраслей, которые за 2-3 года меняются до неузнаваемости. С фронтендерами знакомиться не принято, они каждый год новые. Про AI вообще молчу. Вебморды можно тоже каждые 5 лет собирать в музей, потому что ландшафт рынка уже совершенно иной. Требования к инфре — не отстают, пять лет назад вон только контейнеризацию толком осваивали. Корпоративная коммуникация, спасибо ковиду, за пять лет превратилась в «созвонились-обкашляли». Целые рынки и страны напрочь с ландшафта сходят.
Но я должен отметить здесь некоторую зависимость. Чем более ситуативный и «быстрый» инструмент вы для решения задачи берёте — тем больше шансов, что и он преждевременно устареет, и весь результат устареет в стремительные сроки. Объективно более короткие, чем они могли бы быть.
И поддержу дядю Фаулера: без прозрачности и ремонтопригодности архитектурной и структурной модели шансы на преждевременное устаревание и досрочное списывание в legacy-мусор стремительно увеличиваются.
В этом плане, образцовый пример, хреновый — нейрокод, продукт кодо-содержащий. Если его прямо сейчас никто не проверял, никто не понимает без пинка и потраченного времени, поддерживаемость и расширяемость равны примерно нулю — поздравляю вас, вы только что сами себе написали легаси. Прям со старта. В чем отличия-то, спрашивается.
Более конвенциональные метрики, типа time to change, time to market (для фичей) уместно также применять и к процессам, и к системам целиком. Как только суммарные затраты, косты и внутреннее «трение» в процессах превышает профит и критерии по времени — полезно задаться вопросом, «а не херню ли мы там делаем». Пока не превышает — прикиньте заранее, хрен к носу, насколько их хватит, и когда вы из этих штанов вырастете.
Классический пример легаси-процессов — согласование «фичей» и проектов внутри больших корпораций. Бюрократия, цепочки принятия решений. Менеджмент, который не умеет и не хочет играть «вдолгую» на горизонте планирования более 2-3 лет. Корпоративная культура, в которой решение никуда не поедет, пока совет директоров не проголосует, пока не убедятся, что каждый получит свою прибыль/откат, пролоббирует свои отделы/субподрядчиков и убедится, что не будет нести никакой ответственности за результат.
И действительно, почему мы в такой системе не можем ничего сделать быстро и эффективно. Злые козни врагов, не иначе.
Возвращаясь к Фаулеру, можно сказать, что дядя сам себе противоречит в выводах. Если решение должно быть понятным и прозрачным, то фундаментальная понятность и прозрачность делаются НЕ комментариями с документацией — хотя ими тоже, don’t make me wrong. Ломать копья «в каком порядке нам код дергать» ничем не поможет. А вот в предпосылках он прав:
Если у вас структурные и архитектурные модели не понятные и не прозрачные, или их вовсе нет, то и всё остальное неминуемо, неизбежно будет одноразовым и ситуативно-костыльным. Мгновенное легаси.
Можете ли вы себе это позволить — другой вопрос.
Если прорабатывать структурную базу (и бизнес-домен, например) вы не можете или не хотите — кто я такой, чтобы вам мешать. Особенно если требуются решения срок=вчера, изба горит, вокзал уходит.
Но в таком случае и не надо себя обманывать, играть в «чистую архитектуру», процессную методологию, и прочие фундаментальные штуки: у вас их нет, и не будет, потому что взяться им неоткуда.
Инженерные технологии разработки надежных систем — тоже технологии в том смысле, что не работают «с нарушениями». Управленческие тоже. Вы либо делаете по регламенту, который определяет результат, либо делаете как попало, и сами несёте ответственность за получившееся. Чудес здесь не бывает.