Вы когда-нибудь писали фрагмент кода или отправляли запрос на слияние на GitHub, и в ответ вы получаете комментарий в строках вашего «код чистый»?

Вы когда-нибудь задумывались, что это на самом деле означает?

Здесь я собираюсь перечислить несколько рекомендаций по тому, что делает код «чистым».

Чистый код - это не грязь

Когда что-то грязное, значит, это нечисто. Простой! Верно?

Так что это влечет за собой, можно спросить?

Излишние комментарии

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

#Комментарии! или // Комментарии или / * Комментарии * /

Практически все существующие языки программирования дают вам возможность добавлять «комментарии» к вашему коду, чтобы вы могли «комментировать» свой код. Это может действовать как форма документации (или помогать определенным формальным документам) либо для других разработчиков, либо для вас самих, так что позже, когда вы вернетесь, чтобы прочитать код (ваш собственный код?), Вы могли легко его понять (или, по крайней мере, комментарий поможет вам понять код, если вы не понимаете код из самого кода).

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

Но видели ли вы подобные комментарии?

/**
 * Puts an item into the basket
 * 
 * If there is already the same item in basket then increment the 
 * quantity number
 * 
 * @param item to put in basket
 */
public void putItemInBasket(BasketItem newItem){

Вам не нужны эти «ненужные комментарии».

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

Другими словами, ваш код должен быть «самодокументированным».

Конечно, документация метода объясняет логику для данного метода, но в идеале вы должны иметь возможность вывести логику, просто прочитав код внутри метода.

Самодокументирующийся код

Так что ваш код должен быть «самодокументированным». Что это значит?

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

Неиспользованный код

Вы когда-нибудь сталкивались с кодом в своей кодовой базе, который не нужен или больше не нужен, потому что функция была списана. Именно так, если он не требуется, то его нет в вашей кодовой базе. Убери это. Его удаление позволяет избежать раздутия вашей кодовой базы ненужным кодом, который может сильно отвлекать других разработчиков.

Легко понять имена

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

Конструкции кода я имею в виду переменные, поля, методы, функции, подпрограммы, классы, интерфейсы и т. Д.

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

Например,

private int x;

В Java вы знаете, что переменная x относится к целочисленному типу (т. Е. Представляет собой «целое число» или число, выражаясь непрофессиональным языком). Однако x совсем не описательный. Помимо того, что вы знаете, какой это тип значения, знаете ли вы, что оно представляет?

Может быть, это возраст? Или это число чего-то…? Если да, то что это тогда?

Может быть, это было бы более подходящее имя переменной?

private int age;

Это, конечно, относится и ко всем остальным конструкциям кода, которые я перечислил выше.

Например, по возможности предпочитайте следующее имя метода или функции.

public void calculateDiscount() {
  // code omitted
}

Это очень важно.

Избегайте длинных методов

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

Один из способов добиться этого - разбить ваши длинные методы на более мелкие методы / функции и т. Д. Имейте «вспомогательные» методы, которые помогут вашему логическому рабочему процессу.

Иногда длинные методы означают, что метод делает слишком много. Разбить его на более мелкие разделы, посвященные одному делу, может быть лучшим способом продвижения вперед. Это пример реализации принципа разработки принципа единой ответственности (SRP) на практике. Я вернусь к этому принципу позже.

Скажи нет классу бога

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

Стремитесь к высокой сплоченности. Низкая сплоченность - это плохо, так как это означает, что ваши классы делают слишком много, что опять же нарушает другой принцип разработки программного обеспечения - Принцип единой ответственности (SRP). Это похоже на использование очень длинного метода, о котором говорилось выше. Длинные методы также могут быть известны как методы Бога.

Принцип единой ответственности (SRP) является ключевым

Я уже упоминал этот принцип несколько раз, так в чем именно заключается этот принцип?

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

Хранение вашего кода в сухом состоянии

DRY в разработке программного обеспечения - это аббревиатура от «Don’t Repeat Yourself».

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

Чтобы применить принципы DRY, разработчики обычно используют передовые методы программирования разработки программного обеспечения, такие как абстракция, модуляризация в своем коде для удаления повторяющегося кода. Этого особенно легко добиться, если вы придерживаетесь объектно-ориентированной парадигмы.

Однако, как правило, я лично не применяю DRY во всех местах. В моем коде приложения я разрешаю себе повторить код только один раз. Как мне кажется, только потому, что это повторяется, когда это не гарантирует, что его «абстрагируют», например, в отдельный метод / функцию или даже отдельный класс. Излишняя сложность, связанная с методами абстракции, на самом деле не стоит усилий, если вы повторяете свой код один раз.

Однако, если я нахожу повторяющийся код в нескольких местах (например, более трех) или чувствую, что есть преимущество в наличии чего-то вроде «вспомогательного» метода или функции для абстракции, тогда я бы сразу применил принцип DRY.

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

Следуйте передовым методам разработки программного обеспечения

Что может пойти не так, если следовать лучшим практикам, верно?

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

Здесь я собираюсь упомянуть несколько общих передовых практик, которым я стараюсь следовать, когда пишу код и когда хочу, чтобы мой код был «чистым».

ТВЕРДЫЙ

SOLID - это еще один акроним разработки программного обеспечения, обозначающий:

  • Принцип единой ответственности
  • Принцип открыт-закрыт
  • Лисков Принцип подстановки
  • Принцип разделения интерфейса
  • Принцип инверсии зависимостей

Я уже коснулся одного из принципов SOLID. SRP i, упомянутый выше, является первым из принципов SOLID, в котором он представляет собой букву «S».

К сожалению, я не буду подробно объяснять каждый из этих принципов SOLID, поэтому вместо этого я отсылаю вас к этой статье вики для получения дополнительной информации:

Https://en.wikipedia.org/wiki/SOLID

Я всегда чувствую, что применение принципов SOLID позволяет мне иметь хороший структурный код. Хороший структурный код, особенно в объектно-ориентированном программировании, означает, что ваш код очень легко читать и понимать.

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

GRASP

GRASP еще есть! еще один акроним разработки программного обеспечения, где он означает:

«Шаблоны (или принципы) программного обеспечения для распределения общей ответственности»

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

Опять же, я отсылаю вас к этим статьям вики для получения дополнительной информации:

Https://en.wikipedia.org/wiki/GRASP_(object-oriated_design)

Код спагетти - нет-нет

Код спагетти ужасен.

Период.

Я уверен, что вы встречали кодовую базу с кодом, который содержит много-много разветвлений и условных операторов.

Например, наличие множества if-else-if-else операторов, встроенных в несколько конструкций условных циклов, таких как for циклы или даже более традиционные while циклы.

Что ж, это именно то, что представляет собой спагетти-код. Логика - сплошной клубок спагетти. Это полный беспорядок в коде. По моему личному мнению, это рецепт катастрофы!

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

Избегайте позолоты

Еще одна вещь, о которой следует помнить, стремясь к «чистому коду», - это определенно избегать «золотого покрытия».

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

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

Пожалуйста, объясните, что вы скажете.

Причина просто в том, что бизнес-требования в настоящее время постоянно меняются. То, что является требованием в настоящее время, может вообще перестать быть требованием в не столь ясном будущем.

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

Кроме того, я бы определенно сказал, что не пытайтесь предугадывать требования, которые могут возникнуть. Конечно, для разработчика интерес к бизнес-требованиям - это, безусловно, хорошо, но в конечном итоге ответственность за определение и уточнение требований лежит на бизнес-аналитике (BA) или Product Owner (PO) / Product Manager (PM).

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

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

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

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

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

Практика TDD

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

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

Я действительно люблю «ПОЦЕЛУЙ» ...

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

Это аббревиатура от «Keep It Simple, Stupid».

Мой совет, как следовать этому общему принципу проектирования, на самом деле очень прост.

Между прочим, это не каламбур.

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

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

Применение правила бойскаутов

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

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

Помогает себе и помогает другим разработчикам.

Так что же для меня значит «Чистый код»?

В конце концов, «чистый код» может быть очень субъективной вещью.

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

Для других разработчиков «Чистый код» может означать, что код выглядит красиво и аккуратно. Это может сильно зависеть от языка программирования, на котором вы кодируете, хотя, как известно, некоторые языки программирования более подробны, чем другие (например, Java), тогда как другие кажутся гладкими (например, Python, Groovy или даже Kotlin), но просто, все это просто покрыто синтаксическим сахаром.

Для меня, в конечном счете, «Чистый код» - это просто код, который:

  • Хорошо структурированный
  • Легко читать и понимать (и интерпретировать)
  • Ярмарка мертвый простой

Резюме

Это почти все мои личные рекомендации, которым я стараюсь следовать, когда пишу код, чтобы убедиться, что мой код «чистый».

Напоминаю мои личные и хорошо известные рекомендации:

  • Без лишних комментариев
  • Самодокументирующийся код
  • Описательное кодирование (понятное именование, избегайте длинных методов и т. Д.)
  • Используйте передовые методы кодирования, такие как DRY
  • Рассмотрите другие передовые методы разработки программного обеспечения (SOLID, GRASP)
  • Сказать нет спагетти-коду
  • Избегайте позолоты
  • Простота с KISS
  • Убедитесь, что присутствует только необходимый код (при необходимости обратитесь за помощью к TDD)