https://medium.com/@george.seif94/these-5-clean-code-tips-will-dramatically-improve-your-productivity-b20c152783b оригинал статьи автор George Seif

Эти 5 советов по "чистому коду" значительно улучшат вашу продуктивность.

Качественный код. Много людей говорит об этом, но немного делают это действительно правильно.

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

Причина ошибок понятна во многих случаях. Это может быть сложно прогнозируемо, как люди будут интерпретировать ваш код, будет ли им легко его читать или же наоборот это будет настоящим для них кошмаром. А также дело в том, что однажды ваш проект разрастётся до таких размеров, что даже Вам будет сложно его прочитать!

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

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

Если это не протестировано, оно сломано.

Тестировать, тестировать, тестировать. Мы знаем, что должны всегда это делать, но иногда мы сокращаем путь, чтобы сдать проект быстрее. Но без глубокого тестирования, как Вы можете быть 100% уверены, что Ваш код работает ? Да, есть очень простые части кода , но какая-то всегда застаёт врасплох, когда наступают эти сумасшедшие граничные условия, которые Вы думали не надо тестировать! Сделайте одолжение себе и каждому в своей команде и регулярно проверяйте код, который Вы пишите. Вам захочется протестировать в "грубо-точном" алгоритме. Начните с малого, с модульных тестов, чтобы убедиться , что каждая маленькая часть работает самостоятельно. Потом медленно начните тестировать различные подсистемы, продвигаясь к end-to-end тестированию всей новой системы. Тестирование таким путём позволяет Вам легко проследить, где система сломалась, затем Вы сможете легко проверить каждый отдельный компонент или маленькую подсистему как источник проблемы.

Выбирайте значимые имена

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

Классы и функции должны быть маленькими и подчиняться Принципу единственной ответственности (SRP)

Маленькие классы и функции делают код примерно в 9832741892374 раза легче читаемым.....

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

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

Исключения в коде, обычно, являются граничными условиями или ошибками, которые нам хотелось бы обработать своим собственным специфическим способом. К примеру, обычно при возникновении ошибки программа будет останавливаться. Это определенно не будет работать для кода,который мы развернули для производства, обслуживающего пользователей! Нам захочется отдельно обработать эту ошибку, возможно попытаемся посмотреть является ли она супер критичной или же нужно просто её пропустить и не обращать внимания. Потом Вы можете назвать каждую из тех функций , ссылаясь на то, что они делают и вуаля, код, который сможет прочитать обычный человек! SRP даёт Вам такие же преимущества. Одна из обязанностей означает, что Вам нужно только проверять несколько крайних случаев, и эти случаи довольно легко отлаживать. Кроме того, довольно легко назвать функцию так, чтобы она имела реальное значение. Поскольку она имеет одну единственную цель, она будет названа просто в честь её цели, это лучше, чем назвать функцию, которая пытается выполнить так много разных задач. Вы всегда должны особенно улавливать и обрабатывать исключения, даже если Вы думаете, что это не нужно. Лучше быть в безопасности, чем сожалеть. Обработка исключений даст Вам лучшее ощущение порядка и контроля над вашим кодом, поскольку Вы точно знаете, что произойдёт, если случится какое-либо исключение или сбой части кода. Более глубокое понимание вашего кода, такое как это, облегчает отладку и делает ваш код более отказоустойчивым.

Регистрируй, регистрируй, регистрируй.

Зарегистрируй это. Что Вы можете спросить?..... Всё, что есть! Нет никакой вещи, как слишком много логов! Логи- это ваш абсолютный источник #1 для отладки вашего кода и мониторинга вашего приложения, когда оно находится в производстве. Вы должны регистрировать каждый важный "шаг", который делает ваша программа, любые важные вычисления, которые она делает, любые ошибки, исключения или что из обычных результатов. Также может быть полезно регистрировать дату и время , в которые эти события происходят для лёгкого отслеживания. Всё это позволит легко проследить, какой именно шаг в работе программы завершился неудачей. Многие распространенные языки программирования, такие как Python, выходят со своими собственными библиотеками ведения журналов, в которых есть очень полезные функции , которыми Вы сможете воспользоваться. Если ваше приложение будет запущено в качестве приложения SaaS, то Вам может захотеться рассмотреть бездевайсовое, централизованное ведение журналов. Таким образом , если один из ваших серверов ломается , Вы легко можете восстановить журналы!

Экспозе

1 Если это не протестировано, значит оно сломано.

2 Выбирайте значимые имена

3 Классы и функции должны быть маленькими и подчиняться Принципу единственной ответственности (SRP)

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

5 Регистрируй, регистрируй, регистрируй.

https://medium.com/@george.seif94/these-5-clean-code-tips-will-dramatically-improve-your-productivity-b20c152783b 

Оригинал статьи

Автор George Seif