Вступительное слово
Программная архитектура немного напоминает строительную архитектуру. В зданиях тоже есть фрактальная структура: здания состоят из отсеков, отсеки состоят из комнат, комнаты — из стен, стены — из кирпичей. Программы же состоят из модулей, которые состоят из пакетов, которые состоят из классов, которые состоят из функций и т.д. Однако разнообразие структур программ намного шире, чем зданий, поэтому Дядя Боб считает программную архитектуру «более архитектурной», чем строительную архитектуру.
Кроме того, строительную архитектуру проще визуализировать в голове, чем программную, потому что здания мы видим каждый день, а архитектура программ от нас скрыта внутри исходного кода. Программная архитектура не похожа ни на что.
С другой стороны, программная архитектура тоже должна помнить про физические ограничения, потому что программы запускаются на реальном железе с ограниченной производительностью, памятью, пропускной способностью сети и т.д.
Что такое хорошая архитектура? Это такая архитектура, которая удовлетворяет потребностям пользователей, владельцев бизнеса и программистов не только в текущий момент времени, но и со временем.
«Если вы считаете, что хорошая архитектура – это дорого, то попробуйте плохую».
«Единственный способ идти быстро – это идти хорошо».
Предисловие
Дядя Боб пишет код более 50 лет. Он писал самые разнообразные программы: большие, маленькие, GUI, консольные, веб и т.д. И пришёл к выводу, что правила архитектуры везде одни и те же! И даже за 50 лет они не изменились несмотря на гигантский рост производительности железа.
Языки программирования тоже стали значительно лучше, но базовые конструкции остались теми же самыми: if, присваивание, циклы и т.д. Если посадить программистку из середины прошлого века за современный МакБук, то она сначала офигеет, но потом будет нормально писать Java-код в Идее.
Но за полвека был накоплен большой опыт, которого ещё не было 50 лет назад. Были сформулированы правила, которым и посвящена данная книга.
Введение
Написать рабочую программу нетрудно. Трудно написать программу правильно. Это требует знаний, опыта и умений, для выработки которых нужно большое время и дисциплина.
Когда программа сделана правильно, то её легко поддерживать и вносить в неё изменения. Там очень низкий процент дефектов. Для неё не нужны орды программистов, тонны документов с требованиями и навороченные трекеры.
Это звучит утопично, но Дяде Бобу удавалось работать в таких проектах. Но к сожалению, в большинстве случаев нам приходится работать в условиях ужасного дизайна.
Что такое дизайн и архитектура?
Давайте считать, что дизайн и архитектура – это одно и то же.
Архитектура – это не только верхний уровень, это верхнеуровневые и низкоуровневые детали в целом. Одного без другого не существует.
Цель программной архитектуры – минимизировать человеческие ресурсы, необходимые для построения и поддержки требуемой системы.
Если усилия невелики и остаются таковыми в течение всей жизни, значит дизайн хороший. Если усилия возрастают с каждым релизом, то дизайн плохой.
В качестве примера Дядя Боб показывает график реального проекта, в котором количество сотрудников возросло в 50 раз, но количество строк кода возросло всего в 2.3 раза (3M -> 7M). Более страшный график – это возрастание стоимости одной строки кода в ~40 раз. Т.е. продуктивность упала со 100% практически до нуля. Программисты работают усердно во всю силу, но по сути ничего не могут сделать. А теперь самое страшное: если в первом релизе приходилось платить сотрудникам несколько сот тысяч долларов в месяц, то в конце эта цифра стала 20 миллионов долларов в месяц!
Далее Дядя Боб вспоминает про притчу про зайца и черепаху. В ней черепаха выиграла гонку, потому что заяц был слишком самоуверенный, лёг спать и проспал всю гонку.
То же самое и с разработкой: программист тешит себя уверенностью, что он сможет по-быстрому выкатить продукт, а навести порядок позже. Однако проблема в том, что после релиза ему нужно делать следующую фичу, иначе он отстанет от конкурентов на рынке. В конце концов его продуктивность через несколько месяцев просто упадёт до нуля и он проиграет.
Далее он приводит пример эксперимента, проведённого неким Джейсоном Горменом, где он пишет простую программу несколько раз. И у него получается, что c TDD первый раз получается быстрее, чем даже третий раз без TDD. То есть если писать правильно, то в итоге получается быстрее.
Разработчик должен нести ответственность за беспорядок, который он привносит в проект. К качеству архитектуры нужно относиться серьёзно. Но для этого нужно знать, что такое хорошая архитектура.
Рассказ о двух ценностях
Есть две ценности – поведение и архитектура.
Поведение означает, что программа удовлетворяет функциональным требованиям и тем самым приносит деньги владельцам бизнеса. Проблема в том, что многие программисты верят, что только это и есть их работа.
Вторая ценность – это качество, при котором программа остаётся в поддерживаемом состоянии. То есть её легко изменять. Сложность изменений должна быть пропорциональна масштабу этих изменений, но не их форме. Архитектура не должна делать предпочтений одних форм по отношению к другим, иначе запросы владельцев будет реализовать сложнее и сложнее с каждым разом.
Что важнее – поведение или архитектура? Менеджеры считают, что важнее, чтобы система работала. Но программисты должны считать наоборот, что важнее архитектура.
Матрица Эйзенхауэра говорит, что важное и несрочное имеет более высокий приоритет, чем срочное и неважное. А архитектура всегда важна в отличие от поведения, поэтому она более приоритетна.
Программист должен бороться за архитектуру. Программист – это тоже участник бизнеса. Архитектура – это его ответственность.
Продолжение следует...
Комментарии (30)
alatushkin
09.03.2019 19:54Кмк важно помнить, что опыт Мартина который сформировал его взгляды и кочует из книги в книгу (и из эссе в эссе новых адептов) пришелся на «другое время»: разработчики стоили дешевле, разнообразие направлений было меньше, а мир (бизнеса) менялся медленнее. Но даже в те времена, судя по тексту, ему всего пару раз посчастливилось участвовать в проектах где все было «грамотно».
Сейчас ситуация такова, что важнее не повторять старые мантры о том как мы все сделаем грамотно по книгам (а по факту все-равно «все переписывать» каждые 2-3 года), а стремиться гибко и осознанно подходить и к фичас и к архитектуре.
de1vin
09.03.2019 22:25Сейчас ситуация такова, что важнее не повторять старые мантры о том как мы все сделаем грамотно по книгам (а по факту все-равно «все переписывать» каждые 2-3 года), а стремиться гибко и осознанно подходить и к фичас и к архитектуре.
Насколько я могу судить, что сейчас принцип разработки, все больше склоняется х-х и в продакшен. По крайней мере в бекенде веба. О другом говорить мне сложно.
Недавно общался с коллегой из Европы с которым собираюсь сотрудничать. Когда зашел вопрос об архитектуре и инструментах, тут меня конечно немного удивило, что смысла пилить качественный код нет. Куда выгоднее, с материальной точки зрения, сделать быстро трэш и потом его долго и нудно допиливать.
Я не беру во внимание сейчас enterprise сегмент. Хотя возможно там картина не лучше.alatushkin
10.03.2019 00:06+1Все так. Зп разработчиков таковы, что это давит на экономику компаний поэтому да х-х ив продакшн.
Но! Вот тут и проявляется настоящее мастерство, когда:
1) совместно с бизнесом делите всю систему на части с разной степенью критичности ошибок.
2) критические части делаете тщательно и без суеты с кучей тестов и qa в несколько слоев
3) некритичные — хх, максимально частый деплой, максимально дешёвая архитектура: лишние обобщения скорее вредны. Изменилась предметная область? Не жалко выкинуть и снова сделать быстро. Опирается на ядро из п 2.
Это позволяет и двигаться быстрее и экономить бюджет и явно управлять качеством, а если баг -сорян, у нас лапки, за счёт частого деплояпопрпвим и выложим через 30 минут
kretsu
10.03.2019 12:25Сразу говорю, пишу только то, что виду из своей песочницы и чуть-чуть за ней.
Мне сдается, все сдвинулось в сторону продажи не продукта, а сервисов. Второй момент это даже не доход, а оборот компании. Чем красивее цифирки в отчетах — тем лучше. По этому, бизнесу глубоко пофиг на код. Если в этом году циферки красивее — значит все ок. Если нет, то будет применять все известные инструменты для того, чтоб улучшить циферки в отчетах. Если дешевле закрыть контору, то так и будет.de1vin
10.03.2019 12:32+2Работал на заводе, который оборонкой занимался, в начале нулевых.
Был в цеху один мужичек, хороший токарь. Лет под 60 ему тогда было.
Услышал от него фразу, которую до сих пор употребляю к месту: «Что ху.во сделано, то оху.но выкрашено»
dimkss
09.03.2019 21:31+1Более страшный график – это возрастание стоимости одной строки кода в ~40 раз. Т.е. продуктивность упала со 100% практически до нуля. Программисты работают усердно во всю силу, но по сути ничего не могут сделать.
На правах сарказма:
Это хорошо что они еще оптимизировать и избавляться от лишних строк не начали!
F376
09.03.2019 22:49Но программисты должны считать наоборот, что важнее архитектура.
«Программист» тут слишком широкое понятие.
Это в идеальных представлениях, если за архитектуру программисту платят.
Архитектура важнее для архитектора ПО, для обычного программиста же зачастую это не его область деятельности.
Программист должен бороться за архитектуру. Программист – это тоже участник бизнеса. Архитектура – это его ответственность.
Архитектура должна быть ответственностью все же архитектора. Программист — «участник бизнеса» лишь формально, в большинстве случаев это наемное лицо.
Прежде чем «бороться за архитектуру» следует согласовать это с менеджментом, поскольку «борьба за архитектуру» требует отдельных усилий, это иной класс в разработке.
Не забываем об этом.
А также не забываем о том, что у товарищей типа Robert C. Martin свои специфические интересы и взгляд по-своему специфично деформирован.
Также, все сильно зависит от сегмента ПО и от проекта.
powerman
10.03.2019 09:31Архитектура важнее для архитектора ПО, для обычного программиста же зачастую это не его область деятельности.
Понимать и соблюдать архитектуру должны как раз обычные программисты. Архитектор отвечает за создание и развитие архитектуры, а ревьювить все PR на предмет не обратился ли кто-то из компонента A в компонент B напрямую (что запрещено архитектурой) ни у какого архитектора времени не хватит физически.
Но Вы правы в том, что многие программисты не хотят об этом думать, их устроит любой рабочий вариант реализации фичи, вне зависимости от того, насколько он соответствует требованиям архитектуры. Что характерно, не соответствующий нередко написать проще и быстрее, так что…
Именно по этой причине выстрелила микросервисная архитектура: не смотря на все дополнительные проблемы и накладные расходы связанные с сетевым I/O между компонентами приложения и усложнение деплоя у неё есть киллер-фича — программисты физически не могут нарушить архитектуру (а, точнее, нарушать становится намного дольше и дороже, т.к. требуется вносить странные изменения в API "чужих" сервисов, что требует дополнительной коммуникации с их разработчиками… в общем, становится проще писать используя доступный API, т.е. в рамках ограничений наложенных текущей архитектурой).
qw1
10.03.2019 13:01Просто проблему вынесли на другой уровень. Никто не мешает обратиться в нарушение архтектуры сразу к сервису А вместо того, чтобы писать дополнительный код в сервисе Б (например, кеширующий), как того требует архитектура.
powerman
10.03.2019 14:36Никто не мешает обратиться в нарушение архтектуры сразу к сервису А
Мешает отсутствие нужного API или данных, необходимых для вызова этого API. В этом суть архитектуры в случае микросервисов — не надо проектировать API так, чтобы появилась возможность нарушить архитектуру штатными вызовами API. Если такая возможность есть — значит архитектор облажался, не более того.
qw1
10.03.2019 16:23А если такое API есть?
Ну, например, в приложении (допустим, не клиент-сервер, а обычное локальное на sqlite) в обработке OnClick я не должен обращаться к DAL в обход слоя логики. Но никто, кроме review, не запрещает взять и подключить/использовать ту зависимость, которую использует слой логики.
Аналогично с микросервисами: если договорились, что сервис Б обязан быть фронтом для сервиса А и кешировать его ответы, разработчику может быть лениво создавать в Б загрузку/кеширование некоторой новой сущности и он напрямую залезет за ней в сервис А.powerman
10.03.2019 17:32В этой ситуации все сервисы кроме Б просто не должны знать endpoint сервиса A либо не должны иметь токен дающий доступ к A. Но лично я бы просто не разделял A и Б на два сервиса, если всё-равно все обязаны обращаться к A только через Б.
qw1
10.03.2019 19:12В этой ситуации все сервисы кроме Б просто не должны знать endpoint сервиса A
Это всё хорошо, когда сервисов 3-4, а когда их в проекте 50? Получается примерно то же самое, как с подключением библиотек: все разработчики могут подключать зависимости, а за правомерностью подключений кто-то должен следить.powerman
10.03.2019 19:18Да нет же, следить надо не за правомерностью подключений, а за тем, к чему возможно подключаться в принципе — т.е. за API. Не надо выставлять в API одного из этих 50 сервисов то, чем какой-то из оставшихся 49 сервисов может воспользоваться неправильным способом (т.е. так, чтобы поломать кого-то помимо самого себя).
qw1
10.03.2019 19:50Не понимаю, как можно дизайном API запретить неправильный доступ в обход слоя.
Вот по архитектуре новый модуль должен идти в сервис Б, который обращается к сервису А в свою очередь. Вместо этого там скопипащен кусок сервиса Б и в новом модуле появляется прямое обращение к А (через те API, которые должен был использовать Б).powerman
10.03.2019 20:11В микросервисной архитектуре нет никаких слоёв. Если сервис А выставил наружу некоторое API, то это значит, что любой сервис имеет право это API дёргать и ничего (в сервисе А) от этого не поломается. Если сервис Б предоставляет кеширование для А, и рекомендован к использованию вместо А для остальных сервисов, то это просто рекомендация, если её кто-то проигнорирует, то беды не случится, просто этот кто-то будет работать немного медленнее.
Если сервис А предоставляет API, которое можно использовать некорректным образом, что сломает сервис А, и для решения этой проблемы написан сервис Б, который гарантирует корректное использование API сервиса А, в связи с чем всем остальным запрещено использовать А — то в этом случае А нужно целиком заменить сервисом с корректным API (т.е. Б).
Если у Вас так сложилось, что API сервиса А имеет право дёргать только сервис Б — это уже плохо, и нужно это безобразие как-то гарантировать: например, реализовать авторизацию в API сервиса А, и дать ключ доступ только сервису Б, чтобы остальные сервисы не смогли вызывать API сервиса А т.к. у них нет этого ключа доступа. Или поместите сервисы А и Б в общую изолированную подсеть, чтобы остальные сервисы вообще доступа по сети к А не имели.
qw1
10.03.2019 20:39это просто рекомендация, если её кто-то проигнорирует, то беды не случится
Да и в обычной программе беды не случится, будет просто код постепенно превращаться в лапшу. Я хочу лишь отметить, что микросервисы сами по себе не гарантируюткиллер-фича — программисты физически не могут нарушить архитектуру (а, точнее, нарушать становится намного дольше и дороже, т.к. требуется вносить странные изменения в API «чужих» сервисов
Просто проблема может вылезти другим профилем.powerman
10.03.2019 21:11Это разные проблемы. Микросервисы гарантируют, что изменения в одном не сломают другой. По сути весь интернет — кучка сервисов, как микро так и не очень микро, и только благодаря этому он вообще работает.
Например, есть сервис гуглмапс, у него есть API, и, что бы мы не вытворяли в своём сервисе, использующем сервис гуглмапс — гуглмапс от этого не сломается. Равно как и что бы не вытворяли разработчики гуглмапс — наш сервис это не сломает (ну, предполагая что они, как это принято, сохраняют совместимость API). Про разные части монолита такое сказать нельзя, между ними обычно более сильные связи, разработчики одной нередко вносят изменения в код другой, и в результате незначительные изменения одной могут нечаянно поломать вторую.
F376
10.03.2019 16:01Я пишу исходя из точки зрения высокого уровня, архитектора и топ-менеджмента. Не с точки зрения программиста.
Боб Мартин дорогостоящий архитектор/консультант, и он не очень-то задумывается, о том, что то, что применимо к нему и к крупным организациям, может привести к проблемам у простых смертных. И многие не слишком разумные могут подорваться, и начать пылко исполнять то, что говорят им такие как Роберт Мартин. А если задуматься о том что он предлагает — то он предлагает программистам работать над архитектурой БЕСПЛАТНО. Что не слишком разумный менеджмент и программистов приведет в нехорошие ситуации. Потому что в реальности ничего никогда «бесплатно» не бывает и это аукнется временем, а затем и деньгами. Хорошая архитектура — это не бесплатно во всех смыслах.
Если программист занимается разработкой архитектуры, или от него «требуют архитектуру» — за это должны доплачивать как архитектору. Логично? Если программист это не понимает — он сам себе злобный Буратино. Ну или может быть молодой, пылкий и не очень разумный.
Менеджмент, в свою очередь, должен понимать, что когда х-х и в продакшн, это быстро и дёшево. Но потом не поддерживаемо. Долго, растет стоимость, или всё переписывать. Хотя в некоторых проектах «х-х и в продакшн» это единственный разумный способ разработки, просто потому что сами эти проекты по своей сути представляют собой одноразовое «д в фантике».
По моему мнению, вот это:
Что важнее – поведение или архитектура? Менеджеры считают, что важнее, чтобы система работала. Но программисты должны считать наоборот, что важнее архитектура.
Матрица Эйзенхауэра говорит, что важное и несрочное имеет более высокий приоритет, чем срочное и неважное. А архитектура всегда важна в отличие от поведения, поэтому она более приоритетна.
Программист должен бороться за архитектуру. Программист – это тоже участник бизнеса. Архитектура – это его ответственность.
— «Архитектурный хайп». Не всё тут верно.
Если этому следовать бездумно — будут проблемы.qw1
10.03.2019 16:40Если программист это не понимает — он сам себе злобный Буратино. Ну или может быть молодой, пылкий
А что он должен делать? Говнокод?
Каждый пишет в меру своих способностей. Но если способности оплачиваются неадекватно — это уже другой вопрос и не повод ухудшать качество.
powerman
10.03.2019 18:01+1А если задуматься о том что он предлагает — то он предлагает программистам работать над архитектурой БЕСПЛАТНО.
Это примерно настолько же правда, как и то, что программисты должны БЕСПЛАТНО настраивать и запускать IDE/редактор, БЕСПЛАТНО рефакторить большую функцию на мелкие… любая "сопутствующая" активность не являющаяся обязательной для реализации новой фичи с этой "точки зрения высокого уровня" является потенциальной проблемой, которая может отрицательно сказаться на сроках и/или бюджете проекта.
По сути, хорошая архитектура нужна, в первую очередь, самим программистам — она позволяет им избежать экспоненциального замедления разработки проекта, т.е. даёт им возможность добавлять новые фичи с более-менее константной скоростью, что увеличивает их собственную удовлетворённость от работы, и избавляет от необходимости выслушивать постоянные упрёки менеджеров в том, что всё делается неприемлемо медленно и/или некачественно. Поэтому, да, все программисты должны стараться поддерживать текущую архитектуру, а для этого необходимо её понимать.
Ещё один нюанс заключается в том, что хотя названия архитектурных подходов на низком/среднем/высоком уровнях архитектуры разные, но суть у них очень похожа, поэтому понимание этих принципов необходимо программистам не только для того, чтобы поддерживать архитектуру всего проекта, но и для того, чтобы лучше разделять код по классам/функциям и упрощать тестирование кода в своей области ответственности.
Хорошая архитектура — это не бесплатно во всех смыслах.
О, да! Но Вы упускаете из виду, что отсутствие архитектуры или плохая архитектура — это тоже ни разу ни бесплатно во всех смыслах. Правильно ставить вопрос иначе: что обойдётся дороже для проекта, отсутствующая/плохая архитектура, или хорошая. И ответ на этот вопрос сильно зависит от того, сколько ресурсов планируется тратить на поддержку и развитие проекта.
Программист должен бороться за архитектуру. Программист – это тоже участник бизнеса. Архитектура – это его ответственность.
— «Архитектурный хайп». Не всё тут верно.А по-моему здесь всё верно: если программист воспринимает себя участником бизнеса, то он ответственно решит обойтись без архитектуры в проекте-прототипе, у которого время жизни пара месяцев… и ровно так же ответственно решит, что без нормальной архитектуры писать проект нельзя (даже если менеджмент настаивает на «х-х и в продакшн»), если этот проект планируется долго поддерживать и развивать.
F376
11.03.2019 18:58В общем, я думаю, все всё поняли. Обсуждать тут особо нечего, во всём нужен здравый баланс: Нельзя не уделять внимание архитектуре. Но и ставить архитектурные вопросы как приоритетные нельзя тоже.
Одна из причин моего возражения заключена в том, что миллениалы готовы смотреть в рот Р.Мартину, а я его ровесник. С соответствующим опытом. И то что с апломбом несёт этот товарищ, я воспринимаю критически.
Например, вот что находит у меня возражение. Тенденция настоящего времени — нарастающий хаос, который миллениалы и поколение Z воспринимают как естественное положение вещей. В действительности, отдельными вопросами, такими как архитектурные, должны заниматься отдельные люди. И точно — не все подряд, не безликие «программисты» по Р. Мартину. Хотя бы потому что часто это ведет к тому что невозможно выяснить; кто, зачем и почему придумал такую «архитектуру». В условиях когда каждый программист сам себе свободный архитектор рождаются архитектурные монстры. Проверено.
Neikist
11.03.2019 23:36Серьезно? Вот есть два экрана которые надо связать с апишкой и реализацию этого должен архитектурить аж отдельный человек? По моему если архитектор и есть (а на маленьких проектах это дорого), то он должен общим видением системы заниматься, а не лезть для каждого класса интерфейсы прописывать. Ну и да, на тех же маленьких проектах вполне нормально что программист роль архитектора исполняет, имхо. Как и на больших в пределах своей фичи. С ревью конечно.
Danik-ik
10.03.2019 11:42+2Очень много потерялось в сокращениях и незаконченности, от этого многие комментаторы решили, что в интернете кто-то неправ — при том, что книга не противоречит здравому смыслу, в том числе в части, относящейся к их апелляции.
К примеру, функциональность и архитектура в книге описаны как "первая" и "наибольшая" ценности — приложение которое работает правильно, если его невозможно (можно читать как "слишком дорого") переделать при изменении требований, теряет ценность, если требования меняются (с. 37). Если работает неправильно, но это можно исправить — это лучше. Но лучше всего — когда и работает, как надо, и изменить при необходимости можно. В сравнении плохих вариантов об этом не сказано, но давайте предположим, что читатель адекватен, ладно?
Очевидно, что это имеет существенное значение именно тогда, когда требуется гибкость. Об этом идёт речь, когда заканчивается последовательное введение в тему — с 15 главы (книга вообще философская и сентиментальная, хотя в некоторых вопросах вполне конкретная). При этом дядя Боб не продаёт универсальную таблетку — та же 15 глава говорит о цели и предназначении архитектуры. Сопоставив это с целями, которые мы ставим себе при разработке ПО, мы можем судить о целесообразности, которая (мой вывод) выражается в соотношении ценности функциональности и архитектуры (а не так, что архитектуру вперёд, а цели по боку). Далее, например, в 17 главе, говорящей об архитектурных границах, уже явно обсуждается оверинжиниринг в свете стоимости архитектурных границ.
Если вы верите, что существует экономически обоснованный допустимый уровень говнокода, книга этого не опровергает. Однако, в историческом экскурсе приводятся примеры недостаточного абстрагирования, из-за которых опытный разработчик посмотрел на молодого ещё тогда автора и его команду "как на инопланетян". Есть всё-таки, уровень (сильно зависящий от ожидаемого жизненного цикла продукта, но всегда есть), который надо понимать и соблюдать хотя бы в гигиенических целях.
Если же Вы нуждаетесь в улучшении навыков понимания и построения хорошей архитектуры вообще и архитектурных границ в частности, или, к примеру, хотите понять наконец, что же именно, зачем и как инвертируется при инверсии зависимости — книга будет Вам полезна. А если понравится полуфилософский стиль с уклоном в историю — то ещё и доставит удовольствие.
powerman
10.03.2019 12:14+1Я видел много разочарованных отзывов про эту книжку когда её заказывал: народ ждал новых откровений, и, не узнав из книги ничего нового, сильно расстраивался. А мне она, наоборот, очень понравилась: да, ничего нового в ней нет, зато всё старое описано очень целостно, показана общая картина, с наглядным объяснением зачем и в каких ситуациях нужен каждый элемент архитектуры. И исторические экскурсы там вовсе не лишние, без них целостную картину увидеть сложнее.
Danik-ik
10.03.2019 13:35+1Всегда есть люди, для которых самые "общеизвестные" истины окажутся откровением. Лично для меня уровень понимания темы здорово приподнялся — и за счёт целостности, и за счёт повторения основ теории на более, чем ста страницах (да ещё и с хорошим осмыслением, погружением в суть и развенчанием мифов), и за счёт наглядности и хороших примеров по основной теме.
Это оказалось для меня продвинутым знанием с подробным разбором от самых основ, собранным в одном месте — самодостаточность книги из-за этого на высоте, достаточно не забывать о том самом здравом смысле, и иметь представление об организационных вопросах в обсуждаемой области.
И да, истории там действительно к месту. Главное, что тут имеет место в некотором роде инверсия истории — вместо классического "при нас-то трава была зеленее" они о том, что "Раньше мы многого не знали, а теперь наш опыт может помочь вам".
dopusteam
Что, простите?
'вот Вам почтовый клиент, писем отправлять нельзя, зато архитектура — огонь!'
Lofer
-Нужно добавить «черновик письма».
— Фигня вопрос. Нужно новый почтовый клиент написать 'с нуля'
— Сколько?
-4 месяца
-так вы же клиента написали за 2 месяца!?
— архитекура…
qw1
Петька, архитектура!
20!
Что 20?
А что архитектура?