KISS vs SOLID, что и когда готовить?

Question

[ChernovGV]

Всем привет!
По мотивам видео о реализации FizzBazz на JS задался вопросом - что действительно легче поддерживать, десяток строк KISS ("структурный подход")

spoiler

или 60 строк ООП кода по SOLID?

spoiler

Для того чтобы осмыслить ООП пример и понять идею автора, нужно напрячься, особенно когда ты не видишь диаграммы и объяснений автора. Иначе после первого изменения код перестанет быть SOLID'ным.
В итоге читать больше, понимать сложнее, а джунов к такому коду вообще не пустить. И как это можно назвать более поддерживаемым кодом?

Понятно, что это синтетический пример и в реальном мире задачи сложнее. Но гэп между SOLID и KISS будет приблизительно таким же. Или я не прав и скажем 1000 строк по KISS будет сложнее обслуживать чем 6000 строк по SOLID?

Давайте поговори на тему как провести черту между SOLID и KISS?

P.S.
Не плохой, но не достаточный, комментарий на эту тему https://softwareengineering.stackexchange.com/a/367100
UPDATE:
Код могу предоставить только в таком видео т.к. автор видео не предоставил исходники.

Comments

[Михаил]

1. Код должен в первую очередь работать и решать проблему
2. Его должно легко поддерживать

Код из примера ООП вообще не поддерживаемый, 6 классов для проверки числа на кратность, ага

[twoone]

Первый пример, это мясо. Второй - стандартизация. Когда проект создают много разработчиков, то стандартизация просто необходима, иначе каждый будет делать как умеет. И поскольку понятие "коротко" не сочетается с термином "стандарт", то первый пункт отпадает.

[Василий Банников]

Можно ещё мои примеры fizzbuzz посмотреть для интереса в разных стилях https://github.com/vabka/fizzbuzz/blob/master/Fizz...

Answer 1

[Сергей Горностаев]

Во-первых, сейчас модератор грохнет ваш вопрос за нарушение пункта 3.8 правил. Во-вторых, парадигмы, подходы, шаблоны и принципы - это инструменты управления сложностью кодовой базы, а инструмент надо выбирать под задачу - не стоит наворачивать многоуровневую абстракцию на FizzBuzz. В-третьих, KISS не исключает SOLID.

Comments

[ChernovGV]

Во первых: Спасибо, скорректировал вопрос, надеюсь на понимание.
Во вторых: Если мы навернем многоуровневую абстракцию на что-то более сложное, то и абстракция будет сложнее. Хотя, да и "решение в лоб" усложниться, и наверное еще больше... Получается как-то так:

В третьих: Согласен

[Алан Гибизов]

Это как в физике - энергия тела зависит от точки отсчёта. Так и тут - зависит от постановки задачи.

Когда дают задачу типа «реши», можешь делать как угодно.

Когда «реши с соблюдением принципа kiss», решай максимально кратко.

Когда «с соблюдением принципов SOLID», решаешь с этим вашим ООП - демонстрируешь знание принципов.

Когда задача «сделать поддерживаемый код с соблюдением принципов SOLID и принципа KISS», то KISS становится ОТНОСИТЕЛЬНЫМ. Из нескольких вариантов SOLIDных кодов выбирай тот, в котором ничего лишнего, но всё необходимое есть.

Answer 2

[Adamos]

Сначала KISS: решаем, требуется ли делать код сложным или можно обойтись простым решением, которое будет легко читать и поддерживать.
Если понятно, что читать и поддерживать простыню процедурщины будет затруднительно, начинаем дробить логику, и в этом нам помогает SOLID - именно он определяет границы зон ответственности кода и позволяет минимизировать связи между проектируемыми классами.
Наконец, определившись с архитектурой, мы внутри каждого класса вновь возвращаемся к KISS, не переусложняя его внутреннюю жизнь сверх тех задач, что он должен решать. Благодаря применению SOLID уровнем выше мы сможем безболезненно переделать все потроха этого класса, если задачи изменятся и KISS-решение перестанет работать, без рефакторинга остального кода.
Никаких противоречий.