同僚がすべてのクエリの名前を変更した
私は非常にいらいらするべきかどうか、または何をすべきかわかりません。大規模なデータベース用に300以上のクエリを自分で手作業で作成し、後で見つけられるように命名規則を開発しました。私のオフィスの他の誰もクエリの作成方法を知りさえしていませんが、私は昨日、すべての名前が変更されていることを知りました。今は物を見つけるのにとても苦労していて、何をすべきかを理解しようとしています。
私は責任者と話しました、そして彼女はただ全部を軽視しました。彼女は、それらをより簡単に見つけられるように名前を変更したと言いました。残念ながら、それらを構築、編集、維持する方法を知っているのは私だけであり、彼女がそれらを見つける必要があった唯一の理由は、クエリをテストすることでした。新しい命名規則はまったく意味がなく、開発プロセスで後退したように感じます。
私が理解しようとしているのは：
1）私は過剰反応していますか？
2）これを処理する最良の方法は何ですか？私は上司にこのことを話すのは嫌ですが、昨日同僚と話をした後、彼女は彼女が何も悪いことをしていないように感じていることをすでに言うことができます。
本当にそうではありません-それは信じられないほど失礼なことです。
あなたは彼女と話しましたが、まだ話していませんが、以前の命名規則をバックアップから復元したり、ソース管理にある場合は元に戻したりすることはあなたの権利の範囲内にあるようです。これを行う場合は上司と同僚に通知し、理由を記入してください（自分の仕事を維持することはできません）。
あなたがしたい最後の事柄はこれを行ったり来たりすることですが、状況が厳しくなるようにそれを処理しますが、それが軽視のパターンの一部になる場合は少なくとも文書化する必要があります。
単純に大人のように扱ってみませんか：対立せずに座って、命名スキームの長所と短所のリストを考え出し、1つに同意し、それについて説明する短いドキュメントを書いて公式にします。彼女が関与していると感じている（そして関与している）ように、彼女の意見に真の興味を引き出す.
それが主に好みの問題であり、彼女が絶対に物事を自分のやり方で持っている必要がある種類の人であるならば、あなたはより大きな人であり、それを手放すことを喜んでください。人生は短すぎて、名前の付け方の腹を立てるコンテストを開催できません。
問題は命名方式ですか、それとも尊敬を得られないと感じていますか？もしそうなら、おそらくあなたはあなたの仕事上の関係に取り組むことができます。それが価値がないと感じたなら、なぜ彼女はとにかく彼女の考えを気にかけるのですか？ :)別のオプションとしては、彼女が本当にそれが大したことではないと感じ、物事を見つけるのに苦労していることをうまく説明できれば、それを元に戻すことができるかもしれません。
- データベースの設計には権限（GRANTおよびREVOKE）が含まれます。
- テストには、権限のテストが含まれます。
- 比較的少数の人々がデータベースオブジェクトの名前を変更する権限を持つべきです。
- あなたの同僚は少数の1人ではありません。
「新しい命名規則はまったく意味をなさない」というのは、次のようなケースのように聞こえます。
- 彼女は会社の基準を彼らに適用した。これらは多くの場合、コードが少なくとも一貫していることを確認するために使用され、最良の場合には、小さなカスタムスクリプトなどの周辺機器がコードを簡単に見つけるのに役立ちます。この場合、規範とwhyを理解する必要があります。この状況では「意味がありません」。それでも良いと思う場合はすべての開発者向けのままにして、メソッドが優れている理由を説明し、基準を変更できるかどうか尋ねます（おそらく、優れていることに同意すればOK） ）または、あなたの場合はそれを忘れてください（長期的には可能性が低く、厄介です）。
- 彼女は自分の基準をその場で発明し、それを適用しました。これは、彼女が新しい人である可能性が高く、その理由を説明する必要があります。あなたは何かを学ぶかもしれません、そして/またはあなたがその後あなたの理論的根拠を説明すれば彼女は何かを学ぶかもしれません。
重要な点は、それがyour（単数）コードではなく、グループ全体に属し、グループ全体によって変更される場合です。 コードについての批判は、誰がそれを書いたかを中心にすべきではありません。
私は責任者と話しました、そして彼女はただ全部を軽視しました。
それから私はあなたに言うが、率直に言っておく：
変更をロールバックします。
この戦争をしなさい。あなたの上司はあなたを支持し、あなたの権限を固める必要があります。
1）いいえ、あなたは反応しすぎていません。誰かがあなたに言わずにあなたの仕事を変え、あなたが彼らに理由を尋ねたときそれを払いのけました。それは非常に失礼で失礼な私見です。
2）あなたは公式のDBAですか、それとも少なくともDBの管理者になった人ですか？もしそうなら、名前を元に戻し、あなたが物事をどのように行うかについての慣習文書を書きなさい。また、「ユーザーズガイド」スタイルのドキュメントを作成して、誰かがDBにアクセスして何かを見つける必要がある場合に備えてください。
私はこれをグループに送信します。指を指さずに、座って、構造のニュアンスのいくつかを人々に説明してもらいたいという有益なメモを添えてください。
そうでない場合は、チームとして大会を考え出し、チームとしてそれに従ってください。
余談ですが、300以上のクエリの名前を変更するために何かをテストする必要があった人にとっては、かなり子供っぽいようです。彼女はこれを行うのにどれだけの時間を費やしましたか。誰かに助けを求めて行くのではなく、彼女は彼女の時間、あなたの時間、そして会社の時間を無駄にしました。言うまでもなく、彼女がこれを行ったときにコードが壊れたため、別のチームメンバーの時間も無駄になりました。
私があなただったら、あなたが少し冷めるまで待って、もう一度彼女に話しかけてみます。それが上手くいかない場合は、上司に相談してください。そのようなカウボーイの考え方は、結局チーム全体を束縛するでしょう。
データベースでランダムに名前を変更すると、本番環境がダウンする可能性があります。これらのプロシージャがコードのどこかで参照されている場合、深刻な結果を招く可能性があります。ロールバックを行うことはできますが、このようなテスターが実際に何をしているのかわからない場合は、テスターがプロダクションに変更を加えるのを見ることはそれほど遠くないです。これはビジネスの損失を意味する可能性があるため、開発者とテスターに個別のユーザーロールを実装する必要があります。私たちはテスターと一緒にそれを行い、それは素晴らしい働きをします。テスターは、ライブデータを台無しにすることを恐れて生活する必要がないので、しばしばそれを高く評価します。
他の場所では触れられていないようですが、公共の場所に置かれるソース（クエリなど）は、バージョン管理システムの下にある必要があります。
その後、同僚が命名スキームを変更した場合、作業スキームに簡単に戻すことができます（そして、それらの変更を確認し、必要に応じて元に戻すことができます）。また、変更を特定のユーザーに結び付けるので、だれが混乱したかを確認できます。
これが要求されたかどうかはわかりませんが、公式バージョンはどの命名規則ですか？あなたのバージョンが公式なら、私はその観点から問題に対処すると言います。つまり、「Person Xはすべての変更をロールバックしました」と言う代わりに、「Person Xが公式の命名規則に反する変更を加えた」と言ってください。公式の大会がない場合は、最初にあなたに相談することなく行われた変更に感謝しないことを彼女に知らせることをお勧めします。
どちらの場合でも、「戦争」を行うことは答えではないと思います。勝っても負けます。
ギフト用の馬を口の中で見ないでください。
第一に、集団的なコードの所有権-それらは「あなたのもの」であってはなりません。
次に、名前を変更した場合は、新しい命名方式についての理由を尋ねます。彼らはクエリを使用しています-その場合、それは彼らの呼び出しの一種です。またはそれはそれらを維持することであなたにいくつかの助けを与えることを開始するそれらの最初のステップです。
誰もが彼らが「あなたのもの」だと思っているなら、あなたはそれらを決して取り除くことはなく、何か新しいことに移ります。
それは恐ろしい行動です。彼女は後悔していないように思われるので、上司にそれを取り、彼女が混乱しないように確信できるまで彼女のアクセスを取り消させるようにしてください。
上司が技術的でない場合は、上司が理解できる言葉で説明してください。郵便が配達の準備ができている鳩の穴に仕分けられている郵便室で作業を開始することを想像してください。あなたは一方的に、鳩の穴を現在の部門別のシステムではなく、床、次に姓でソートすることを決定します。それは短期的にあなたの人生を楽にするかもしれませんが、あなたは他の郵便室のスタッフによって殺害されるでしょう。
それは無礼です。私は激怒します。
ランダムな人がそれらを変更するのを停止する権限を設定する以外に、機能をテストするのが彼女の仕事であることも説明する必要があります。ランダムな人がコードに変更を加えている場合、信頼性を保証することはできません。
皆が言ったように、あなたがこれらのクエリの作成者であるメンテナーであるため、彼女はあなたを尊敬していなければ、これを行うべきではありませんでした。
そうは言っても、クエリの名前を最初に変更したのは、彼女があなたの命名規則を理解できなかったためだと言った人はいないでしょう。
そのため、命名規則を文書化し、同僚がドキュメントにアクセスして必要なものを見つけられるようにすることで、問題を簡単に解決できます。
また、他の人がどのようにクエリを見つけて使用するかを注意深く考慮に入れる必要があります。命名規則で仕事を効率的に行えない場合は、おそらく、タグと合意されたキーワードにより、他のユーザーは探しているものを見つけることができます。
ここで鍵となるのは、誰も孤立して作業することはなく、お互いのつま先を踏まないようにするための最善の方法は、共通の基本ルールを伝えて合意することです。
はい、あなたは過剰反応しています。
バージョンコントロールと呼ばれるものがあります。これは、同僚があなたの物をいじるときに$＃！7を打ち負かす必要がないために使用されます。以前のバージョンにロールバックしてファイルをロックするだけで、彼女に怒りを処理させることができます。これは、他人のものに依存するコードに根本的な変更を行うことは、明確な理由もなく、最初に尋ねることもないことは、単に間違っているだけでなく、非常に非現実的であり、実際には罪であることを説明する機会を開きます。
もちろん、これはあなたの命名規則が彼女の規則よりも優れていることを前提としています。そうでない場合は、変更を処理できるようになり次第、コードの変更を開始するのが最も賢明な方法ではありません。次回は、より良い命名規則を考えてみてください。
上司にそれを持ち込まないでください。問題を解決する成熟した方法は、直接同僚と一緒に行うことです。その後、彼女と一緒に作業する必要があります。そのため、簡単に解決できるけんかのために関係を損なうのは愚かです。
私は同じように対応します-すべてを元に戻すというあなたの決定を軽視します。彼女の変更を元に戻し、同僚に本当に短いメールを書いてください：
「名前付け規則を理解できなかったため、現時点ではrXXXXの変更を元に戻しました。試していただきありがとうございます。:)」