Роберт Мартин - Чистая архитектура. Искусство разработки программного обеспечения

И если вас переместить обратно в 1966-й год и показать, как писать и править код на PDP-8, пробивая перфокарты на телетайпе, поддерживающем скорость 10 символов в секунду, вам также могут понадобиться сутки, чтобы оправиться от разочарования. Но потом и вы смогли бы писать код. Сам код мало бы изменился при этом.

В этом весь секрет: неизменность принципов программирования — вот причина общности правил построения программных архитектур для систем самых разных типов. Правила определяют последовательность и порядок компоновки программ из строительных блоков. И поскольку сами строительные блоки являются универсальными и не изменились с течением времени, правила их компоновки также являются универсальными и постоянными.

Начинающие программисты могут подумать, что все это чепуха, что в наши дни все совсем иначе и лучше, что правила прошлого остались в прошлом. Если они действительно так думают, они, к сожалению, сильно ошибаются. Правила не изменились. Несмотря на появление новых языков, фреймворков и парадигм, правила остались теми же, как во времена, когда в 1946-м Алан Тьюринг написал первый программный код.

Изменилось только одно: тогда, в прошлом, мы не знали этих правил. Поэтому нарушали их снова и снова. Теперь, с полувековым опытом за плечами, мы знаем и понимаем правила.

Именно об этих правилах — не стареющих и не изменяющихся — рассказывает эта книга.

Ниже перечислены все (не в каком-то определенном порядке), кто сыграл важную роль в создании этой книги:

Крис Гузиковски (Chris Guzikowski)

Крис Зан (Chris Zahn)

Мэтт Хойзер (Matt Heuser)

Джефф Оверби (Jeff Overbey)

Мика Мартин (Micah Martin)

Джастин Мартин (Justin Martin)

Карл Хикман (Carl Hickman)

Джеймс Греннинг (James Grenning)

Симон Браун (Simon Brown)

Кевлин Хенни (Kevlin Henney)

Джейсон Горман (Jason Gorman)

Дуг Бредбери (Doug Bradbury)

Колин Джонс (Colin Jones)

Гради Буч (Grady Booch)

Кент Бек (Kent Beck)

Мартин Фаулер (Martin Fowler)

Алистер Кокберн (Alistair Cockburn)

Джеймс О. Коплиен (James O. Coplien)

Тим Конрад (Tim Conrad)

Ричард Ллойд (Richard Lloyd)

Кен Финдер (Ken Finder)

Крис Ивер (Kris Iyer (CK))

Майк Карев (Mike Carew)

Джерри Фицпатрик (Jerry Fitzpatrick)

Джим Ньюкирк (Jim Newkirk)

Эд Телен (Ed Thelen)

Джо Мейбл (Joe Mabel)

Билл Дегнан (Bill Degnan)

И многие другие.

Когда я просматривал книгу в окончательном варианте и перечитывал главу о кричащей архитектуре, передо мной стоял образ улыбающегося Джима Уэрича (Jim Weirich) и в ушах слышался его звонкий смех. Удачи тебе, Джим!

Роберт С. Мартин(Robert C. Martin), известный также как «дядюшка Боб» (Uncle Bob), профессионально занимается программированием с 1970 года. Сооснователь компании cleancoders.com , предлагающей видеоуроки для разработчиков программного обеспечения, и основатель компании Uncle Bob Consulting LLC , оказывающей консультационные услуги и услуги по обучению персонала крупным корпорациям. Служит мастером в консалтинговой фирме 8th Light, Inc . в городе Чикаго. Опубликовал десятки статей в специализированных журналах и регулярно выступает на международных конференциях и демонстрациях. Три года был главным редактором журнала C++ Report и первым председателем Agile Alliance .

Мартин написал и выступил редактором множества книг, включая The Clean Coder [6] Роберт Мартин. Идеальный программист. Как стать профессионалом разработки ПО. СПб.: Питер, 2016. — Примеч. пер. , Clean Code [7] Роберт Мартин. Чистый код: создание, анализ и рефакторинг. СПб.: Питер, 2013. — Примеч. пер. , UML for Java Programmers , Agile Software Development [8] Роберт Мартин. Быстрая разработка программ. Принципы, примеры, практика. М.: Вильямс, 2004. — Примеч. пер. , Extreme Programming in Practice , More C++ Gems , Pattern Languages of Program Design 3 и Designing Object Oriented C++ Applications Using the Booch Method ».

Чтобы написать действующую программу, не нужно много знать и уметь. Дети в школе делают это постоянно. Юноши и девушки в колледжах начинают свой бизнес, вырастающий до стоимости в миллиарды долларов, написав несколько строк кода на PHP или Ruby. Начинающие программисты в офисах по всему миру перелопачивают горы требований, хранящихся в гигантских баг-трекерах, и вносят исправления, чтобы заставить свои системы «работать». Возможно, они пишут не самый лучший код, но он работает. Он работает, потому что заставить что-то работать — один раз — не очень сложно.

Создать программу, которая будет работать правильно, — совсем другое дело. Написать правильную программу сложно. Для этого необходимы знания и умения, которые молодые программисты еще не успели приобрести. А чтобы приобрести их, требуется мыслить и анализировать, на что у многих программистов просто нет времени. Это требует такой самодисциплины и организованности, которые не снились большинству программистов. А для этого нужно испытывать страсть к профессии и желание стать профессионалом.

Но когда создается правильный программный код, происходит что-то необычное: вам не требуются толпы программистов для поддержки его работоспособности. Вам не нужна объемная документация с требованиями и гигантские баг-трекеры. Вам не нужны огромные опенспейсы, работающие круглые сутки без выходных.

Правильный программный код не требует больших трудозатрат на свое создание и сопровождение. Изменения вносятся легко и быстро. Ошибки немногочисленны. Трудозатраты минимальны, а функциональность и гибкость — максимальны.

Да, такое представление кажется утопическим. Но я видел это воочию. Я участвовал в проектах, где дизайн и архитектура системы упрощали их создание и сопровождение. У меня есть опыт работы в проектах, потребовавших меньшего числа участников, чем предполагалось. Мне довелось работать над системами, в которых ошибки встречались удивительно редко. Я видел, какой невероятный эффект оказывает хорошая архитектура на систему, проект и коллектив разработчиков. Я был на земле обетованной.

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