Вы неплохой разработчик, просто у вас есть вредные привычки

У всех они есть. Плохие привычки. Ни один человек на этой земле не совершенен.

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

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

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

Сказать да всему

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

Но сказать «да» всему - это огромный убийца производительности. В конце концов, вам, вероятно, придется самому доставить код.

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

Пауло Коэльо пришел к выводу, что сказал:

Когда вы говорите «да» другим, убедитесь, что вы не говорите «нет» себе.

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

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

Ваше определение слова «готово», вероятно, на самом деле не «сделано»

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

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

Вы реорганизовали свой код? И если вы критически взглянете на свой код, как вы думаете, понимают ли его другие разработчики? Если ответ на один из вопросов выше «нет» - исправьте!

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

Рассказав тестировщику, как следует тестировать функцию, вы оба сэкономите много времени.

Знаете ли вы, что, по словам Глории Марк, изучающей цифровое отвлечение в Калифорнийском университете, на то, чтобы вернуться к исходной задаче после перерыва, требуется в среднем 23 минуты?

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

Не тестировать свой собственный код

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

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

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

«Но тестирование увеличивает время разработки».

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

Создание слишком больших коммитов

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

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

Маленькие коммиты - ваш друг. Они позволяют разработчику дать описательное сообщение о фиксации. Сожалеем, но фраза «Исправлены некоторые проблемы» не является описательным сообщением о фиксации.

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

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

Это сделает вас намного эффективнее, не приложив больших усилий.