Создание, анализ ирефакторинг
 Скачать 3.16 Mb.
|
|
Отношение Вам доводилось продираться через код настолько запутанный, что у вас уходи- ли недели на то, что должно было занять несколько часов? Вы видели, как изме- нение, которое вроде бы должно вноситься в одной строке, приходится вносить в сотнях разных модулей? Эти симптомы стали слишком привычными . Почему это происходит с кодом? Почему хороший код так быстро загнивает и превращается в плохой код? У нас обычно находится масса объяснений . Мы жалуемся на изменения в требованиях, противоречащие исходной архитектуре . Мы стенаем о графиках, слишком жестких для того, чтобы делать все, как поло- жено . Мы сплетничаем о глупом начальстве, нетерпимых клиентах и бестолковых типах из отдела маркетинга . Однако вина лежит вовсе не на них, а на нас самих . Дело в нашем непрофессионализме . Возможно, проглотить эту горькую пилюлю будет непросто . Разве мы виноваты в этом хаосе? А как же требования? График? Глупое начальство и бестолковые типы из отдела маркетинга? Разве по крайней мере часть вины не лежит на них? Нет . Начальство и маркетологи обращаются к нам за информацией, на основании которой они выдвигают свои обещания и обязательства; но даже если они к нам не обращаются, мы не должны бояться говорить им то, что мы думаем . Пользо- ватели обращаются к нам, чтобы мы высказали свое мнение относительно того, насколько уместны требования в системе . Руководители проектов обращаются к нам за помощью в составлении графика . Мы принимаем самое деятельное 27 28 Глава 1 . Чистый код участие в планировании проекта и несем значительную долю ответственности за любые провалы; особенно если эти провалы обусловлены плохим кодом! «Но постойте! — скажете вы . — Если я не сделаю то, что говорит мой начальник, меня уволят» . Скорее всего, нет . Обычно начальники хотят знать правду, даже если по их поведению этого не скажешь . Начальники хотят видеть хороший код, даже если они помешаны на рабочем графике . Они могут страстно защищать график и требования; но это их работа . А ваша работа — так же страстно защи- щать код . Чтобы стало понятнее, представьте, что вы — врач, а ваш пациент требует пре- кратить дурацкое мытье рук при подготовке к операции, потому что это занимает слишком много времени 1 ! Естественно, пациент — это ваш начальник; и все же врач должен наотрез отказаться подчиниться его требованиям . Почему? Потому что врач знает об опасности заражения больше, чем пациент . Было бы слишком непрофессионально (а то и преступно) подчиниться воле пациента . Таким образом, программист, который подчиняется воле начальника, не пони- мающего опасность некачественного кода, проявляет непрофессионализм . Основной парадокс Программисты сталкиваются с основным парадоксом базовых ценностей . Каж- дый разработчик, имеющий сколько-нибудь значительный опыт работы, знает, что предыдущий беспорядок замедляет его работу . Но при этом все разработчи- ки под давлением творят беспорядок в своем коде для соблюдения графика . Ко- роче, у них нет времени, чтобы работать быстро! Настоящие профессионалы знают, что вторая половина этого парадокса неверна . Невозможно выдержать график, устроив беспорядок . На самом деле этот бес- порядок сразу же замедлит вашу работу, и график будет сорван . Единственный способ выдержать график — и единственный способ работать быстро — заклю- чается в том, чтобы постоянно поддерживать чистоту в коде . Искусство чистого кода? Допустим, вы согласились с тем, что беспорядок в коде замедляет вашу работу . Допустим, вы согласились, что для быстрой работы необходимо соблюдать чи- стоту . Тогда вы должны спросить себя: «А как мне написать чистый код?» Беспо- лезно пытаться написать чистый код, если вы не знаете, что это такое! К сожалению, написание чистого кода имеет много общего с живописью . Как пра- вило, мы способны отличить хорошую картину от плохой, но это еще не значит, 1 Когда Игнац Земмельвейс в 1847 году впервые порекомендовал врачам мыть руки перед осмотром пациентов, его советы были отвергнуты на том основании, что у врачей слишком много работы и на мытье рук у них нет времени . 28 Расплата за хаос 29 что мы умеем рисовать . Таким образом, умение отличать чистый код от грязно- го еще не означает, что вы умеете писать чистый код! Чтобы написать чистый код, необходимо сознательно применять множество при- емов, руководствуясь приобретенным усердным трудом чувством «чистоты» . Ключевую роль здесь играет «чувство кода» . Одни с этим чувством рождаются . Другие работают, чтобы развить его . Это чувство не только позволяет отличить хороший код от плохого, но и демонстрирует стратегию применения наших на- выков для преобразования плохого кода в чистый код . Программист без «чувства кода» посмотрит на грязный модуль и распознает беспорядок, но понятия не имеет, что с ним делать . Программист с «чувством кода» смотрит на грязный модуль и видит различные варианты и возможности . «Чувство кода» поможет ему выбрать лучший вариант и спланировать последо- вательность преобразований, сохраняющих поведение программы и приводящих к нужному результату . Короче говоря, программист, пишущий чистый код, — это художник, который проводит пустой экран через серию преобразований, пока он не превратится в элегантно запрограммированную систему . Что такое «чистый код»? Вероятно, сколько существует программистов, столько найдется и определений . Поэтому я спросил у некоторых известных, чрезвычайно опытных программи- стов, что они думают по этому поводу . БьёРн СтРАуСтРуП, СОЗДАтель C++ И АВтОР КнИГИ «The C++ ProgrammIng LangUage» Я люблю, чтобы мой код был элегантным и эф- фективным. Логика должны быть достаточно прямолинейной, чтобы ошибкам было трудно спрятаться; зависимости — минимальными, что- бы упростить сопровождение; обработка оши- бок — полной в соответствии с выработанной стратегией; а производительность — близкой к оптимальной, чтобы не искушать людей за- грязнять код беспринципными оптимизациями. Чистый код хорошо решает одну задачу. Бьёрн использует слово «элегантный» . Хорошее слово! Словарь в моем Mac- Book® выдает следующие определения: доставляющий удовольствие своим изяществом и стилем; сочетающий простоту с изобретательностью . Обратите внимание на оборот «доставляющий удовольствие» . Очевидно, Бьёрн считает, 29 30 Глава 1 . Чистый код что чистый код приятно читать . При чтении чистого кода вы улыбаетесь, как при виде искусно сделанной музыкальной шкатулки или хорошо сконструированной машины . Бьёрн также упоминает об эффективности — притом дважды . Наверное, ни- кого не удивят эти слова, произнесенные изобретателем C++, но я думаю, что здесь кроется нечто большее, чем простое стремление к скорости . Напрасные траты процессорного времени неэлегантны, они не радуют глаз . Также обратите внимание на слово «искушение», которым Бьёрн описывает последствия неэле- гантности . В этом кроется глубокая истина . Плохой код искушает, способствуя увеличению беспорядка! Когда другие программисты изменяют плохой код, они обычно делают его еще хуже . Прагматичные Дэйв Томас (Dave Thomas) и Энди Хант (Andy Hunt) высказали ту же мысль несколько иначе . Они сравнили плохой код с разбитыми окнами 1 Здание с разбитыми окнами выглядит так, словно никому до него нет дела . По- этому люди тоже перестают обращать на него внимание . Они равнодушно смо- трят, как на доме появляются новые разбитые окна, а со временем начинают сами бить их . Они уродуют фасад дома надписями и ус траивают мусорную свалку . Одно разбитое окно стало началом процесса разложения . Бьёрн также упоминает о необходимости полной обработки ошибок . Это одно из проявлений внимания к мелочам . Упрощенная обработка ошибок — всего лишь одна из областей, в которых программисты пренебрегают мелочами . Утеч- ка — другая область, состояния гонки — третья, непоследовательный выбор имен — четвертая… Суть в том, что чистый код уделяет пристальное внимание мелочам . В завершение Бьёрн говорит о том, что чистый код хорошо решает одну задачу . Не случайно многие принципы проектирования программного обеспечения сводятся к этому простому наставлению . Писатели один за другим пытаются донести эту мысль . Плохой код пытается сделать слишком много всего, для него характерны неясные намерения и неоднозначность целей . Для чистого кода ха- рактерна целенаправленность . Каждая функция, каждый класс, каждый модуль фокусируются на конкретной цели, не отвлекаются от нее и не загрязняются окружающими подробностями . ГРЭДИ БуЧ, АВтОР КнИГИ «obJeCT orIenTeD anaLySIS anD DeSIgn wITh aPPLICaTIonS» Чистый код прост и прямолинеен. Чистый код читается, как хорошо написанная проза. Чистый код никогда не затемняет намерения проекти- ровщика; он полон четких абстракций и про- стых линий передачи управления. 1 http://www .pragmaticprogrammer .com/booksellers/2004-12 .html . 30 Расплата за хаос 31 Грэди частично говорит о том же, о чем говорил Бьёрн, но с точки зрения удобо- читаемости . Мне особенно нравится его замечание о том, что чистый код должен читаться, как хорошо написанная проза . Вспомните какую-нибудь хорошую книгу, которую вы читали . Вспомните, как слова словно исчезали, заменяясь зрительными образами! Как кино, верно? Лучше! Вы словно видели персонажей, слышали звуки, испытывали душевное волнение и сопереживали героям . Конечно, чтение чистого кода никогда не сравнится с чтением «Властелина ко- лец» . И все же литературная метафора в данном случае вполне уместна . Чистый код, как и хорошая повесть, должен наглядно раскрыть интригу решаемой зада- чи . Он должен довести эту интригу до высшей точки, чтобы потом читатель вос- кликнул: «Ага! Ну конечно!», когда все вопросы и противоречия благополучно разрешатся в откровении очевидного решения . На мой взгляд, использованный Грэди оборот «четкая абстракция» представ- ляет собой очаровательный оксюморон! В конце концов, слово «четкий» почти всегда является синонимом для слова «конкретный» . В словаре моего MacBook приведено следующее определение слова «четкий»: краткий, решительный, фактический, без колебаний или лишних подробностей . Несмотря на кажущееся смысловое противоречие, эти слова несут мощный информационный посыл . Наш код должен быть фактическим, а не умозрительным . Он должен содержать только то, что необходимо . Читатель должен видеть за кодом нашу решительность . «БОльшОй» ДЭйВ тОМАС, ОСнОВАтель oTI, КРеСтный Отец СтРАтеГИИ eCLIPSe Чистый код может читаться и усовершенство- ваться другими разработчиками, кроме его ис- ходного автора. Для него написаны модульные и приемочные тесты. В чистом коде использу- ются содержательные имена. Для выполнения одной операции в нем используется один путь (вместо нескольких разных). Чистый код обла- дает минимальными зависимостями, которые явно определены, и четким, минимальным API. Код должен быть грамотным, потому что в зави- симости от языка не вся необходимая информа- ция может быть четко выражена в самом коде. Большой Дэйв разделяет стремление Грэди к удобочитаемости, но с одной важ- ной особенностью . Дэйв утверждает, что чистота кода упрощает его доработку другими людьми . На первый взгляд это утверждение кажется очевидным, но его важность трудно переоценить . В конце концов, код, который легко читается, и код, который легко изменяется, — не одно и то же . Дэйв связывает чистоту с тестами! Десять лет назад это вызвало бы множество недоуменных взглядов . Однако методология разработки через тестирование оказала огромное влияние на нашу отрасль и стала одной из самых фундамен- 31 32 Глава 1 . Чистый код тальных дисциплин . Дэйв прав . Код без тестов не может быть назван чистым, каким бы элегантным он ни был и как бы хорошо он ни читался . Дэйв использует слово «минимальный» дважды . Очевидно, он отдает предпо- чтение компактному коду перед объемистым кодом . В самом деле, это положение постоянно повторяется в литературе по программированию от начала ее суще- ствования . Чем меньше, тем лучше . Дэйв также говорил, что код должен быть грамотным . Это ненавязчивая ссылка на концепцию «грамотного программирования» Дональда Кнута [Knuth92] . Итак, код должен быть написан в такой форме, чтобы он хорошо читался людьми . МАйКл ФИЗеРС, АВтОР КнИГИ «workIng effeCTIveLy wITh LegaCy CoDe» Я мог бы перечислить все признаки, присущие чистому коду, но существует один важнейший признак, из которого следуют все остальные. Чистый код всегда выглядит так, словно его автор над ним тщательно потрудился. Вы не найдете никаких очевидных возможностей для его улучшения. Все они уже были продуманы автором кода. Попытавшись представить воз- можные усовершенствования, вы снова придете к тому, с чего все началось: вы рассматриваете код, тщательно продуманный и написанный на- стоящим мастером, небезразличным к своему ремеслу. Всего одно слово: тщательность . На самом деле оно составляет тему этой книги . Возможно, ее название стоило снабдить подзаголовком: «Как тщательно работать над кодом» . Майкл попал в самую точку . Чистый код — это код, над которым тщательно поработали . Кто-то не пожалел своего времени, чтобы сделать его простым и стройным . Кто-то уделил должное внимание всем мелочам и относился к коду с душой . РОн ДжеФФРИС, АВтОР КнИГ «exTreme ProgrammIng InSTaLLeD» И «exTreme ProgrammIng aDvenTUreS In C#» Карьера Рона началась с программирования на языке Fortran . С тех пор он писал код практиче- ски на всех языках и на всех компьютерах . К его словам стоит прислушаться . 32 Расплата за хаос 33 За последние коды я постоянно руководствуюсь «правилами простого кода», сформулированными Беком. В порядке важности, простой код: — проходит все тесты; — не содержит дубликатов; — выражает все концепции проектирования, заложенные в систему; — содержит минимальное количество сущностей: классов, методов, функций и т. д. Из всех правил я уделяю основное внимание дублированию. Если что-то делает- ся в программе снова и снова, это свидетельствует о том, что какая-то мыслен- ная концепция не нашла представления в коде. Я пытаюсь понять, что это такое, а затем пытаюсь выразить идею более четко. Выразительность для меня прежде всего означает содержательность имен. Обыч но я провожу переименования по несколько раз, пока не остановлюсь на окончательном варианте. В современных средах программирования — таких, как Eclipse — переименование выполняется легко, поэтому изменения меня не бес- покоят. Впрочем, выразительность не ограничивается одними лишь именами. Я также смотрю, не выполняет ли объект или метод более одной операции. Если это объект, то его, вероятно, стоит разбить на два и более объекта. Если это метод, я всегда применяю к нему прием «извлечения метода»; в итоге у меня остается основной метод, который более четко объясняет, что он делает, и не- сколько подметодов, объясняющих, как он это делает. Отсутствие дублирования и выразительности являются важнейшими составляю- щими чистого кода в моем понимании. Даже если при улучшении грязного кода вы будете руководствоваться только этими двумя целями, разница в качестве кода может быть огромной. Однако существует еще одна цель, о которой я также постоянно помню, хотя объяснить ее будет несколько сложнее. После многолетней работы мне кажется, что все программы состоят из очень похожих элементов. Для примера возьмем операцию «найти элемент в коллек- ции». Независимо от того, работаем ли мы с базой данных, содержащий инфор- мацию о работниках, или хеш-таблицей с парами «ключ-значение», или масси- вом с однотипными объектами, на практике часто возникает задача извлечь кон- кретный элемент из этой коллекции. В подобных ситуациях я часто инкапсули- рую конкретную реализацию в более абстрактном методе или классе. Это откры- вает пару интересных возможностей. Я могу определить для нужной функциональности какую-нибудь простую реа- лизацию (например, хеш-таблицу), но поскольку все ссылки прикрыты моей ма- ленькой абстракцией, реализацию можно в любой момент изменить. Я могу бы- стро двигаться вперед, сохраняя возможность внести изменения позднее. Кроме того, абстракция часто привлекает мое внимание к тому, что же «действи- тельно» происходит в программе, и удерживает меня от реализации поведения коллекций там, где в действительности достаточно более простых способов по- лучения нужной информации. Сокращение дублирования, высокая выразитель- ность и раннее построение простых абстракций. Все это составляет чистый код в моем понимании. 33 34 Глава 1 . Чистый код В нескольких коротких абзацах Рон представил сводку содержимого этой книги . Устранение дублирования, выполнение одной операции, выразительность, про- стые абстракции . Все на месте . уОРД КАннИнГеМ, СОЗДАтель wIkI, СОЗДАтель fIT, ОДИн ИЗ СОЗДАтелей ЭКСтРеМАльнОГО ПРОГРАММИРОВАнИя . ВДОхнОВИтель нАПИСАнИя КнИГИ «DeSIgn PaTTernS» . ДухОВный лИДеР SmaLLTaLk И ОБъеКтнО- ОРИентИРОВАннОГО ПОДхОДА . КРеСтный Отец ВСех, КтО тщАтельнО ОтнОСИтСя К нАПИСАнИю КОДА . Вы работаете с чистым кодом, если каждая функция делает примерно то, что вы ожидали. Код можно назвать красивым, если у вас так- же создается впечатление, что язык был создан специально для этой задачи. Подобные заявления — отличительная способность Уорда . Вы читаете их, ки- ваете головой и переходите к следующей теме . Это звучит на столько разумно, настолько очевидно, что не выглядит чем-то глубоким и мудрым . Вроде бы все само собой разумеется . Но давайте присмотримся повнимательнее . «…примерно то, что вы ожидали» . Когда вы в последний раз видели модуль, который делал примерно то, что вы ожидали? Почему попадающиеся нам моду- ли выглядят сложными, запутанными, приводят в замешательство? Разве они не нарушают это правило? Как часто вы безуспешно пытались понять логику всей системы и проследить ее в том модуле, который вы сейчас читаете? Когда в последний раз при чтении кода вы кивали головой так, как при очевидном за- явлении Уорда? Уорд считает, что чтение чистого кода вас совершенно не удивит . В самом деле, оно даже не потребует от вас особых усилий . Вы читаете код, и он делает при- мерно то, что вы ожидали . Чистый код очевиден, прост и привлекателен . Каждый модуль создает условия для следующего . Каждый модуль показывает, как будет написан следующий модуль . Чистые программы написаны настолько хорошо, что вы этого даже не замечаете . Благодаря автору код выглядит до смешного простым, как и все действительно выдающиеся творения . А как насчет представления Уорда о красоте? Все мы жаловались на языки, не предназначенные для решения наших задач . Однако утверждение Уорда воз- лагает ответственность на нас . Он говорит, что при чтении красивого кода язык кажется созданным для решения конкретной задачи! Следовательно, мы сами должны позаботиться о том, чтобы язык казался простым! Языковые фанатики, задумайтесь! Не язык делает программы простыми . Программа выглядит простой благодаря работе программиста! 34 |