В настоящее время я наставляю коллегу, который отказывается удалять код. В настоящее время работает строго html/css разработчиком, но когда редактирует CSS, код не удаляет. Он закомментирует все, что хочет изменить, и применит свои изменения.
Вот пример того, что я имею в виду: когда меня просят удалить отступы из элемента и изменить цвет на красный:
.sampleRule {
/* padding:20px */
margin-left:20px;
color: /*black*/ red;
}
Когда я спросил его об этом поведении - он говорит, что делает это в целях документирования. Он хочет знать, какими были свойства до внесения изменений. У него есть опыт работы дизайнером, поэтому я могу понять его мышление, но наша кодовая база завалена кодом, который выглядит вот так.
Я предложил ему использовать систему управления исходным кодом, если ему интересно просмотреть прошлые изменения (например, вы можете использовать TFS, чтобы показать все изменения, внесенные в файл).
В настоящее время я просматриваю код всей его работы, но я не уверен, как подойти к этой ситуации. Должен ли я поговорить с моим боссом? Должен ли я удалить это поведение, когда я его увижу? Должен ли я оставить его в покое?
Спасибо за помощь.
Насколько я знаю, он использует систему управления версиями, как и все остальные, но вместо того, чтобы просто удалить старый код, как только он закончит, он предпочитает сохранять весь старый код в виде комментариев.
Это должно быть отражено в политике компании. Если политика вашей компании гласит, что весь старый код должен быть удален, чтобы файлы оставались как можно меньше, он должен следовать этой политике.
Да, вам следует поговорить со своим начальником, чтобы узнать, какова политика компании. Нет, я бы не стал удалять ни одну из его работ.
Если политики нет и это только ваше личное ощущение, то вроде бы стоит просто соглашаться не соглашаться. То, что вы считаете, что это правильный способ написания кода, не означает, что все с вами согласятся.
На самом деле это довольно распространенная практика, и «правильность» или неправильность этого сильно различаются в зависимости от стандартов магазина.
Если нет стандартов магазина, запрещающих это, то ничего страшного, если есть, то он нарушает порядок.
Спросите у своего босса, каковы стандарты магазина для этого, и действуйте соответственно.
Если вы считаете, что это должно быть стандартом магазина, а это не так, доведите это до сведения своего начальника и сделайте так, чтобы в качестве установленного стандарта удалялся код, а не комментировался.
Предисловие: я работаю в этой области более 11 лет и более 3 лет руковожу командами разработчиков интерфейса в крупных компаниях, таких как Nike.
Я не согласен с предыдущими ответами по нескольким пунктам. (Это предположение основано на том факте, что вы сказали, что наставляете его, что вы также его ведущий, если нет, и под боссом вы подразумеваете ведущего разработчика, чем слушать предыдущие ответы и говорить с ними, если под боссом вы означает владельца, начальника отдела или кого-то другого, не являющегося разработчиком, тогда продолжайте читать)
Во- первых: я бы НЕ пошел к вашему боссу. Вы должны рассматривать обращение к своему боссу как ядерный вариант, который следует приберечь как крайнюю меру. Ваш босс был уверен в вашей способности наставлять этого разработчика и справляться с такими вещами. Каждый раз, когда вы приходите к своему боссу, чтобы попросить его справиться с чем-то подобным, это немного подрывает вашу уверенность. Уверяю вас, у вашего босса есть дела поважнее, чем диктовать стандарты кодекса. Привлекайте своего начальника только в том случае, если вам нужны разъяснения по поводу чего-то или ситуация должна обостриться до формального выговора или увольнения.
Во-вторых: это не политика компании. Форматирование кода и стандарты кода полностью остаются на усмотрение ведущего разработчика. Ваш босс не заботится или не должен заботиться о таких нюансах, как форматирование и комментарии.
В- третьих: Это не обычное дело, за 11 с лишним лет я только сталкивался с одной компанией, которая позволяла оставлять комментарии в коде для истории. Единственное место, где я ожидаю увидеть этот тип кодирования, — это устаревший магазин, который игнорирует лучшие практики и не имеет системы управления версиями, PR или репозиториев GIT, и если это так, БЕГИТЕ , бегите далеко-далеко и никогда не оглядывайтесь назад.
На вашем месте я бы сначала провел ему экскурсию по GIT и показал, как это работает, поскольку он явно не понимает историю коммитов. Надеюсь, это поможет облегчить его опасения и заставит его понять, откуда вы исходите, когда говорите не делать этого, и на этом все закончится.
Во-вторых, я бы отказался одобрить любой из его PR, пока он не последует вашим предложениям, вы ведете, так что ведите. Если код не соответствует вашим стандартам, его не следует объединять, это так просто.
Если он по-прежнему отказывается менять его и позволяет своим PR вечно просиживать, а вы их блокируете, то пришло время поговорить с вашим боссом о разработчике. Может быть, пусть босс скажет ему выслушать вас, или напишет ему, или, возможно, даже уволит, в зависимости от того, как он отреагирует и от его общей работы.
Вы его наставник, и если он отказывается слушать ваше наставничество, значит, он не выполняет свою работу и мешает вам выполнять важную часть вашей. Имейте в виду, что если ваш начальник считает, что этот разработчик ничему не учится или не слушает вас, а вы ничего не сказали своему боссу, то это плохо отражается на вас, а не на разработчике, которого вы наставляете.
Наконец, если ваша компания не использует GIT или PR (запросы на включение), то это гораздо более серьезная проблема, чем оставление комментариев разработчиком, и вы должны настаивать на том, чтобы компания следовала современным передовым методам, которые предотвращают подобные проблемы или запускают их. уехать и искать работу, которая будет более полезной для вашей карьеры.
Во многих языках это довольно хорошая практика, по крайней мере, временно, поскольку она позволяет легко отменить изменения, а другие участники кодовой базы могут видеть недавнее развитие и произошедшие изменения. Тем не менее, это немного странно делать в CSS, где изменения довольно незначительны и их легко поменять местами, и обычно легко сразу увидеть изменения.
Несмотря на это, это не очень редкость, но было бы необычно оставлять комментарии к коду через некоторое время. Я бы просто сказал ему, что все в порядке, но после того, как изменения будут внесены, и он решит, что они хороши, вернитесь и удалите комментарии. На самом деле нет причин, по которым они должны быть там, если изменения приняты и, как ожидается, останутся.
Также может быть хорошей идеей добавить инструмент для минимизации файлов и удаления комментариев перед развертыванием, таким образом, в техническом смысле не имеет значения, будут ли файлы больше или его комментарии останутся. Это не средство от источника проблемы, а полезная мера для предотвращения ее последствий.
Temporary
это нормально, но это становится permanent
, когда вы совершаете это.
ЛенниКоды
Бернхард Баркер
Макнз
Джакомо1968
Ян В
опечатка
color: /*black*/ red;
объявление, если комментарии CSS не могут быть вложены друг в друга?длб