Співробітник перейменував усі мої запити [закрито]

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

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

Що я намагаюся з’ясувати:

1) Чи я занадто реагую?

2) Який найкращий спосіб впоратися з цим? Я ненавиджу згадувати це своєму начальнику, але після розмови з моїм колегою вчора я вже можу сказати, що вона відчуває, що вона нічого поганого не зробила.

1. Насправді - це надзвичайно неповажна справа.

2. Ви розмовляли з нею, а у нас немає, але, здається, ви б в межах своїх прав відновити попередні умови іменування з резервної копії або відновити їх, якщо вони знаходяться в контролі джерела. НЕ повідомляйте свого начальника і колегу, якщо ви це зробите, і поясніть свою причину (Ви не можете підтримувати власну роботу).

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

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

Якщо це здебільшого питання смаку і якщо вона така людина, яка абсолютно повинна мати свої речі, то просто радійте, що ви більша людина, і відпустіть це. Життя занадто коротке, щоб мати шалений конкурс іменних схем.

Чи проблема в схемі називання чи ви вважаєте, що не отримуєте поваги? Якщо так, можливо, ви можете попрацювати над своїми робочими стосунками. Якщо ви вважаєте, що це не варто, то навіщо вам все одно, що вона думає? :) Ще одним варіантом може бути те, що вона справді не відчуває, що це велика справа, і якщо ви добре поясните, що у вас проблеми з пошуком речі, можливо, ви можете змінити її назад.

1. Дизайн бази даних включає дозволи (GRANT та REVOKE).
2. Тестування включає дозволи на тестування.
3. Порівняно небагато людей повинні мати дозвіл на перейменування об'єктів бази даних.
4. Ваш колега - не один з небагатьох.

"Нова угода про іменування взагалі не має сенсу" звучить так, як це може бути і так:

1. Вона застосувала до них якусь норму компанії. Вони часто використовуються для того, щоб переконатися, що код є принаймні послідовним, і в кращих випадках може допомогти периферійним речам, таким як невеликі спеціальні сценарії, легко знайти код. У цьому випадку вам потрібно зрозуміти норму і чому вона "не має сенсу" у вашій ситуації. Якщо ви все ще вважаєте, що краще всі розробники залишити його таким, яким він був, поясніть їм, чому саме ваш метод перевершує, і запитайте, чи можете ви змінити норму (напевно, гаразд, якщо вони згодні, що це вище) або відмовитись у вашому випадку (малоймовірно і безладно в довгостроковій перспективі).
2. Вона вигадала власний стандарт на місці і застосувала це. Це більше ймовірно, якщо вона нова, і їй слід пояснити своє обґрунтування. Ви можете чомусь навчитися, і / або вона може чомусь навчитися, якщо потім поясніть своє обгрунтування.

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

Я розмовляв із відповідальною людиною, і вона просто перекреслила всю справу.

Тоді я скажу вам без зусиль:

Скасувати зміни.

Ведіть цю війну. Ваш менеджер повинен підтримати вас і зміцнити свої повноваження.

1) Ні, ти не надто реагуєш. Хтось змінив вашу роботу, не розповідаючи вам, і викреслив її, коли ви запитали їх, чому. Це вкрай неповажно і грубо імхо.

2) Ви є офіційним представником справ або, принаймні, особою, яка перетворилася на зберігача БД? Якщо так, змініть імена та напишіть документ про звичайні умови для того, як ви робите справи. Крім того, напишіть документ у стилі "Посібник користувача", щоб, якщо комусь доведеться зайти в БД і знайти щось, що вони можуть.

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

Якщо ні, то придумайте команди як команди та дотримуйтесь їх як команди.

Зі сторони, для когось, кому довелося щось перевірити, щоб змінити назви 300+ запитів, це здається досить по-дитячому. Скільки часу вона витрачала на це, і лише для того, щоб вона могла знайти речі? Замість того, щоб просто поїхати і попросити когось про допомогу, вона витратила свій час, свій час та час компанії. Не кажучи вже про код, який, ймовірно, зламався, коли вона це зробила, тим самим витрачаючи час іншого члена команди.

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

Перейменування випадково в базі даних може легко призвести до погіршення виробничого середовища. Якщо на ці процедури посилатися десь у коді, це може мати серйозні наслідки. Ви можете зробити відкат, але якщо тестер, подібний до цього, справді не знає, що вона робить, це не так далеко, щоб побачити тестер внести деякі зміни у виробництво. Це може означати втрату бізнесу, саме тому вам слід спробувати реалізувати окремі ролі користувачів для розробників та тестерів. Ми робимо це разом з нашими тестерами, і це чудово працює. Тестери часто це цінують, оскільки їм не доведеться жити, боячись викрутити живі дані.

Це, схоже, не торкається в іншому місці, але будь-яке джерело (наприклад, запит), розміщене в громадському місці, повинно знаходитися під системою контролю версій.

Потім, якщо колега змінить вашу схему іменування, ви можете легко повернутись до вашої робочої схеми (і переглянути їх зміни; і, можливо, повернути назад, якщо необхідно). Ви також прив’язуєте зміни до конкретних користувачів, щоб ви могли бачити, хто зіпсував речі.

Не дивись подарунковій коні в рот.

По-перше, колективне володіння кодом - вони не повинні бути "вашими".

По-друге, якщо вони перейменували їх, то запитайте міркування щодо нової схеми іменування. Або вони використовують запити - у цьому випадку це свого роду їх дзвінок; або це перший крок у них, починаючи надати вам певну допомогу в їх підтримці.

Якщо всі думають, що вони "твої", ти їх ніколи не позбудешся, і перейдеш до чогось нового.a

Я не знаю, чи це запитували, але яка конвенція про іменування є офіційною версією? Якщо Ваша версія офіційна, то я скажу це питання з точки зору. Тож замість того, щоб сказати, "Person X відмовив усі мої зміни", просто скажіть: "Person X вніс зміни, які суперечать офіційним умовам іменування". Якщо офіційної конвенції немає, то я пропоную їй повідомити, що ви не цінуєте внесені зміни без попередньої консультації.

В будь-якому випадку я думаю, що "війна" не є відповіддю. Навіть якщо ви виграєте, ви програєте.

Це жахлива поведінка. Це здається, що вона не шкодує, тому візьміть це до свого начальника і зробіть випадок, щоб її скасувати доступ до тих пір, поки вона не зможе переконатись, що не возитися.

Якщо ваш начальник не технічний, поясніть це термінами, які вони зрозуміють. Уявіть, що ви починаєте роботу в поштовій кімнаті, де посада сортується в отвори голубів, готові до доставки. Ви вирішуєте в односторонньому порядку сортувати отвори голубів за підлогою, потім прізвище замість поточної системи відділу, а потім підлоги. Це може полегшити ваше життя за короткий термін, але вас вб'є інший персонал поштової кімнати.

Це поза грубістю. Я був би розлючений.

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

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

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

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

Головне, тут я думаю, що ніхто не працює ізольовано, і найкращий спосіб уникнути наступання пальців ніг один на одного - це спілкування та узгодження загальних принципів.

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

"Змінено rXXXX на даний момент, оскільки я не зрозумів, що це умовне іменування. Дякую, що спробував. :)"

Так, ви надмірно реагуєте.

Існує щось, що називається контролем версій, що, крім усього іншого, його застосовують для того, щоб не потрібно вибивати $ #! 7 з колег, коли вони возиться з вашими речами. Просто поверніть на попередню версію і заблокуйте файл, тому дозвольте їй впоратися з гнівом. Це відкриє вам можливість пояснити, що виконувати радикальні зміни коду, які залежать від чужих речей без поважних причин і не вимагати спочатку, це не просто неправильно, вкрай непрактично і практично гріх.

Звичайно, це передбачає, що ваша умова іменування краща, ніж її, і що ви можете насправді створити резервну копію цього рішення грунтовними об'єктивними аргументами, якщо це не так, наймудріше, що потрібно робити, почати змінювати свій код, як тільки ви зможете впоратися зі змінами та спробуйте придумати кращу конвенцію про іменування наступного разу.

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