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

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

Ошибки, которые, если сделать их привычкой, могут навредить вашей работе, команде, проекту, репутации и всей вашей карьере.

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

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

Плохое планирование, неопределенные требования, паника или просто невезение привели вас к этой ситуации, не имеет значения — внедряя некачественный код, вы создаете технический долг, который кому-то придется погасить. быть платным.

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

Ожидаемые функции
Потому что "Что, если нам это понадобится позже?"

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

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

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

Преждевременная абстракция
Одним из лозунгов индустрии программного обеспечения является:

Преждевременная абстракция — корень всех зол

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

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

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

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

Нам нужны абстракции, но только в нужное время и в правильном количестве.

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

Давайте сравним два примера:

function sentenceCase(value: string): string {
  // Returns the original value if not matching the criteria
  if(isString(value) && !isNaN(parseInt(value))) {
    return value;
  }
  // Returns an empty string
  if (!value || !isString(value)) {
    return '';
  }
  // We need to bring the string to lowercase
  const normalizedString = toLower(startCase(camelCase(value)));
  // Returns the string transformed to Sentence case
  return upperFirst(normalizedString);
}

и:

/**
 * Transforms a string into the
 * `Sentence case` - capitalizes first letter of the string.
 * @param value string
 * @returns string
 *
 * @example
 * 'myString' => 'My string'
 * 'my_string' => 'My string'
 * 'MY_STRING' => 'My string'
 * 'my string' => 'My string'
 * 'My string' => 'My string'
 * 'My String' => 'My string'
 */
function sentenceCase(value: string): string {
  if(isString(value) && !isNaN(parseInt(value))) {
    return value;
  }
  
  if (!value || !isString(value)) {
    return '';
  }

  const normalizedString = toLower(startCase(camelCase(value)));
  return upperFirst(normalizedString);
}

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

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

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

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

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

И если это по какой-то причине работает, вы отправляете исправление, не зная, с чего началась ошибка.

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

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

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

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

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

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

Слишком высокие цели
Однажды я слышал, как заинтересованная сторона, недовольная обзором спринта, сказала, что не имеет значения, завершена ли функция на 95 %, потому что она не в производстве.

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

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

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

Не просить о помощи ("Потому что я чувствую, что должен сделать это сам")
Когда вы застряли, вы может не решиться обратиться за помощью или разъяснениями. Застревание может привести к тому, что вы потратите время, пытаясь решить проблемы самостоятельно, вместо того, чтобы обращаться за помощью, что приводит к разочарованию и демотивации.

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

Никто не сделает вашу задачу за вас, но с радостью подскажут или зададут правильный вопрос, который может направить вас на правильный путь! И, возможно, именно вы поможете им в следующий раз!

Я обещаю вам, что построение таких отношений более ценно, чем работа в одиночестве.

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

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

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

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

Помните, что почти всегда вопрос — это просто вопрос, а не вызов на дуэль.

Или, может быть, вы знаете что-то, чего не знают они? Используйте это как возможность объяснить, что вы делаете и почему именно так, а не иначе!

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

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

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

Это одно из удивительных преимуществ работы в команде!

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

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

И я думаю, что незнание — это возможность учиться, а не помеха или что-то, чего нужно стыдиться. Проблема в невежестве.

Не поспевает за новыми технологиями
«Что вы недавно узнали?» — один из вопросов, которые я задаю кандидатам во время собеседований. и я всегда надеюсь услышать что-нибудь. Ничего особенного, но ответ многое говорит об отношении кандидата к обучению.

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

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

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

Все эти вредные привычки одновременно и вызывают привыкание и заразны.

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

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

Срезать углы всегда было и будет плохой инвестицией. Сколько бы времени вы ни «экономили» на разработке, вы тратите в два раза больше времени на исправление ошибок.

В конце концов вы погасите свой технический долг, а если не вы, то это придется сделать вашим коллегам.

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

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

Спасибо за чтение!

Повышение уровня кодирования

Спасибо, что являетесь частью нашего сообщества! Перед тем, как ты уйдешь:

  • 👏 Хлопайте за историю и подписывайтесь на автора 👉
  • 📰 Смотрите больше контента в публикации Level Up Coding
  • 🔔 Подписывайтесь на нас: Twitter | ЛинкедИн | "Новостная рассылка"

🚀👉 Присоединяйтесь к коллективу талантов Level Up и найдите прекрасную работу