Comments 23
Объемный текст о системном подходе в разработке. Затронуты темы технического долга, изоляции контекста, проектирования с прицелом на изменение. Примеры узнаваемы, подача последовательная. Местами перегружен по объему, но структура в целом выдержана.
Полезен как материал для обсуждения подходов к архитектуре в команде. Без привязки к конкретным технологиям, с акцентом на мышление и долгосрочные последствия решений.
Вы попросили чатгпт оценить эту статью в положительном ключе?
Нет, GPT ещё не пишет за меня комментарии - только помогает тем, кто не умеет читать без сарказма. Но если есть что возразить по делу, а не по фантазиям - слушаю.
не пишет за меня комментарии - только помогает тем, кто не умеет читать без сарказма
В русском языке нельзя построить одно противопоставление по двум несвязанным категориям.
Все ещё настаиваете, что вы – живой человек?
Любопытно, как легко вы уловили формальное "нарушение" — и так же легко прошли мимо смысла, который при этом читается без всяких затруднений.
Как правило это не вопрос языка, а вопрос внутренней настройки: если хочется уколоть, текст всегда покажется острым в нужном месте.
Но всё равно спасибо - напомнили, как тонко работает проекция.
Isaqb систематизировала область, curriculum открыт.
Отличная статья, всё по теме, приятный слог - прочитал на одном дыхании!
Было бы неплохо, если бы Автор расширил её (в смысле написал новую, или несколько) о борьбе с легаси и рефакторингом легаси кода. Ну, например, если в наследство достался мегабайт спагетти-кода с 10 классами и передачей параметров через God-класс и отсутствием комментариев. С удовольствием почитал бы.
Спасибо. Однако считаю что вот как раз "мегабайт спагетти с God-классами" - это не отдельная тема, а следствие как раз отсутствия архитектурного мышления на старте. Мысли не про рефакторинг руками, а про то, как не создавать такие конструкции в принципе. Но если интерес к техникам расчистки хрупкого легаси устойчивый - можно будет отдельно разобрать подходы: от адаптеров до стратегий поэтапной миграции.
"мегабайт спагетти с God-классами" достался в наследство. Не моё творчество, хотя, определённая логика в нём всё же есть: проект развивался как побочный продукт для одного заказчика, просто как система для экспериментов и потихоньку стал чуть ли не основным источником дохода. Над архитектурой и качеством кода поначалу никто не задумывался - исполнитель общался с заказчиком напрямую и просто добавлял нужный код.
Думаю, такая проблема не только у меня. Было бы интересно почитать о способах решения.
Такое часто бывает. Сначала просто пишут, потому что нужно, потом оно неожиданно становится важным, а менять уже сложно. Архитектура как правило не приоритет, когда цель - по шустрому сдать и показать результат.
Если система уже работает, задача не в том, чтобы всё исправить. Тут задача в том, чтобы понять, что можно изолировать, а что пока лучше не трогать. Минимум риска, максимум стабильности. Всё остальное семимильными шагами по мере необходимости. О способах решения еще будет материал.
Автор, прекращай амуры с LLM.
Я бросил читать на 2й минуте
метод, знающий слишком много о глобальном контексте, - мина
Дело не в том, что он слишком много знает и должен умереть, а что он не может без этого знания выполнять свои обязанности. И если что-то там поменялось то ему тоже придётся меняться и далее по цепочке. Антипатерн стрельба дробью.
Знания хранятся в "вики/конфлюенс". Хранение знаний в голове - на мороз.
Найди в нем ОДИН if... Вырежи его.
Я что-то упустил в современном программировании? if'ы-то чем не угодили? :о
Особенно если учесть, что под капотом этих фабрик такие же If-ы, просто более хитро организованные.
Первая заповедь Питона - явное лучше неявного. И всё, как хочешь, так и понимай. Это должен быть код, написанный в лоб или это должно быть явное поведение кода? А если архитектора нет в команде, что делать?
if сам по себе не враг. Но когда их десятки, каждый с бизнес-исключением, и все в одном методе - это уже не контроль потока, это шифр на выживание. Ни имею ничего против if - против превращения кода в минное поле.
Мне, вот, очень нравится принцип YAGNI (You Aren't Gonna Need It), который я всегда держу в голове, когда выполняю задачи, чтобы не сделать ничего лишнего, что не нужно для решения конкретной задачи (хотя какой-нибудь мелкий рефакторинг всё равно иногда прорывается). Конечно, в код по возможности закладывается что-то на будущее, но не уделяется этому много внимания.
Допустим, я не просто выполнил задачу, а предусмотрел какое-то потенциальное будущее и вместо сдачи задачи вчера сдам её завтра. Но, что если эта функциональность, на которую было потрачено драгоценное время на запуске стартапа, понадобится только через год? А что, если стартап вообще до этого момента не доживёт.
Поэтому стоит выбирать золотую середину между красивой архитектурой с потенциалом и тем, что нужно здесь и сейчас. В общем достаточно писать так, чтобы не было тех. долга и при этом не было написано ничего лишнего.
Сейчас один легаси-проект (.NET Framework 4.8.1) переводим на последнюю версию. Так оттуда столько такого потенциально хорошего архитектурного "добра" уже выпилили, но всё стало только лучше. И это мы только в начале пути.
YAGNI работает, когда знаешь, что фича реально может не понадобиться. Но с архитектурой так не выйдет - она либо позволяет двигаться дальше, либо мешает. Если что-то не заложил, а потом без этого никак - придётся резать по живому.
.NET 4.8.1 - как раз такой случай. Вроде без излишков писали, а теперь всё мешает. Не потому что наделали глупостей, а потому что система не готова меняться.
Так что да, ничего лишнего - это хорошо. Но если завтра менять будет нечего - толку от этого мало.
Системное мышление: когда разработчик становится архитектором