A Philosophy of Software Design

Создано 2023-04-22 · Обновлено 2023-09-16

Книга посвящена созданию хорошего дизайна при разработке программного обеспечения. В основе лежит два списка правил:

как делать хорошо
как понять, что сделано плохо

Проще начать с описания того, что считается плохим кодом: это связанная паста из кода, которая не имеет чёткой зоны ответственности и документации. В связи с чем использование кода приводит к трудностям к получению результата. Для того, чтобы выявить такой код можно ознакомиться со списком красных флагов. И тут принципиально ничего нового по сравнению с остальными книгами вида “Clean Code”, “Refactoring” и так далее ничего нового не привноситься.

А вот как писать хорошо - здесь уже появляются новые мысли. Полный список принципов можно глянуть здесь, но я бы хотел остановится на главной концепции: Shallow vs Deep modules. Под shallow модулем будем понимать такой модуль, интерфейс которого широк, а вот реализация прямолинейна и проста. В таких модулях происходит нарушение сразу нескольких принципов: это и плохое [[разделение отвественности]], и высокая [[сплочённость]], а так же отсутствие [[скрытие информации]]. И дальше мы выходим на критику стандартного правила про “не больше N строчек на функцию”. Ведь именно разделение на простые прямолинейные куски может привести к появлению таких модулей. В книге же наоборот подразумевается, что хороший модуль имеет простой интерфейс и сложную реализацию. Именно за счёт этого мы можем собирать более сложный код, как кубики к этим абстракциям, которые скрывают за собой информацию и сложность.

Отдельно хочется отметить главы про документацию и комментарии к коду. В них раскрывается тема, что документация должна находится как можно ближе к коду, чтобы можно было обновлять её синхронно. А так же что комментарий по отношению к коду, такая же абстракция как код над процессами. Это наводит нас на практику [[Readme Driven Development]], только через код.

Стоит отметить тот факт, что все приложенные принципы требует большого времени на подготовительном этапе разработки. Прежде чем приходить к добавлению функциональности нужно задумать о том, нужна ли она нам. Сколько лишних возможностей она введёт или она будет изолированно и сделана в единственном роде. Это всё будет проходить на стадии до написания кода, и даже занимать больше времени, чем сбор всех требований.

Так же видны некоторые пересечения в том, что все возможные правила к автоматизации должны быть автоматизированы. И это напоминает идею фитнес функций из Building Evolutionary Architectures.

Наверное, лучшая книга по software engineering на данный момент.

Цитаты

202305090925: recognize code more complicated than needs to be
202305090936: recognize complexity is a crucial design skill
202305090937: practical definition of complexity
202305090951: cognitive load is how much you need to know in prior
202305090957: unknown unknowns are the worst
202305100914: complexity accumulates rapidly, but hard to eliminate
202305100922: to manage deps you introduce interface
202305100923: best modules are those whose interfaces are much simpler than their implementations
202305100927: deep and shallow modules
202305110916: information leakage
202305100932: shallow module
202305110925: information hiding and deep modules are closely related
202305120920: module needs simple interface, and not implementation
202305130845: indications that two pieces of code are related
202305131153: exceptions are part of interface
202305140921: comment is an abstraction to code
202305140913: design it twice
202305140924: comments capture information from designer mind
202305230914: comments can fill missing details
202305230925: Implementation Documentation Contaminates Interface
202305250826: bug about variable naming
202305250828: names are a form of abstraction
202305250836: comment driven development
202305300907: the design of a mature system is determined more by changes made during the system’s evolution
202305300909: comments close to code for transactional update
202305300912: enforce convention through automation
202305300913: When in Rome, do as the Romans do.
202305300918: increments of development should be abstractions
202305310916: expensive operations for today
202305310926: good designer spend more time in design phase
202305310927: the most important software design principles
202305310928: list of red flags in code

Задачи

#task Обработать все выдержки из книги в рамках Zettels ⏳ 2023-08-09 ✅ 2023-08-11
#task Написать выдержку из книги ⏳ 2023-09-10 ✅ 2023-09-11
#task Доработать свои заметки на основе идей из книг

Обратные ссылки

Programming

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

Showcase

Это заметка, чтобы проверять, что у меня работают разные фичи в openbox. При этом сейчас...

Модульность

Базовая идея в программирование, которая сводится к тому, что большую программу надо разделять по частям....