Одна из замечательных особенностей Чистого кода заключается в том, что по мере продвижения по книге рассматриваемые концепции становятся более абстрактными. На мой взгляд, эта практика отражает то, как человек становится лучше в искусстве программирования. Когда вы начинаете читать Чистый код, вы охватываете такие понятия, как хорошие имена для переменных или функций и оптимальное количество строк для класса. Однако по мере того, как вы читаете, дядя Боб и компания подробно рассказывают о том, как вы можете отойти от кода и убедиться, что он хорошо спроектирован, чтобы один из ваших коллег мог зайти в вашу программу в любой день и легко понять, что вы намерены это сделать.

Таким же образом, изучив синтаксис и базовые функции языка или фреймворка, вы сможете подняться на уровень абстракции со своим кодом, сосредоточившись на общем дизайне и удобстве сопровождения ваших программ. Здесь я имею в виду эмерджентный дизайн - концепцию гибкой разработки программного обеспечения, которая побуждает разработчиков сосредоточиться на создании функциональности приложения и позволить со временем проявиться общему дизайну этой системы. В этом блоге я рассмотрю общие правила Чистого кода (в порядке важности) для облегчения разработки на стадии разработки, а также то, как вы можете создавать надежные программы, которые будут более удобочитаемыми и удобными в обслуживании.

Правило 1. Запустите все тесты.

Хотя мы говорили о тестировании раньше, стоит повторить. Чтобы не усложнять этот урок, я повторю самую часто цитируемую фразу, которую мне говорят мои наставники в сфере разработки программного обеспечения: Непроверенный код - это сломанный код. Как сказано в Clean Code, непроверенная программа - это непроверяемая программа; то есть, вы не можете проверить, последовательно ли ваш код выполняет то, что вы хотели. И если вы не можете проверить, что делает система, вы также можете не развертывать ее.

Хотя я могу показаться скверным, приоритезация тестов по существу вынуждает писать более чистый код. Например, если вся ваша логика программы существует в одном файле, ее будет чрезвычайно сложно протестировать. Чтобы написать тесты для этой логики, вам нужно будет разбить ваши функции на отдельные файлы, более строго придерживаясь SRP по умолчанию и в конечном итоге уменьшая размер ваших программ. Кроме того, эта практика хорошо подходит для ослабления сцепления и высокой сплоченности. Так что, если вы больше ничего не почерпнули из этого сообщения в блоге, почерпните следующее: НАПИШИТЕ СВОИ ТЕСТЫ.

Правило 2: Рефакторинг

Мы уже затронули тему рефакторинга и раньше, но, как и тестирование, это настолько важная тема, что мы должны обсудить ее более подробно. Проще говоря, рефакторинг нашего кода необходим для хорошего дизайна. На самом деле, правило рефакторинга следует за правилом о тестах по очень веской причине: если у нас есть хорошие тесты, мы можем быть уверены, что наша программа выполняет то, что мы намереваемся делать, , даже если мы изменим ее . Как пишет Джефф Лангр в Чистый код:

Тот факт, что у нас есть эти тесты, избавляет от опасений, что очистка кода сломает его!

Хотя это может быть пугающим предложением, невероятно важно постепенно реорганизовывать наш код. Еще раз взглянув на нашу логику, мы даем себе возможность применить передовой опыт программирования, выбрать лучшие имена, разбить нашу логику на модули и т. Д. Благодаря тестированию и рефакторингу на переднем крае эмерджентного дизайна мы можем точно настроить наш код с помощью последних трех правила.

Правило 3: без дублирования

На этом этапе вы, вероятно, видите, что я суммирую многие свои предыдущие сообщения в блоге в этой статье. Но несмотря на то, что есть еще главы для чтения и предстоящие публикации в блоге от меня о Чистом коде, эта глава служит хорошей инкапсуляцией книги, суммируя многие из наиболее важных моментов, когда вы хотите написать связную часть программного обеспечения.

Дублирующий код привносит излишнюю сложность в вашу систему и, вместе с этой сложностью, увеличивает вероятность отказа ваших программ. Устранение этого дублирования делает ваш код более пригодным для повторного использования. Хотя существует множество методов для сохранения D.R.Y. вашего кода, Clean Code специально упоминает Template Method из невероятно влиятельных Design Patterns как способ уменьшить эту сложность.

Правило 4: выразительность

Мы все были там, пытались расшифровать нечеткий код, кропотливо просматривая каждую строчку в поисках закономерностей. Часто мы сами программисты, которые в первую очередь написали этот непонятный код, что еще больше усугубляет путаницу. Как сообщает Чистый код, «большая часть затрат на программный проект связана с долгосрочным обслуживанием». Поэтому очень важно, чтобы мы писали программное обеспечение, которое будет понятно всем в нашей команде.

С помощью кода существует много способов хорошо выразить себя. Хорошие имена помогают нам писать выразительный код, так же как и небольшие функции и разделение задач. Кроме того, модульные тесты служат еще одним способом сделать наш код выразительным. Когда мы запускаем наши тесты, мы лучше понимаем, что намеревается делать наш код.

Правило 5: Минимизируйте классы и методы

Хотя правила 3 ​​и 4 важно соблюдать, мы не хотели бы заходить слишком далеко и создавать тысячи классов и / или файлов для выполнения нашей задачи. Сохраняя небольшие классы и методы, мы можем сделать их слишком много, что в конечном итоге увеличит сложность нашего кода и замедлит нашу работу. По правде говоря, написание чистого кода - это баланс; пытаясь достичь своей цели, вы постоянно будете спрашивать себя, не слишком ли велик этот метод? У меня слишком много занятий? Эти тесты хрупкие?

Откровенно говоря, эта неопределенность заложена в природе программирования. На большинство проблем программирования не существует однозначного и быстрого «правильного ответа». Программирование - это творческое упражнение, которое никогда не бывает доведено до совершенства, но, пытаясь быть совершенным, мы с каждым днем ​​становимся немного лучше. По мере того, как ваши навыки улучшаются, идея о том, что не существует «идеального кода», превращается из ужасающей в в конечном итоге освобождающей. Пытаясь написать чистый код, вы станете лучше как программист, вы будете подталкивать своих коллег к совершенствованию и будете создавать удивительные вещи. Какая работа может быть лучше этой?

В конце этой главы Лангр упоминает, что, хотя эти правила важно соблюдать, никакие рекомендации не могут превзойти знания, полученные с опытом. Тем не менее, следуя этим принципам, программисты всех уровней повышают вероятность написания чистого кода и, тем самым, создания элегантного программного обеспечения.

Удачного кодирования!