В этом году издательство «Питер» выпустило русскоязычный перевод книжки Майкла Нейгарда “Release it! Проектирование и дизайн ПО для тех, кому не всё равно” Оригинал этой книжки “Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers)” появился в 2007 году. Не знаю какими соображениями руководствовалось издательство выпуская перевод сегодня. Как, впрочем, не помню почему именно эту книжку я взял почитать в отпуск. Тем не менее хочу порекомендовать эту книжку для чтения всем, кто так или иначе связан с архитектурой информационных систем.
Один из отзывов на ozon.ru утверждает:
Остался в некотором разочаровании от книги. Вопреки названию и аннотации оказалось, что она рассчитана не на рядовых программистов, а скорее на архитекторов систем. Все темы автор рассматривает в контексте распределенных систем, ориентированных на огромное число пользователей.
— и это чистая правда. В ходе чтения я не мог избавиться от ощущения déjà vu, постоянно ловил себя на мысли: откуда-то я все это уже знаю. Вряд ли я раньше читал оригинал. Ну, может быть, полистал однажды, но не более того. Скорее эта книжка просто приводит абсолютно типичные истории из жизни информационных систем. Пара предложений из предисловия:
Современные учебные программы по разработке программного обеспечения являются до ужаса неполными. В их рамках рассматривается только то, как должна вести себя система. При этом не раскрывается обратный аспект — как системы не должны себя вести. А они не должны рушиться, зависать, терять данные, предоставлять несанкционированный доступ к информации, приводить к потере денег, разрушать вашу компанию или лишать вас заказчиков.
А далее идут примеры каскадного обрушения стабильных монолитных систем, успешно прошедших все нагрузочные и интеграционные тестирования, но развалившихся в определенный момент в следствии «невероятного стечения обстоятельств». Главная метафора книги появляется в разделе 3.2 Режимы отказов:
К катастрофическому отказу могут привести как внезапные импульсы, так и чрезмерная нагрузка. Но в любом случае какой-то компонент системы начинает отказывать раньше, чем все остальное. В своей книге Inviting Disaster Джеймс Р. Чайлз называет это трещинами (cracks) системы. Он сравнивает сложную систему, находящуюся на грани отказа, со стальной пластинкой с микроскопической трещиной. Под нагрузкой эта трещина может начать расти быстрее и быстрее. В конечном счете скорость распространения дефекта превысит скорость звука, и металл с резким треском сломается.
Компонуя разделы учебной программы “Мастерская проектирования ИТ-решений”, я долго не мог придумать как в компактной, но понятной форме рассказать о проектировании технологической архитектуры. Какие слова смогут убедить слушателя в том, что логичные и красиво составленные сценарии синхронного взаимодействия информационных систем не годятся для описания интеграций. Они просто не будут работать. Вернее, будут, но не всегда и совсем не долго. Максимум – до завершения интеграционного и нагрузочного тестирования. В ходе реальной эксплуатации в информационной системе очень быстро появятся трещины и единственный внятный способ с ними справиться– заранее спроектировать решение так, чтоб оно противостояло распространению трещин.
Такого рода книжек очень не хватает архитекторам информационных систем. Нас все время пытаются завлечь в обсуждения малосущественных вещей типа сравнения нотаций моделирования, построение архитектурного процесса или выбор «правильного» инструмента рисования картинок. И все это происходит на фоне регулярно рассыпающихся корпоративных информационных систем, происходящего из-за недостатков проектирования.
Книга хороша, спору нет! Только надо обязательно уточнить, что издательство Питер славится своими не качественными переводами технической литературы. Ошибка есть прямо на обложке: «Design and Deploy» перевели как «Проектирование и Дизайн». Это же просто ужас.
Действительно так. И в тексте и на картинках много переводческих ляпов и просто не согласованных терминов. В одном случае на картинке будет написано «балансировщик», в другом «распределитель нагрузки».
К тому же, автор «порадует» нас порцией недоумения по поводу отсутствия сессий в протоколе HTTP, но книжка то старая и заслуживает снисхождения