Шесть привычек, которые снижают эффективность разработчика

1. Посещать слишком много встреч

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

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

2. Заниматься чрезмерным проектированием

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

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

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

3. Писать собственные структуры данных

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

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

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

4. Проявлять непоследовательность

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

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

5. Пренебрегать планированием

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

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

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

6. Не обращаться за помощью

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

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

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

Источник.