A Philosophy of Software Design by John Ousterhout

Делать программное обеспечение в целом несложно. Сложности начинаются, когда нужно делать хорошее и качественное ПО, которое можно нормально развивать, поддерживать и которое не падает каждые 5 минут.

Чем сильнее развиваются технологии – тем важнее становятся фундаментальные навыки (и тем больнее бьёт по голове их отсутствие). Одним из таких навыков у инженеров является написание понятного и поддерживаемого кода. С массовым распространением вайбкодинга отсутствие этого навыка у инженеров плавно ведёт нас в горящую бездну отвратительного софта.

Самая известная книга на тему написания хорошего ПО – «Чистый код» Роберта Мартина. В ней много здравых и интересных идей, но она мне всегда казалась несколько однобокой и надуманной (я пробовал описанные техники в реальных проектах, и получалась изрядная фигня). И наконец-то у меня дошли руки до ещё одной книги о том, как создавать хорошее, качественное, поддерживаемое ПО – «A Philosophy of Software Design» за авторством John Ousterhout.

⭐️ О чём книга

По сути, книга посвящена одной многогранной теме: сложности ПО. Автор рассказывает о принципах и подходах к построению ПО с управляемой сложностью и о том, как эту сложность снижать.

В книге раскрываются следующие темы: ➡️ Тактическое vs стратегическое программирование ➡️ Как создавать «глубокие» модули ➡️ Управление исключениями для снижения сложности ➡️ Техника «двойного дизайна» ➡️ Применение комментариев для снижения сложности

⭐️ 3 идеи из книги 🟡Одним из симптомов сложности является когнитивная нагрузка. Код с высокой сложностью трудно понимать, поэтому разработчикам приходится тратить на этот процесс больше времени. А многим не хватает сил/времени/мотивации нормально разобраться, в результате чего изменения приводят к багам и прочим проблемам.

🟡Простой код = код, который легко понять. Просто написать работающий код недостаточно. Каждый инженер должен думать о долгосрочном развитии и поддержке системы, над которой он работает. Иногда быстрое тактическое решение может ухудшить дизайн системы, и такие решения имеют свойство накапливаться. Поэтому инженерам стоит выделять 10-20% своего времени на совершенствование дизайна. Это и есть стратегическое программирование.

🟡Комментарии должны описывать нюансы, которые не очевидны при чтении кода. «Самодокументирующийся код» – это фантастический зверь, который в реальной жизни практически не встречается. При этом комментарии, которые просто дублируют код, тоже только увеличивают когнитивную нагрузку. Хорошие комментарии улучшают дизайн системы за счёт упрощения её понимания для других людей.

⭐️ Мои впечатления

Книга Оустерхаута показалась мне гораздо более жизненной и практичной, чем «Чистый код». Во многом мысли авторов конфликтуют – и этот конфликт интересен, потому что на самом деле правильного ответа нет и чувство прекрасного у каждого своё.

Сейчас я бы рекомендовал читать «Чистый код» и «A Philosophy of Software Design» парой, друг за другом. Такой подход позволит не просто слепо копировать практики, а посмотреть на разные взгляды ветеранов разработки ПО и аргументированно выбрать лучшее для себя.

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

«A Philosophy of Software Design» я заношу в свой почётный список книг, обязательных к прочтению уважающим себя инженером. И очень рекомендую прочитать 🔥 Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.

➡ А для тех, кто хочет читать с большей пользой, у меня есть статья с описанием моего процесса чтения и упражнениями.

➖➖➖➖➖➖➖➖➖➖➖ 📝 @ulshinblog

В этом посте были ссылки, но мы их удалили по правилам Сетки