Поспешай не торопясь.
И она же является ответом на дилемму, стоящую перед руководством. Единственный способ обратить вспять снижение продуктивности и увеличение стоимости – заставить разработчиков перестать думать как самонадеянный Заяц и начать нести ответственность за беспорядок, который они учинили.
Разработчики могут подумать, что проблему можно исправить, только начав все с самого начала и перепроектировав всю систему целиком, – но это в них говорит все тот же Заяц. Та же самонадеянность, которая прежде уже привела к беспорядку, теперь снова говорит им, что они смогут построить лучшую систему, если только вновь вступят в гонку. Однако в действительности все не так радужно:
Самонадеянность, управляющая перепроектированием, приведет к тому же беспорядку, что и прежде.
Заключение
Любой организации, занимающейся разработкой, лучше всего избегать самонадеянных решений и с самого начала со всей серьезностью отнестись к качеству архитектуры ее продукта.
Серьезное отношение к архитектуре программного обеспечения подразумевает знание о том, что такое хорошая архитектура. Чтобы создать систему, дизайн и архитектура которой способствуют уменьшению трудозатрат и увеличению продуктивности, нужно знать, какие элементы архитектуры ведут к этому.
Именно об этом рассказывается в данной книге. В ней рассказывается, как выглядит добротная, чистая архитектура и дизайн, чтобы разработчики могли создавать системы, способные приносить прибыль долгое время.
2. История о двух ценностях
Всякая программная система имеет две разные ценности: поведение и структуру. Разработчики отвечают за высокий уровень обеих этих ценностей. Но, к сожалению, они часто сосредоточиваются на чем-то одном, забывая про другое. Хуже того, они нередко сосредоточиваются на меньшей из двух ценностей, что в конечном итоге обесценивает систему.
Поведение
Первая ценность программного обеспечения – его поведение. Программистов нанимают на работу, чтобы они заставили компьютеры экономить деньги или приносить прибыль заинтересованной стороне. Для этого мы помогаем заинтересованным сторонам разработать функциональную спецификацию или документ с требованиями. Затем пишем код, заставляющий компьютеры заинтересованных сторон удовлетворять этим требованиям.
Когда компьютер нарушает требования, программисты вынимают свои отладчики и исправляют проблему.
Многие программисты полагают, что этим их работа ограничивается. Они уверены, что их задача – заставлять компьютеры соответствовать требованиям и исправлять ошибки. Они жестоко ошибаются.
Архитектура
Вторая ценность программного обеспечения заключена в самом названии «программное обеспечение». Слово «обеспечение» означает «продукт»; а слово «программное»… Как раз в нем и заключается вторая ценность.
Идея программного обеспечения состоит в том, чтобы дать простую возможность изменять поведение компьютеров. Поведение компьютеров в некоторых пределах можно также изменять посредством аппаратного обеспечения, но этот путь намного сложнее.
Для достижения этой цели программное обеспечение должно быть податливым – то есть должна быть возможность легко изменить его. Когда заинтересованные стороны меняют свое мнение о некоторой особенности, приведение ее в соответствие с пожеланиями заинтересованной стороны должно быть простой задачей. Сложность в таких случаях должна быть пропорциональна лишь масштабу изменения, но никак не его форме.
Именно эта разница между масштабом и формой часто является причиной роста стоимости разработки программного обеспечения. Именно по этой причине стоимость растет пропорционально объему требуемых изменений. Именно поэтому стоимость разработки в первый год существенно ниже, чем во второй, а во второй год ниже, чем в третий.
С точки зрения заинтересованных сторон они просто формируют поток изменений примерно одинакового масштаба. С точки зрения разработчиков, заинтересованные стороны формируют поток фрагментов, которые они должны встраивать в мозаику со все возрастающей сложностью. Каждый новый запрос сложнее предыдущего, потому что форма системы не соответствует форме запроса.
Я использовал здесь слово «форма» не в традиционном его понимании, но, как мне кажется, такая метафора вполне уместна. У разработчиков программного обеспечения часто складывается ощущение, что их заставляют затыкать круглые отверстия квадратными пробками.
Проблема, конечно же, кроется в архитектуре системы. Чем чаще архитектура отдает предпочтение какой-то одной форме, тем выше вероятность, что встраивание новых особенностей в эту структуру будет даваться все сложнее и сложнее. Поэтому архитектуры должны быть максимально независимыми от формы.
Наибольшая ценность
Функциональность или архитектура? Что более ценно? Что важнее – правильная работа системы или простота ее изменения?
Если задать этот вопрос руководителю предприятия, он наверняка ответит, что важнее правильная работа. Разработчики часто соглашаются с этим мнением. Но оно ошибочно. Я могу доказать ошибочность этого взгляда простым логическим инструментом исследования экстремумов.
Если правильно работающая программа не допускает возможности ее изменения, она перестанет работать правильно, когда изменятся требования, и вы не сможете заставить ее работать правильно. То есть программа станет бесполезной.
Если программа работает неправильно, но легко поддается изменению, вы сможете заставить работать ее правильно и поддерживать ее работоспособность по мере изменения требований. То есть программа постоянно будет оставаться полезной.
Эти аргументы могут показаться вам неубедительными. В конце концов, нет таких программ, которые нельзя изменить. Однако есть системы, изменить которые практически невозможно, потому что стоимость изменений превысит получаемые выгоды. Многие системы достигают такого состояния в некоторых своих особенностях или конфигурациях.
Если спросить руководителя, хотел бы он иметь возможность вносить изменения, он ответит, что безусловно хотел бы, но тут же может уточнить, что работоспособность в данный момент для него важнее гибкости в будущем. Однако если руководитель потребует внести изменения, а ваши затраты на эти изменения окажутся несоизмеримо высокими, он почти наверняка будет негодовать оттого, что вы довели систему до такого состояния, когда стоимость изменений превышает разумные пределы.
Матрица Эйзенхауэра
Рассмотрим матрицу президента Дуайта Дэвида Эйзенхауэра для определения приоритета между важностью и срочностью (рис. 2.1). Об этой матрице Эйзенхауэр говорил так:
У меня есть два вида дел, срочные и важные. Срочные дела, как правило, не самые важные, а важные – не самые срочные[9].
Рис. 2.1. Матрица Эйзенхауэра
Это старое изречение несет много истины. Срочное действительно редко бывает важным, а важное – срочным.
Первая ценность программного обеспечения – поведение – это нечто срочное, но не всегда важное.
Вторая ценность – архитектура – нечто важное, но не всегда срочное.
Конечно, имеются также задачи важные и срочные одновременно и задачи не важные и не срочные. Все эти четыре вида задач можно расставить по приоритетам.
1. Срочные и важные.
2. Не срочные и важные.
3. Срочные и не важные.
4. Не срочные и не важные.
Обратите внимание, что архитектура кода – важная задача – оказывается в двух верхних позициях в этом списке, тогда как поведение кода занимает первую и третью позиции.
Руководители и разработчики часто допускают ошибку, поднимая пункт 3 до уровня пункта 1. Иными словами, они неправильно отделяют срочные и не важные задачи от задач, которые по-настоящему являются срочными и важными. Эта ошибочность суждений приводит к игнорированию важности архитектуры системы и уделению чрезмерного внимания не важному поведению.
Разработчики программного обеспечения оказываются перед проблемой, обусловленной неспособностью руководителей оценить важность архитектуры. Но именно для ее решения они и были наняты. Поэтому разработчики должны всякий раз подчеркивать приоритет важности архитектуры перед срочностью поведения.
Битва за архитектуру
Эта обязанность означает постоянную готовность к битве – возможно, в данном случае лучше использовать слово «борьба». Честно говоря, подобная ситуация распространена практически повсеместно. Команда разработчиков должна бороться за то, что, по их мнению, лучше для компании, так же как команда управленцев, команда маркетинга, команда продаж и команда эксплуатации. Это всегда борьба.
Эффективные команды разработчиков часто выходят победителями в этой борьбе. Они открыто и на равных вступают в конфликт со всеми другими заинтересованными сторонами. Помните: как разработчик программного обеспечения вы тоже являетесь заинтересованной стороной. У вас есть свой интерес в программном обеспечении, который вы должны защищать. Это часть вашей роли и ваших обязанностей. И одна из основных причин, почему вас наняли.
Важность этой задачи удваивается, если вы выступаете в роли архитектора программного обеспечения. Архитекторы, в силу своих профессиональных обязанностей, больше сосредоточены на структуре системы, чем на конкретных ее особенностях и функциях. Архитекторы создают архитектуру, помогающую быстрее и проще создавать эти особенности и функции, изменять их и дополнять.
Просто помните, что если поместить архитектуру на последнее место, разработка системы будет обходиться все дороже, и в конце концов внесение изменений в такую систему или в отдельные ее части станет практически невозможным. Если это случилось, значит, команда разработчиков сражалась недостаточно стойко за то, что они считали необходимым.
II. Начальные основы: парадигмы программирования
Архитектура программного обеспечения начинается с кода, поэтому начнем обсуждение архитектуры с рассказа о самом первом программном коде.
Основы программирования заложил Алан Тьюринг в 1938 году. Он не первый, кто придумал программируемую машину, но он первым понял, что программы – это всего лишь данные. К 1945 году Тьюринг уже писал настоящие программы для настоящих компьютеров, используя код, который мы смогли бы прочитать (приложив определенные усилия). В своих программах он использовал циклы, конструкции ветвления, операторы присваивания, подпрограммы, стеки и другие знакомые нам структуры. Тьюринг использовал двоичный язык.
С тех пор в программировании произошло несколько революций. Одна из самых известных – революция языков. Во-первых, в конце 1940-х появились ассемблеры. Эти «языки» освободили программистов от тяжкого бремени трансляции их программ в двоичный код. В 1951 году Грейс Хоппер изобрела первый компилятор A0. Именно она фактически ввела термин компилятор. В 1953 году был изобретен язык Fortran (через год после моего рождения). Затем последовал непрерывный поток новых языков программирования: COBOL, PL/1, SNOBOL, C, Pascal, C++, Java и так до бесконечности.
Другая, еще более важная, как мне кажется, революция произошла в парадигмах программирования. Парадигма – это способ программирования, не зависящий от конкретного языка. Парадигма определяет, какие структуры использовать и когда их использовать. До настоящего времени было придумано три такие парадигмы. По причинам, которые мы обсудим далее, едва ли стоит ожидать каких-то других, новых парадигм.
3. Обзор парадигм
В этой главе дается общий обзор следующих трех парадигм: структурное программирование, объектно-ориентированное программирование и функциональное программирование.
Структурное программирование
Первой, получившей всеобщее признание (но не первой из придуманных), была парадигма структурного программирования, предложенная Эдсгером Вибе Дейкстрой в 1968 году. Дейкстра показал, что безудержное использование переходов (инструкций goto) вредно для структуры программы. Как будет описано в последующих главах, он предложил заменить переходы более понятными конструкциями if/then/else и do/while/until.
Подводя итог, можно сказать, что:
Структурное программирование накладывает ограничение на прямую передачу управления.
Объектно-ориентированное программирование
Второй парадигмой, получившей широкое распространение, стала парадигма, в действительности появившаяся двумя годами ранее, в 1966-м, и предложенная Оле-Йоханом Далем и Кристеном Нюгором. Эти два программиста заметили, что в языке ALGOL есть возможность переместить кадр стека вызова функции в динамическую память (кучу), благодаря чему локальные переменные, объявленные внутри функции, могут сохраняться после выхода из нее. В результате функция превращалась в конструктор класса, локальные переменные – в переменные экземпляра, а вложенные функции – в методы. Это привело к открытию полиморфизма через строгое использование указателей на функции.
Подводя итог, можно сказать, что:
Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.
Функциональное программирование
Третьей парадигмой, начавшей распространяться относительно недавно, является самая первая из придуманных. Фактически изобретение этой парадигмы предшествовало появлению самой идеи программирования. Парадигма функционального программирования является прямым результатом работы Алонзо Чёрча, который в 1936 году изобрел лямбда-исчисление (или λ-исчисление), исследуя ту же математическую задачу, которая примерно в то же время занимала Алана Тьюринга. Его λ-исчисление легло в основу языка LISP, изобретенного в 1958 году Джоном Маккарти. Основополагающим понятием λ-исчисления является неизменяемость – то есть невозможность изменения значений символов. Фактически это означает, что функциональный язык не имеет инструкции присваивания. В действительности большинство функциональных языков обладает некоторыми средствами, позволяющими изменять значение переменной, но в очень ограниченных случаях.
Подводя итог, можно сказать, что:
Функциональное программирование накладывает ограничение на присваивание.
Пища для ума
Обратите внимание на шаблон, который я преднамеренно ввел в представление этих трех парадигм программирования: каждая отнимает у программиста какие-то возможности. Ни одна не добавляет новых возможностей. Каждая накладывает какие-то дополнительные ограничения, отрицательные по своей сути. Парадигмы говорят нам не столько что делать, сколько чего нельзя делать.
Если взглянуть под другим углом, можно заметить, что каждая парадигма что-то отнимает у нас. Три парадигмы вместе отнимают у нас инструкции goto, указатели на функции и оператор присваивания. Есть ли у нас еще что-то, что можно отнять?
Вероятно, нет. Скорее всего, эти три парадигмы останутся единственными, которые мы увидим, – по крайней мере единственными, что-то отнимающими у нас. Доказательством отсутствия новых парадигм может служить тот факт, что все три известные парадигмы были открыты в течение десяти лет, между 1958 и 1968 годами. За многие последующие десятилетия не появилось ни одной новой парадигмы.