Comments 13
.https://habr.com/ru/articles/668300/comments/#comment_24386038 - вот один из моих комментов про сложность систем - забавно, все заметно коррелирует
Разработка через управление сложность - это мое хобби последние лет 5. В среднем мне это дает производительность х4 по сравнению с моими коллегами, плюс очень малое падение скорости разработки на длинном этапе. А в легаси проектах даже прирост скорости (за счет попутного рефакторинга на обычных задачах).
Я для себя сформулировал следующие подходы для минимизации сложности:
Единообразие
Минимизация сторонних библиотек
Минимизация слоев абстракции
Минимизация наследования
Изучение и совершенствование базовых технологий, а не производных (совершенствовать SQL лучше чем совершенствовать ORM)
Domain Driven Design
Управление границами
Управления зонами ответственности
Слой абстракции полезно вводить как прокладку между программистами. Это и зависимости уменьшает и понимание упрощает.
А ещё упрощает изменение кода. Ровно до тех пор пока сами абстракции не придется переделывать.
Одному программисту проще без абстракций.
По сторонним библиотекам недавно удалось обойтись расширениями к функционалу библиотеки (c# extension methods), очень положительный опыт.
Наследование вредно потому что зависимость дочернего класса от родительского потом сложно переделать.
"совершенствовать SQL лучше чем совершенствовать ORM" - согласен. Хотя, orm очень неплох для быстрой разработки прототипа.
А на практике были случаи когда я писал код в 10(!) раз более краткий и понятный чем у соседа по цеху.
Я правильно понимаю, что сосед думал то же самое про ваш код, потому что место для упрощения в вашем коде видел, а в своём – нет?
Ха.
"Внутренняя сложность задачи (inherent complexity) и непреднамеренно привнесённая сложность (accidental complexity)."
А еще бывает преднамеренно привнесенная сложность. Например, в Linux привнесли systemd.
Задача бывает простой в начале и в конце ее решения.
В начале - мы дилетанты, в конце - профи.
-------------------
Следствие:
Если простая задача вдруг стала сложной, то вы на пути ее решения.
Мне кажется, статья несколько ... ни о чем. За все хорошее против всего плохого, без чего-то по сути
--------------------------
В целом ... я даже не скажу, в чем проблема у автора. Читать код - это не самое критичное. Его сложность - тоже.
Куда важнее его сопровождение, т.е. возможность внесения изменение БЕЗ ВЛИЯНИЯ на остальное. Это именно то, что нгапрямую влияет на сроки, риски и деньгию
Простой пример. На "дисковери" разбирали код старого приложения клиента. Это был .NET, в котором я "баран баранчиком", но ... код представлял собой кучу копипейста, вот просто овер до фига, вызов хранимок и SQL прям напрямую, WebForms и т.д.
Код - полное овно, но читался просто прекрасно даже для меня. Все понятно, очевидно. Бизнес логика понятно. Косяки тоже :)
Но сопровождение такого кода - это найтмар. В одном методе в коде меняется визибилити элемента и чего-то запросом пишется в базу, куча "магических констант", повторяемых кусков кода. Что-то менять просто страшно, поэтому пациента приговорили
Но повторюсь - с чтением вообще нет проблем. Как художественную книжку (за ислючением магических констант, тут понятно логика выпадает, и надо просто понять и простить)
Т.е. важна сопровождаемость, а все остальное - уже производные
Мне показалось, что у вас как минимум три раза пропущены запятые. Это необходимая сложность, без нее сложнее читать.
Борьба со сложностью