Stankar0x

Читаемость кода, соглашения и я должен отпустить


Профессионализм Программное обеспечение промышленности Код Работа

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

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

Теперь один из моих сверстников, у которого есть старшинство, скажем, из-за продолжительности его пребывания в должности. Умный парень, посвященный кодексу, и написал важные пьесы. Отводит меня в сторону и говорит:

Зачем ты это делаешь? Вы меняете мой код. Мы команда. Этот код был написан таким образом, чтобы его понимали от кого-либо из команды. И его нужно поддерживать даже через 100 лет. Если вы не следуете правилам команды, мы должны расстаться, или я поговорю с менеджерами, чтобы вам больше не приходилось касаться этого кода. Эта вещь ... не будет понята младшими разработчиками, и я знаю, что вы там делаете, только потому, что я вижу diff. Я написал этот код и знаю каждую строку в нем, и теперь с ним трудно следовать. Он не читается, и я пишу свой код, чтобы он ясно дал понять, что я думаю. Вы должны делать то, что я вам говорю - это означает, что я не прикасаюсь к моему коду, и если есть ошибки, исправьте ошибку и все.

Хорошо, я признаю, что я виноват. Я не соблюдал Конвенцию Кодекса до Т, но, как правило, я думаю, что моя версия более читаема, чем предыдущая версия.

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

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

Разъяснения:

  • Человек, с которым я беседовал, не мой менеджер, он сверстник. Мы на одном уровне. Его восприятие старшинства основано на том, что он был там дольше меня.
  • В кодексе четко сказано, что я могу изменить код, чтобы сделать его в духе соглашения о коде. Конвенция была написана его прямым менеджером.
  • @Fattie - Я обычно согласен, что обе версии кода - мусор. Я поклонник дяди Боба, Грэди Буча, Кента, Мартина Фаулера и т. Д. Поэтому я знаю, что вы подразумеваете. Теперь я не прошел весь путь, чтобы сделать его неузнаваемым, так как я боялся просто войти в этот территориальный спор. В этом случае я просто придерживался конвенции.
  • У меня сложилось впечатление, что некоторые из вас предполагают, что быть новым в этом месте - значит, неопытный. Пожалуйста, не думайте об этом.
  • Для меня удобство чтения является предвестником для упрощения обслуживания в будущем. Я знаю, что могу срезать углы и оставить это как есть. В конце концов, я собираюсь сменить корабль. Будущим разработчикам придется иметь дело с этим. Не нужно усложнять мою жизнь за 3 строки кода. Просто хотел собрать мнения, если бой стоит того. В этом отношении (для этого случая) ответ @AO имеет наибольший смысл.
Jane S♦
Комментарии не предназначены для расширенного обсуждения; этот разговор был перемещен в чат .

thirtydot
Глядя на код в старом редактировании (и говорящий как программист): Я думаю, что разделение длинных сложных строк на несколько строк - это хорошее изменение, что значительно упрощает его чтение. Часть, в которой вы вводите оператор % более спорна. Возможно, старый код там был понятен, особенно для младших разработчиков, которые часто не могут использовать этот оператор (кроме FizzBuzz). Как вы думаете, он бы так жаловался, если бы вы только разделили линии? Тем не менее, его реакция была очень плохой. Будьте осторожны с этим парнем в будущем ...

Stankar0x
Я согласен, что оператор mod (%) добавляет к обману. Но даже без этого я уверен, что реакция была бы такой же.

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

Ответы


A.S

Отпусти ситуацию. Вы пытаетесь пойти на компромисс между тремя или четырьмя приоритетами: вашими предпочтениями, кодовыми соглашениями, предпочтениями старшего разработчика, код которого вы изменили, и способность команды понимать код. По словам старшего разработчика, его стиль кодирования имеет смысл для команды. Таким образом, приоритеты 3 и 4 могут быть объединены. Теперь это между вами, условными обозначениями кода и старшей командой разработчиков +.

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

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

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

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

David Hammen
Re По словам старшего разработчика, его стиль кодирования имеет смысл для команды. Я подозреваю, что это не так. Это «его код», что этот новичок имел галочку. Я подозреваю, что никто не трогает его код, потому что (а) он совершенно нечитабелен, но, похоже, магически работает, и (б) парень настолько тронут своим «кодом», что любой, кто смеет прикасаться к нему, получает лекцию.

Matthieu M.
@DavidHammen: Самый токсичный коллега когда-либо. Напоминает мне о старшем коллеге, который был мертв против обзоров кода, потому что он не хотел, чтобы кто-либо просматривал его код ...

Flater
Хотя я в основном согласен с ответом, я не согласен с обоснованием «Согласно старшему разработчику, его стиль кодирования имеет смысл для команды». (1) Каждый код имеет смысл для себя. Вы должны проверить мнение других . (2) Старший может применять стандарты кодирования, основываясь на том, чтобы быть старшим, в некоторой степени независимо от того, какой стандарт он устанавливает. Тот факт, что ведущий разработчик задействует OP на личном уровне («почему вы это делаете?», В отличие от «стандарта кодирования - это такое»), предполагает, что ведущий разработчик вызывает снимки, а не [. .]

Flater
[..] в соответствии с установленным руководством, которое объективно определено. Если существует такое установившееся правило, он должен ссылаться на это руководство, а не на то, чтобы быть оскорбленным действиями ОП, преувеличивая претензии «100 лет ремонтопригодности», угрожая удалить доступ OP к коду или высокомерно заявив, что его код (недвусмысленно) не трогать. Если цитата из ведущего разработчика никоим образом не точна, возникает серьезная проблема с чрезмерной самоуверенностью ведущего разработчика и превентивной профилактикой всего, что подчеркивает честную ошибку (или несовершенное решение).

meriton

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

Поэтому я бы ответил следующим образом:

S: Почему вы это делаете? Вы меняете мой код. Мы команда ...

J: Я пытался заставить его придерживаться конвенции кодирования. В нем говорится, что мы должны делать XXX и улучшать существующий код, когда увидим его?

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

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

Что делать, если я вижу что-то в вашем коде, которое я не понимаю или думаю, можно сделать проще?

И снова слушай, чего он хочет.

Это выполняет несколько вещей:

  1. Его довольно эмоциональный отклик указывает на то, что он эмоционально вкладывается в свой код и чувствует, что его экспертное мнение неуважительно. Прося свой опыт, вы показываете, что вы цените его опыт, который должен огорчить дискуссию.
  2. Он сообщает, что вы не хотели не уважать его или выставлять напоказ социальные нормы. Скорее, это заставляет его понять, что вы просто еще не знали, чего от вас ожидали, и что вы пытаетесь это исправить.
  3. Он разъясняет, что от вас ожидается, чтобы избежать дальнейших случайных конфликтов.
Fildor
«Он разъясняет, что от вас ожидается, чтобы избежать дальнейшего случайного конфликта». Я думаю, что коллега уже сделал это ясно: «Еще раз коснись моего кода! Еще раз коснись моего кода! Я смею тебя ...» - Поэтому я не думаю, что участие в предлагаемом разговоре будет конструктивным.

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

meriton
@Fildor: В гневе люди иногда делают опрометчивые заявления, которые они распознают как менее совершенные решения при спокойном размышлении. В этом случае я считаю необходимым пересмотреть необходимость, потому что предлагаемое решение не является устойчивым: что должен делать OP, если ему заданы задачи, требующие существенных изменений кода этого старшего?

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

Stephan Branczyk

Вы уже изменили эти изменения. Так что пусть это уйдет.

Говоря это, в следующий раз это произойдет. Убедитесь, что в вашей интерпретации правил кодирования нет комнаты для маневра. Потому что, если вы собираетесь сразиться с кем-то, обязательно выберите битву, в которой у вас есть 100% шанс выиграть.

Это важно, особенно если у вас нет такого социального капитала, как этот человек.

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

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

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

akaioi
+ 20zillion для упоминания модульных тестов. ; D Это сделает любые изменения без особого труда!

Stephan Branczyk
@emory, я не согласен.

Mat's Mug
@emory все сообщество Code Review не соглашается с этим утверждением.

Mat's Mug
@emory no. модульные тесты охватывают, делает ли код то, что ему нужно, - не реализовано ли оно читаемым способом. И если ваши тесты превращают детали реализации в спецификации, тогда ваши тесты линяют всю базу кода в цементе.

James Snell
@emory - ОП пытался исправить ошибку. Код был плохо написан и нуждался в рефакторинге, чтобы следовать, и только тогда была обнаружена ошибка в другом месте (несколько строк ниже рефакторинга). Это абсолютно код, который мне нужен, чтобы рефакторировать только для того, чтобы следовать ему, и когда перед лицом «старшего» девика их отношение подсказывает возможность напомнить им, что я бы не исправлял ошибку, если бы они не оставили ее там, не пришлось бы реорганизовать, если бы он соответствовал стандартам корпорации. Единственный «выход», который я бы им дал, - это то, что эта часть кодовой базы предшествовала тем (что вполне может сделать.)

akaioi

Увидел ряд ответов, говорящих «Отпусти это». Я не могу согласиться с этим, потому что проблема будет возникать снова и снова.

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

Вы удалили свой конкретный пример (который, как я думал, был слишком плохим, он предлагает некоторый контекст), но позвольте мне просто добавить одну вещь ... Эта потенциально сложная часть (увеличение индекса по модулю для обертывания вокруг до 0) должна быть понятной для J Random Programmer, но не помешало бы добавить комментарий на верхней части строки в качестве напоминания ...; D

jmoreno
Я согласен с тем, что конкретный пример полезен, и он связан с модулем: поскольку он не упрощал чтение индекса, он изменил расчет индекса. Это был oldindex + 1> = count? 0: oldIndex +1; новый - значение oldIndex +1%. значение oldIndex 4 и счет 3, old = 5> = 3 результат 0. Новый результат = 5% 3 2. Возможно, этого не происходит, все еще ... код имеет как синтаксис, так и семантику. Изменение читаемости семантических эффектов - это изменяет концепцию, даже если она не изменяет результат. Фиксирование граничной ошибки в цикле for не изменяет намерение, переписывая LINQ.

jmoreno
ИМО в этом случае по модулю изменила не только рассчитанное значение, но и концепцию происходящего. Теперь oldIndex является обертывающим или круговым индексом, где 0, 10 и 2,145,690 все одинаковы, равнодействующее значение для подсчета 10.

Jasper

Много продолжается

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

Ошибки и исправления стиля

Вы исправили проблему, одновременно изменив код.

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

Разные виды

Вы не согласны с тем, какая версия лучше соответствует соглашениям, более читаема и более удобна в обслуживании.

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

Жесткий код

С самого начала код был трудно понять.

Я нашел, что полезно задавать вопросы о коде в таких ситуациях, особенно если вы знаете, кто написал код (и / или код был написан недавно). Задаваемые вопросы могут помочь вам лучше понять код и помочь другому человеку понять, почему код был трудно понять для начала. Это часто приводит к тому, что код можно сделать более понятным сам по себе, и вы можете обсудить его перед их внедрением.

Атака

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

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

Его код

Он не хочет, чтобы вы редактировали его код.

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

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

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

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

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

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

В заключение

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

James Snell
+1 для кода Hobbyist - многие старые кодеры из этой школы Hobbyist / RockStar «это только другие люди, которые делают ошибки», и это требует много самоанализа и опыта, чтобы понять, почему всем нам нужны другие аспекты программного обеспечения как модульное тестирование и удобочитаемость.

Stankar0x
Я ценю нарушение проблемы, как и вы. Обычно я использую технику Мартина Фаулера и реорганизую код, когда я продвигаюсь, чтобы иметь смысл для меня или упростить его. Таким образом, изменения стиля и исправления ошибок, а также жесткий код все решаются им. Это здорово, когда у вас есть модульные тесты для подтверждения ваших предположений. Но также работает, когда вы выполняете ручное тестирование, преследуя ошибки. Также, когда оригинальные программисты недоступны или когда люди заняты и не хотят или не успевают обсудить детали с вами. [..]

Stankar0x
[..] Вот некоторые ссылки для тех из вас, кто интересуется этим: ссылка или его книга: Рефакторинг Улучшение дизайна существующего кода.

Jasper
@ Stankar0x Интересное чтение (хотя немного датировано). Я не совсем уверен, что вы подразумеваете, но под заголовком «Ошибки и исправления стиля» я никогда не хотел сказать, что вы не должны этого делать. Я просто хотел сказать, что может быть лучше сделать refactor-commit-refactor-commit-fix-commit, а не refactor-refactor-fix-commit. Я знаю, что я немного в стороне, когда речь идет о разделении разных вещей в разных коммитах, но я говорил, что если бы исправление было в нескольких строках ниже рефакторинга, это могло бы помочь де-эскалации проблемы несколько, если они были отдельными коммитами.

Flummox

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

И ваш коллега пытается запугать вас, не ошибитесь в этом.

Во-первых , код, над которым вы работаете, не является его ни вашим, ни вашим. Это принадлежит тому, кто платит вам.

Во-вторых , вы не должны делать то, что он говорит, что вы должны делать, если только он не ваш босс, а кто он. Вы должны делать то, что хочет сделать ваш работодатель.

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


Таким образом, вы не хотите усложнять свою жизнь за 3 строки кода. Хорошо на вас! Но что вы собираетесь делать в следующий раз?

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

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

jean
Конфликты членов команды - это самый полный способ сделать вашу жизнь несчастной

Flummox
@jean, согласитесь, что конфликты членов команды ничтожны, но коллега здесь может начать такую ​​ситуацию. Я думаю, что эту ситуацию лучше всего решить, поставив перед собой задачу руководителя команды, это его / ее команда.

IMil

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

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

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

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

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

Brandin
Трюк только умный, если он работает. В этом случае использование% вместо условного изменения поведения. Полученный код может быть неправильным. Трудный правильный код всегда лучше, чем «четкий» неправильный код. Конечно, с осторожностью вы можете добиться четкого и правильного кода.

IMil
@Brandin IMHO не было изменения поведения. Исходный код сказал в основном: (если x + 1> = length, то 0 else x + 1). Умный трюк должен был переписать его как ((x + 1)% длины). Это точно так же. Главное отличие состоит в том, что трюк Кливера не очевиден.

Bryan Goggin

Когда вы новичок, обычно рекомендуется занять некоторое время, чтобы наблюдать за динамикой и чувствовать себя в команде и т. Д., Прежде чем принимать на себя какие-либо значительные изменения. Хорошее эмпирическое правило: «Если оно не сломалось, не исправить его» или следствие этого: «Если бы он был сломан, кто-то его исправил». Если бы этот код был большой проблемой, он, вероятно, был бы (или, по крайней мере, должен был быть исправлен к настоящему времени. Возможно, какой-то код, с которым вы сталкиваетесь на этом задании, нуждается в исправлении, но подождите, пока вы больше не познакомитесь с перед тем, как вы решите, соответствует ли какой-либо такой код.

Несмотря на то, как много усилий идет на разработку универсальных стандартов кодирования / документации, у КАЖДОЙ РАБОЧЕЙ МЕСТНОСТИ ИМЕЮТ ИХ СОБСТВЕННЫЕ СТАНДАРТЫ, и требуется время, чтобы определить, что именно они представляют.

underscore_d
Re CAPS ... Стандарты явно не являются стандартами, если они должны быть «выведены» ... Они являются стандартами, если они четко определены в политических документах. Что-то, что существует только как совокупность социальной динамики и конвенций, передаваемых только наблюдением, не является стандартом. Никакое рабочее место не может обеспечить это, особенно не с агрессивностью коллеги, о которой идет речь. Я не думаю, что совет сесть и заткнуться - это хорошо; если работодатель ОП имеет официальные стандарты, он / она прав, чтобы быть озадаченным такой противоположной и решительной наградой за приверженность (при условии, что они читают ее правильно)

cale_b
Это просто двойной крик или тройной крик, когда все это ВЕРХНИЙ И ОБРАБОТАН ? :)

Daniel
Если бы это было сломано, кто-то теперь ее исправил. - вы явно никогда не работали над правильным устаревшим кодом. :)

Bryan Goggin
@underscore_d Ой, поверь мне, я согласен с каждым словом, которое ты сказал. Но на практике, я думаю, мы оба знаем, как нечеткие некоторые «стандарты: могут быть.

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

Danikov

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

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

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

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

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

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

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

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

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


L.Dutch

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

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

У вас есть два варианта:

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

Hotlush

«Код конвенция четко сказать, что я могу изменить код, чтобы сделать его в духе коды конвенции. Конвенция была написана его непосредственным руководителем.»

Я не могу не думать, что это страшная директива. Всеми средствами генерировать билет на «улучшение» определенный участок кода, или доведя его до стандарта, но «изменить его, если вам не нравится, как это выглядит» рецепт для катастрофы. Как вы контролируете эти изменения, когда они сделаны как часть других исправить? Как вы проверяете изменения?


Timothy Truckle

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

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

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

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

Смотри также