И пять приемов, чтобы очистить ваш.
Почему каждый разработчик думает, что пишет совершенно понятный код? Почему тот же разработчик не может расшифровать чужой код, чтобы не поддерживать его?
Потому что все они пишут неаккуратный, работающий код. То есть код, который сейчас работает, но не очень расширяемый или универсальный из-за его беспорядка. Кроме компьютерных ученых - они пишут красивый код, который не работает.
Причина 1. Для компьютерных ученых программирование - это искусство. Для всех остальных это инструмент
Компьютерные ученые кодируют, потому что хотят кодировать. Все остальные кодируют, потому что хотят что-то сделать.
Средний разработчик структурирует программу на основе первой идеи, которая приходит ему в голову. Затем они будут развивать эту идею, пока не получат что-то вроде MVP. Обычно они даже не думают об альтернативных подходах.
Напротив, компьютерный ученый рассмотрит каждый вариант реализации и взвесит все за и против каждого. Через несколько недель у них будет красивый фрагмент кода, который все еще не полностью функционален, потому что компьютерный ученый еще не определился с форматом вывода.
Создается много неаккуратного кода, потому что разработчики начинают с простого инструмента и органично развивают код. Напротив, компьютерные ученые часто начинают создавать структуру, а затем работают в ней.
Органический подход лучше всего позволяет избежать блокировки кодера и выполнить работу вовремя. Однако, если вы хотите написать долговечный код, вы можете сначала поставить структуру.
Причина 2. Разработчики не всегда пишут, думая о читателе.
Даже в совместных проектах разработчики склонны писать код, имея в виду только его функцию. При этом они забывают о том, что код тоже нужно поддерживать.
Проблема в том, что такое мышление имеет неприятные последствия. Когда разработчик хочет добавить функцию через три месяца, он может не понять свой собственный код. Это происходит чаще, чем вы думаете!
И это становится еще более сложным, когда другого разработчика просят реализовать новую функцию. В зависимости от размера проекта понимание чужого кода может занять от нескольких дней до нескольких недель.
Причина 3: стиль важен
Все кодируют по-разному. Некоторые люди ненавидят встроенные комментарии, другие их любят. Некоторые люди комментируют свои функции над его первой строкой, некоторые - ниже. Одни любят переключатели, другие ненавидят их.
Вот почему фрагмент кода может показаться ужасным для одного человека, но вполне приемлемым для другого.
Это не проблема, когда вы работаете один. Но в наши дни многие программы создаются в сотрудничестве. Поэтому важно исправить руководство по стилю на ранних этапах проекта.
И, конечно же, вы должны убедиться, что все разработчики соблюдают его. В противном случае вы получите беспорядочный код, потому что это смесь различных соглашений.
Причина 4: заблуждение мгновенных вознаграждений
Вы когда-нибудь испытывали кайф, когда сталкивались с проблемой в течение нескольких дней, пока наконец не нашли способ ее решить? Это очень мотивирующий момент.
Проблема в том, что когда разработчик гонится за быстрыми исправлениями, он часто игнорирует долгосрочные проблемы. Например, они могут исправить ошибку или добавить функцию, но не осознают, что структура кода устарела.
Это означает, что каждый раз, когда они добавляют новую функцию, им придется приложить больше усилий. Напротив, однократная реструктуризация программы упростит добавление дополнительных функций в долгосрочной перспективе.
Если вы предпочитаете делать быстрые решения, а не устранять основную проблему, вы не одиноки. Система человеческого вознаграждения более восприимчива к краткосрочным исправлениям, чем к долгосрочным изменениям. Но таким образом вы накапливаете технический долг. И в конечном итоге это может дорого стоить.
Опасности чистоты и беспорядка
Разработчики, утверждающие, что они всегда пишут чистый код, либо лгут, либо переоценивают себя. При этом есть несколько причин, по которым вы не хотите писать слишком чистый код:
- Если ваша цель - написать безупречный код с нуля, вы увеличиваете свои шансы получить Coder’s Block. Чтобы избежать серьезной блокировки, лучше всего вначале вырастить ваш код органически. Это особенно актуально, если вы новичок.
- Некоторые разработчики тратят целые дни на очистку своего кода только ради эстетики. Конечно, это может быть полезно, если есть много других соавторов или если код будет представлен каким-либо образом. Но чаще всего доработка кода так же эффективна, как пластическая хирургия для общего здравоохранения - это может выглядеть хорошо, но не решает более глубоких проблем.
С другой стороны, вы также не хотите, чтобы ваш код был слишком беспорядочным. Слишком много беспорядка делает ваш код невозможным. Отсутствие поддержки ведет к гниению кода, и в конечном итоге проекты будут отброшены, поскольку они приносят больше вреда, чем пользы.
Итак, что необходимо, так это здоровый баланс между быстрыми результатами и поддерживаемым кодом. Большинство разработчиков сильно склонны к беспорядку, поэтому повышение чистоты - лучший способ. Хорошая новость в том, что несколько хороших привычек могут иметь огромное влияние на чистоту и продуктивность разработчика.
Уловка 1. Тестируйте рано и часто.
Некоторые разработчики настолько верят в свое мастерство, что создают целый проект без запуска тестов. Но если поставленная задача не является полностью тривиальной, это имеет неприятные последствия.
Как только они пытаются скомпилировать или запустить программу, экран заполняется сообщениями об ошибках. Или, что еще хуже, ошибки остаются незамеченными до тех пор, пока пользователи не поймут, что программа ведет себя не так, как ожидалось.
Это плохая практика. Если работа в сфере технологий вас чему-то научила, то это должно быть так:
Никогда не предполагайте, что что-то работает должным образом, если вы не проверили все сценарии.
Постарайтесь как можно скорее создать что-нибудь исполняемое. Даже если это очень и очень просто. И протестируйте его, как только представится возможность. Таким образом, вы можете исправить ошибки, как только они будут созданы.
Уловка 2: хорошо структурируйте и небрежно форматируйте
Погоня за быстрыми исправлениями - это нормально, если основная структура кода хороша. На самом деле происходит то, что разработчики пытаются внести быстрые исправления в код, имеющий неаккуратную или устаревшую структуру.
В таком случае лучше потратить время на реструктуризацию кода. Если исправление не прокомментировано должным образом или есть какие-то загадочные имена переменных, это не будет концом света. Но попытка создать чистую функцию в коде с ошибками - пустая трата времени и ресурсов - вам, вероятно, все равно придется переписывать много из них.
Таким образом, хорошим компромиссом между чистотой и скоростью будет поддержание базовой структуры в чистоте и обновлении, а также в том, чтобы быть настолько беспорядочным, насколько это необходимо в деталях.
Уловка 3: Выделите время на рефакторинг
Каждый раз, когда у вас беспорядок, вы создаете технический долг. Как и в случае с денежным долгом, чем дольше вы его оставляете, тем дороже он становится.
С другой стороны, среднестатистический разработчик не тратит дни или даже недели на чистку кода. Вот почему может быть полезно установить распорядок ежедневной выплаты небольшого долга.
Хороший способ начать - тратить 15% своего времени каждый день на рефакторинг. Я называю это правилом времени. Вы удивитесь, сколько кода вы сможете улучшить!
Уловка 4: Оставьте код чище, чем вы его нашли
Я называю это туалетным правилом. Если бы все оставляли общественные туалеты хотя бы такими же чистыми, как они их находили, они были бы в безупречном состоянии.
Судя по состоянию большинства общественных туалетов, в реальности так не работает. Соблюдение такого правила требует дисциплины от каждого разработчика, а для этого нужен отличный менеджер.
Но дисциплина того стоит, поскольку со временем вознаграждение может быть огромным. Вы не достигнете невозможного, делая невозможные вещи - вы добиваетесь этого, принимая несколько хороших решений и делая небольшие шаги в их направлении каждый божий день.
Хак 5: Просите отзывы!
Иногда код получается запутанным, потому что разработчик не знает, как это сделать лучше. Например, код может использовать оператор switch, где карта будет намного проще. В этом случае совет старших разработчиков является ключевым.
Установление процедуры проверки кода может помочь создать цикл обратной связи. Это приводит к улучшению кривой обучения молодых разработчиков и способствует формированию культуры здорового обсуждения.
Как и в случае с туалетным правилом и правилом времени, распорядок является ключевым. Запрашивать отзывы должно быть привычкой для младших разработчиков, а советы должны быть неотъемлемой частью работы старших разработчиков.
В идеале, время обзора должно быть частью основных процессов команды разработчиков, а краткое изложение ключевых рекомендаций должно быть частью каждой встречи.
Уравновешивание структуры и хаоса
Слишком большая уборка может быть пустой тратой времени и ресурсов. А писать небрежный код намного лучше, чем столкнуться с блоком кодера и вообще не выполнить его.
С другой стороны, небрежный код негибкий и его сложно поддерживать. Пять правил помогут сделать ваш код намного чище, не теряя времени. Как и в любой другой сфере жизни, хорошие вещи создаются со здоровым балансом структуры и хаоса.
