Делать программное обеспечение в целом несложно. Сложности начинаются, когда нужно делать хорошее и качественное ПО, которое можно нормально развивать, поддерживать и которое не падает каждые 5 минут.
Чем сильнее развиваются технологии – тем важнее становятся фундаментальные навыки (и тем больнее бьёт по голове их отсутствие). Одним из таких навыков у инженеров является написание понятного и поддерживаемого кода. С массовым распространением вайбкодинга отсутствие этого навыка у инженеров плавно ведёт нас в горящую бездну отвратительного софта.
Самая известная книга на тему написания хорошего ПО – «Чистый код» Роберта Мартина. В ней много здравых и интересных идей, но она мне всегда казалась несколько однобокой и надуманной (я пробовал описанные техники в реальных проектах, и получалась изрядная фигня). И наконец-то у меня дошли руки до ещё одной книги о том, как создавать хорошее, качественное, поддерживаемое ПО – «A Philosophy of Software Design» за авторством John Ousterhout.
О чём книга
По сути, книга посвящена одной многогранной теме: сложности ПО. Автор рассказывает о принципах и подходах к построению ПО с управляемой сложностью и о том, как эту сложность снижать.
В книге раскрываются следующие темы:
- тактическое vs стратегическое программирование;
- как создавать «глубокие» модули;
- управление исключениями для снижения сложности;
- техника «двойного дизайна»;
- применение комментариев для снижения сложности.
3 идеи из книги
-
Одним из симптомов сложности является когнитивная нагрузка. Код с высокой сложностью трудно понимать, поэтому разработчикам приходится тратить на этот процесс больше времени. А многим не хватает сил/времени/мотивации нормально разобраться, в результате чего изменения приводят к багам и прочим проблемам.
-
Простой код = код, который легко понять. Просто написать работающий код недостаточно. Каждый инженер должен думать о долгосрочном развитии и поддержке системы, над которой он работает. Иногда быстрое тактическое решение может ухудшить дизайн системы, и такие решения имеют свойство накапливаться. Поэтому инженерам стоит выделять 10–20% своего времени на совершенствование дизайна. Это и есть стратегическое программирование.
-
Комментарии должны описывать нюансы, которые не очевидны при чтении кода. «Самодокументирующийся код» – это фантастический зверь, который в реальной жизни практически не встречается. При этом комментарии, которые просто дублируют код, тоже только увеличивают когнитивную нагрузку. Хорошие комментарии улучшают дизайн системы за счёт упрощения её понимания для других людей.
Мои впечатления
Книга Оустерхаута показалась мне гораздо более жизненной и практичной, чем «Чистый код». Во многом мысли авторов конфликтуют – и этот конфликт интересен, потому что на самом деле правильного ответа нет и чувство прекрасного у каждого своё.
Сейчас я бы рекомендовал читать «Чистый код» и «A Philosophy of Software Design» парой, друг за другом. Такой подход позволит не просто слепо копировать практики, а посмотреть на разные взгляды ветеранов разработки ПО и аргументированно выбрать лучшее для себя.
Книга довольно небольшая и очень легко написана. Тем не менее, для её осознания потребуются время и практика. Такие книги лучше всего снабдить закладочками для практики и положить себе на рабочий стол, чтобы время от времени возвращаться к мыслям и практикам автора.
«A Philosophy of Software Design» я заношу в свой почётный список книг, обязательных к прочтению уважающим себя инженером. И очень рекомендую прочитать.