В книге собраны 97 рассказов, которые главный редактор (или интервьюер?) назвал “этюдами” от разных авторов. Все они объединены общей темой - архитектурное проектирование систем. Эта книга повторяет идею книги “97 этюдов для программистов”, хотя редакторы в них - разные, да и темы отличаются.
Строительство программных систем - это такая устоявшаяся аналогия, которая встречается повсеместно и повсеместно приводятся примеры того, насколько она не верная. Пока, в одной из глав не была выдвинута идея, что программные продукты выращиваются, а не строятся. И занимаясь выращиванием, вы сталкиваетесь с проблемами начиная с того, что именно вы растите (по сути, работа с требованиями), где и как вы будете растить (техника и технологии), что будет после того, как программа обгонит планы роста и вообще, её дальнейшую судьбу. Используя похожую аналогию встречается несколько советов о том, что минимальный программный продукт надо выпускать как можно быстрее, а уже дальше развивать его, наращия функционал. И мне эта мысль очень нравится.
Уделяется много внимания процессу переговоров, выяснение требований и в целом, вовлечения людей в процесс создания и эксплуатации. Насколько важно понимать пользователей системы и вообще, всех, кто будет причастен к процессу эксплуатации и сопровождения. Насколько важна команда, советы о том, как нанимать людей и пр. Что мне показалось немного странным, так как считал, что архитектор - это не руководящая должность.
Помимо этого в книге даются и технические советы, правда они уже не такие интересные, так как с момента издания прошло уже много времени и технологии продвинулись вперед. С другой стороны, какие-то идеи остались актуальными до сих пор, и это может послужить сигналом к тому, что к авторам этих идей можно присмотреться, узнать, какие еще идеи им принадлежат и все такое.
Иногда проскакивают интересные факты, вроде того, что термин “непрерывная интеграция” был предложен Фаулером в качестве шаблона проектирования. Или приведен классный примеры выбора базы данных для танка: основной критерий - это скорость восстановления, так как при выстреле происходит электромагнитный импульс, который выводит из строя на короткое время электронику (этот пример приводился как следствие влияния контекста на правила).
Часто встречается напоминание о том, что необходимо вести документацию, при этом соглашаясь, что она может устаревать. Так или иначе, рекомендуется записывать свои обоснования, и тут приходит на ум, что уместнее всего эти обоснования фиксировать в техническом дневнике. Это должно помочь в дальнейшей эксплуатации системы и её сопровождении, включая возможное расширение.
Кевлин Хенни рекомендует руководствоваться неопределенностью, именно так называется один из этюдов, в котором рассматривается идея того, что если у вас стоит выбор из технологий, значит что-то идет не так. Следует отступить назад и переработать код так, что бы не было разницы, какую технологию выбирать, по тому что код инкапсулирован, то есть смена технологии обойдется достаточно дешево. Развитие этой идеи описано у Дядюшки Боба в его “Чистой архитектуре”.
Было забавно увидеть высказывание “Одна строка рабочего кода стоит 500 строк спецификаций” от Allison Randal. А забавно по тому, что она примерно в это время являлась архитектором VM Parrot, которая проектировалась примерно 15 лет и в итоге последняя версия была выпущена в 2016 году. Кстати, о этом проекте было объявлено 1 апреля 2001 года, как шутка. Шутка затянулась…
В целом, из почти 100 заметок всегда можно найти что-то интересное для себя. Другое дело, стоит ли для этого читать всю книгу? Не знаю, наверное - нет. По этому эта книжка поедет в архив.
Электронная книга с неплохой версткой, не знаю, что еще добавить.
Под редакцией:
- Richard Monson-Haefel
Автор(ы):
- Nitin Borwankar
- Neal Ford
- Mark Ramm
- Mark Richards
- Randy Stafford
- Einar Landre
- Udi Dahan
- Michael Nygard
- Keith Braithwaite
- Allison Randal
- Rebecca Parsons
- Niclas Nilsson
- Dave Muirhead
- Kevlin Henney
- John Davies
- Dave Bartlett
- Norman Carnovale
- Dan Chak
- Dave Quick
- Jeremy Meyer
- Erik Doernenburg
- Philip Nelson
- Barry Hawkins
- Edward Garson
- Craig Russell
- Evan Cofsky
- Gregor Hohpe
- Timomthy High
- Paul W. Homer
- Chad LaVigne
- David Ing
- Mnsedisi Kasper
- Bill de hÓra
- Michael Harmer
- Clint Shank
- Micke Brown
- George Malamidis
- Dave Anderson
- Doug Crawford
- Kamal Wickramanayake
- Scot Mcphee
- Greg Nyberg
- Zubin Wadia
- Stephen Jones
- Sam Gardiner
- Brian Hart
- Yi Zhou
- Eben Hewitt
- Peter Gillard-Moss
- Eric Hawthorne
- Burk Hufnagel
- Richard Monson-Haefel
- Vinayak Hegde
Год издания: 2010
Количество страниц: 218
Оценка: 3/5
Издатель: Символ-Плюс
Ссылка на страницу книги на сайте издательства: —
Оригинальное название: 97 Things Every Software Architect Should Know 1st Edition
Год издания: 2009