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

1. Вам это не пригодится (принцип YAGNI)

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

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

Берегите своё время. Этот код вам не пригодится! 

2. Избегайте преждевременной оптимизации

Как и в первом случае, заманчиво оптимизировать код как можно раньше. Вот риски: 

  • код станет менее понятен другим; 
  • вы потратите время на проблему, которая, вероятно, не существует. 

Давайте уточним эти два момента.

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

Вы усложняете код, а у сложности есть множество недостатков (смотрите пункт KISS).

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

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

3. Не заумничайте

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

Ниже прекрасный пример подобного кода. Сколько времени вам потребовалось, чтобы понять, что он делает? 

test = [1, 2, 3, 4, 2, 2, 3, 1, 4, 4, 4]
print(max(set(test), key = test.count))
# 4

Этот код станет намного понятнее, если разбить его на несколько строк с одним-двумя комментариями с пояснениями к аргументам функции max().

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

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

Как сказал Ван Россум:

“Поддерживаемый код важнее, чем умный код.”

4. Не повторяйтесь (принцип DRY)

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

Но если вам нужно прочитать другой файл и его содержимое, не пишите такой же код. Или ещё хуже — не копируйте! 

Вместо этого можно создать функцию, что дает два важных преимущества: 

  • меньшее количество кода проще поддерживать и отлаживать; 
  • маленькие функции легко тестировать (подробнее в разделе Модульное тестирование).
  • хорошо названная функция — это форма документации (подробнее в разделе Документируйте код).

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

5. Используйте модульное тестирование 

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

В наиболее экстремальной форме вы применяете практику, называемую разработка через тестирование (TDD). Применяя этот подход, вы сперва создаёте модульный тест, а потом реализуете функцию. 

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

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

Создание модульных тестов помогает вам:

  • Писать лучший код с меньшим количеством ошибок.
  • Адаптировать код с большей уверенностью на более позднем этапе. 
  • Заставляет создавать маленькие функции, которые выполняют одно действие. 
  • Документировать код, приводя полезные примеры. 

6. Сохраняйте простоту (принцип KISS)

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

Эдсгер Вибе Дейкстра, один из пионеров компьютерной науки, однажды сказал: “Простота является необходимым условием надёжности”. Чем проще ваше решение, тем труднее внедрение ошибки. Всё просто. 

“Простота является необходимым условием надёжности.”

7. Придерживайтесь фиксированного стиля кода

Придерживайтесь стиля, особенно, когда работаете в команде. Например, некоторые предпочитают подобное оформление:

while (true)
{
  // делает что-то
}

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

while (true) {
  // делает что-то
}

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

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

  • У Google есть руководства по стилю для множества языков.
  • Для Python есть PEP8. Множество IDE содержат плагин PEP8, проверяющих код при вводе. 
  • Для Java можно использовать такие инструменты, как Checkstyle, для определения стиля (или использовать один из доступных) и обеспечивать соблюдение стиля при компиляции. Некоторые IDE также помогают в этом после первоначальной настройки.

8. Документируйте код

Существует три способа документирования кода:

  1. Использование комментариев в коде.
  2. Написание документации в отдельном документе.
  3. Написание самодокументируемого кода.

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

Документация может быть очень полезной. Подумайте обо всех этих репозиториях на GitHub. Включать файл README.md в корневой каталог проекта фактически стало стандартом.

Этот файл описывает несколько важных вещей:

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

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

  • Используйте хороший дизайн, чтобы база кода была проста в ориентировании и логично структурирована.
  • Следуйте наработанным методам, таким как DRY (не повторяйтесь), YAGNI (вам это не пригодится) и KISS (не усложняйте).
  • Не пытайтесь сэкономить на символах. Используйте полные имена для переменных, классов и функций. Вместо wm, к примеру, используйте windowManager, вместо rf —  readFileToString. Эти имена очень помогут, когда кто-то другой — или вы сами — спустя несколько месяцев попытается понять, что происходит. 
  • Как можно больше кода выделяйте в функции, которые делают что-то одно. Давайте им подходящие имена. Например, создавая функцию, которая читает файл в строку, назовите её readFileToString(String fileName). Люди будут знать, что она делает, без детального знакомства с кодом. В идеале ваш код выглядит как последовательность вызовов функций, подобных этой, читающийся почти как человеческий язык. Только при необходимости читатель погружается глубже. Этот код документирует себя сам! 

9. Правильно просите о помощи

Профессионал просит о помощи только после тщательных попыток найти решение другими способами. Перед тем как задать вопрос:

  • Прочтите документацию — этот совет также известен как RTFM (“читайте чёртову документацию”).
  • Поищите ответ в сети, если документация не достаточно понятна или не решает вашу проблему. 

Если это не поможет, подумайте, куда обратиться за помощью:

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

И последнее, прежде чем задать вопрос, имейте в виду следующее:

  • Будьте вежливы и благодарны. Люди, которые отвечают на ваш вопрос и стараются вам помочь, чаще всего делают это бесплатно и тратят своё свободное время.
  • Будьте максимально подробны. Предоставляйте контекст: над чем вы работаете, зачем, что вы уже пытались делать.
  • Включайте сообщения об ошибках, лог файлы (или их часть) и код, вызывающий проблему. Не выкладывайте файлы полностью, включайте только необходимые фрагменты.

В общем, уважайте чужое время.

10. Рефакторинг

Рефакторинг — это реструктуризация кода без изменения его поведения.

И зачем же это делать? Чтобы улучшить код, конечно! Существует несколько фактов, делающих рефакторинг необходимым:

  • Программное обеспечение никогда не получается идеальным с первой попытки. Оно, безусловно, может работать, но будет беспорядочным, в нём будет дублирование.
  • Компьютерный код постоянно развивается. Даже если вы начали с идеальной базой кода, она быстро может стать запутанной.

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

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

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

Не превращайте ваш код в минное поле. 

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

Возможно вы видели подобный код прежде. Вроде тех, где при изменении одной строки всё становится непонятным.

11. Будьте профессионалом

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

Вы — профессионал. Мы — профессионалы. Мы работаем в сфере деятельности, пользующейся большим спросом. Не позволяйте никому и никогда унижать вас. В ИТ всё ещё существует незаслуженная стигматизация, поэтому позвольте чётко заявить:

  • Вы не гик.
  • Вы не ботаник.
  • Вы не “тот компьютерный парень или девушка”.

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

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

12. Продолжайте учиться

Профессиональный инженер-программист продолжает учиться на протяжении всей своей карьеры. В мире ИТ существует только одна константа, и эта константа — изменение.

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

Если вам понравилась эта статья, вот три книги, которые помогут вам стать лучшим разработчиком ПО. Эти книги стали настольными для многих (включая меня), и все они написаны Робертом С. Мартином:

Читайте также:

Перевод статьи Erik-Jan van Baaren: The 12 Habits of Highly Effective Software Developers

Предыдущая статьяВычислительные затраты на написание чистого кода
Следующая статьяРеализация base64 на Rust