Как быть с программистом html / css, который комментирует все изменения, которые он вносит в CSS, вместо того, чтобы удалять их [закрыто]

ЛенниКоды

Как быть с программистом html / css, который комментирует все изменения, которые он вносит в CSS, вместо того, чтобы удалять их [закрыто]

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

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

.sampleRule {
   /* padding:20px */
   margin-left:20px;
   color: /*black*/ red;
}

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

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

В настоящее время я просматриваю код всей его работы, но я не уверен, как подойти к этой ситуации. Должен ли я поговорить с моим боссом? Должен ли я удалить это поведение, когда я его увижу? Должен ли я оставить его в покое?

Спасибо за помощь.

ЛенниКоды

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

Бернхард Баркер

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

Джакомо1968

«Я предложил ему использовать систему управления версиями, если ему интересно просмотреть прошлые изменения…» Ерунда. Я также использую контроль версий, но для быстрых изменений я не готов на 100%, я комментирую вещи, а затем удаляю их только позже в процессе. Например, сегодня пятница… У меня есть запрос на изменение. Я внес изменения, развернул код и отправился домой… Но мне действительно не хочется открывать новое окно браузера только для того, чтобы просмотреть изменения, когда я вернусь на работу в понедельник с более ясной и отдохнувшей головой. Имеет смысл держать такие вещи «бок о бок», пока вы не станете на 100% уверенным.

Ян В

@Emotive.io, теперь вы выявили 2 проблемы: оставляете закомментированный код на месте и отказываетесь от использования инструмента контроля версий. Второе оправдывает первое. Я не могу поверить, что разработчики не знакомятся с контролем версий в первом классе любого курса CS. Объясните преимущества контроля версий, закрытых ветвлений и т. д. (и проверку изменений с полезными комментариями) и то, как это повышает его производительность. Почему/когда он сделал это изменение? См. причину и дату заезда. Сделано и там на всеобщее обозрение, если только не в приватной ветке.

опечатка

Как бы он удалил это color: /*black*/ red;объявление, если комментарии CSS не могут быть вложены друг в друга?

длб

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

курт1893

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

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

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

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

марквангенд

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

Билл Липер

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

Н.Кэмпбелл

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

Матти Вирккунен

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

Старый_Фонарщик

На самом деле это довольно распространенная практика, и «правильность» или неправильность этого сильно различаются в зависимости от стандартов магазина.

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

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

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

Ян В

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

Фес Враста

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

Эфарли

Предисловие: я работаю в этой области более 11 лет и более 3 лет руковожу командами разработчиков интерфейса в крупных компаниях, таких как Nike.

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

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

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

В- третьих: Это не обычное дело, за 11 с лишним лет я только сталкивался с одной компанией, которая позволяла оставлять комментарии в коде для истории. Единственное место, где я ожидаю увидеть этот тип кодирования, — это устаревший магазин, который игнорирует лучшие практики и не имеет системы управления версиями, PR или репозиториев GIT, и если это так, БЕГИТЕ , бегите далеко-далеко и никогда не оглядывайтесь назад.

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

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

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

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

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

Призраки

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

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

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

Майлз

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

easymoden00b

Я не могу себе представить, что это хорошо, учитывая, что такие вещи, как git, полностью охватят этот случай и на 10000% более элегантно. Сохраняет ли он комментарии после второго/третьего изменения? Достаточно, чтобы мои глаза кровоточили при одной мысли о попытке сохранить такую ​​вещь. "Я просто нажимаю Ctrl + F, где применяется этот стиль... 1000000 прокомментированных результатов.."

Робин Беннетт

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