/ клин коʊд /

О Боже! Сейчас он говорит об очистке своих кодов! Какой безумец!

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

Чистый код

без грязи, следов или пятен.

инструкции программы.

В буквальном смысле слова «Чистый код» будет означать «Программные инструкции, на которых нет грязи, следов или пятен». Хотя в каком-то смысле он точен, нам все же нужно объяснить, что делает его «свободным от грязи, следов или пятен».

У разных людей разные стандарты. Я мог бы сделать свои коды настолько чистыми и элегантными, насколько это возможно, но если я не буду следовать какому-то руководству, я никогда не получу одобрения некоторых людей, и мои коды никогда не будут по-настоящему «чистыми». К счастью, многие интеллектуалы объединились и поговорили о том, что считается «чистым кодом». Хотя они по-прежнему делятся своими взглядами на это, широкая публика приняла это как нечто «чистое».

Что такое чистый код?

Как сказал Бьерн Страуструп, изобретатель C++:

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

Как и ожидалось от мастера словесности. Г-н Страуструп уделяет особое внимание элегантности и эффективности. Хотя Грэди Буч, автор книги Объектно-ориентированный анализ и проектирование с помощью приложений, придерживается следующего мнения о чистом коде:

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

И, наконец, «Большой» Дэйв Томас, основатель OTI, крестный отец стратегии Eclipse, сказал:

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

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

  1. Элегантно: должно быть приятно читать. Чтение этого должно заставить вас улыбаться от уха до уха, так же, как вы улыбаетесь, когда видите своего особенного человека, или так же, как если бы вы нашли ту особенную вещь, которую искали.
  2. Читаемость. Чистый код должен читаться как хорошо написанная проза. Каждая функция, каждый класс, каждый модуль раскрывает целеустремленность, которая остается полностью неотвлеченной и незагрязненной окружающими деталями.
  3. Просто: выполните одно действие в соответствии с принципом единой ответственности (принцип компьютерного программирования, который гласит, что каждый модуль, класс или функция должны нести ответственность за одну часть функций, предоставляемых программным обеспечением, и эта ответственность должны быть полностью инкапсулированы классом, модулем или функцией). Все просто и упорядоченно, уделено должное внимание деталям.
  4. Тестируемый: запустить все тесты. Это должно быть полностью протестировано.

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

Что можно и чего нельзя делать

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

Делать: значимые имена

Когда мы только начинали программировать, можно было, например, использовать имена "int d" или "String s", так как мы тогда только учились, мы работали над нашими собственными небольшими проектами, а не над более крупными, где мы сотрудничаем с разными людьми. И я здесь, чтобы показать вам, почему такие имена не работают! Рассмотрим следующее:

int d; // d = amount of rewinds

Можем ли мы без комментариев понять, что означает «д»?? Нет, нет, мы бы не стали (если только мы не разработчик, написавший это). Теперь рассмотрим следующее:

String message;

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

Нельзя: Ментальная карта

Читатели не должны мысленно переводить ваши имена в другие имена, которые они уже знают. Эта проблема обычно возникает из-за выбора не использовать ни термины предметной области, ни термины предметной области решения. Одно различие между умным программистом и профессиональным программистом заключается в том, что профессионал понимает, что ясность важнее. Профессионалы используют свои способности во благо и пишут код, понятный другим. Позволь мне показать тебе что-то :

# bad
a = get_apple()
o = get_orange()
s = make_smoothie(a, o)

Хотя это описательные (get_apple(), make_smoothie(a, o)) эти два относятся к реальным функциям. Термины «а», «о» и «с» слишком ужасны для кодов. Кажется, что скорость просто заменяет читабельность, а это плохо для кода. Поскольку плохая читаемость означает худшую скорость, если мы не успеваем быстро. А теперь предлагаю другое:

# good
apple = get_apple()
orange = get_orange()
smoothie = make_smoothie()

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

Делать: одно дело

Следование принципу единой ответственности (SRP):

Функции должны делать одну вещь. Они должны делать это хорошо. Это должны делать только они.

Что это значит? Это буквально означает то, что означает: функции должны делать только одну вещь, и делать это громко и ясно. Вы же не ожидаете, что фен заморозит ваши волосы, не так ли? Или кукла вашего ребенка, чтобы платить налоги? Каждая функция имеет свою индивидуальную функцию, поэтому они должны выполнять ее хорошо.

Например:

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

// single responsibility principle - bad example

interface IEmail {
	public void setSender(String sender);
	public void setReceiver(String receiver);
	public void setContent(String content);
}

class Email implements IEmail {
	public void setSender(String sender) {// set sender; }
	public void setReceiver(String receiver) {// set receiver; }
	public void setContent(String content) {// set content; }
}

Мы можем создать новый интерфейс и класс с именем IContent и Content, чтобы разделить обязанности. Имея только одну ответственность за каждый класс, мы получаем более гибкий дизайн.

// single responsibility principle - good example
interface IEmail {
	public void setSender(String sender);
	public void setReceiver(String receiver);
	public void setContent(IContent content);
}

interface Content {
	public String getAsString(); // used for serialization
}

class Email implements IEmail {
	public void setSender(String sender) {// set sender; }
	public void setReceiver(String receiver) {// set receiver; }
	public void setContent(IContent content) {// set content; }
}

Нельзя: повторять себя

Ах, СУХОЙ. Нет, не держать одежду СУХОЙ или тому подобное. СУХОЙ — это аббревиатура, СУХОЙ: не повторяйся. Дублирование — это проблема программного обеспечения. Многие принципы и лучшие практики были созданы для уменьшения дублирования кода. Как уже было сказано, повторение нехорошо, не говоря уже о дублировании. Вот почему DRY — это хорошая концепция, которой стоит придерживаться при реализации чистого кода.

Каждая часть знаний должна иметь единственное, недвусмысленное, авторитетное представление в системе.

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

Принципы

Хотя мы многое рассмотрели, на самом деле есть кое-что, что я забыл упомянуть, а именно Принципы чистого кода. Хотя Принципы созданы группой разработчиков с их собственными взглядами, используемые Принципы получили широкое признание ИТ-сообщества, поэтому они остаются верными до сих пор. На самом деле, я уже говорил об одном из принципов, а именно о СУХОМ (не повторяйся). Остальные принципы следующие:

KISS: Будь проще, глупец. Принцип конструкции, зародившийся в ВМС США еще в 1960 году. В нем говорится, что большинство систем должны быть максимально простыми (но не проще, как сказал бы Эйнштейн). Следует избегать ненужной сложности. Вопрос, который следует задать, когда вы пишете код: «Можно ли это написать проще?»

СУХОЙ: не повторяйтесь. На самом деле я немного объяснил о DRY выше. Он тесно связан с KISS и философией минималистского дизайна. Нарушения DRY называются WET: нам нравится печатать, писать все дважды, тратить время всех.

YAGNI: вам это не понадобится. Разработчик не должен добавлять функциональность, если не считает это необходимым. YAGNI является частью методологии экстремального программирования (XP), целью которой является улучшение качества программного обеспечения и увеличение скорости реагирования на требования клиентов. YAGNI следует использовать в сочетании с непрерывным рефакторингом, модульным тестированием и интеграцией.

Composition Over Inheritance: к сожалению, это не аббревиатура. Это принцип, согласно которому вы проектируете свои типы исходя из того, что они делают, а не из того, чем они являются. Многие разработчики отдают предпочтение композиции, а не наследованию, потому что наследование вынуждает вас создавать таксономию объектов на ранней стадии проекта, что делает ваш код негибким для последующих изменений.

Предпочтите удобочитаемость. Дело не в том, что машина может прочитать ваш код так, как это может сделать другой человек. В частности, при работе над проектом с несколькими людьми всегда отдавайте предпочтение удобочитаемости, а не краткости. Нет смысла иметь краткий код, если люди его не понимают.

Вывод

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

Адеус~