Введение сложное, длинное описание более потяное.

Есть 2 популярные парадигмы программирования: функциональное и ООП.

Я придумал следующее: в сущностях (можно написать "объектах" или любое другое слово, но это не прям объекты ООП, а в целом то, что мы используем при написании программы, функция - тоже какого-то рода "объект", который используется при написании программ, класс - это тоже некая сущность, некий "объект", который мы использвем при написании программ, переменная - тоже самое, т.е. те сущности их которых состоит программа).

В общем в этих сущностях/объектах выделять минимальные "свойства" (или можно сказать минимальное "поведение" или "элементарные свойства"), и создавать программы не на основе чего-то стандартного, например функции или класса, а создавать программы комбинируя эти выделенные минимальные "свойства" получая новые сущности/объекты.

В статье я попытался расписать подробнее что я имею ввиду.

А что если представлять программу как не набор ключевых слов, а как какой-то формальный язык, с математической строгостью. Тогда программу можно выразить через линии (например).

Т.е. чисто теоретически может существовать такой язык программирования, где вместо ключевых слов в котором будут линии и изгибы. Например вот такая линия выражает программу "достать все товары без фильтров из базы данных".

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

Меня всегда волновал вопрос: можно ли писать код единственно правильным образом. В данной статье я через противоречие доказываю, что при изменении бизнес требований написать код так, чтобы он всегда работал без ошибок - невозможно. По-этому правильного способа написания кода - не существует. Отсюда и каждый код превращается в говнокод. Потому что программист решает логически противоречащие друг другу задачи, а значит написать правильно код - невозможно. UPD: в комментариях нашли способ! Указан в UPD в конце статьи. Но все равно может статья будет кому-то полезна (проблема и ее решение).

Чем отличается плохой работник от хорошего. Я считаю одно из качеств — формулируем полностью от и до ТЗ (техническое задание) на задачу, и смотрим сколько требуется затратить своих усилий, чтобы работник все-таки выполнил задачу. Подробности под катом.