Bank worldでコード設計の労力または遅延を選択する
私は素晴らしい投資銀行で2年間働いてきました。
私は、最適化された良いデザインパターンを尊重し、SOLID原理、デメテルの法則、あらゆる種類の重複コードを回避することを尊重して、コードを最も最適化して作成することを望んで、いくつかの技術プロジェクトを作成しました...
本番環境での配信=>バグがゼロの場合、すべて期待どおりに発生しました。
しかし、私のすべてのコードが読解するには複雑すぎることを正確にするために、大多数の開発者が私にやって来ました。たとえば、「ifとinstanceofを作成して、ポリモーフィズムを忘れて、緊急のプロダクションバグを修正するのが非常に簡単になるようにします」と聞きました。答えたくなかった…….
これらの開発者を知ることはまったく好奇心がなく、優れた設計を理解するための取り組みを拒否します（たとえば、開発者の90％は戦略パターンとは何かを知らず、手続き型コードを作成し、必要なためにoo-designを実行することはありません。 ）、私のプロジェクトマネージャーは、私は本当に間違った方法であり、銀行の世界にとって理想的すぎると私に言った。
何かアドバイスはありますか？本当に良いコードの欲求を維持するべきか、私を大多数の開発者に適応させるべきか、繰り返しますが、私によると、私たちの開発者の仕事のすべての美しさを考慮した設計コードでは本当に面白くありません。
あるいは逆に、彼らは私のコードに適応するための基本的なOO原則とベストプラクティスを学ぶべきですか？
私のプロジェクトマネージャーは、私は本当に間違った方法であり、銀行の世界にとっては理想主義的すぎると私に言いました。
GTFO！
彼らを残して同情する時間。なんでファックするの？あなたは彼らの無能なスタッフと一緒に長期的に彼らにお金がかかることを知っています。これは技術的な議論のゲームではありません。これは政治についてです。他の開発者またはGTFOをトレーニングしてもらいます。あなたが十分な政治的重みを持っていないなら、GTFO！より良い慣行を持つ会社を検索します。
そこにとどまる唯一の理由はあなたの頭痛の十分な補償です。ですから、彼らは平均以上の方法でGTFOに支払うほうが良いです！ソフトウェア開発者としても成長できるとは思えません。私たちの職業の成長は、主にあなたよりも上手でベストプラクティスを奨励する人々と協力することによって達成されます。そしてあなたが上手であるほど、気にする企業にとってあなたの市場価値は高くなります。
ええ、私はこれが私の通常の答えの1つではないことを知っていますが、実際には、この会社GTFOで政治ゲームをプレイできない場合は。
何かアドバイスはありますか？本当に良いコードの欲求を維持するか、私を開発者の大多数に適応させるべきか、繰り返しますが、私によると、私たちの開発者の仕事のすべての美しさを考慮した設計コードでは本当に面白くありません。
私は次善のソリューションを提供することを望んでいる会社には働きません。私はソフトウェアに私の名前を刻みたいです。誇りに思っています。 OOパラダイムに基づく言語で手続き型アプリケーションを作成することはありません。高品質のソフトウェアを信じており、そうでない場合はGTFOを利用します！お金"。
タフなスポット。私はあなたが2つの方法を並行して進むことができると思います、あなたの主張を立て、妥協する意志を示す：
これはお金についてです。実際の開発者の仕事と同じですが、銀行の環境を重視しているため、これはさらにうまく機能するはずです;）。あなたのスタイルがお金を節約することを彼らに示してください。設計により、要件の変更を簡単に行う方法の例を見つけてください。他のコードを探してみてください（ここではあまり積極的になりすぎないようにする必要がありますが、コードのスタイルを比較するためのものです）。すぐに壊れる可能性が高く、必要な方法を示してください。あなたのコードはそもそも品質が高いので、このような問題に注意してください。
これはお金についてです。実際にコーディングスタイルに費用がかかる場合はどうなりますか？他の人々があなたのコードを理解しようとするより多くの時間を適切な設計によって保存されているものよりも費やすなら、それはうまくいくかもしれません。あなたは技術的に正しいことをしているかもしれませんが、それでもチームの努力に積極的に貢献していないかもしれません。また、OOP設計をやり過ぎることも可能です。私は「良い設計は美しい」という側面であなたと一緒にいますが、私はここで彼らの視点と方法を認識させようとしています彼らは実際には彼らの観点から正しいかもしれません。前のポイントと並行して、あなたがそれをやり過ぎた場所を見つけてください。それはあなたに操縦する余地を与えます：わかりました、私はあちこちでもう少し実用的であることができますでも、見てください、このコードが本当に優れている場所もあります。また、他の人の立場に身を置こうとする場合に、より協調的な考え方に入るのに役立ちます。
しかし、私のすべてのコードが理解を読むには複雑すぎることを正確にするために、大多数の開発者が私にやって来ました
彼らが正しいかもしれないということはあなたにまったく起こりましたか？
私は彼がエレガントであると述べたコードを書くことに多くの努力を払った誰かと協力しました。彼は多くの時間を他の人の作品をエレガントではないと非難しました。コードの保守が必要になると、彼のコードは私が変更することを選択したコードではありません。それは非常に正確で厳密であり、それを変更することは非常に危険に満ちています。
ここでおもしろい言葉は「複雑」です。 complexと記述できるコードは、特に優れたコードと記述されることはほとんどありません。
ビクトリア朝時代の家具メーカー（少なくとも、現在でも私たちの仕事を目にするもの）は本物の職人でした。彼らが作ったものは、機能的で美しく、巧妙に細工され、生涯続くように設計および構築されました。しかし、過去150年の間に世界は変化しました。ダイニングルームのテーブルを購入するときに、より安い代替品がより商業的に実用的である場合、多くの人々はそのような職人技に対して支払う準備ができていません。
多くのプログラマーは古くからの職人になりたいと願っていますが、残念ながら商取引ではこれが常に起こるわけではありません。あなたには選択肢があり、適応するか去るかです。職人を求めている企業もありますが、ほとんどが機能し、安価で、現在機能している製品を求めている企業に比べて圧倒的に多数です。
あなたがほとんどの商用ソフトウェア開発に適していないという私へのヒントは、「本番環境での配信=>バグがゼロのとき」です。 Nasaでさえスペースシャトルでそれを達成しませんでした。
詳細に注意を払い、したがって初期費用が許容される可能性が高い唯一の場所は、レベル1の生命に関わるシステムです。アビオニクス/航空宇宙、自動車、軍事、医療。
雇用主の変更などの抜本的な措置を講じる前に、プログラマー以外のプログラマーに対して、あなたのコーディング方法が会社にとってより優れている理由を説明し、時間とお金を節約するための独自の能力を向上させたいと思います。また、デザインパターンのためだけにデザインパターンを適用していないことを確認してください。KISSとYAGNIのルールも適用しましたか？（OK、戦略パターンと多態性はロケットサイエンスはありません。同僚に少し時間をかけてそれらを適応させて説明してくださいなぜあなたはそのアプローチを選択します。）
まず、あなたのやり方が本当に良いことを確認します。オブジェクト指向のコードは非常に優れている場合がありますが、隠れた副作用の悪夢にもなり、すべてのアクションでいくつかの異なるクラスが必要になる場合があります。
InfoQに行ってRich Hickeyの講演 "Simple Made Easy" をご覧ください。
私の会社では、 Clean Code Developer に基づいて一連のワークショップを実施しました。目的は、開発者がソフトウェア設計の原則（前述のとおり）、プログラミング手法などについて学び、プロジェクトと自分の仕事。
実際のプロジェクトの実際の例も議論されました。参加者からのフィードバックはAFAIKは非常に肯定的でした。ただし、実際の利益を測定することは困難です。
これらのワークショップへの参加は、一部は企業主催の時間であり、一部は参加者自身の空き時間でした。学習に関心がなく、単に仕事をして家に帰りたいと思う同僚には連絡しませんが、自分の仕事に関心のある他の人にとっては、これは興味深いかもしれません。
問題は、あなたが間違った場所で働いているということです。あなたは非常に学問的な傾向のあるプログラマーのようです。あなたがいる環境ではうまくいかないでしょう、そしてあなたとあなたの「あまりに複雑な」コードを取り除くためにいくつかの言い訳が発明される可能性が高いです。あなたが自分で合意するか、彼らがあなたを解雇するのに十分な裏表紙の証跡を持っているかのいずれかになるまで、あなたはジャンクの割り当てや悪いパフォーマンスレビューなどを与えられるかもしれません。
学業を重視する職場を見つけることをお勧めします。彼らはそこにいます。実用的なものと学問的なものの境界にあるものもあります。そのような仕事は、他の人たちが彼らの手綱を手助けするのを助けながら、あなたのアプローチにいくつかの混乱を招くことができるので、あなたの最良の選択肢かもしれません。
あなたが絶え間ない闘争なしにそこで働き続けることを望むなら、あなたは少しでも譲らなければならないでしょう。すべて手続き型の開発グループは、すぐには多態性を受け入れません。 O-O方式で設計できない場合もありますが、コードから学習できます。彼らはあなたのコードのいくつかが維持しやすいことを感謝するかもしれません。
補足として、好みに合わせることが重要だと思う場合は、インタビュープロセス中に質問して、どの開発プロセスとコーディング方法論が使用されているかを確認する必要があります。
プログラミングは、それ自体のためではなく、目的を達成するための手段として考えられていることを覚えておいてください。使用しているすべての製品とサービスについて考えてみてください。その下のコードがエレガントに作成されているかどうかを検討するのに多くの時間を費やしていますか？それとも機能するので、単にそれらを高く評価しますか？あなたが情熱を注いでいる業界または原因を見つけ、それからその組織を見つけて、includeプログラミングというソリューションだけでなく、それらを提供します。問題はさまざまな方法で見事に解決できます。
緊急事態が発生します。あなたは完璧ではなく、彼らの手はある時点でコードを台無しにするでしょう。休みを取らない限り、GPが確認するように、健康に良くありません。そして、貧弱なコードを発行する可能性が高くなります。
あなたのコードmayより高い品質があります（証明されていない事実）彼らはポリシーを持っています。 （地獄の事実として確実に）
ポリシーに従うように警告されており、ポリシーに従わなかった場合の責任があります。緊急事態に。銀行アプリケーションで。つまり、もしあなたの目標が貧困で終わり、刑務所にいるなら同じ結果を得るための多くのよりおもしろい、より意味のある方法を見つけることができます。
ただし、セルメイトは喜んで元同僚の好奇心の欠如について取り乱していると聞きます。
（そして、あなたの会社はおそらくOO設計に対して内部ポリシーを持っていませんが、あなたのコードを修正しようとする不器用なCOBOL訓練を受けたエンジニアは薄い空気からいくつかを作り上げます、そして私見、最悪のシナリオでは、40％の確率でクリティカルヒットを記録します）