Сотрудник переименовал все мои запросы [закрыто]

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

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

То, что я пытаюсь выяснить, это:

1) Я слишком остро реагирую?

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

1. Не совсем - это невероятно неуважительно.

2. Вы говорили с ней, а мы нет, но, похоже, вы имеете право восстановить прежние соглашения об именах из резервной копии или вернуть их, если они находятся в системе контроля версий. НЕОБХОДИМО уведомить своего начальника и коллегу, если вы это сделаете, и указать причину (вы не можете поддерживать свою собственную работу).

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

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

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

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

1. Дизайн базы данных включает в себя разрешения (GRANT и REVOKE).
2. Тестирование включает в себя тестирование разрешений.
3. Относительно немногие люди должны иметь разрешение на переименование объектов базы данных.
4. Ваш коллега не один из немногих.

«Новое соглашение об именах вообще не имеет смысла» звучит так:

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

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

Я говорил с ответственным лицом, и она просто преуменьшала все это.

Тогда я скажу вам, беззастенчиво:

Откатить изменения.

Веди эту войну. Ваш менеджер должен поддержать вас и укрепить ваш авторитет.

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

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

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

Если нет, то придумайте условности в команде и следуйте им в команде.

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

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

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

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

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

Не смотри дареному коню в рот.

Во-первых, коллективное владение кодом - они не должны быть «вашими».

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

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

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

В любом случае, я думаю, что «война» - не ответ. Даже если вы выиграете, вы проиграете.

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

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

Это за грубость. Я был бы в ярости.

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

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

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

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

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

Я бы ответил так же - преуменьшая ваше решение вернуть все обратно. Просто отмените ее изменения и напишите действительно короткое письмо своим коллегам:

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

Да, вы слишком остро реагируете.

Есть нечто, называемое управлением версиями, которое, помимо прочего, используется для того, чтобы не выбивать из колоды $ #! 7 коллег, когда они возятся с вашими вещами. Просто вернитесь к предыдущей версии и заблокируйте файл, позволяя ей справиться с гневом. Это откроет вам возможность объяснить, что радикальные изменения в коде, который зависит от чужого материала без веской причины и без предварительного запроса, не просто неправильны, крайне непрактичны и практически грех.

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

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