чистый код или совершенный код
Чистый код: причины и следствия
Автор: Виктор Свирский, Senior Python Developer / Team Lead, DataArt
Сколько программистов, столько и определений, что такое чистый код. Часто, проводя собеседование, я слышу, что хороший код — это такой, который легко читается. Согласен, но как подсказывает мой личный опыт, это только вершина айсберга.
Первый звоночек, который нам сообщает, что код перестает быть чистым — это рост времени разработки новой функциональности и увеличение регрессионного скоупа при малейшем изменении в системе. Это следствие того, что технический долг накапливается, компоненты в системе очень тесно связаны, автотесты отсутствуют. Причины этого могут быть:
Что такое чистый код?
Получается, чтобы сказать, что код чистый и система спроектирована грамотно, легкого чтения кода недостаточно. Он должен обладать и другими качествами:
Стоит ли писать чистый код?
Однозначно стоит! Но не всегда и не везде стоит уделять чистоте слишком много внимания.
Не стоит забывать о целесообразности и сроке жизни вашего кода. Например, если перед вами стоит задача разработки концепции — PoC (Proof of concept), и вы доказываете, что выбранный стек технологий выполняет поставленную задачу, ваш код станет неактуален уже через неделю или две. Не стоит тратить силы на совершенствование этого функционала.
Бытует мнение, что не нужно следить за качеством кода или части системы, которые в скором времени будут заменены. И это неверно по нескольким причинам. Высокое качество исполнения сделает переход или интеграцию с новыми частями более простыми, бесшовными и быстрыми. Оно наверняка упростит жизнь в тех случаях, когда несколько версий кода придется поддерживать одновременно. Количество регрессионных ошибок с чистым кодом будет в разы меньше. Также не стоит забывать, что нет ничего более постоянного, чем временное. Возможно, задачи по улучшению этой части кода еще несколько месяцев будут лежать в бэклоге.
Что поможет улучшить ваш код?
Большинство программистов мечтают писать код быстро и максимально красиво, причем так, чтобы все идеально работало с первого раза. Но далеко не каждому удается сделать код не просто работающим, но и понятным. Как же добиться успеха в написании чистого кода? Есть два пути — самоорганизация и командная работа.
Самоорганизация
Рассмотрим несколько возможных способов улучшить индивидуальное качество кода. Эти рекомендации подойдут разработчику любого уровня.
Не спешите решать задачи в лоб. Задавайте вопросы старшим разработчикам и самому себе. Всегда важно понимать причинно-следственную связь тех или иных решений. Хорошо понимая проблему, вы сможете эффективно ее решить.
Любой опыт лучше, чем его отсутствие.
Командная работа
Большинство задач решается в команде. Очень важно разделять ответственность за качество между ее участниками. Чем больше команда, тем сложнее поддерживать продукт в хорошем состоянии. Рассмотрим несколько подходов удержания кода в вышеуказанных условиях.
Во время проверки кода необходимо учитывать несколько вещей:
Суть непрерывной интеграции в том, что она позволяет быстро получить множество отзывов о текущем состоянии кода.
Непрерывная интеграция работает, когда вы следуете двум простым правилам:
Важно иметь список соглашений о кодировании. Но прежде чем вы начнете составлять список, все в команде должны понимать значимость этого соглашения. Не рассчитывайте, что такое соглашение будет принято с первого раза, вас ожидает множество дискуссий.
Составьте список соглашений о кодировании, в которых вы обозначаете то, как переменные должны объявляться, соглашения об именах и т. д. Количество правил, которые вы можете добавить в этот список, не ограничено и может варьироваться. Просто делайте то, что работает для вас и вашей команды. Не стесняйтесь добавлять новые правила в список соглашений, если команде это подходит. Это же касается и удаления соглашений из списка.
После того, как вы получили свой список соглашений о кодировании, крайне важно придерживаться их. Наиболее предпочтительный способ — проверить соглашения о кодировании с помощью статических анализаторов и непрерывной интеграции, поскольку он не требует каких-либо ручных действий.
Чем меньше ошибок в коде, тем выше его качество. Тщательное тестирование отфильтровывает критические ошибки и гарантирует, что код работает так, как задумано.
Наличие четкой стратегии тестирования важно, когда дело доходит до улучшения качества кода. Как минимум, ваш код должен быть модульным. Еще лучше, если вы хотите использовать и другие способы, например интеграционное или регрессионное тестирование.
Наличие ошибок в вашем коде, вероятно, неизбежно. Поэтому анализ и способ обработки этих ошибок очень важны. Если вы хотите улучшить свои навыки, важно учиться на собственных ошибках.
Когда возникает ошибка, проанализируйте ее с помощью нескольких вопросов:
Есть несколько метрик, которые вы можете использовать для количественной оценки качества вашего кода. С такой задачей легко справляется SonarQube. Он с легкостью поможет вам собрать все необходимо важные метрики:
Используется при тестировании программного обеспечения. Она показывает процент исходного кода программы, который был выполнен в процессе тестирования. Задайте планку, ниже которой процентное соотношение ваших тестов не опускается.
Ошибки в коде чем-то сродни углеродному следу. Избежать совсем невозможно, а лишний выхлоп сам по себе не убьет ни человечества, ни окружающей его природы. Тем не менее, снизить негативный эффект от своего пребывания на планете сегодня кажется естественной потребностью. Примерно так же и написание чистого кода оказывается ответственностью каждого разработчика. Независимо от того, какой именно путь вы выберете, необходимо стремиться писать работающий и понятный код.
Хорошо, если удастся не превращать чистоту в фетиш, учитывая срок жизни нашего кода и оценивая целесообразность дальнейших улучшений. Главное помнить о людях: пользователях, которых может подвести внезапный отказ даже небольшой части разработанной нами системы, и инженерах, которым предстоит эту систему поддерживать.
Что такое «чистый код» в 2020-м?
«Чистый код» и чистый кот
Разработчиков хлебом не корми, дай поспорить о чистоте кода: например, недавно шумиху навёл пост Дэна Абрамова «Goodbye, Clean Code».
Но при этом у самого понятия «чистый код» нет чёткого определения. Главная книга по этому вопросу — «Clean Code», где Роберт «Дядюшка Боб» Мартин сразу заявляет: «сколько программистов, столько и определений». Впрочем, из этого он делает не вывод «говорить об этом бесполезно», а вывод «стоит сравнить разные определения». Поэтому в книге он привёл мнения нескольких выдающихся программистов о том, что такое чистый код.
Нам стало интересно: в 2020-м представления человечества о чистом коде остались теми же, или с выхода книги как-то изменились? Различаются ли мнения у разных айтишников: может, бэкендеры видят всё с одного ракурса, а тестировщики с другого?
А поскольку тема холиварная, наверняка кто-то из вас окажется не согласен с какими-то из мнений. В таком случае айда спорить в комментариях, это тоже весело!
UPD: Когда мы писали эту статью, Роберт планировал приехать на наши конференции. К сожалению, ситуация изменилась. Также из-за запрета на проведение массовых мероприятий мы перенесли конференции на другие даты. Следите за обновлениями на сайте конференции. 13 марта мы обновили этот пост, чтобы он не содержал некорректную информацию.
DotNext
Джон Скит
Джон — легенда Stack Overflow, автор книги «C# in Depth» и один из самых известных дотнетчиков планеты. Он дал нам такое определение:
«Для меня чистый код — это скучный код, с точки зрения имплементации. Единственный сюрприз в нём — это то, насколько он лишён сюрпризов. Я должен чувствовать „Да, я бы мог такое написать”, даже если бы на самом деле я и не мог — по тому, насколько хорошо он спроектирован.
Когда абстракция выбрана верно, имплементация выводится естественным образом. В идеале эта абстракция также должна ощущаться простой и очевидной — хотя на самом деле доведение её до такого состояния могло занять часы, недели, месяцы размышления и экспериментов.
Упомянутое отсутствие сюрпризов позже переносится и на использование: когда я пишу код, используя хорошо спроектированный API, мой код тоже становится очевидным и скучным».
Андрей Акиньшин
Когда мы спросили, что он думает про чистый код, Андрей сослался на два своих старых хабрапоста: «Совершенный код и реальные проекты» и «Комментировать или не комментировать». И мы выбрали для вас пару абзацев оттуда, с которыми кто-то наверняка захочет поспорить:
«Я люблю совершенный код. Ведь это не только правильный подход к написанию программ, но и настоящее искусство. От чтения хорошего листинга я получаю не меньше удовольствия, чем от чтения хорошей книги. Проектировать архитектуру большого проекта ничуть не легче, чем проектировать архитектуру большого здания, а в случае хорошей работы — результат не менее прекрасен. Порой меня завораживает то, как изящно переплелись паттерны проектирования в создании совершенной программной системы. Меня восхищает внимание к деталям, когда абсолютно каждый метод настолько прост и понятен, что претендует на место классического примера совершенного кода.
Но, увы, всё это великолепие разбивается о суровую действительность и реальные проекты. Если мы говорим о продакшн-проекте, то пользователей не волнует, насколько красив ваш код и насколько хороша архитектура, их волнует, чтобы проект хорошо работал. Но я всё равно считаю, что в любом случае нужно стремиться писать правильно, просто при этом фанатизма быть не должно».
Дилан Битти
Хабрачитатели могут помнить Дилана по его вдумчивому и яркому докладу про работу с легаси-кодом: для Хабра мы делали его расшифровку. И когда мы обратились к Дилану по поводу чистого кода, он написал такой развёрнутый и продуманный текст, что его хоть отдельным постом публикуй:
«Для меня интересно, что понятие «чистый код» распространилось далеко за пределы круга людей, читавших книгу Роберта Мартина. Я общался с многими, многими разработчиками, которые слышали слова «clean code», но не читали книгу. Я даже встречал их в кодревью: «Тут всё довольно хорошо, но можешь немного почистить?» — и такая просьба может быть раздражающе неточной, если неочевидно, что «чистый» означает в данном конкретном контексте.
В английском есть слова, которые часто встречаются вместе — «clean», «tidy», «organised», «neat» — и для меня как носителя английского они все означают немного разные вещи. Я думаю, что полезно рассмотреть некоторые коннотации этих слов применительно к разработке софта.
Представим, например, кухню ресторана. У слова «clean» в этом контексте будут очень конкретные коннотации. Всё вымыто, стерилизовано, нет никакой угрозы заражения из-за сырых продуктов, и тому подобное.
Но это не означает автоматически, что здесь всё хорошо организовано. Если вы когда-нибудь пытались приготовить еду у друга или в квартире, снятой на Airbnb, вы знаете, как раздражает, когда вещи не на своих местах. Средство для мытья посуды стоит в буфете, в котором рассчитываешь увидеть кастрюли, а чеснокодавилка вообще непонятно где. Да, всё чистое — нет угрозы, что кто-то отравится едой, приготовленной на этой кухне — но работать в таких условиях раздражает.
А теперь представим деревообрабатывающий цех. В этом месте грязь тоже может вызывать проблемы, но здесь у вас совсем не такое определение «чистоты», как на кухне. Вы можете начищать зубило, пока оно не начнёт сверкать, но вы всё равно вряд ли стали бы резать им сосиски. Так что слово «clean» может быть очень субъективным.
Но для меня слова вроде «tidy» и «organised» работают и таких контекстах, где «clean» не очень хорошо подходит. «Organised» означает, что кто-то как следует подумал, как расположить элементы конкретного рабочего места, а «tidy» означает, что эти элементы действительно находятся на отведённых им местах. Как говорится в старой поговорке, «всему есть своё место и всё на своём месте».
Возможно, в случае с кодом нам стоит думать о словах «clean», «tidy» и «organised» как о трёх разных понятиях. «Clean» означает, что вы смотрите на составные части кодовой базы — методы, функции, интерфейсы — и не видите никаких причин для беспокойства. В именовании придерживаются конвенций; названия переменных и методов написаны без ошибок; в деталях вроде отступов и скобок придерживаются единого стиля; куда ни посмотри, видишь подтверждения того, что на базовом уровне этим заправляют люди, подходящие к делу серьёзно. Это противоположность «грязного кода» — такого, где в названиях куча опечаток, фигурные скобки и отступы захотичны, несоответствующие названия файлов. Это те вещи, которые магически оказываются исправлены, когда вызываешь инструмент «code cleanup» в чём-то вроде ReSharper.
«Organised» — это про архитектуру. Это о том, что можно нырнуть в незнакомую кодовую базу и найти вещи там, где ожидаешь их увидеть. Интерфейсы и доменные границы помогают, а не мешают; методы и переменные названы не просто корректно названы с точки зрения языка, но и отражают единый язык бизнеса, с которым работаешь.
А «tidy» — это про уважение локальных конвенций… кодовая база, в которой можешь найти нужные вещи в соответствующих им местах, даже если конкретная организационная модель вам в этот момент не слишком понятна.
Я думаю, что когда говорят о борьбе за «чистый код», этим обычно подразумевают все три эти вещи. Но ставить целью полностью «чистый код», особенно когда работаешь со сложным легаси-проектом, может быть довольно устрашающей перспективой. Возможно, нам всем было бы полезно задуматься немного глубже и разобраться, что именно из составляющих «чистого кода» по-настоящему принесёт пользу проекту, над которым мы в данный момент работаем».
Heisenbug
Это «конференция по тестированию не только для тестировщиков»: она на стыке тестирования и разработки. Поэтому многие её спикеры понимают специфику обоих этих миров сразу.
Иван Крутов и Анна Чернышева
Иван и Анна работают в разных компаниях, но кое-что их объединяет: оба много знают про Selenium. Мы общались с ними одновременно, так что получилось совместное определение:
Иван: «Для меня самое простое определение чистого кода — это код, который понятен без комментариев, «самодокументирующийся». Код, который завален комментариями, которые пытаются объяснить, что он делает — это не чистый код».
Анна: «У меня похоже: это код, в котором можно быстро разобраться, исправить баг, легко расширить его, дополнить».
Иван: «Ещё можно сказать, что это «код, за который не стыдно». Вообще говорят, что если ты смотришь код, который написал полгода назад, и не ужасаешься, то ты не развиваешься. Получается, что с каждым годом твой код должен становиться всё чище».
Себастиан Дашнер
Себастиан — Lead Java Developer Advocate в IBM, и его часто можно увидеть на Java-конференциях. Но поскольку сейчас он прилетает на Heisenbug, мы спросили его о чистом коде именно в контексте тестирования, и он ответил:
«По моему опыту, качество кода важно не только в случае продакшн-кода, но и для наших тестов. В тестах чистым кодом, правильными абстракциями и делегацией часто пренебрегают, что приводит к такому коду тестов, который не поддержишь. Когда мы рефакторим продакшн-код и меняем его поведение, становится видно, хорошую работу ли мы проделали над моделированием и имплементацией наших тестов».
Андрей Лушников
Андрей работает над инструментом для браузерной автоматизации Playwright, о котором мы недавно писали. Его определение оказалось самым лаконичным:
«Чистый код — это тупой, очень понятный код. И чем тупее, тем лучше».
Александра Сватикова
Александра — эксперт по информационной безопасности в Одноклассниках, которая «начинала в IT как Java-разработчик, но свернула не туда». Её определение оказалось таким:
«Чистый код обладает тремя свойствами: другой разработчик может легко прочесть и понять его, незначительные доработки требуют соразмерных усилий, и эффект от конкретного изменения может быть предсказан.
На деле это означает, что код структурирован, лаконичен, следует общепринятым практикам для того языка на котором написан, не содержит неявных зависимостей или побочных эффектов и покрыт тестами».
HolyJS
Андрей Мелихов
Андрей известен многим по проекту «Девшахта». Неудивительно, что человек, постоянно формулирующий свои мысли в «Девшахта-подкасте», и свою позицию сформулировал чётко:
«Роберт «Дядя» Мартин тремя своими главными книгами («Clean Code», «The Clean Coder» и «Clean Architecture»), как мне кажется, пытается для себя ответить на вопросы: кто, что и как должен писать. Можно поспорить о корректности некоторых его выводов, но вот что, неоспоримо — эти книги построены на богатом личном опыте и здравом смысле. И в рамках этой идеи я могу сказать, что для меня чистый код — это код, который написал бы человек, споткнувшийся о немалое количество подводных камней в своей жизни и в этом болезненном процессе научившийся идти осторожной походкой, позволяющей этих камней избегать.
Вам может быть неудобен стиль этого человека, но если вы будете ему следовать, вы точно останетесь целы. Вы можете взять этот стиль и переработать его, сделать удобным для себя. Или вы можете отчаянно нырнуть в реку набивать собственные шишки, вырабатывать свой собственный стиль, пока остальные будут смотреть на вас с недоумением, двигаясь под присмотром старших товарищей.
Чистый код — это код, который легко читается, легко поддерживается и легко расширяется. Именно эти три аспекта закладывают прочный фундамент под приложениями, которым предстоит жить годами в условиях изменчивости внешних требований. А именно такие приложения мы пишем в крупных компаниях»
Александра Калинина
Александра состоит в программном комитете HolyJS, у неё большой опыт в программировании — и, хотя она не с Heisenbug, с тестами она тоже знакома не понаслышке (unit, integration, E2E, B2B). Вот её текст:
«Clean code — сейчас это простое понятие, но понять его довольно трудно. Мне кажется, что чистый код может получиться при соблюдении следующих правил:
— каждый отдельный кусочек кода должен иметь возможность масштабироваться или расти/улучшаться независимо от других кусочков, но при этом сохранять изначальную идею/интеграцию с другими кусочками (в этом очень помогает SOLID, а также правило «все решения, которые могут быть приняты позже, должны приниматься позже»).
— код должен читаться как увлекательная книга, с понятными типичными названиями и обозначениями. К примеру, если вы задумаете писать рассказ, то у него, вероятнее всего будет типичная структура вроде вступления, завязки, кульминации и развязки. Даже если только вы один работаете на проекте, код должен читаться легко вами же спустя любое время, независимо от выбранной архитектуры, языка, фреймворков.
— код должен иметь понятную структуру. Т.е. должна быть понятна причина, по которой тот или иной кусочек кода находится в проекте.
— каждая строчка кода должна быть обоснована с точки зрения бизнеса»
Nicolò Ribaudo
Николо, будучи ещё студентом, стал одним из ключевых разработчиков компилятора Babel (об этом мы его уже расспрашивали отдельно). Его вариант оказался таким:
«Чистый код — это код, который можно легко разделить на маленькие атомарные составляющие.
«Атом кода» — это наименьший возможный набор инструкций, обладающий самостоятельным смыслом, не зависящие излишне от окружающего контекста: имена переменных и операций достаточно описательные, чтобы читающему их не требовалось выделять в голове дополнительную память для хранения их значений и возможных модификаций, а также не требовалось смотреть ещё куда-то в коде, чтобы понять, что означает результат этого «атома». Чем меньше атомы, тем проще понять, что делает код.
Код может быть чистым вне зависимости от языка программирования или парадигмы: атомы можно реализовать как маленькие объекты, функции, или даже как маленькие фрагменты кода, не изолированные синтаксически».
Заключение
Наконец, когда мнения были собраны, мы показали их самому Дядюшке Бобу и спросили, хочется ли ему что-то сказать. Ответ оказался таким:
«Я полностью поддерживаю комментаторов выше. Я бы добавил только одну вещь, которую когда-то сказал Майкл Фезерс: “Чистый код всегда выглядит так, будто его писал человек, которому не всё равно”».
Его заключение звучит очень дружелюбно. Но чистый код — такая дискуссионная тема, что пока кто-то из вас согласно кивает, кто-то другой наверняка горит, ощущая что-то такое:
Эти книги должен прочитать каждый, кто считает себя программистом!
Содержание статьи
Польза не во многих, но в хороших книгах.
Сенека
Все мы прекрасно понимаем: чтобы стать профессиональным программистом, необходимо читать специализированную техническую литературу. Но на сегодняшний день доступно огромное количество различных изданий по программированию. Целой жизни не хватит, чтобы одолеть и половину из них. Какие же книги нужно читать в первую очередь? Без каких книг нельзя обойтись? В этой статье мы расскажем о тех трудах великих авторов, с которыми должен быть знаком каждый профессиональный разработчик.
С. Макконнелл «Совершенный код»
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.
Сложно найти гуру программирования, который не читал «Совершенный код» Стива Макконнелла. Действительно, одна книга, хоть и немаленькая (чуть менее 900 страниц), покрывает практически все аспекты разработки ПО: от рецептов написания высококачественного кода, механизмов тестирования и отладки до стратегий оптимизации кода и психологических факторов, влияющих на разработку. Представь себе: библиография книги занимает 20 страниц и содержит более 500 источников! Книга «Совершенный код» — одно из самых полезных и, как следствие, популярных изданий по разработке ПО. Она неоднократно доказала это, возглавляя рейтинги книг по программированию (goo.gl/3q0kx). Благодаря простой манере изложения, особому стилю и чувству юмора Стива книга читается очень легко.
Говоря о проектировании и конструировании программных систем, Макконнелл выделает Главный Технический Императив Разработки ПО — управление сложностью. Простота и ясность исходного кода и архитектуры системы определяют ее качество. Большая часть книги посвящена написанию высококачественного кода. Макконнелл, как никто другой осознавая значимость мелочей, детально описывает все правила, которыми необходимо руководствоваться при написании хорошего кода. Необходимый уровень абстракции, разработка качественных интерфейсов классов и пакетов, написание высококачественных методов, выбор удачных имен переменных, упрощение управляющих структур, комментирование кода — ничто не ускользает от внимания автора. Например, общим принципам использования переменных отведен целый раздел книги более чем на 100 страниц. Только вопросу выбора имен переменных посвящена целая глава на 30 страниц. При этом все правила и советы даются исключительно с практической точки зрения.
В части, в которой говорится о качестве ПО в целом, Макконнелл формулирует Главный Закон Качества ПО: повышение качества системы снижает расходы на ее разработку. Причина ясна — большую часть времени программисты занимаются чтением и отладкой написанного кода, тогда как на собственно написание уходит около 10% рабочего времени. Поэтому поддержание качества кода системы на высоком уровне экономит много времени и тем самым повышает КПД программиста.
Автор не обходит вниманием и различные методики разработки. Подробно описывается парное программирование, ревизии кода, формальные и неформальные инспекции, разработка на основе тестирования. «Рефакторинг» — единственная глава книги, которую можно назвать «слабоватой». При рассмотрении методов рефакторинга приводится лишь длинный список его видов из книги М. Фаулера «Рефакторинг». При этом нет ни одного конкретного примера кода. Раздел носит скорее ознакомительный характер.
Говоря о повышении производительности ПО, автор приводит убедительные доводы против преждевременной оптимизации, когда программист в процессе разработки интуитивно распознает «узкие» места в программе и незамедлительно принимает меры по оптимизации в ущерб качеству кода. Приводимая статистика показывает, что в 9 из 10 своих предположений программист ошибается.
Подвести итоги можно словами Джона Роббинса: «Это просто самая лучшая книга по конструированию ПО из всех, что когда-либо попадались мне в руки. Каждый разработчик должен иметь ее и перечитывать от корки до корки каждый год. Я ежегодно перечитываю ее на протяжении вот уже девяти лет и все еще узнаю много нового!»
М. Фаулер «Рефакторинг»
Написать код, понятный компьютеру, может каждый, но только хорошие программисты пишут код, понятный людям.
М. Фаулер
Практически любое издание о рефакторинге ссылается на книгу Мартина Фаулера «Рефакторинг». Действительно, в этой книге Фаулер сделал невозможное — в предельно понятной форме донес до читателей почти полностью исчерпывающее описание понятия «рефакторинг», его назначение, особенности и методы реализации.
При немалом объеме (400 страниц) книга читается буквально за пару вечеров, от нее просто невозможно оторваться. Главная причина головокружительного успеха книги — ее практическая направленность. Все мы знаем, что самая сложная задача при подаче материала — привести хороший показательный пример. В этом Фаулеру нет равных. Книга начинается с примера улучшения программы, который сразу с головой затягивает читателя в мир рефакторинга. Всего 40 страниц примера дают нам вполне конкретное представление о рефакторинге, его целях, принципах и основных методах реализации. Мартин определяет рефакторинг как «изменение во внутренней структуре ПО, имеющее целью облегчить понимание его работы и упростить модификацию, не затрагивая наблюдаемого поведения». Но когда необходимо проводить данное изменение? Какой код должен подвергаться переработке? Автор дает исчерпывающие ответы на эти вопросы. Он вводит правило «трех ударов»: «После трех ударов начинайте рефакторинг». То есть когда вы делаете что-то аналогичное в третий раз, это сигнал для начала рефакторинга. Раздел «Код с душком» дает нам четкое представление о том, какой же код требует улучшения. К признакам такого кода относятся: длинный метод, большой класс, длинный список параметров метода, дублирование кода, операторы типа switch, временные поля, отказ от наследства, неуместная близость классов и многое другое.
Фаулер, как сторонник TDD (Test-driven development), посвящает главу книги созданию автоматических тестов и описанию среды JUnit. Если обнаружена ошибка, сначала необходимо написать автоматический тест, выявляющий ее, и лишь затем проводить исправление. Это позволит в будущем не наступать на одни и те же грабли. Аналогично перед проведением рефакторинга следует написать тест для улучшаемого кода, чтобы обеспечить неизменность его поведения.
Бо́льшую часть книги занимает каталог методов рефакторинга. Он содержит разделы, посвященные составлению методов, перемещению функций между объектами, организации данных, упрощению условных выражений и вызовов методов, решению задач обобщения и крупным архитектурным рефакторингам. Многие из методов рефакторинга автоматизированы в популярных IDE. Например, Visual Studio предоставляет возможности по автоматическому выделению метода (ExtractMethod), удалению параметра (RemoveParameter), выделению интерфейса (ExtractInterface) и пр. В качестве крупных рефакторингов уровня системы Фаулер приводит следующие: разделение иерархии наследования, выполняющей более одной задачи, преобразование процедурного подхода к проектированию в объектно-ориентированный подход, отделение предметной области от уровня представления, а также выделение иерархии, подразумевающее разбиение большого класса на целую иерархию значительно меньших по размеру и более специализированных подклассов.
Прочитав эту книгу, большинство программистов изменяет свой подход к написанию кода. Они становятся более грамотными, аккуратными и внимательными к своему творению. Книга обязательна к прочтению для всех программистов, стремящихся к совершенству в своем ремесле.
Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес «Паттерны проектирования»
Проектирование объектно-ориентированных программ — нелегкое дело, а если их нужно использовать повторно, то все становится еще сложнее.
Э. Гамма
Спросите у опытного разработчика, какую книгу по объектно-ориентированному программированию вам обязательно стоит прочитать. В абсолютном большинстве случаев он посоветует именно эту. В отношении данной книги слово «бестселлер» звучит недостаточно выразительно, ведь с момента ее выпуска было продано уже более полумиллиона экземпляров на английском и тринадцати других языках!
Очень часто начинающий разработчик самостоятельно берется за решение уже более тысячи раз решенной до него задачи проектирования и изобретает очередную разновидность пятиколесного велосипеда, истинно гордясь своим «новшеством». Владение языком паттернов позволяет решить множество задач проектирования наиболее оптимальным способом, затрачивая при этом минимум усилий. Всего двадцать описанных в книге паттернов предоставляют инструментарий для решения огромного спектра задач проектирования ПО. Материал книги довольно сложен и требует от читателя определенных знаний в области объектно-ориентированного проектировании. Для освоения паттернов недостаточно просто прочитать книгу, необходимо основательно над ней «попотеть». Впрочем, твои усилия не пройдут даром. Книга содержит 350 страниц и состоит из двух частей. В первой части дается общее понятие паттернов проектирования, описывается их практическое применение на примере создания визуального редактора документов Lexi. Вторая часть книги содержит каталог паттернов с подробным описанием назначения, структуры, особенностей реализации и примерами применения каждого паттерна.
Коллектив авторов известен как Gang of Four («Банда четырех»), поэтому представленные в книге паттерны называют GoF. Авторы разбивают все множество представленных паттернов на три группы: порождающие паттерны, структурные паттерны и паттерны поведения. Порождающие паттерны решают задачу инстанцирования (создание экземпляров) классов. К самым популярным паттернам в данной группе можно отнести AbstractFactory (абстрактная фабрика), FactoryMethod (фабричный метод) и Singleton (одиночка).
Структурные паттерны предназначены для решения вопросов компоновки системы на основе классов и объектов. К ним относятся такие важнейшие паттерны, как Adapter (адаптер), Bridge (мост), Composite (компоновщик), Proxy (заместитель) и Façade (фасад). Паттерны поведения связаны с алгоритмами и вопросами распределения обязанностей между классами. Здесь необходимо упомянуть Strategy (стратегия), TemplateMethod (шаблонный метод), Observer (наблюдатель), Command (команда) и Iterator (итератор).
Единственное, что может смутить читателя, — некоторые примеры в книге написаны на малоизвестном на сегодняшний день языке программирования Smalltalk, а для изображения диаграмм классов вместо привычного UML используется OMT (Object Modeling Technique).
Р. Мартин «Чистый код»
Умение писать код — тяжелая работа. Она не ограничивается знанием паттернов и принципов. Над кодом необходимо попотеть.
Р. Мартин
«Чистый код» — одна из наиболее удачных книг, посвященных написанию высококачественного кода. Размер книги — 360 страниц, не считая приложений. При этом она настолько увлекательна и доступна, что за два-три вечера запросто прочитаешь ее от корки до корки. В дружеской манере «дядюшка» Боб рассказывает нам, какими же принципами нужно руководствоваться, чтобы писать хороший код. Книга изобилует примерами из реальных приложений, с которыми автор сталкивался в своей практике. Среди них такие известные продукты, как JUnit, FitNesse, JDepend, Ant и TomCat.
Книга разделена на три части. Первая часть — теория написания «чистого» кода: приемы, паттерны и принципы, которым необходимо следовать разработчику. Вторая часть носит практический характер и подробно описывает сам процесс «чистки» кода существующих приложений. Третья часть подводит итоги всей книги и содержит перечень «запахов кода» и методов их устранения.
В теоретической части подробно описываются принципы именования переменных, методов и классов, правила создания функций, написания комментариев, форматирования кода, принципы обработки ошибок и написания модульных тестов. Целый раздел посвящен особенностям создания многопоточных приложений. Роберт дает понять, что хорошо написать код недостаточно.
Необходимо поддерживать его чистоту с течением времени, чтобы предотвратить «загнивание». Поэтому он вводит «правило бойскаута»: «Оставь место стоянки чище, чем оно было до твоего прихода». То есть с каким бы участком кода мы ни работали, нужно пытаться в итоге сделать его качественнее, чем он был. В таком случае, код не будет загнивать и останется чистым.
При создании функций во главу угла ставятся компактность, правило одной операции и одного уровня абстракции — очевидные на первый взгляд принципы, которые так часто нарушаются программистами. Будучи ярым адептом TDD, Мартин указывает на важность «чистоты» не только кода конечного продукта, но и кода модульных тестов. Он иронически замечает: «Какими отличительными признаками характеризуется чистый тест? Тремя: удобочитаемостью, удобочитаемостью и удобочитаемостью».
Пожалуй, единственный недостаток книги — это ее Java-ориентированность. Все представленные примеры написаны исключительно на языке Java. При этом большое количество советов и «запахов кода» характерны в основном для Java-кода.
В начале книги Роберт приводит ответы мэтров программирования на вопрос, что же такое «чистый код». Грэди Буч отвечает: «Чистый код прост и прямолинеен. Чистый код читается, как хорошо написанная проза. Чистый код никогда не затемняет намерения проектировщика; он полон четких абстракций и простых линий передачи управления». Программисты, которые стремятся писать «чистый код», просто обязаны прочитать эту книгу.
Д. Кнут «Искусство программирования»
Лучший способ в чем-то разобраться до конца — это попробовать научить этому компьютер.
Д. Кнут
Программист, у которого нет книги «Искусство программирования», как священнослужитель, у которого нет Библии. Монографию Дональда Кнута часто называют «Библией программиста». Она содержит подробное описание и анализ важнейших фундаментальных алгоритмов, используемых в информатике, а также множество практических задач для усвоения и закрепления представленного материала. Журнал American Scientist включил работу Кнута в список двенадцати лучших физико-математических монографий XX века наряду с работой Эйнштейна по теории относительности. Успех книги определило качество изложения и глубина анализа общих вопросов программирования.
Кнут начал работу над «Искусством программирования» еще в 1962 году. По замыслу автора монография должна состоять из семи томов. Пока было издано три первых тома, а также первая половина четвертого. Все изданные на сегодняшний день материалы составляют почти 3000 страниц. Читать книгу совсем не просто (как, впрочем, и Библию), главным образом потому, что все примеры рассматриваются на низкоуровневом языке программирования — ассемблере для гипотетического выдуманного автором компьютера MIX. Поэтому у программиста вряд ли получится использовать книгу в качестве набора готовых рецептов для решения конкретных задач. Эта книга дает программисту не рыбу, а скорее хорошую удочку, с помощью которой он сможет не без определенных усилий самостоятельно наловить рыбы.
Первый том посвящен основным алгоритмам и состоит из двух глав. Первая глава подготавливает читателя к работе над книгой. Здесь рассматриваются основные математические понятия и теоремы, на которых базируется весь материал. Читатель знакомится с «полиненасыщенным компьютером» MIX, его архитектурой и его языком ассемблера. Вторая глава посвящена информационным структурам и алгоритмам работы с ними. Здесь рассматриваются деревья, многосвязные структуры, линейные списки, в том числе стеки, очереди, деки, циклические и дважды связанные списки и прочее.
Второй том включает в себя третью и четвертую главы. Третья глава посвящена работе со случайными числами и последовательностями. В четвертой главе описываются вопросы арифметики, а именно различные виды систем счисления, арифметика чисел с плавающей точкой и рациональных чисел, полиномиальная арифметика и другое. Третий том посвящен алгоритмам сортировки и поиска (соответственно, главы 5 и 6). Из четвертого тома опубликованы материалы седьмой главы, описывающей вопросы комбинаторного поиска.
Исходя из планов автора, в четвертый том также войдет восьмая глава, в которой рассматриваются рекурсивные алгоритмы. Пятый том будет содержать материалы по синтаксическим алгоритмам, в том числе по лексикографическому и синтаксическому поиску. Ожидающие издания шестой и седьмой тома будут посвящены теории языков и компиляторам.
В своем отзыве о работе Кнута Билл Гейтс сказал: «Если вы считаете себя действительно хорошим программистом… прочитайте „Искусство программирования“ (Кнута)… Если вы сможете прочесть весь этот труд, то вам определенно следует отправить мне резюме». Цитата лишний раз подчеркивает, что, несмотря на сложность материала, настоящий профессионал обязательно должен осилить труд Дональда Эрвина Кнута «Искусство программирования».
Э. Хант, Д. Томас «Программист-прагматик»
Программисты-прагматики не уклоняются от ответственности. Вместо этого они испытывают радость, принимая вызовы и распространяя свой опыт.
Эндрю Хант
Книга «Программист-прагматик» полностью оправдывает свое название. Викисловарь говорит, что прагматик — это тот, «кто ставит практическую полезность, выгоду выше всего». Программисты-прагматики ориентируются в первую очередь на практическую успешность реализуемых проектов. Авторы на основании своего богатейшего опыта программирования создали структурированный набор практических советов для программистов. Небольшой размер книги (270 страниц) говорит о высокой концентрации важной для программиста информации.
Практически все излагаемые в книге темы поясняются выразительными аналогиями, которые порой поражают своей точностью. В книге проводятся параллели между некачественным кодом и теорией разбитого окна, столярным делом и работой программиста, вождением автомобиля и написанием кода, стрельбой трассирующими пулями и созданием прототипов ПО, хождением по минному полю и программированием в расчете на стечение обстоятельств. В конце каждого раздела приводятся вопросы для обсуждения и упражнения, что лишний раз подчеркивает практическую направленность книги.
Одним из самых замечательных принципов программирования, которым мы обязаны авторам, является принцип DRY (Don’t Repeat Yourself), что в переводе на русский означает: «Не повторяй самого себя». Это значит, что каждый фрагмент знания должен иметь единственное и однозначное представление в системе. Следование данному принципу позволяет повысить надежность, доступность и простоту сопровождения программного продукта.
В главе, посвященной общей философии прагматичного программирования, мы узнаем, каким авторы видят программиста-прагматика: он всегда принимает ответственность за свой код, следит за состоянием своего продукта, постоянно совершенствуется, общается и находит компромисс с пользователями. Глава «Прагматический подход» говорит об общих методиках разработки и оценки трудоемкости проектов. Важнейшая глава «Гибкость против хрупкости» рассказывает, каким же образом необходимо создавать действительно гибкие и устойчивые к изменению системы. Из главы «Перед тем, как начать проект» можно узнать о процедуре формирования и утверждения требований к системе. «Прагматические проекты» знакомят нас с критическими аспектами создания реальных проектов, такими как работа в команде, тестирование и формирование документации.
Единственное, что может подпортить впечатление о книге, так это недостаточно качественный перевод на русский язык и наличие множества опечаток. Книгу лучше всего читать в оригинале на английском языке. Нельзя не согласиться с отзывом Кента Бека: «Главное в этой книге то, что она поддерживает процесс создания программ в хорошей форме. [Книга] способствует вашему постоянному росту и явно написана людьми, знающими толк в программировании». Если вы стремитесь к постоянному росту как программист, эта книга обязательна к прочтению.
Заключение
Значение хороших книг по программированию сложно переоценить. Каждая из описанных книг позволяет совершить огромный скачок в развитии. «Искусство программирования» закладывает прочный фундамент, обучая нас фундаментальным алгоритмам и приемам программирования. «Совершенный код» позволяет выйти на новый качественный уровень конструирования ПО. «Чистый код» и «Рефакторинг» учат нас внимательнее относиться к качеству кода и поддерживать его в идеальном состоянии. «Программист-прагматик» подсказывает, как же реально добиться практического успеха при разработке ПО. «Паттерны проектирования» вооружают тяжелой артиллерией паттернов для решения множества задач проектирования.