1. Не писать код “на будущее”
Если код в данный момент не нужен, не стоит тратить время и силы на его написание. Вам может показаться, что он понадобиться в дальнейшем, поэтому желание создать его заранее будет очень сильным. Тем не менее, есть как минимум две проблемы, которые нужно взять во внимание:
- Возможно, он вам все-таки не пригодится. Но код продолжит существовать, потому что удалить его никто никогда не решится (ведь будет непонятно, что может перестать работать после удаления этого фрагмента).
- Код, который не используется, не обновляется. Из-за этого повышается риск возникновения новых уязвимостей и ошибок.
2. Не делать преждевременную оптимизацию
Оптимизировать код заранее – заманчивая идея, не так ли? А теперь подумайте о рисках:
- другим станет сложнее понять код;
- вы потратите силы и время на решение проблемы, которой, может быть, даже не существует.
Однажды вы поймете, что обычно скорость кода не играет важной роли. Циклы процессора стоят дешевле рабочих часов. Чтобы не усложнять себе жизнь и не делать дополнительных ошибок, просто увеличьте процессорную мощность, либо подождите немного дольше.
3. Не повторяться
Это распространенная ошибка начинающих разработчиков: часто повторять один и тот же или очень похожий фрагмент кода. Например, нужно открыть файл, а потом прочитать содержимое. Делается этого всего лишь несколькими строками.
Однако если вам понадобиться прочитать другой файл, не нужно писать аналогичный код, тем более копировать предыдущий!
Лучше создайте функцию и тогда получите 2 важных преимущества:
- поддержка и отладка облегчаются, когда кода меньше;
- чем меньше функции, тем проще их тестировать.
Ценный совет: есть IDE, которые находят дублирующий код и акцентируют на нем внимание разработчика, а иногда даже помогают создать из дубликатов методы и функции.
4. Не пытаться заумничать
Ясность намного лучше, чем вычурные технические уловки. Ваша задача – не красоваться, а сделать так, чтобы люди впоследствии читали ваш код без проблем. Позерство выставит вас в невыгодном свете, так что лучше демонстрируйте свои знания, например, в блоге.
Вот наглядный пример такого кода:
test = [1, 2, 3, 4, 2, 2, 3, 1, 4, 4, 4]
print(max(set(test), key = test.count))
# Как быстро вы поняли, что он делает?А ведь можно написать его гораздо понятнее, всего лишь разбив еще на пару строк и дополнив комментариями, поясняющими функцию max.
Всегда стремитесь писать максимально понятный код, чтобы другой программист через время мог легко разобраться с ним, когда понадобиться в срочном порядке исправить ваши недочеты.
5. Использовать модульное тестирование
Часто модульное тестирование упускают. Должен признаться, что я тоже так делаю. Но вообще не применять его – неправильно.
В самой экстремальной форме программист совершает процесс, называемый “разработка через тестирование” (TDD). В основе этого подхода лежит принцип: сначала сделать модульный тест, и только потом реализовать функцию.
В результате тестируя все создаваемые функции, разработчик тщательно обдумывает их действия и предполагаемый вывод.
Теме экстремального программирования посвящена прекрасная , ставшая бестселлером.
6. Чем проще – тем лучше
Данное правило полезно повсюду, а не только в разработке. Так что не усложняйте (тем более намеренно, см. правило 4), а ищите самое простое решение из всех возможных.
7. Придерживаться определенного стиля кода
Это очень важно во время командной работы.
К примеру, одним нравится такое оформление:
while(true)
{
// комментарий
}А другие пишут более лаконично:
while(true) {
// комментарий
}Каждый подход имеет свои преимущества и недостатки. Но главное – это четко придерживаться одного из них. Поэтому, работая в команде, кому-то чаще всего приходится использовать не привычный для себя стиль.
Когда будете выбирать лучшее решение для языка, с которым работаете, учитывайте все его инструменты, особенности и стандарты.
8. Документировать код
Есть 3 способа, как документировать код:
- Оставляя в нем комментарии.
- Создавая отдельный документ с документацией.
- Делая самодокументируемый код.
Что касается комментариев, советуем использовать их как можно реже, т.е. не нужно комментировать очевидное – оставляйте пояснения только в тех местах, где они на самом деле нужны.
Документация бывает очень полезной, так что задумайтесь о GitHub-репозиториях. Сейчас включение файла «README.md» в корневую директорию проекта стало почти стандартной практикой.
Но лучше писать самодокументированный код, хотя это сложнее всего и требует от разработчика большого опыта.
9. Просить о помощи грамотно
Настоящий профессионал не будет обращаться за помощью при возникновении малейшей трудности. Для начала он попытается найти решение самостоятельно.
Поэтому, прежде чем спросить, сделайте это:
- Изучите документацию.
- Если документация сложная для понимания или в ней нет нужных вам ответов, попытайтесь найти информацию в интернете.
Если решение все еще не найдено, подумайте, куда нужно обратиться:
- Система отслеживания ошибок работает только с ошибками, там не стоит задавать другие вопросы.
- Почтовая рассылка предназначена для программистов, которые разрабатывают проект, а не используют его.
- Часто для продуктов существует определенная страница с пояснительной информацией: как, о чем и где нужно задавать вопросы.
- Есть крупные группы в социальных сетях, в том числе Facebook, посвящённые разным языкам программирования, инструментам и технологиям, где можно получить ответы на много общих вопросов.
10. Рефакторинг
Это процесс перепроектирования кода, в котором его внешнее поведение остается прежним – меняется только внутренняя структура для облегчения понимания работы программы.
Вот несколько фактов, почему улучшать код нужно:
- Невозможно создать идеальное ПО с первой попытки. Конечно, оно может правильно работать, но код будет беспорядочным и полным дублирования.
- Программный код развивается, так что даже если в начале у вас была идеальная база, очень скоро она может оказаться запутанной.