1. Соблюдайте принципы YAGNI и KISS 👄
Принцип YAGNI («You aren't gonna need it»; с англ. – «Вам это не понадобится»): не пишите код, который, как вам кажется, может пригодиться в будущем, но сейчас в нём потребности нет. Вскоре он станет неактуальным и его придётся переписать под конкретную задачу.
YAGNI минимизирует объе\ём ненужной работы и тесно связан с принципом KISS («Keep it simple, stupid»; с англ. – «Не усложняй»): избегать добавления функций и повышения сложности кода до тех пор, пока это действительно не понадобится.
2. Сначала проектируйте API для простых запросов
Что касается API, сначала проектируйте интерфейс для простых запросов. По мере необходимости добавляйте дополнительные методы для более сложных вариантов использования.
Напишите руководство, которое поможет разработчику быстро приступить к работе. При изменении API позаботьтесь об обратной совместимости.
3. Меньше кода 🔪
Будьте лаконичны и удаляйте ненужные участки кода, делая программы настолько простыми, насколько это возможно.
4. Следуйте стандарту, а не объясняйте всё комментариями 💬
Следование стандарту программирования упрощает обнаружение проблем, поддержку программного обеспечения, снижает риски сбоя и уязвимость к атакам.
Не злоупотребляйте комментариями. При активной разработке комментарии становятся неактуальны, поэтому изначально пишите читабельный код по стандарту вашего языка программирования, чтобы обходиться без них. Комментарии должны отвечать на вопрос «Почему», а не «Что».
Сначала пишите правильный, соответствующий стандартам код, потом оптимизируйте скорость выполнения.
5. Принцип DRY 🏜️
DRY («Don't Repeat Yourself»; с англ. – «Не повторяйся») – принцип разработки программного обеспечения, нацеленный на уменьшение сложности кода и снижения повторения информации. Сторонники принципа DRY стремятся обеспечить существование только одного способа выполнения кода, объединяя экземпляры повторящегося кода в единый блок, что окупается в долгосрочной перспективе, т. к. ускоряет время разработки.
DRY важнее в тестируемом коде, чем в тестах, потому что последние выполняются и читаются отдельно, а не как часть большой системы.
6. Пользуйтесь готовыми решениями 🚲
Используйте встроенные структуры и типы данных, пишите свои только по необходимости. Ведь за готовыми решениями стоят годы отладки и оптимизации.
7. Сначала пишите тесты 📝
Юнит-тест проверяет поведение кода, а не его реализацию. Относитесь к своим тестовым объектам как к «чёрным ящикам», тестируемым через публичный API.
Предварительное написание тестов побуждает использовать небольшие единицы кода, что в большинстве случаев приводит к написанию более чистого кода.
Тесты должны быть написаны так, чтобы их можно было использовать, как документацию.
8. О скорости юнит-тестов
Небольшие юнит-тесты дают в случае неудачи более ценную информацию – они явным образом указывают что именно не так. Как правило, тест, на который уходит больше 0.1 с, юнит-тестом не является.
9. Рефакторинг
Проводите рефакторинг, когда это возможно. Каждое преобразование должно улучшать структуру программы, не изменяя её поведения. Потенциальные преимущества рефакторинга заключаются в повышении читаемости кода и понижении его сложности. Это повысит удобство при сопровождении кода и создаст более простую, чистую и выразительную архитектуру.
10. Проверяйте тесты
Сделайте преднамеренную ошибку и убедитесь, что тест работает. В противном случае вы не знаете, что действительно тестируете. Нерабочие тесты уменьшают пользу вашего набора тестов, до такой степени, что, в конце концов, все игнорируют их результаты. Исправляйте или удаляйте такие тесты.
Итак, мы вспомнили о таких принципах программирования как YAGNI, KISS и DRY. Также узнали, какой юнит-тест считается медленным и как нужно проводить рефакторинг.
Вот ещё пара материалов по теме публикации:
Комментарии