Comments 10
Начав читать, а потом проскролив статью, могу сказать автору только одно: KISS
Буквально на днях программист рассказывал мне, что у него GodObject реализован, потому что KISS. Ведь работает, и зачем я что-то усложняю у себя, ведь "этого нет в ТЗ".
P.S. Статья читается крайне тяжело, потому что написана на английском русском.
Увы, так оно и есть, очень часто сталкивался с кодом, который написан так, будто основная цель его создания была - написать как можно больше ребусов для любителей поразгадывать загадки. Куча слоев абстракций, шаблоны, наследование, полиморфизм, все в кучу свалено и что-бы просто найти тот кусок кода, в котором запрятался баг ,приходится день копаться во всем этом с отладчиком, потому что просто анализируя код почти невозможно понять где-же в конце-концов он выполняется.
Я только за проектирование снизу-вверх, ныне забытое и заброшенное
KISS, YAGNI, Functional Programming которое все это поощряет
FP вы просто пишите смысловую код не особо заботясь о связующей части. Когда понадобится вы легко ее свяжете. Вам не нужно как в ООП сороконожке думать в какой последовательности переставлять ваши 40 ног.
Особенно в гибких методах разработки, когда нужно создать прототип, когда нет четких требований и видения что будет меняться.
Но вот если у вас есть четкий план / ТЗ то давайте ка лучше будем смотреть на систему в целом и пойдем сверху-вниз. DRY, abstractions, polymorphism, low coupling high cohesion и прочие принципы, стремящиеся сдержать трудоемкость изменений при росте кодовой базы.
Не бойтесь рефакторинга, часто это проще чем пытаться предусмотреть все заранее. Главное, чтобы изменения не сломали вашу базу.
Что снизу вверх, что сверху вниз, думаю можно сделать одинаково хороший, простой и понятный код, если есть опыт и желание сделать просто и понятно. Беда многих коллег в том, что они явно больше озабочены наворачиванием всякой "крутизны", там где можно сделать просто.
Недавно вот работал на одном проекте - наворотили всяких стратегий и кучу других паттернов, там где код потом годами не модифицируется, не добавляется ни одна стратегия.
В итоге получается что ради упразднения нескольких ифов в нескольких классах, были наворочены десятки интерфейсов, разлапистая иерархия объектов и в целом код стал похож на какую-то головоломку для скучающих программистов, которым заняться нечем кроме как поломать голову над ребусами.
Если спросить авторов этого чуда: вот у нас рест выдал вот такое, какой объект и какой метод в нем при этом отработал? Они и сами без отладчика на этот вопрос не ответят, потому что из-за нагромождения паттернов и полиморфизма это вообще не очевидно. Там и опытным синьорам было сложно работать с кодом, не то что-бы джунам.
Длинно, на нерусском русском, неинтересно.
Заявленного ответа на вопрос "Что такое цикломатическая сложность?" не видно в статье
Мало первести статью, ее необходимо осмыслить, что автор не сделал
Подробное объяснение принципа KISS в программном обеспечении