Гегелевский скачок или почему не понятно как работает
Любой, кому доводилось разбираться с чужими проектами знает - там бывает страшно. :) Кстати, это не шутка. Когда видишь наслоение непонятно чего над чем-то невнятным, и все это написано по принципам лохматых годов современным недрослем (будем считать, что я про ИИ, хотя это не так)... Да, бывают просто шедевральные программные опусы.
Вспомнил я это когда выкладывал предыдущий короткий пост про "Автоотклики на HH".
Проблема на самом деле видится не в кривом коде и не в человеках-снежинках за клавиатурами. Проблема глубже и описана была уже давно Гегелем. Просто почему-то в массовом сознании разделяется: философия это про человека, а все остальное своей жизнью живет. Я вот не соглашусь.
Гегель говорил: пока изменения количественные, система сохраняет меру (тождество себе). Но накопление количества рано или поздно пробивает эту меру, и происходит скачок в новое качество. Это же и про разработку. Видите аналогию?
Начало 2000-х: код без архитектуры, без стандартов. Система маленькая, её "мера" это способность одного-двух разработчиков держать всё в голове. Управление полное, потому что сложность ниже порога понимания.
Рост: появляются слои, фреймворки, патчи, "временные" решения. Количество кода и связей растёт. Фреймворки дали механизмы, но не логику: они не отменяют энтропию, а лишь задают русло.
Скачок: рано или поздно наступает момент, когда никто в компании не держит систему целиком в голове. Это и есть переход количества в качество: система обретает новое свойство. Непрозрачность для внешнего наблюдателя. Каждая часть начинает вести себя непредсказуемо не потому, что в ней баг, а потому, что её поведение определяется сетью связей, которую никто не обозревает.
(Спойлер - дальше будет много букафф.)
Те компании, и HH в их числе, что выжили с 2000-х, прошли именно эти стадии. Конкретно HH был создан в 2000 году. Маленькая деталь - их первый сайт National Job Club был запущен в мой день рождения. :)
Первый код не был построен на "прогрессивных" фреймворках, которые так нынче любят. Он строился как всё в 2000-х. А именно: может ли разработчик на коленке запилить "вот это"? Может? - Пилим!
А что пилить? Правильно! Монолит! Потому, что микросервисная архитектура как таковая упоминается только с середины 2000-х, а концепция вообще появилась лишь в 2011 году. Не было еще ничего такого в формате концепта у HH.
Но сейчас сайт уже на микросервисах. И это конечно здорово, но тут надо понимать: переписать систему из 10 страниц на другую архитектуру - задача вполне решаемая. А вот переписать систему из N*10 страниц - решаемая конечно, но не рентабельная. Это будет означать потерю времени и денег, отваливание части функционала на не пойманных багах и прочие "милые шалости".
Конечно, я не говорю что не реально. Я лишь утверждаю, что полный реврайт всей системы, работающей в продакшене 10 лет не рентабелен в принципе. Но рентабелен зато постепенный рефакторинг частей системы - это контролируемый процесс.
Казалось бы - и что? По простому скажу: да ничего, кроме того, что в этом процессе даже в финале остануться артефакты от того, предыдыущего ядра.
Монолит - Куча наслоений кода поверх - Рефакторинг на другую архитектуру - Куча наслоений кода поверх... Добавим ИИ... Снова куча наслоений кода поверх...
Как-то так выглядит к слову 99.9 IT-решений тех, кто выжил с 2000-х. И говорить могут много - "у нас все четко", "у нас все описано", "у нас нет костылей"... Как говорится: "Ага, парторгу расскажешь". Не ожидаю услышать иное от людей, вещающих в рамках "корпоративной риторики", и держащихся за свое место.
Только вот старика Гегеля никто не отменял. Сама логика формирования этих систем строится ровно по его принципам.
Так что понять до конца со стороны как работает тот же HH выглядит как "дао" - то, к чему стремимся, но никогда не достигнем потому, что такие системы давно уже живут своей жизнью и не контролируются самими создателями. Я не про то, что они "разумны" - я про сложность и непредсказуемость взаимодействий внутри.
Проблем кстати будет еще больше знаете с чем? С продуктами 2020-х, которые ИИ писал и допиливал. :)
· 10 ч
Ну то есть, если на входе и в процессе мы имеем мусор, то увеличение мусора ведёт к качественному переходу на выходе? Или мы про то, что увеличивая количество мусора мы получим на выходе качественно другой мусор - невообразимую дрянь, когда со дна постучали?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 10 ч
В точку! Изначально (на заре разработки) не было еще бест-практик как писать, что использовать (к слову и технологий не было соответствующих). Что-то лепили сами - где-то лучше, где-то хуже.
И это живет до сих пор к слову сказать.
И если над этим мусором по современным взглядам накидывать что-то посвежее, потом посвежее, потом еще.... То мы получаем исторические наслоения из чего-то что работает, но как именно периодически сложно понять даже находясь "внутри". Для внешней оценки это совершенно не предсказуемая фигня получается.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён