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

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

Отвечая Да на все

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

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

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

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

Пауло Коэльо

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

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

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

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

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

Рассказывая тестировщику о том, как следует тестироват приложение, вы сэкономите много времени.

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

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

Не проверять свой собственный код

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

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

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

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

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

Создание коммитов, которые слишком велики

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

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

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

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

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

About the Author

Ergashev Lazizbek

Добрый день, дорогие мои читатели, позвольте мне рассказать вам немного о себе. Я Лазизбек Эргашев, я веб-разработчик из Узбекистана. В основном я использую laravel/php для бэкэнда и vuejs/javascript для фронтэнда. Основная цель моего блога - поделиться с вами своим опытом и знаниями.

View All Articles