Уважение поддерживающих [закрытых] разработчиков

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

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

Моя внутренняя реакция - наброситься ...

Я вижу в этих утверждениях ОЧЕНЬ ОЧЕНЬ СОБСТВЕННЫЕ вещи.

1. Именование ДЕЙСТВИТЕЛЬНО, ДЕЙСТВИТЕЛЬНО важно. Стоит переписать код, чтобы он был правильным.
2. Это не ТВОЙ код
3. Как это неуважительно?

Вы воспринимаете это слишком лично.

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

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

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

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

Нарушение сборки - нехорошо.

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

Привет,

Ребята! Нам всем нужно РАЗГОВорить !

Просто сидите вместе и ГОВОРИТЕ ! Всегда есть причины меняться и всегда есть причины, по которым НЕ делать.

Решайте вместе !

Не заходите в StackOverflow или на форум и не говорите «задавайте такие вопросы».

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

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

Кому это нужно?

Просто выложите свои аргументы на стол и все.
Новому разработчику тоже нужно немного представить.
Старый dev должен быть ТОЖЕ перечислен.

Это должна быть совместная работа И не злить друг друга.

Решать вместе, разговаривать, как КОМАНДА .

И ... лучше задавайте такие вопросы, как «Как лучше реорганизовать это?»

Ура.

В любой команде разработчиков программного обеспечения размером> 1 стандартизация является ключевым моментом. Не только для того, чтобы каждый разработчик понимал код другого, но и для того, чтобы люди, которые пришли через 2, 5 и 10 лет, могли взглянуть на любую часть кода и увидеть четкую и последовательную схему. Будете ли вы ... и остальная часть команды ... серьезно все еще там, работая над этим проектом, через много лет?

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

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

Вот и все.

Теперь о мягких навыках ...

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

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

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

Что именно нужно моделировать? Наследование данных или методов?

Edit : Вот небольшая статья, которую я нашел: http://fluff.info/blog/arch/00000162. Просто помните, что это не «ваш» код. Код принадлежит компании, в которой вы работаете. Вы написали код, и вам за это заплатили. Позвольте Руководству делать с этим все, что они хотят.

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

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

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

1. Если вы измените код и что приводит к поломке чего-то еще, вы несете ответственность за это, а не я.
2. Если я не согласен с внесенными вами изменениями, я верну его так, как я хочу, поскольку я должен нести ответственность за это фрагмент кода в будущем.

Не все разработчики должны вносить изменения во весь код все время. Лишь в некоторых случаях с целью ознакомления с кодом (обмена знаниями).

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

Вы касаетесь моего кода и что-то ломаете, (1) вам лучше иметь вескую причину для изменения, с которой согласны все разработчики с и (2) вам лучше не оставлять сломанные вещи сломанными или просить меня пойти за вами убрать, ЕСЛИ вы не мой начальник. Я смиренно подчинюсь, если это так.

Вы касаетесь моего кода и что-то ломаете, (1) вам лучше иметь вескую причину для изменения, с которой согласны все разработчики с и (2) вам лучше не оставлять сломанные вещи сломанными или просить меня пойти за вами убрать, ЕСЛИ вы не мой начальник. Я смиренно подчинюсь, если это так.

Вы касаетесь моего кода и что-то ломаете, (1) вам лучше иметь вескую причину для изменения, с которой согласны все разработчики с и (2) вам лучше не оставлять сломанные вещи сломанными и не просить меня пойти убрать за вас, ЕСЛИ вы не мой начальник. Я смиренно подчинюсь, если это так.

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

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

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

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

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