銀行の世界でコード設計の努力または怠lazを選択する

私は素晴らしい投資銀行で2年間働いてきました。

私は、最適化されたコードを作成し、適応された優れたデザインパターン、ソリッド原則、デメテルの法則を尊重し、あらゆる種類のコードの重複を回避することを望んで、いくつかの技術プロジェクトを作りました

本番環境での配信=>バグがゼロの場合、すべてが期待どおりに行われています。

しかし、大部分の開発者は、すべてのコードが読解には複雑すぎることを正確にするために来ました。たとえば、「ifおよびinstanceofをいくつか作成し、ポリモーフィズムを忘れて、緊急の生産バグを修正するのが非常に簡単になるようにします」。私は答えることを好まなかった......

これらの開発者はまったく好奇心がないことを知っており、優れた設計を理解する努力を拒否しています（たとえば、90％の開発者は戦略パターンとは何かを知りません。 ）、私のプロジェクトマネージャーは、私は本当に間違ったやり方であり、世銀の世界にとって理想主義すぎると言った。

私に何をアドバイスしますか？本当に良いコードの欲求を維持するか、そうである開発者の大多数に私を適応させるならば、私によると、私による開発者の仕事のすべての美しさである設計コードによって本当に面白くないです。

それとも逆に、基本的なオブジェクト指向の原則とベストプラクティスを習得して、自分のコードに適応する必要がありますか？

私のプロジェクトマネージャーは、私は本当に間違ったやり方であり、世銀の世界にとって理想主義すぎると言っていました。

GTFO！

それらを離れて同情する時間。なぜ性交する必要がありますか？無能なスタッフと長期的に見ればお金がかかることはご存知でしょう。これは技術的な議論のゲームではありません。これは政治についてです。彼らに他の開発者やGTFOを訓練してもらいましょう！あなたが十分な政治的重みを持っていないなら、GTFO！より良い慣行を持つ会社を検索します。

そこにとどまる唯一の理由は、あなたの頭痛に対する適切な補償です。したがって、彼らは平均またはGTFOをはるかに上回ります！ソフトウェア開発者としてもあなたがそこで成長できるとは思いません。私たちの職業の成長は、主にあなたよりも優れており、ベストプラクティスを奨励する人々と働くことによって達成されます。そして、あなたが良いほど、気にする企業にとってのあなたの市場価値は高くなります。

ええ、私はこれが私の通常の答えの1つではないことを知っていますが、実際、この会社で政治ゲームをプレイできないなら、GTFOです。

私に何をアドバイスしますか？本当に良いコードの欲求を維持するか、そうである開発者の大多数に私を適応させるならば、私によると、私による開発者の仕事のすべての美しさである設計コードによって本当に面白くないです。

最適ではないソリューションの提供を希望する会社では働きません。ソフトウェアに自分の名前を刻みたい。私はそれを誇りに思います。私は、OOパラダイムに基づいた言語で手続き型アプリケーションを作成しません。私は高品質のソフトウェアを信じており、もし会社がそうでなければ、GTFOをやる！あなたが十分なお金を持っていることを願っています。

タフスポット。私は、あなたの主張に立ち、妥協する意志を示す、2つの方法を並行して進めることができると思います

• これはお金についてです。実際には開発者の仕事と同じですが、銀行の環境を重視しているので、これはさらにうまくいくはずです;）。あなたのスタイルがお金を節約することを見せてください。設計が理由で要件の変更が本当に簡単に行える方法の例を見つけてください。他のコードの一部を見つけてみてください（ここではあまり攻撃的にならないようにしなければなりませんが、コードのスタイルを比較することです）。そもそもコードの品質が高いため、このような問題に注意してください。

• これはお金についてです。実際にコーディングスタイルにお金がかかる場合はどうでしょうか？他の人が適切な設計によって保存されているものよりもあなたのコードを理解しようとしてより多くの時間を費やすなら、それはうまくいくかもしれません。あなたは技術的に正しいことをしているかもしれませんが、それでもチームの努力に積極的に貢献していません。また、OOP設計をやり直すこともできます。私は「良いデザインは美しい」という側面であなたと一緒にいますが、ここで彼らの視点と彼らが実際に彼らの視点からどのように正しいのかをあなたに気付かせようとしています。前のポイントと並行して、あなたがそれを上書きした場所を見つけようとします。これにより、操作の余地があります。わかりました、あちこちでもう少し実用的になることができますが、このコードが本当に優れているところもあります。

しかし、大部分の開発者は、私のすべてのコードが読解には複雑すぎることを明確にするために私のところに来ました

彼らが正しいかもしれないということは、あなたにはまったく起こりましたか？

私は、彼がエレガントだと表現したコードを書くことに多大な努力をした人と仕事をしました。彼は他の人の仕事をエレガントではないと非難しました。コードを維持する必要が出てきたとき、彼のコードは私が修正することにしたコードではありません。それは非常に正確で厳格なので、それを変更することは非常に危険です。

ここで言及する興味深い言葉は「複雑」です。複雑であると表現できるコードが、特に良いと表現されることはめったにありません。

ビクトリア朝時代の家具メーカー（少なくとも、今日でもその仕事を見る人たち）は本物の職人であり、彼らが作ったものは、機能的で、美しく、巧みに作られ、設計され、生涯続くように作られました。しかし、過去150年間で世界は変わりました。食堂のテーブルを購入する際に安価な代替品がより商業的に実用的である場合、多くの人々はそのような職人技の代価を支払う準備ができていません。

多くのプログラマーは、残念ながら古くからの職人になりたいと思っていますが、これは常に起こり得ないことです。あなたは、適応するか、去るかを選択できます。職人を求めている企業もありますが、ほとんどが機能し、安価で、現在の製品を求めている企業に圧倒されています。

あなたがほとんどの商用ソフトウェア開発に適していないという私へのヒントは、「本番環境での配信=>バグがゼロの場合」です。Nasaでさえ、スペースシャトルでそれを達成していませんでした。

詳細に注意を払い、初期コストが許容される唯一の場所は、レベル1のライフクリティカルなシステムです（例：アビオニクス/航空宇宙、自動車、軍事、医療）。

問題は、間違った場所で作業していることです。あなたは非常にアカデミックに傾倒しているプログラマーのようです。あなたがいる環境ではうまくいかず、あなたとあなたの「複雑すぎる」コードを取り除くためにいくつかの言い訳が発明される可能性が高いです。あなたは自分で同意するか、あなたを解雇するのに十分な裏表紙の証跡を持つまで、ジャンクの割り当てやパフォーマンスの悪い評価などを与えられることがあります。

あなたの学問的価値を大切にする職場を見つけることをお勧めします。彼らはそこにいます。また、実用的なものと学問的なものとの境界にあるものもあります。そのような仕事はあなたの最良の選択肢かもしれません。なぜならそれはあなたが他の人たちの手綱を抑えるのを助けるようにあなたのアプローチにいくらかの混乱を招くことができるからです。

雇用主を変更するなどの抜本的な対策を講じる前に、あなたのエグゼクティブのような非プログラマーが、なぜあなたのコーディング方法が会社にとって優れているのか、時間とお金を節約できるのかを説明する能力を向上させようと思います。また、デザインパターンのためだけにデザインパターンを適用していないことを確認してください。KISSとYAGNIのルールも守っていますか？（OK、戦略パターンとポリモーフィズムはロケット科学ではありません。同僚に適応する時間を与え、そのアプローチを選択する理由を説明してください。）

私の会社では、Clean Code Developerに基づいて一連のワークショップを実施しました。その目的は、多忙で期限があり、不正な妥協点がある通常の日常業務以外のフォーラムを作成することでした。自分の仕事。

実際のプロジェクトからの実例も議論されました。参加者からのフィードバックは非常に肯定的でした。ただし、実際のメリットを測定することは困難です。

これらのワークショップへの出席は、一部は企業主催の時間であり、一部は参加者自身の余暇でした。学習を気にせず、単に仕事をして家に帰りたいだけの同僚に連絡することはありませんが、自分の仕事に興味がある他の人にとっては興味深いかもしれません。

まず、あなたのやり方が本当に良いかどうかをチェックします。オブジェクト指向コードは非常に優れている場合がありますが、隠れた副作用の悪夢にもなり得、すべてのアクションはいくつかの異なるクラスを必要とします。

さらに良いのはInfoQに行き、Rich Hickeyの「Simple Made Easy」に関する講演をご覧ください

絶え間なく苦労せずにそこで働き続けたい場合は、少し手を加える必要があります。すべて手続き型の開発者グループは、すぐにポリモーフィズムを受け入れません。彼らはオブジェクト指向で設計することはできないかもしれませんが、彼らはあなたのコードから学ぶことができます。彼らはあなたのコードのいくつかが保守しやすいことを評価するかもしれません。

補足として、面接プロセス中に質問をして、好みに一致することが重要だと思われる場合は、どの開発プロセスとコーディング方法が使用されているかを確認する必要があります。

緊急事態が発生します。あなたは完璧ではなく、彼らの手はある時点であなたのコードを台無しにします。GPが確認するように、決して休まない限り、それは健康に良くありません。そして、劣悪なコードを出力する可能性が高くなります。

コードの品質は向上する可能性がありますが（実証されていない事実）、ポリシーがあります。（地獄の事実として確認してください）

ポリシーに従うよう警告されており、ポリシーに従わなかった場合の責任があります。緊急事態。銀行のアプリケーション。つまり、あなたの目標が貧しい状態で終わり、刑務所に入ったら、同じ結果を得るためのもっと楽しくてもっと意味のある方法を見つけ出すことができます。

あなたのセルメートは、あなたの元同僚の好奇心の欠如についてとりとめのないことを聞いて喜んでいるでしょう。

（再び、あなたの会社はおそらくOO設計に対する内部ポリシーを持たないでしょうが、コードを修正しようとする不器用なCOBOLトレーニングを受けたエンジニアは、薄気味悪い部分を補ってくれるでしょう。クリティカルヒットを獲得する確率は40％です）

プログラミングは、それ自体のためではなく、目的を達成するための手段として考えられていることを忘れないでください。使用するすべての製品とサービスについて考えてください。下のコードがエレガントに作られているかどうかを検討するのに多くの時間を費やしていますか？または、それらが機能するだけで、それらに感謝しますか？興味のある業界や原因を見つけて、それを使って組織を見つけ、それだけでなくプログラミングを含むソリューションを提供します。問題はさまざまな方法で見事に解決できます。