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


38

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

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

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

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

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

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

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

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


1
Если у вас есть такая возможность, посмотрите на продукты JetBrains (Re-Sharper для C #, IntelliJ для Java и даже некоторые «динамические» языки), которые могут вносить идиоматические изменения в рамках всего проекта с минимальными затратами времени. (Он также может быть использован для интерактивного обучения юноши тому, что является нелепым. Но убедитесь, что вы и они согласны с одинаковыми настройками для проекта. (И убедитесь, что вы делаете все эти вещи в отдельном коммите, чтобы не смешивать существенные и косметические изменения в одном коммите),
Дэвид Баллок


2
Реализовать руководство по стилю / минимануал? Я имею в виду, что они не будут писать лучший код, но каждый способен следовать рекомендациям, которые требуют написать тривиальные вещи одним конкретным способом.
Петерис

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

3
@ Ramhound, так как Тьюринг разработал Машину Тьюринга, я думаю. Но вернемся к делу, если вы старший, который должен заставить юниоров выслушать вас. Научите их, как делать правильный (или в конвекционном) способ. Но важно спросить их мнение, и, возможно, у них есть некоторые идеи о том, как сделать вещи лучше. Также, если вы используете сырой CSS для любого нетривиального проекта, вы делаете это неправильно, попробуйте заставить ваш проект принять LESS или SASS.
Гофман

Ответы:


79

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

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

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

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

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

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


Я на 100% согласен с вами, однако мне интересно, как применять это при наличии сжатых сроков. Предлагаете ли вы проводить проверки кода, даже если они могут потратить больше нашего драгоценного ограниченного времени (как в процессе проверки, так и в исправлениях, внесенных после проверки)?
Фил

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

23
@Phil При расчете крайнего срока необходимо учитывать время для пересмотра кода. Это не дополнительный шаг на вершине процесса разработки - это неотъемлемая часть процесса разработки.
dj18

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

2
@JustinPaulson не поймите меня неправильно - тот факт, что кто-то написал какой-то код, не делает этот код «его». Неделю спустя какой-то другой член команды получит задание, которое потребует от нее изменения этого кода, и она определенно должна изменить код для своих нужд. Однако я не вижу случая, когда кто-то должен «очищать» чужой код ради очистки, особенно не в последнюю минуту в сжатые сроки.
Ури Агасси

29

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

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

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


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

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

20
Проблема в том, что уродливый код быстро превращается в неработающий код.
Теластин

1
@ramhound - конечно, но OP (и почти все остальные) не говорят о коде, который просто использует старые стандарты, - они говорят о неуклюжем, непоследовательном, некачественном коде.
Теластин

1
@JamesAnderson Это очень близорукая перспектива. Код написан один раз, но он сохраняется на протяжении всего срока службы продукта. Большая часть кодирования является рефакторингом. Как долго вы фактически пишете код на пустом экране, прежде чем настраивать его и смотреть, работает ли он так, как ожидалось? Поэтому вы проводите рефакторинг даже в первый час после начала нового урока. Стоимость рефакторинга некрасивого кода в последующих исправлениях и улучшениях превзойдет стоимость небольшого времени, потраченного на предварительный анализ кода и приведение команды к единому четкому стандарту.
Скотт Шипп

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

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

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

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

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


9

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

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

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

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

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

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

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

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


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

6

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

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

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

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


4

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


3

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

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


Я работал в некоторых крупных, очень ориентированных на процессы компаниях, которые были готовы потратить oooooodles денег, чтобы обеспечить соблюдение стандартов и практики кодирования. ОНИ НИКОГДА НЕ БЫЛИ, пока автоматизированные инструменты не начали применять их.
Данк

@ Данк Военные США считают «большими и ориентированными на процесс»? Они все время используют S & P: stroustrup.com/JSF-AV-rules.pdf
Кейси

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

Кстати, я не говорю, что нет нужды в стандартах и ​​практиках кодирования. Там абсолютно необходимо. У меня просто есть спор с частью «все сотрудники должны следовать», если только вы не упомянули что-то о применении этого с помощью автоматизированных инструментов.
Данк

@Dunk Команда JSF-AV, должно быть, признала это, в документе конкретно упоминается использование автоматизированных инструментов в качестве способа обеспечения соблюдения S & P (еще в 2005 году)
Кейси,

2

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

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


2

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

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

2

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

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

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

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

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

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

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

Как программист на Python и лидер по обзору кода, я напечатал PEP 8 и руководство Google по Python Style, по крайней мере, дюжину раз, чтобы их можно было разослать. То, что программисты не будут учиться у них, отстанет от тех, кто делает. Тем не менее, я согласен, что проверка стиля также является хорошей практикой, если вы можете реализовать ее.
Аарон Холл

Я не использую Python, поэтому я не знаю доступных инструментов, но если вы полагаетесь на обзоры кода для обеспечения соблюдения правил стиля, то вы тратите сотни (если не тысячи) часов в год на то, что вы может быть сделано для вас по существу без затрат времени. Я, конечно, не стал бы реализовывать версию для дома. Я бы потратил деньги, чтобы купить коммерческую версию, которая будет НАИБОЛЕЕ лучше всего, что может быть построено в нерабочее время. Даже дорогие инструменты окупятся во много раз.
Данк

Python, будучи рогом изобилия с открытым исходным кодом, имеет все виды бесплатных инструментов (pylint, pep8, pyflakes), некоторые из которых мы объединили и улучшили, которые, поскольку у нас есть тысячи разработчиков, действительно хорошо масштабируются.
Аарон Холл

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

2

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

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

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

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

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


0

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

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

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

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

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

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

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

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


0

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

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

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

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

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


0

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.