Главная

6 привычек высокоэффективных программистов

Первая часть статьи об оптимизации рабочего процесса.

 

29+

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

❶ Еще не время

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

Первая: не факт, что этот код вам понадобится в будущем, однако, написав функцию, вы захламляете проект неиспользуемым кодом, который потом все боятся удалить, ибо “а если что-то сломается?”.
Вторая: неиспользуемый код не обновляется. Это может привести к ошибкам и уязвимостям в безопасности. Это очень важно и с этим шутить нельзя!

Не тратьте время впустую! Еще не время…

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

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

  • Код будет менее понятен для других.
  • Вы потратите время на решение проблемы, которой, скорее всего, не существует.

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

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

❸ Не надо умничать

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

Я поместил прекрасный пример этого в другую мою статью. Ниже приведен код трюка №19 из этой статьи. Можете ли вы сразу сказать, что делает этот кусок кода? Сколько времени нужно, чтобы понять принцип работы данного кода?

Этот код будет более понятен, если разбить его на несколько строк с комментариями, которые объясняют аргументы функции max().Ваш код должен быть настолько простым для понимания, насколько это возможно. Ваш код должен быть таким, чтобы через год любой программист мог сходу понять его и быстренько там что-то подправить. Да, кстати, этим любым программистом можете оказаться вы. Гвидо Ван Россум во время своего пребывания в Dropbox сказал:

«Поддерживаемый код важнее, чем заумный код».

Гвидо Ван Россум

❹ Не повторяйтесь! (DRY — Don`t Repeat Yorself)

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

  1. Код легче поддерживать и отлаживать.
  2. Небольшие функции легко проверить (см. Unit Testing).

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

❺ Unit тесты

Модульное тестирование часто игнорируется . Я также склонен к этому. Зачастую я создаю юнит-тесты уже по факту или вообще не создаю. В любом случае юнит тесты по факту уже лучше, чем ничего. Есть одна хорошая практика, которая называется разработка через тестирование (TDD — Test-Driven Development). Согласно TDD вы сначала создаете модульный тест, а затем реализуете саму функцию.

Такой подход заставляет тестировать каждую созданную функцию и тщательно обдумывать, что должна делать эта функция и каков ее ожидаемый результат. Хорошая книга на эту тему — «Test Driven Development: By Example».
Еще одним преимуществом создания модульных тестов является то, что вы или другие разработчики можете чувствовать себя более уверенно при внесении изменений в код. При любом изменении проекта вы просто можете запустить юнит тесты. Если все отработало нормально, то скорее всего, внесенные изменения не сломают проект.

  1. Преимущества юнит тестов:
  2. Меньше ошибок в коде.
  3. При адаптации кода вы чувствуете себя более уверенно.
  4. Принуждают к созданию небольших функций, которые реализуют четко определенный функционал.
  5. Документируют ваш код, приводя примеры использования.

❻ Придерживайтесь простоты (KISS — Keep It Simple Stupid)

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

«Простота является предпосылкой надежности».

29+