 |
Благодарности. Об авторе. I. Введение
|
|
|
|
Благодарности
Ниже перечислены все (не в каком‑ то определенном порядке), кто сыграл важную роль в создании этой книги:
Крис Гузиковски (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], Clean Code[7], UML for Java Programmers, Agile Software Development[8], Extreme Programming in Practice, More C++ Gems, Pattern Languages of Program Design 3 и Designing Object Oriented C++ Applications Using the Booch Method».
I. Введение
Чтобы написать действующую программу, не нужно много знать и уметь. Дети в школе делают это постоянно. Юноши и девушки в колледжах начинают свой бизнес, вырастающий до стоимости в миллиарды долларов, написав несколько строк кода на PHP или Ruby. Начинающие программисты в офисах по всему миру перелопачивают горы требований, хранящихся в гигантских баг‑ трекерах, и вносят исправления, чтобы заставить свои системы «работать». Возможно, они пишут не самый лучший код, но он работает. Он работает, потому что заставить что‑ то работать – один раз – не очень сложно.
Создать программу, которая будет работать правильно, – совсем другое дело. Написать правильную программу сложно. Для этого необходимы знания и умения, которые молодые программисты еще не успели приобрести. А чтобы приобрести их, требуется мыслить и анализировать, на что у многих программистов просто нет времени. Это требует такой самодисциплины и организованности, которые не снились большинству программистов. А для этого нужно испытывать страсть к профессии и желание стать профессионалом.
Но когда создается правильный программный код, происходит что‑ то необычное: вам не требуются толпы программистов для поддержки его работоспособности. Вам не нужна объемная документация с требованиями и гигантские баг‑ трекеры. Вам не нужны огромные опенспейсы, работающие круглые сутки без выходных.
Правильный программный код не требует больших трудозатрат на свое создание и сопровождение. Изменения вносятся легко и быстро. Ошибки немногочисленны. Трудозатраты минимальны, а функциональность и гибкость – максимальны.
|
|
|
Да, такое представление кажется утопическим. Но я видел это воочию. Я участвовал в проектах, где дизайн и архитектура системы упрощали их создание и сопровождение. У меня есть опыт работы в проектах, потребовавших меньшего числа участников, чем предполагалось. Мне довелось работать над системами, в которых ошибки встречались удивительно редко. Я видел, какой невероятный эффект оказывает хорошая архитектура на систему, проект и коллектив разработчиков. Я был на земле обетованной.
Но я не прошу верить мне на слово. Оглянитесь на свой опыт. Случалось ли у вас что‑ то противоположное? Доводилось ли вам работать над системами с настолько запутанными и тесными связями, что любое изменение, независимо от сложности, требовало недель труда и было сопряжено с огромным риском? Испытывали ли вы сопротивление плохого кода и неудачного дизайна? Приходилось ли вам видеть, как дизайн системы оказывал отрицательное влияние на моральный дух команды, доверие клиентов и терпение руководителей? Доводилось ли вам оказываться в ситуации, когда отделы, подразделения и целые компании становились жертвами неудачной архитектуры их программного обеспечения? Были ли в аду программирования?
Я был, и многие из нас были там. В нашей среде чаще встречается опыт борьбы с плохим дизайном, чем получение удовольствия от воплощения хорошо продуманной архитектуры.
|
|
|
