同僚がすべてのクエリの名前を変更した[終了]

私は非常にイライラする必要があるかどうか、または何がわからない。大規模なデータベースに対して300を超えるクエリを独力で構築し、後で見つけられるように命名規則を開発しました。私のオフィスの他の誰もクエリの作成方法を知りませんが、昨日、すべてのクエリの名前が変更されたことを知りました。私は今、物事を見つけるのに非常に苦労しています。

私は責任者と話をしましたが、彼女はすべてを軽視しました。彼女はもっと簡単に見つけられるように名前を変更したと言いました。残念ながら、私はそれらを構築、編集、および保守する方法を知っている唯一の人であり、彼女がそれらを見つける必要がある唯一の理由はクエリをテストすることでした。新しい命名規則はまったく意味をなさないため、開発プロセスで後方への一歩を踏み出したように感じます。

私が理解しようとしているのは：

1）私は過剰反応していますか？

2）これを処理する最良の方法は何ですか？私はこれを上司に話すのは嫌いですが、昨日同僚と話した後、彼女は何も悪いことをしていないように感じていることをすでに伝えることができます。

1. そうではありません-それは信じられないほど無礼なことです。

2. あなたは彼女と話しましたが、私たちは話しませんでしたが、以前の命名規則をバックアップから復元したり、ソース管理にある場合は元に戻したりする権利があるようです。これを行う場合は、上司と同僚に通知し、理由を伝えてください（自分の仕事を維持することはできません）。

最後にしたいことは、これについて何度もやり直しますが、状況がwarしそうに見えるのでそれを処理してください。

大人のように単純に処理してみませんか？対立せずに座って、命名スキームの長所と短所のリストを考え出し、同意して、それを説明する短い文書を作成して公式にします。彼女が関与していると感じている（そして関与している）ように、彼女のインプットに対する純粋な興味を引き出します。

それが主に趣味の問題であり、彼女が物事を絶対に持たなければならない種類の人なら、あなたがより大きな人であることを喜んで手放してください。人生は短すぎてネーミングスキームの放尿コンテストをすることができません。

問題は命名スキームですか、それとも敬意を払っていないと感じていますか？もしそうなら、あなたはあなたの仕事上の関係に取り組むことができます。あなたはそれが価値がないと思うなら、なぜあなたは彼女がとにかく考えていることを気にしますか？:)別の選択肢は、彼女が本当に大したことではないと本当に感じていないことかもしれません。

1. データベース設計には許可（GRANTおよびREVOKE）が含まれます。
2. テストには、権限のテストが含まれます。
3. データベースオブジェクトの名前を変更する権限を持つ必要がある人は比較的少ないはずです。
4. あなたの同僚は数少ない人の一人ではありません。

「新しい命名規則はまったく意味をなしません」これらのいずれかが当てはまるようです。

1. 彼女は彼らに会社の規範を適用しました。これらは多くの場合、コードの一貫性を確保するために使用され、最良の場合には、小さなカスタムスクリプトなどの周辺機器がコードを簡単に見つけるのに役立ちます。この場合、標準を理解する必要があり、それがあなたの状況で「意味をなさない」理由を理解する必要があります。それでもすべての開発者がそれをそのままにしておく方が良いと思う場合は、正確にあなたの方法が優れている理由を説明し、規範を変更できるかどうか尋ねます（おそらく彼らが優れていることに同意する場合はOK） （長期的にはめったになく面倒です）。
2. 彼女はその場で独自の標準を発明し、それを適用しました。彼女が新しい場合、これはより可能性が高く、彼女は彼女の理論的根拠を説明する必要があります。あなたは何かを学ぶかもしれません、そして/またはあなたがあなたの理論的根拠を説明するならば、彼女は何かを学ぶかもしれません。

重要な点は、それがあなたの（単一の）コードではなく、グループ全体に属し、グループ全体によって変更されるということです。コードについての批判は、それを書いた人を中心に考えるべきではありません。

私は責任者と話をしましたが、彼女はすべてを軽視しました。

それから私はあなたに、恥ずかしがらずに言います：

変更をロールバックします。

この戦争をしなさい。上司はあなたを支持し、あなたの権威を固めるべきです。

1）いいえ、あなたは反応しすぎていません。誰かがあなたに話をせずにあなたの仕事を変え、なぜあなたが彼らに尋ねたときにそれを打ち消した。それは非常に無礼で失礼です。

2）あなたは公式のDBAですか、少なくともDBの管理者になっている人ですか？もしそうなら、名前を変更し、あなたが物事を行うための規約文書を書きます。また、「ユーザーズガイド」スタイルのドキュメントを作成して、誰かがDBにアクセスして何かを見つけなければならないようにします。

指を指さずに、グループに送って、あなたが喜んで座って、構造の微妙なニュアンスを人々に説明してもらえると助かります。

そうでない場合は、チームとして規則を考え出し、チームとしてそれらに従ってください。

ちなみに、300件以上のクエリの名前を変更するために何かをテストする必要がある人にとっては、かなり幼稚なようです。彼女がこれをするのにどれだけの時間を無駄にしましたか？彼女はただ誰かに助けを求めるのではなく、時間、あなたの時間、そして会社の時間を無駄にしました。言うまでもなく、コードはおそらく彼女がこれを行ったときに壊れたため、他のチームメンバーの時間も無駄にします。

もし私があなただったら、あなたが少し冷めるまで待って、もう一度彼女と話してみてください。それがうまくいかない場合は、上司に相談してください。そのようなカウボーイのメンタリティは、最終的にチーム全体を拘束します。

データベース内でランダムに名前を変更すると、本番環境が簡単にダウンする可能性があります。これらのプロシージャがコードのどこかで参照されていた場合、深刻な結果を招く可能性があります。ロールバックを行うことはできますが、このようなテスターが実際に何をしているのか分からない場合、テスターが本番に変更を加えるのを見るのはそれほど遠くありません。それはビジネスの損失を意味する可能性があります。そのため、開発者とテスター用に別々のユーザーロールを実装する必要があります。私たちはテスターでそれを行い、それはうまく機能します。テスト担当者は、ライブデータを台無しにすることを恐れずに生活する必要があるため、それを高く評価しています。

他の場所では触れられていないようですが、公共の場所に置かれているソース（クエリなど）はバージョン管理システムの下にある必要があります。

同僚が命名スキームを変更した場合、作業スキームに簡単に戻すことができます（そして、その変更を確認し、必要に応じて元に戻すことができます）。また、特定のユーザーに変更を結び付けるため、だれが混乱したかを確認できます。

口の中で贈り物の馬を見ないでください。

まず、集合的なコードの所有権-それらは「あなたのもの」であってはなりません。

第二に、名前を変更した場合は、新しい命名スキームに関する理由を尋ねます。どちらもクエリを使用している-その場合、それは一種の呼び出しです。または、それらを維持する上でいくつかの助けを与え始めるそれらの最初のステップです。

誰もが自分のものだと思ったら、それらを取り除くことは決してなく、新しいものに進みます。

これが尋ねられているかどうかはわかりませんが、どの命名規則が公式バージョンですか？あなたのバージョンが公式であれば、私は観点から問題に取り組むと言います。したがって、「Person Xはすべての変更をロールバックしました」と言う代わりに、「Person Xは公式の命名規則に反する変更を加えた」とだけ言ってください。正式な慣例がない場合は、最初に相談せずに、行われている変更に感謝しないことを彼女に知らせることをお勧めします。

どちらの場合でも、「戦争」をすることは答えではないと思います。あなたが勝ったとしても、あなたは負けます。

それはぞっとするような行動です。彼女は後悔していないように聞こえるので、それをあなたの上司に伝えて、彼女が混乱しないように確信できるまで彼女のアクセスを取り消すことを主張してください。

上司が技術的でない場合は、上司が理解できる用語で説明してください。ポストが配達の準備ができている鳩の穴に分類されるポストルームで作業を開始することを想像してください。ハトの穴を現在の部門のシステムではなく床の順に並べ、次に姓で分類することを一方的に決定します。短期的にはあなたの生活が楽になるかもしれませんが、他の郵便局のスタッフに殺されてしまいます。

それは失礼ではありません。私は怒ります。

ランダムな人々がそれらを変更するのを止める許可を設定する以外に、機能をテストするのが彼女の仕事であるため、あなたも説明する必要があります。

皆が言ったように、あなたがこれらのクエリの作成者であるのであなただけを尊重するなら、彼女はこれをするべきではありませんでした。

そうは言っても、最初にクエリの名前を変更したのは、命名規則を理解できなかったためだという事実を誰も言及していません。
したがって、命名規則を文書化し、同僚が文書にアクセスして必要なものを見つけられるようにすることで、この問題を簡単に解決できます。

また、他の人がどのようにクエリを見つけて使用するかを注意して考慮する必要があります：命名規則が彼らの仕事を効率的に行うことを許可していない場合は、おそらく、タグと合意されたキーワードにより、他の人が探しているものを見つけることができます。

ここで重要なのは、だれも孤立して動作せず、お互いのつま先の踏み出しを回避する最善の方法は、共通の基本ルールを伝えて同意することだと思います。

同じように対応します-すべてを元に戻すという決定を軽視します。彼女の変更を元に戻し、同僚に本当に短いメールを書くだけです。

「今のところrXXXXの変更を元に戻しました。命名規則が理解できなかったためです。お試しいただきありがとうございます。:)」

はい、あなたは過剰に反応しています。

バージョンコントロールと呼ばれるものがあります。これは、同僚があなたのものをいじるときに$＃！7を破る必要がないことなどに使用されます。前のバージョンにロールバックしてファイルをロックするだけで、彼女は怒りを処理できます。これにより、他の人のものに依存するコードに対して、確固たる理由もなく、また最初に尋ねることなく根本的な変更を行うことは、間違っているだけでなく、非常に非現実的であり、実際に罪ではないことを説明する機会が開かれます。

もちろん、これはあなたの命名規則が彼女の命名規則よりも優れていることを前提としており、変更を処理するためにできるだけ早くコードの変更を開始するのが最も賢明なことではない場合、実際の目的の引数でこの決定をバックアップできることを前提としています次回はより良い命名規則を考えてみてください。

それを上司に渡さないでください。それを解決する成熟した方法は同僚と直接です。その後、彼女と協力して、簡単に解決できる口論の関係を損なう必要があります。