Привет, Хаброжители! В книге «Идеальная работа. Программирование без прикрас» легендарный Роберт Мартин (Дядюшка Боб) создал исчерпывающее руководство по хорошей работе для каждого программиста. Роберт Мартин объединяет дисциплины, стандарты и вопросы этики, необходимые для быстрой и продуктивной разработки надежного, эффективного кода, позволяющего испытывать гордость за программное обеспечение, которое вы создаете каждый день. Роберт Мартин, автор бестселлера «Чистый код», начинает с прагматического руководства по пяти основополагающим дисциплинам создания программного обеспечения: разработка через тестирование, рефакторинг, простой дизайн, совместное программирование и тесты. Затем он переходит к стандартам — обрисовывая ожидания «мира» от разработчиков программного обеспечения, рассказывая, как часто различаются эти подходы, и помогает вам устранить несоответствия. Наконец, он обращается к этике программиста, давая десять фундаментальных постулатов, которым должны следовать все разработчики программного обеспечения.
Принятые практики
Что такое принятая практика? Это набор правил, состоящий из обязательной и произвольной частей. Обязательная часть — это то, что делает практику действенной; это причина ее существования. Произвольная часть придает практике форму и содержание. Без произвольной части практика существовать не может.
Например, хирург перед операцией моет руки. Понаблюдав за этим процессом, вы увидите, что мытье рук выполняется особым образом. Хирург не просто намыливает их под проточной водой, как это делает любой из нас. Он следует ритуальной процедуре, которая выглядит примерно так:
взять соответствующее мыло;
взять подходящую щетку;
для каждого пальца сделать:
десять движений по верхней стороне;
десять движений по левой стороне;
десять движений по тыльной стороне;
десять движений по правой стороне;
есять движений под ногтем;
и т. д.
Обязательная часть практики должна быть очевидной. Хирург обязан иметь очень чистые руки. Но обратили ли вы внимание на произвольную часть? Почему движений десять, а не восемь или двенадцать? Зачем делить палец на пять областей? Почему не на три или на семь?
В данном случае все эти числа выбраны произвольно. Просто считается, что этого будет достаточно.
В этой книге я расскажу вам о пяти практиках профессиональной разработки программного обеспечения. Одним из них уже полвека. Другим всего пара десятков лет. Но все они показали свою полезность. Без них в сфере создания ПО было бы практически немыслимым само понятие профессионального мастерства.
Каждая из этих практик имеет собственные обязательные и произвольные элементы. В процессе чтения вы можете столкнуться с тем, что некоторые из этих практик покажутся вам необоснованными или ненужными. В этом случае попытайтесь понять, какие элементы — обязательные или только произвольные — вызывают это чувство. Не позволяйте произвольным элементам сбить вас с толку. Как только вы поймете сущность каждой практики, влияние произвольных элементов, скорее всего, уменьшится.
Скажем, в 1861 году Игнац Земмельвейс (Ignaz Semmelweis) опубликовал статью о необходимости мытья рук для врачей. Результаты его исследований ошеломляли. Он смог показать, что в случаях, когда перед осмотром беременных врачи тщательно мыли руки водным раствором хлора, смертность от родильной горячки, от которой в то время умирала каждая десятая женщина, падала практически до нуля.
Но врачи того времени, рассматривая предложенную Земмельвейсом практику, не смогли отделить обязательную часть от произвольной. Водный раствор хлора был произвольной частью. Суть практики заключалась в самом факте мытья рук. Но мыть их хлорной водой было неудобно, поэтому врачи отвергли саму идею. Прошло много десятилетий, прежде чем они стали это делать.
ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ
В 1970 году, после статьи Уинстона Ройса каскадная разработка стала общепринятой практикой. Исправление этой ошибки заняло почти 30 лет.
К 1995 году специалисты в сфере программного обеспечения начали рассматривать другой, более поэтапный подход. Была предложена к рассмотрению методология Scrum, разработка, управляемая функциональностью (feature-driven development, FDD), метод разработки динамических систем (dynamic systems development method, DSDM) и методология Crystal. Но в целом в отрасли мало что изменилось.
В 1999 году издательство Addison-Wesley выпустило книгу Кента Бека Extreme Programming Explained1. Предложенная Беком концепция базировалась на идеях из вышеперечисленных подходов, добавляя к ним кое-что новое, а именно практики разработки.
Следующие два года энтузиазм по отношению к экстремальному программированию рос экспоненциально. Именно это и привело к Agile-революции. Экстремальное программирование по сей день остается наиболее определенным и наиболее полным из всех Agile-методов. Эта глава посвящена принятым в нем практикам разработки.
Жизненный цикл
На рис. 1.1 вы видите жизненный цикл Рона Джеффриса, содержащий перечень практик XP. Я расскажу вам о четырех практиках, расположенных в центре, и об одной крайней слева.
В центре находятся такие практики, как разработка через тестирование (test-driven development, TDD), рефакторинг, простота проектирования и парное программирование (которое мы будем называть совместным программированием). В крайней левой позиции располагается наиболее технически и инженерно-ориентированная из коммерческих практик XP — пользовательское тестирование.
Это основополагающие практики профессиональной разработки программного обеспечения.
РАЗРАБОТКА ЧЕРЕЗ ТЕСТИРОВАНИЕ
Разработка через тестирование — ключевая дисциплина. Без нее все остальные практики невозможны или бесполезны. Именно поэтому две следующие главы, в которых она описывается, занимают почти половину книги и наполнены техническими деталями. Такой подход может показаться вам несбалансированным. Более того, мне тоже так кажется. Я изо всех сил пытался понять, как с этим быть, но пришел к выводу, что подобный перекос возник как следствие ситуации в нашей отрасли. К сожалению, с этой практикой хорошо знакомо слишком маленькое количество программистов.
Практика разработки через тестирование определяет действия программиста вплоть до секунд. Ее невозможно применить заранее или постфактум. Ее нельзя не заметить, поскольку она пронизывает весь процесс. Ее не получится придерживаться частично. Вы или практикуете разработку через тестирование, или нет.
Суть TDD очень проста. Все начинается с маленьких циклов и тестов. Причем тесты всегда оказываются на первом месте. Они первыми пишутся. Они первыми приводятся в порядок. Они предшествуют любой задаче. При этом все задачи разбиты на мельчайшие циклы.
Время цикла измеряется не в минутах — в секундах. Оно измеряется в символах, а не в строках. Цикл обратной связи замыкается, едва открывшись.
Цель TDD — создать набор тестов, которому можно полностью доверять. Если этот набор тестов пройден, значит, при развертке кода можно чувствовать себя в безопасности.
Разработка через тестирование — самая обременительная и сложная из всех практик. Она обременительна, поскольку влияет на все остальные аспекты. С нее вы начинаете и ею заканчиваете. Она накладывает ограничения на все действия. Она поддерживает темп работы, невзирая на давление окружающей среды.
Сложность разработки через тестирование обусловлена сложностью кода. Для каждого варианта кода существует соответствующий вариант TDD. При этом тесты должны соответствовать коду, но не быть с ним связаны, должны охватывать почти все аспекты кода, но при этом выполняться за секунды. Разработка через тестирование — скрупулезно нарабатываемый и сложный навык, который осваивается с большим трудом, но дает потрясающие результаты.
РЕФАКТОРИНГ
Рефакторинг — это практика, позволяющая писать чистый код. Она трудно реализуема, а порой и невозможна без TDD1. Соответственно, получить чистый код без TDD сложно или невозможно.
Рефакторинг превращает плохо структурированный код в код с лучшей структурой, не меняя его поведения. Последняя часть здесь — самая важная. Именно неизменность поведения кода гарантирует, что даже после изменения его структуры он останется безопасным.
Хотя программные системы и деградируют со временем, в них предпочитают не вмешиваться из страха повлиять на их поведение. Наличие безопасного способа очистки позволяет привести код в порядок, остановив деградацию.
Как гарантировать, что улучшения не повлияют на поведение? С помощью тестов.
Практика рефакторинга также очень сложна, поскольку существует множество способов создания плохо структурированного кода, а значит, и множество стратегий его очистки. Более того, каждая из этих стратегий должна плавно и согласованно вписываться в цикл разработки через тестирование. Как видите, эти практики настолько тесно переплетены, что практически неразделимы. Сложно представить рефакторинг без TDD, а TDD без рефакторинга.
ПРОСТОТА ПРОЕКТИРОВАНИЯ
Жизнь на земле можно описывать на разных уровнях. Высший уровень — это экология, изучающая взаимодействие в рамках биосистем. Ниже находится физиология, изучающая внутреннюю механику жизни. Еще ниже — микробиология, рассматривающая клетки, нуклеиновые кислоты, белки и другие макромолекулярные системы. Те, в свою очередь, описываются химией, которая базируется на квантовой механике.
Если таким же способом рассматривать программирование, то TDD окажется аналогом квантовой механики. Рефакторинг будет соответствовать химии, а простота проектирования — микробиологии. На уровне физиологии у нас окажутся принципы SOLID, объектно-ориентированное проектирование и функциональное программирование, а на уровне экологии — архитектура.
Простота проектирования практически невозможна без рефакторинга. Ведь именно она выступает конечной целью рефакторинга, в то время как сам он является единственным практическим средством для достижения этой цели. Именно рефакторинг позволяет получить проект, состоящий из простых атомарных фрагментов, хорошо вписывающихся в более крупные структуры программ, систем и приложений.
Простота проектирования базируется на четырех несложных правилах, так что придерживаться данной практики легко. Однако, в отличие от TDD и рефакторинга, это неточная дисциплина. Здесь приходится опираться на рассуждения и опыт. Первый признак, по которому можно отличить выучившего правила новичка от понимающего принципы специалиста, — отличный результат. Майкл Физерс (Michael Feathers) назвал это чувствовать проект.
СОВМЕСТНОЕ ПРОГРАММИРОВАНИЕ
Практика совместного программирования отражена в искусстве работы в команде. Она включает в себя такие вещи, как парное или групповое программирование, анализ кода и мозговые штурмы. Совместное программирование предполагает участие вообще всех членов команды — как программистов, так и всех остальных. Это основной способ поделиться знаниями, обеспечить согласованность работы и объединить команду в функционирующее целое.
Совместное программирование — наименее техническая и наименее директивная из всех практик. Но порой она оказывается самой важной, поскольку создать эффективную команду очень непросто, и это большая ценность.
ПОЛЬЗОВАТЕЛЬСКОЕ ТЕСТИРОВАНИЕ
Практика пользовательского тестирования связывает команду разработчиков программного обеспечения с его заказчиками. Перед разработчиками стоит цель — обеспечить поведение системы в соответствии с данной заказчиками спецификацией. Для проверки этого соответствия пишутся тесты. Успешное их прохождение означает, что система ведет себя так, как указано в требованиях.
Представители заказчика должны иметь возможность прочитать и понять эти тесты и внести в них коррективы. Наблюдение за процессом тестирования и участие в нем позволяют заказчикам убедиться, что программное обеспечение делает именно то, что от него требуется.
Более подробно с книгой можно ознакомиться на сайте издательства:
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 30% по купону — Мартин
Покупка электронной книги вне РФ доступна на Google Play.
