問題を解決したい人が、公式のインターフェースをスキップして、基礎となる実装の詳細に直接アクセスしたい場合、私は時々苦労します。
彼らは、そうすることで問題をより迅速に解決できると主張しています。そうすることで、アーキテクチャがより緊密に結合され、新しい要件が出現しても変更が困難になると私は主張します。
現在の設計に費やされたすべての作業、設計の哲学、および柔軟性の価値、壊れやすいコードを維持および変更しようとするコスト、カプセル化とデータの隠蔽、階層化されたアーキテクチャの価値、および堅牢であることを指摘します。仕様の小さな変更は、コードの小さな変更につながります。そして彼らは「しかし、これはもっと簡単だろう」と言います。
これらの人々をどのように扱いますか？
バグを修正するいくつかのレガシーコードに取り組んでもらいます。これは、私が知っているほとんどの人が、これらの本当に価値のある教訓を学んできた方法です...難しい方法です.
近道をするのは間違った経済だと彼らに納得させてください。
最初のコーディング作業は、最初の開発作業の 30% 未満であり、(私の経験では) プロジェクト全体の作業 (メンテナンスを含む) の 10% 未満であることを説明してください。
彼らが納得しないままで、あなたにそうする権限がある場合は、あなたのやり方でやるように伝えてください。権限がない場合は、何もしません。最終的にあなたの上司は、彼女が何か価値があるなら、これを認識し、あなたは権威ある立場に立つでしょう.
私は実際にこれについて反対意見をとることを嫌いますが...
ヴァン・ヘイレン（決まり文句を引用）を引用すると、「すべてに時間と場所があります」。私は確かにひどく書くことを主張していませんが、時々、あなたはただそれを成し遂げる必要があり、頑強で永続的なものとハッキングされた/文書化されたものの間の幸せな媒体を見つける必要があります。（文書化された部分は、2つの面で特に重要です。1つは、実行していることが単にそれを実行するために実行されており、特定のショートカットを使用していることを明確に示していることです。2つは、大まかなアイデアです。問題に取り組むためのより正しい方法が何であるかについて。
プログラマーとして、私たちはしばしば完璧なコードを書くように努めます（まあ、私たちの中にはそうする人もいます）、そして時々全体像を見失うことがあります-速くて緩くプレイすることが（レベルで）大丈夫かもしれない理由はたくさんありますコードを使用して、将来の影響を最小限に抑えます。
これを正当化として使用しないでください。もちろん、80/20の法則がここに適用されます。ほとんどの場合、これらの線に沿ったショートカットを絶対につぶしたいと思うでしょう。でも時々...
「簡単」いつ？さて、すべてが流動的な状態にないときは？それとも、顧客の要件が変化し、もはやソリューションではない「ソリューション」を手に入れた 3 か月後ですか?
私は構造とルールのための構造とルールにはあまり興味がありませんが、A) 誰がボートを運転しているか、B) ルールとは何か、C) なぜこの方法を選択したのかを知ることは良いことです.
私のショップでは、コードを書き直す必要はありません。大量のものを台無しにしてハードコーディングしたり、問題に対する脆弱な「解決策」を作成したりしたからです。より柔軟なアプローチに従うことは、後で多くの要件の変更によって物事がひっくり返ったときのフラストレーションを軽減することに人々が気付くと、それほど難しくない傾向があります。私たちは通常、「今日必要」ではなく「長期」のためにコードを作成するため、設計には理由があり、設計には同じ理由があります。
私は人生の 1 週間 (連続 7 日間) をモジュールの書き直しに費やしました。7 日間の厳しい時間、1 日 10 ～ 12 時間、正しい方法でそれを行い、ゲームの後半、スーパー ボウルを観戦していた可能性があるとき。その悪臭。私はそこで教訓を学びました。あなたの「友達」も、そのような目を見張るものを経験する必要があるかもしれません.
頑張ってください！
あなたはそれらの類推を試すことができます....
チェスのルールはとてもシンプルです。子供に「馬はこう動く」「城はこう動く」などと教えることができます。
それだけのことを知っていれば、チェスをプレイしておそらく楽しい時間を過ごすことができますが、ゲームについてより深い知識を持つ誰かが毎回あなたと一緒にボードを拭いてくれます。彼らがどのようにやっているのかわからないので、あなたはひどく殴られて、もう楽しくさえありません.
同じ原則がプログラミングにも当てはまります。言語の構文といくつかの単純なデータ構造を知っていれば、動作するプログラムを作成するのに十分ですが、複数のリリース サイクルに耐えなければならない大規模なアプリケーションではうまくいきません。
チェスには、開始点、攻撃戦略などが設定されています。デザイン パターンがあります。
最善の方法は、おそらく彼らを管理職に昇進させて、それほど大きな損害を与えることができないようにすることです.
見せる！「しかし、これは簡単だろう」で小さなモジュールを実行させます。正しい方法でスタイリングします。次に、要件に 2 ～ 5 個の変更を加えるよう依頼し (変更を行うのは彼らでなければなりません)、変更の実装について時間制限のあるコンテストを行います。1日か2日かかるかもしれませんが、彼らはそれを手に入れます. そうしないと、新しいプロジェクトやタスクのたびに同じ議論をすることになります。
私は約 5 年前に大きくて複雑なシステムを設計しました。私は次の 5 年間、野蛮人が私のアーキテクチャを汚すのを防ぐために、「私の」システムに影響を与えるすべてのプロジェクトに自分自身を注入しました。絶え間なく絶え間なく圧力をかける限り、建築物をきれいに保つことができましたが、負け戦を戦っていました。理由は次のとおりです。
1) ほとんどの人は、今日仕事をやり遂げたかどうかで判断されます。3 年前にプロジェクトを時間通りに完成させるために手抜きをしたからといって、だれも叱責されたことはありません。一方で、多くの人がプロジェクトを時間通りに完成させなかったことで叱責されています。
2) コード、アプリケーション、またはユーザーなどに対する所有権があるため、システムを整頓したい場合があります。多くの人は所有権を持っていないため、喜んで何かをハックします。彼らはそれで行うことができます。馬を水に導くことはできますが、世話をさせることはできません。
3)全員にコードを適切に維持するよう説得した場合、新しい人々が参加し、物事を正しく行う方法を教える必要があります。そのため、成功したとしても、常に新しい敵と同じ戦いを繰り広げているため、失敗しているように感じることがあります.
4) あなたは実際には間違っているかもしれません。Microsoft が MS-Paint を堅牢で保守しやすいものにするために 2 倍のプログラマー時間を費やすことは、経済的に理にかなっていますか? 醜いハッキングされたシステムで十分な場合があります。ほとんどの優れたプログラマーはこれを理解するのに苦労しますが、これは通常、彼らが優れたプログラマーであるためです。
5) 物事を一緒にハッキングすることにひねくれた喜びを感じている人がいると断言できます。それは、より速くできるか、それを理解できるのが自分だけであるか、ルールを破る子供じみた必要があるためです。これらの人々と議論することはできません。彼らとの議論に時間を費やすほど、プロジェクトの締め切りが近づき、とにかく何かを一緒にハックすることを余儀なくされます.
6) 彼らよりもあなたの方がシステムをよく理解している可能性は十分にあります。あなたにとって醜いハックのように見えるものは、システムに精通していない人にとっては「軽く踏む」ように見えるかもしれません. または、コードを堅牢にするための余分な努力により、プログラマーは、これまで経験したことのない、理解できない問題から保護されます。リターン コードをチェックしなかったため、何か問題が発生するまでリターン コードのチェック方法を学習しません。その時点で、それは「余分な作業」ではなくなり、「必須の作業」になり始めます。
小規模でタイトな開発チームであれば、それは可能です。しかし、組織が大きくなればなるほど、成功する可能性は低くなります。250 人の IT ショップに、物事を迅速に行うことよりも、物事を正しく行うことを重視してもらうことができれば、あなたの説得力は伝説的です。
問題は、ほとんどの人が、最も基本的な概念とドラッグ アンド ドロップ スタイルの開発以外のソフトウェア設計についてさえ知らないことです。すべての最高の新しい概念と技術について研究し、自分自身を教育する開発者 1 人に対して、家に帰って PC を見ない人が 10 人います。あなたは彼らに教えなければなりません。
http://catb.org/jargon/html/L/LART.html SCNRなどpp;）
読むように伝えてください (決して読むつもりではありません) カプセル化理論: http://www.edmundkirwan.com/