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

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

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

Когда ты не знаешь, с чего начать

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

Решение простое: это не имеет значения.

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

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

«Неважно, насколько медленно вы идете, пока вы не останавливаетесь».
- Конфуций

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

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

Это будет циклично.

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

Когда вы не хотите проверять PR

Мы все были там. Множество проверок кода смотрят нам прямо в глаза. Классический баланс между «своей работой» и «чужой». Но знаете что?

Это ваша работа.

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

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

Итак, что вы делаете, когда последнее, о чем вы думаете, - это проверять код? Два действенных варианта:

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

Если вы перегружены обзорами и не можете получить доступ ко всем из них, вам следует поработать над их передачей другому инженеру, у которого есть циклы. Это работает намного лучше, чем вскидывать руки и говорить: «тьфу, еще один обзор!»

Когда вы начинаете писать повторяющийся код

Легко избежать СУХОГО кода при первой работе над проблемой или при создании новой функции. Однако позвольте этой привычке продолжаться слишком долго, и вы только потом закончите делать дополнительную работу для себя.

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

Вы жертвуете длительной ремонтопригодностью и эффективностью ради краткосрочного удовлетворения:

«Послушайте, у меня все получилось».

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

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

Когда вы снова вернетесь к работе над этим фрагментом кода, первым пунктом на повестке дня должно стать его ОСУШЕНИЕ и устранение хаоса. Вы немного продвинетесь вперед, код будет читаться лучше, чем раньше, и, возможно, вы даже услышите это «ага!» момент, который решает основную проблему.

Когда вы теряете безопасность

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

  • «Что произойдет во время аудита безопасности?»
  • «Что произойдет, если их найдет злоумышленник?»

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

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

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

Когда начинаешь становиться сварливым разработчиком

… Не будь этим человеком.

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

Это неприятно, и никому в команде не полезно быть полным засранцем.

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

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

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

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

Спасибо за внимание! Если вы замечаете, что некоторые из этих проблем формируются, я надеюсь, что эти стратегии могут помочь. Каковы ваши собственные стратегии борьбы с вредными привычками программирования?