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

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

Вам это не понадобится (YAGNI)

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

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

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

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

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

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

Давайте разберемся с этим подробнее.

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

Вы усложняете, а усложнение имеет много недостатков (см. Также: KISS).

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

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

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

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

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

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

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

Гвидо Ван Россум во время своего пребывания в Dropbox сказал:

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

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

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

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

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

Код легче поддерживать и отлаживать.
Небольшие функции легко проверить (см. Unit Testing).
Также качественно названная функция — это некая форма документации (см. Документирование вашего кода).

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

Unit тесты

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

Есть одна хорошая практика, которая называется разработка через тестирование (TDD — test-driven development). Согласно с TDD вы сначала создаете модульный тест, а затем реализуете саму функцию.
Такой подход заставляет тестировать каждую созданную функцию и тщательно обдумывать, что должна делать эта функция и каков ее ожидаемый результат.

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

Преимущества юнит тестов:

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

Придерживайтесь простоты (KISS — keep it simple, stupid)

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

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

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

Придерживайтесь определенного стиля

Стиль кода — это важно. Особенно при работе в командах. Например, некоторые люди предпочитают использовать скобки вот так:

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

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

Каждый язык имеет свои инструменты и стандарты в этом отношении. С помощью Google вы можете отыскать лучшие стили для выбранного вами языка.

Вот несколько ссылок:

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

Документируйте свой код

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

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

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

Написание документации: достаточно полезная вещь. Подумайте обо всех репозиториях GitHub. Фактически включать файл README.md в корневой каталог проекта стало стандартом.

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

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

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

Используйте хороший стиль, чтобы ваша кодовая база была легко ориентирована и структурирована.
Следуйте лучшим практикам, таким как DRY (don`t repeat yourself), YAGNI (you are not gonna need it) и KISS (keep it simple, stupid).
Не бойтесь длинных названий. Используйте полные имена для ваших переменных, классов и функций. Вместо имени wm используйте имя windowManager, вместо rf — readFileToString. Это значительно упрощает чтение кода и, когда кто-то откроет ваш код спустя несколько месяцев, он интуитивно поймет о чем идет речь.
Функция должна иметь строго определенный функционал. Название функции должно соответствовать ее предназначению. Например, функцию, которая читает данные файла в строку, следует назвать readFileToString(String fileName). Даже мельком просматривая код, человек будет интуитивно понимать, что делает эта функция. В идеале, ваш код должен выглядеть как последовательность вызовов функций, которая выглядит почти как человеческий язык. Лишь при необходимости человек, который читает код, может погрузиться в детали функционала.

Следуя этим принципам, вы сможете писать код, который документирует сам себя!

Обращение за помощью. Как делать это правильно?

Профессионал просит помощи только после тщательной попытки самостоятельно найти решение. Прежде чем задавать вопросы:

Прочитайте документацию. RTFM — read the f*ucking manual.
Поищите ответ в гугле, если документация недостаточно ясна или не решает вашу проблему.

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

bug tracker — это не то место, где можно задавать вопросы, которые не касаются (потенциальных) ошибок.
Почтовая рассылка для разработчиков(developer mailing group) предназначена для разработчиков, работающих над продуктом, а не для разработчиков, использующих продукт.
Во многих проектах есть страница, в которой рассказывается, как и где задавать вопросы.
Существуют большие группы в Facebook, посвященные определенным языкам программирования и технологиям, где вы можете задать более общие вопросы. Исходя из моего опыта, группы Facebook не особо полезны, ибо там много мусора, но откопать нужный ответ можно и в них.

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

Будьте добры, будьте благодарны. Люди, которые отвечают вам и пытаются помочь, делают это в свободное время и бесплатно.
Опишите все максимально подробно. Укажите контекст: над чем вы работаете, почему, что вы уже пробовали?
Прикрепите скрины с сообщениями об ошибках и проблемный участок кода. Не выгружайте файлы целиком. Добавляйте в сообщение только то, что необходимо для получение помощи.

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

Рефакторинг

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

Какого черта ты это сделал? Ну, чтобы улучшить код… Существует несколько признаков, благодаря которым можно определить необходимость рефакторинга:

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

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

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

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

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

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

Не теряйте профессионализм

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

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

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

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

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

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

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

Источник