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

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

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

Первым делом давайте обсудим, что делать?

Код без дедлайнов.

Код без оптимизации.

Код без переключения между задачами.

Код без лени.

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

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

Прежде чем перейти к коду, давайте разберемся, что такое продукт в ИТ-организации?

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

Более или менее это то, что означает программный продукт в ИТ.

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

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

Поддержание баланса между бизнес-требованиями и технологиями иногда бывает сложным.

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

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

Первый тип

Разработчик, который заботится о сроках и завершает работу в соответствии с бизнес-требованиями.

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

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

В чем тогда проблема?

Нет никакой проблемы, скорее это начальная фаза проблемы, которая не может быть обоснована прямо сейчас.

Мы обсудим важность хорошего качества кода как-нибудь в другой раз.

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

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

Люди тогда согласились с утверждением, что хорошее качество кода так же важно, как и хороший продукт.

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

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

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

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

Как следует из названия, «они думают о сроках и бизнес-требованиях». Следовательно, они почти не фокусируются на процессе улучшения качества кода. Лучшее качество кода — это процесс, а не продукт. Давайте разберемся, как кодировать.

«Избегайте дедлайнов при кодировании» Никогда не думайте о дедлайнах при кодировании, я говорил своим коллегам делать это, но ответ таков:

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

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

Позволь мне объяснить.

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

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

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

Это очень важно, и это не проблема намерения, а проблема привычки.

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

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

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

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

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

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

Второй тип:

Оптимизация:

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

Эти разработчики поглощены качественным кодом, а не бизнес-требованиями. Их впечатляет, когда код написан компактно и осмысленно.

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

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

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

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

В конце концов, во многих организациях они заканчивают тем, что работают сверхурочно и получают стресс в качестве бонуса.

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

Проблема заключается в их понимании концепции качества кода, понимании и осознании того, что «Качество кода — это процесс, а не продукт».

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

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

Разве вышеупомянутые предметы не являются великими вещами?

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

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

Это плохой код, даже если он написан очень хорошо и хорошо структурирован, но он не работает даже в большинстве положительных случаев.

Лучше писать плохой код, но он работает в большинстве положительных случаев.

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

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

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

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

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

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

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

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

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

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

Третий тип

Переключение между задачами:

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

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

Один из способов, которые сработали для меня, определить тип задач. Если это привычная задача и занимает менее 30 секунд, например, пересылка почты, просто ответьте ok, ответив: «Мы проверим и обновим ». Прикрепляя уже созданный документ, эти элементы в основном обусловлены привычкой, поэтому они не съедают наш мозг, и вам не нужно начинать думать с самого начала, когда вы переключаетесь на исходную задачу кодирования.

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

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

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

Теперь снова вернитесь к коду, вы делаете много кода за 20 минут, если делаете это последовательно.

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

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

Лень:

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

Последнее примечание:

Вы уже делаете хорошо, все дело в том, чтобы делать лучше.

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