Главная

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

Продолжение статьи о повышении эффективности.

Поделиться:
 

19+

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

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

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

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

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

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

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

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

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

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

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

  1. Что это за код?
  2. Какую проблему он решает?
  3. Как вы можете начать работать над этим кодом?
  4. Конкретные инструкции для создания среды разработки, если таковые имеются.
  5. Как конечные пользователи используют программное обеспечение?
  6. Полезные ссылки, такие как дополнительная документация, справочная информация и так далее.
  7. Куда и как люди должны обращаться за помощью?

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

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

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

Профессионал просит помощи только после неудачной попытки самостоятельно найти решение. Прежде чем задавать вопросы:
a) Прочитайте документацию. RTFM read the f*cking manual.
b) Поищите ответ в гугле, если документация недостаточно ясна или не решает вашу проблему.
Если и это не помогло, то сперва подумайте, куда обратиться за помощью:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Профессиональный инженер-программист продолжает учиться на протяжении всей своей карьеры. В мире IT есть одна константа, и эта константа — это переменчивость. Языки программирования изменяются с каждым годом. Есть такое чувство, что новые фреймворки в JS выходят каждый день. Чтобы держать волну, вы должны продолжать учиться.
Если вам понравилась эта статья, вот три книги, которые помогут вам стать лучшим разработчиком программного обеспечения. Для многих они считаются Библией (включая меня) и все написаны Робертом К. Мартином:
1.Clean Code — A Handbook of Agile Software Craftsmanship
2.The Clean Coder— кодекс поведения программиста.
3. Clean Architecture — руководство по структуре и дизайну программного обеспечения.

Спасибо!

19+