自分のやり方でやったことが役に立ったことはありますか？インダイレクトやインジェクション、余分なインターフェイスを使っていて、土壇場になっても悪態をつくことなく、スムーズに美しく処理されたことはありましたか？前の仕事でも、そのコードをここでコミットされたことがないなら？

あったと仮定します。その話をする練習をしましょう。それは具体的で現実的なものです。それは “x might happen "や "y might change "ではなく、"once upon a time, I did it this way and here’s how it worked out "です。管理者（私もその一人です）は、might**が起こるかもしれないことのためにお金を使うことに警戒心を持っています（そして私を信じてください、あなたが最初のパスで他の人が理解できないようなより複雑なコードを書くことは、お金を使うことです）。彼らは、「本の学習」やインターネットによると最新の流行に基づいているだけかもしれない投機に資金を供給したくないのです。しかし、あなたの経験に基づいて描画するとき？それは完全に別の状況です。

私は工場、プロバイダー、インジェクターや何かの大ファンではありません。彼らは一般的に、実際には決して起こらないことのために設定されている（MS SQLからOracleへの切り替え）または彼らが行うときに小さな影響を持っている（ファイルが保存されているフォルダを変更する）。しかし、非常に揮発性の高い取り決めの中では、あなたがいるように見えるような取り決めの中にも場所があります。だから、あなたは彼らがその場所を持っていることを示す必要があります。あなたは、「これは物事を行うための通常の方法であり、そうでない理由が必要だ」という立場から来ているように見えます。あなたのマネージャーは、「これは普通ではない。これは普通ではない、普通は簡単で単純なことだ。その理由に働きかけましょう。過去に実際に起こったサクセスストーリーで、その追加レイヤーが何日も何週間もの作業を救ったというようなことを考えてみてください。あなたのエンジニアリングを正当化してください。

ソフトウェアエンジニアとして、それは私にとって「表面上は良い理由がないかもしれないが、表面上は良い理由がある」ということをするのが第二の自然になります。

私は次のライフサイクルのいくつかの繰り返しを見てきました：

• 熟練したプログラミングチームは、プログラミングに別のアプローチを思い付く。
• それは数年間、最大10年のために、任意の欠点や制限にもかかわらず、普遍的に使用されるべきものとして表示されます。この段階では、Xが純利益であるかどうかを分析することなく、「私は方法論Xを適用しています」と言うのに十分です。
• それはファッションの外に行くが、その最も有用なアイデアは、ソフトウェア開発ツールキットの一部として、彼らが純利益をもたらすときはいつでも引き出して使用されるように、周りにとどまります。

私の心には、TDDとデザインパターンの両方は、プログラミング方法論のライフサイクルの第2と第3の段階の間のスプリットの周りに浮かんでいます。私は、TDDと多くのデザインパターンがツールキットの中で長く貴重な人生を過ごすことになると確信しています。私はまた、彼らはまだ意図的な思考ではなく、習慣によって、過剰に使用されているかもしれないと思います。

あなたはそれが第二の自然であるか、またはそれのあなたの使用を説明するのに苦労しているから****設計パターンを適用するべきではありません。その代わり、デザインパターンを適用する前に、この特定の状況でのコストと利益を考えてみてください。そのメリットが本当にコストを上回るのであれば、その理由を正確に知るべきです。メリットがコストを上回っていない場合は、そのパターンを使用しないでください。また、あなたのデザインについてのあなた自身の考えは、適用可能なデザインパターンをなぜ使わなかったのかと聞かれたときに答えられるように準備されているはずです。あまりにも多くの間接性があると、将来のプログラマが実際に何が起こっているのかを見つけるのが難しくなります。

ワークプレイスでは、実際の職場での紛争よりもコーディングの実践に焦点が当てられていることに当惑しているのは私だけでしょうか？だから私は別のアプローチを取ります。

ここで私が見たあなたの問題の一般化された側面は次のとおりです：

1. あなたはコラボレーションを必要とする熟練したフィールドにいる
2. この共同作業がどのように行われるべきかを支配する文書化された手順がありません
3. この共同作業がどのように行われるべきかに不一致がある
4. 不同意の人の一人はあなたのマネージャーです

それはあなたのグループが集まり、どのような基準と実践を採用し、良くも悪くもグローバルに採用することに同意する必要があるように私には聞こえます。なぜなら、**nothing is worse for a product than a team that is constantly at argds.

だから、いくつかの基準に同意するためにあなたのチームを集めてみてください。そして、その会議では、あなたが使っている実践方法を主張してみましょう。そうでない場合は、それはそうである。あなたの仕事は美しいコードを書くことではありません。あなたの仕事は完成品を提供することです。もしあなたの雇用主(あなたのマネージャーによって体現されている)が、あなたのグループの大多数が、あなたが特定の方法でそれを行うことを主張しているならば、あなたは誰ですか？

しかし、それはあなたのチームのほとんどがあなたに同意しているように聞こえるので、これらの議論の間に、あなたのマネージャーは奇妙な一人であることがかなり明らかになるはずです。この人がまだチームのコンセンサスに変更することを拒否した場合、それは私たちがあなたを解決するのを助けることができないことを機能不全です（別のチームに移動することをお勧めする以外）。

残念ながら、彼はあなたのマネージャーであり、あなたは彼が書いて欲しいと思っているようなコードを書いていません。もし彼が管理職なら、ほとんどの開発者が計画しているように 2-3 年で会社を辞めるつもりはないかもしれません。あなたが書いているコードは、あなたの後継者が修正するのが難しくなるようなもので、それがそのような方法で作ったことで彼があなたを厳しく非難している理由です。LOBアプリケーション以上のことを書いているとしたら、私はむしろ驚きです。

私の10年間の開発の中で、真のストラテジー/ファクトリーパターンが必要とされたのは3回だけで、そのうちの2回はジョブからのものです:

• 製品情報を表示するアプリケーションで、いくつかの製品が箱の中の小さな製品の束になっていて、どの工場が製品情報(キーを介して要求された)をビューに変換するために必要かを決定するためにストラテジーを使いました。輝かしいものではありませんが、それは仕事をしました。バグについてのあなたの謙虚な自慢話に合わせていいなら、私の全在職期間中、バグは一度もありませんでした！（1つは私が退職した後に報告されましたが、1つだけでした。(1つは私が辞めた後に報告されましたが、ユーザーのミスであることが判明しました :)
• 出席しているクラスの行き先をユーザーに示すアプリケーションでは、Bing Maps APIとGoogle Maps APIの間で素早くシフトできるようにファクトリーと抽象化を使用しました。これは、どちらにもコストとベネフィットがあり、どちらを使うかの決定が進んでいなかったためです。最終的には、ホームオフィスに聞いたところ、すでに片方のAPIキーを持っていて、起動直前にそのAPIにピボットすることができました。

そして3つ目は、Windowsサーバのサーバ監視を行うプロジェクトです。モニターは（アプリケーションの設定に基づいて）高度に設定可能です。出力の実装は、私が新しいモニターをテストしているかどうかによって異なりますし、IOutputInterfaceは、異なることができる実装としてConsoleOutputとSqlOutputを持っているように、デプロイに行くかどうかによって異なります。仕事は仕事であり、あなたが自分のやり方で物事をやりたいなら、幸せな媒体を見つけようとすることです。仝それにしても、このようなことをしているのか、というと、そうではありませんでした。あなたの個人的なホームプロジェクトは、あなたが望むだけのパターンの山にしてもらいましょう。

簡単な解決策。**

難しい解決策：どんな意見の相違でも、半分はあなたにある。

少し時間をおいて、他のチームの働き方を研究し、自分と相手の間のインピーダンスのミスマッチがどこにあるかを把握する。早めに、そして頻繁に、直接相手と話をする。これをうまくやれば、あなたも相手の懸念や信任状を理解することができるようになり、相手もあなたの意見や経験、気丈な意見を評価してくれるようになります。ここに考慮すべきいくつかの分野があります:

• 品質の高い製品と市場への時間
• 良い製品と良いコード
• スマートなコードと分かりやすいコード
• トップダウンの企業文化とボトムアップのエンジニアリング文化

それがうまくいかない場合は、チーム内の別の役割、会社内の別のチーム、または最終的に別の会社を検討してみてください。

彼らと正面から向き合えば最大の抵抗を受けるぞ マクギリス 私は戦略的にツボを突いた時に 変化をもたらすのに最も効果的だった それには多くの忍耐と屈服が必要だ。私は最初に弱点で圧力を適用する前に、それらに_適応しなければなりません。

あなたの心を空にして、無形である。形のない、水のようなもの。コップに水を入れると、コップになる … 今、水は流れることもあれば、崩れることもある。- ブルース・リー

彼らの話を聞いて、たくさんの質問をしてみてください。**誰かに耳を傾けることは、抵抗するために彼らの欲求を奪う。彼らの思考を動機づけるものを理解してから、彼らの言語を話す。あなたの信念が軸になっているので、現時点では、彼はおそらくあなたの頑固さ、軽蔑とフラストレーションを反映しています。あなたは部下であるので、それはあなたの波長に参加しない彼の選択であり、責任は橋を構築するためにあなたにあります。あなたが彼を扱うように、あなたは自分自身を扱うようになります。彼を思うように、あなたはあなた自身を思うようになります。決してこれを忘れてはならない、彼の中であなたは自分自身を見つけるか、自分自身を見失うことになるからだ。- ヘレンSchucman

詠春拳のマスターは、彼が最も脆弱であるセンターラインを求め、攻撃する前に、彼の相手を描画し、距離を閉じます。勝つためだけにminutiaeを主張しないでください、大きな問題の中心線を見つけて、そこに圧力を集中しています。

私はretoolするか、新しいプログラミングのパラダイムを学ぶことを拒否し、私は私が数えることができるよりも多くの時間を引数 “私はパンチカード以来、ここにいた "のいくつかのフォームを与えられている日常的にエンジニアに対処します。私の推定では 80% の戦いに負けていますが、そのうちの 20% は…おぉ…私は大きな変化を起こしてきました。私は漠然と聞こえるかもしれませんが、これらのキーワードのいくつかでいくつかのgoogleの研究を行うと、あなたは私が言いたいことを得るでしょう。

また、あなたの方法でそれを行うことができます新しいリスプロジェクトに取得しようとします。それが本当にうまくいって、時間やお金を節約できるのであれば、人々はあなたの考え方に回り込んでくるでしょう。新しいプロジェクトがない場合は、会社が持っていると誰も解決するために時間を取ることに興味を持っていない痛みのポイントを解決するために、あなたの空き時間に1つを作成します。

どうすればいいのでしょうか？

ソフトウェア工学では、コードがどれだけうまく書かれているか（あるいは書かれすぎているか）は、常にある程度の解釈（意見）の対象となります。私には、あなたは私があなたの立場になるような手順を踏んでいますが、しかし、最終的にはあなたのマネージャーは光を見る必要がある人です…彼にそれを示し続けてください。

私は、痛みを伴うかもしれませんとして、あなたがやっていることを正確に行い、デザインパターンを使用して投資の見返りを指摘することができますあなたのマネージャーをbadにすることなく、_続けるでしょう。あなたは闘争を続けるように、チーム内のいくつかの他の同盟国を得るために試してみてください。このようにして、あなたはパターンのために話して聞いた唯一の声ではありません。

しかし、いくつかのポイントで、if彼らは拒否して、あなたはこの環境があなたのために右であるかどうかのようにするための選択を持っています。しかし、この環境が自分に合っているかどうかは、いつかは自分で選択できるようになるでしょう。コーディング文化を変えたいのであれば、そのパターンの価値を示すのはあなた次第です。

まず、与えられた情報から誰が正しいのかを判断することはできません。実際、もし私がプロジェクトの監査に呼ばれたとしても、誰が正しいかを判断するのは難しいかもしれません。しかし、私の推測では、ボスはあなたよりも目的をよく知っているのではないかと思います。"どうすれば上司を説得できますか？" 答えは、あなたはおそらくできないということです。最終的には、彼は上司です。私がソフトウェアエンジニアリングで彼の考えを変更するために上司を説得した唯一の時間は、私たちが1年を費やした後、彼が望んでいた方法で書かれていたソフトウェアの信頼性のない部分にパッチを当てた後だった、と私たちは彼に言った、私たちはそれを別の設計することによって以外にそれを信頼性の高いものにすることはできませんでした。

技術的な観点から誰が正しいのかはわかりません - それは、過去から抜け出せなくなったマネージャーかもしれませんし、 誇大広告を盲目的に信じている新しい開発者かもしれません。

しかし、彼はあなたのマネージャーです。そして、それが通常の状態であり、あなたのマネージャーが決定を下すということです。また、成功か失敗かの責任を最終的に負うのは彼であって、あなたではないというのも、通常の状態です。彼には権限があります。そして、彼の言う通り、あなたは彼の権限を疑うべきではありません。彼が正しいかどうかを疑うことはできますが、彼の権威を疑うことはできません。その間、物事が思うように進まないことを考えるのではなく、自分の限界の中でどのようにして最高の品質のコードを作るかを考えてみてください。多くのことは、様々な方法で行うことができます。素直で悪い設計」と「素直で良い設計」があります。後者を目指しましょう。

経験によって、そのデザインパターンによる利益が将来的に可能かどうか、可能性があるかどうかを判断することができます。監督者がそのパターンを知っているにもかかわらず、それを拒否している場合、彼はおそらく、このパターンまたは類似のパターンを適用しても利益を得られない場合を認識しています。時々、経験が規則を矛盾させたり、より可能性の高い解釈をしたりします。

短くてより簡単なコードの方が理解しやすく、大幅な変更にも対応できるという既知の意見があります。

私はペアプログラミングとピアレビューをお勧めします。これは、あなたの同僚があなたのコードをよりよく理解するのを助けるでしょう、あなたはそれを行うようにwhyとhowを説明する必要があるので、事実の後ではなく。