Насколько важно очищать чужой код, когда сталкивается с жестким сроком? [закрыто]

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

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

Я столкнулся с 2 проблемами:

1. Их стиль кодирования немного беспорядок.
2. Эстетика не очень хорошая.

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

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

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

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

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

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

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

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

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

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

Я говорил это раньше и скажу еще раз: «рабочий код более ценен, чем красивый код».

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

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

• Короткий ответ - нет. В трудные времена иногда нужно просто опустить голову и взять эстетическую пулю. ;)

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

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

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

Но в ответе есть суждение. Я бы сказал «умеренно» важно. Чистый код действительно может ускорить работу, а качество кода, в конце концов, является частью результата. Я не думаю, что смогу прикоснуться к коду (даже к своему), не потратив некоторое время на очистку. Но убедитесь, что суета со стилем и форматом, а также войны за стиль не становятся более важными, чем получение кода для производства.

При исправлении кода и наличии срока я обычно использую два правила:

Код ужасен, но можно найти проблему в разумные сроки и исправить ее

Я исправляю проблему и оставляю все остальное нетронутым .

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

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

Пограничный случай:

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

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

Мне было бы интересно узнать, на каком этапе вашего процесса вы находите эту проблему?

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

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

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

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

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

Для текущей партии очистите код в соответствии с документом S & P при рефакторинге кода, но только при рефакторинге.

Я довольно неопытен в программировании. Однако, будучи студентом, я часто обязуюсь проводить рецензирование и партнерские отношения по проектам. Если у меня будет достаточно времени для завершения проекта, я пойду и приведу в порядок код члена команды для ясности и читабельности. Чаще всего мне будет трудно даже просеять первые 100 строк или около того. В этих случаях я более чем готов протянуть руку, чтобы помочь обучить программиста лучшим навыкам и программированию. Если времени просто не хватает, я просто копирую / вставляю и работаю над своими проектами, чтобы понять их плохие интерфейсы. После этого я обязательно дам множество советов по технике кодирования. Когда дело доходит до экспертной оценки, конструктивная критика (независимо от того, насколько нежелательной) приносит пользу как ему, так и мне в долгосрочной перспективе.

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

Улучшение общего качества значительно превосходит использование одного человека в качестве «фильтра» для большой группы. На этой записке:

• Парное программирование работает как расширенная версия обзора кода для понимания того, как развиваться, - это как разница между чтением и выполнением, рассказом и показом. Наблюдение за развитием кода и быстрое обсуждение изменений очень помогает понять не только то, как, но и почему рефакторинг и хороший код. По моему опыту, это быстрее, чем развиваться в одиночку, поскольку идеи постоянно разбрасываются, что в итоге приводит к более высокому качественному результату и лучшему пониманию как кода, так и мышления другого человека.
• Инструменты Linting могут проверить, что стиль кодирования соблюдается. Это учит всех, как форматировать код, и ошибки должны быстро исчезать, как только разработчики запомнят стандарт.
  • Сделайте это частью процесса сборки, чтобы убедиться, что он исправлен перед фиксацией.
  • Используйте языковые шаблоны, чтобы гарантировать, что ваш CSS, HTML, JavaScript и код на стороне сервера могут проверяться отдельно.
• Инструменты проверки могут проверить, что сгенерированный вывод является нормальным. Они также должны быть частью процесса сборки.

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

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

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

• учиться лучше стиля
• следовать лучшим практикам
• научиться исследовать то, что они делают

А некоторые преимущества для себя вы получите:

• более эффективен во время отладки в последнюю минуту (которая всегда будет происходить)
• как ваша команда, так и руководство признаны экспертом и лидером

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

Также я понимаю, что большинство людей не очень хорошо воспринимают это. Я тоже это понимаю.

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

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

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

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

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

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

Есть некоторые вещи, которые не сложнее исправить в тот момент, когда код требует обслуживания, чем они должны исправить сейчас. Это на самом деле не очень полезно для исправления. Наиболее очевидными являются тривиальные проблемы (ошибки с пробелами и т. П.), Поэтому трудно представить, что у вас есть время задать этот вопрос, но не исправить его ;-) Для тех, которые не являются тривиальными и относятся к этому типу, тогда ОК у вас есть код, который не идеален, но вы должны быть прагматичными. Это работает, и вы в срок. Используй это.

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

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

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

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

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

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

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

В-третьих, набор стандартизированных сред разработки с предварительно настроенными инструментами неоценим. TS сервер превосходен для этого. У всех одинаковые инструменты (и версии), одинаковые конфигурации и одинаковые обновления. Установите инструмент рефакторинга, такой как CodeRush или Resharper, предварительно настроенный на ваши стандарты, и проинструктируйте вас, программисты, что вы будете отклонять любые коммиты, у которых все еще есть предупреждения. Теперь вы можете использовать время проверки кода вашей команды, чтобы фактически улучшить свой набор правил на основе их отзывов, и ваша команда с радостью исправит себя, и вам не придется постоянно убирать после этого. Программисту также намного легче воспринимать критику кода из правильно настроенного инструмента, чем от коллеги или начальника, где стандарты могут показаться произвольно заданными или неправильно понятыми. Если IDE говорит вам, что ваш код плохой, никто не будет спорить с этим, и это будет исправлено. Вы обнаружите, что качество кода резко возрастет, и команда в целом потратит НАМНОГО меньше времени на рефакторинг и очистку через несколько недель. Программисты также привыкнут к правилам и перестанут писать дерьмовый код.

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

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

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