厳格か実用的か？

私は、ソフトウェアの開発が（とりわけ）自分自身に常に質問するプロセスであることを認識し始めています。コードの品質、懸念の分離、依存関係の最小化に関する質問...

しかし、主な質問は、精神病院に行かずにどこまで行けるかということです。

私は新しい仕事に応募しています。昨日、将来の雇用主と一緒にプログラミングの能力をテストしたいと考えていました。演習の1つは、このコードの機能を説明することでした。私は、彼らが開発するアプリケーション（vb.netのwinforms）のコードをいくつか試しました（病院の管理アプリケーションです）。これは、彼らが物事にどのようにアプローチするかを実際に見る機会を与えてくれました。

いくつかの例：

• どこかで見ました：[ここにサブルーチンの名前を挿入]を呼び出します->私は打たれました：それはVB6からのものではありませんか？
• それらには、ado.netを使用する個別のデータレイヤーがありますが、調べなければならない1つのメソッドは、呼び出し元レイヤーにデータセットを返します。そのため、データ層を分離するかどうかに関係なく、アプリケーションはado.netに関連付けられます（別のデータアクセスアプローチに切り替えない場合は問題になりません）。
• そのデータセットは現状のままで読み取られるため、データ中心のアプローチです（もちろん、「Patient」や「LabAnalysisRequest」などのクラスに含めることができるロジック/動作を議論することができます。
• また、文字列連結によるsqlクエリの構築を見たことがあると思います。
• ストアドプロシージャを使用します（私にとって、これはロジックの分散です）
• ビュー/コントローラーについての言及はありません：それはすべてフォーム駆動です
• 私が見た最もいことは：

      TestEnvironment.IsTestingの場合
         someVar = [ハードコーディングされた値]
      そうしないと
         someVar = [動的に取得した値]
      終了する場合
      [ここの関数の残り]
  

それはすべて、私が学校で学んだこととはまったく異なります：（永続性にとらわれない）ドメイン層、永続化層、プレゼンテーション層、ユニットテスト、...

だから私は私の質問を言い換えます：どのように基本的または独断的である必要がありますか？プログラマーはどの程度まで自分の原則に固執するべきでしょうか、それとも仕事をするコードを書くべきでしょうか？

それはあなたの質問に直接答えないことは知っていますが、これはコメント以上の価値があると感じています：

就職面接をするとき、あなたは彼らがあなたに面接しているのと同じくらい彼らに面接している。インタビューをクロールするものとして見ている習慣を破り、何かを提供してくれるように懇願してください。彼らはあなたをチェックアウトしますが、あなたもそれらをチェックアウトします。彼らはあなたを好きではない場合、彼らはあなたを雇うことはありません。それらが気に入らなければ、そこで働きに行かないでください。

はい、業界では、厳しい締め切り、リソースの不足、金銭的な制約により、バックグラウンド、スキル、情熱が異なる3ダースの開発者によって10年前のレガシーコードベースがハッキングされてきました。あなたが（それが）学んだはずの方法を見てください。いくつか譲歩する必要があります。しかし、何個、どこで線を引くかは、あなた次第です。
もちろん、あなたが行う譲歩が少ないほど仕事を見つけるのは難しくなります。しかし、彼らはもっと楽しいかもしれません。

FWIW、私はこれまでに（業界で10年以上）多くの開発者（最大30人の開発者が最も多く、12の規範でした）の大企業で働いたことはありません。会社。子供を飢えさせないように十分なお金を稼ぐ限り、私は大企業で小さな歯車になりたくありません。私がしなければならないのは、残りのギアと同期することだけです。
彼らが私にパスしたかったテストを見て、私は求人を断りました。私はC ++の開発者であり、多くのC ++テストがあり、それらは足の爪を嫌悪感に陥れます。そして、風車との戦いに時間を費やしたくはありません。
また、インタビューで異なっていると言っても、彼らのプログラミング哲学（短期目標、来年は気にしない）が私の能力（長期コードの安定性）に合わなかったので、数ヶ月後に仕事を辞めました。

仕事をするだけのコードを書かないでください。しかし、あなたの教義を同様に喜んで調べてください。あなたが学校でそれを学んだからといって、それが現在の思考、あるいは有効な思考であることを意味するわけではありません。ソフトウェア設計のライフサイクルは、プログラミングがビジネスの世界により反応する必要があるため、時代遅れになります。部品が時間の許す限り交換されたため、時々、ぎこちなくリンクされたソフトウェアソリューションがぎこちなくリンクされます。

企業のコーディングライフスタイルにどの程度適合するかを判断するために、私がまとめた問題のリストを以下に示します。

1. リファクタリングし、コードベースを最新の状態にするために時間を確保することをどの程度重視していますか。彼らがコードベースの更新をどのように見るかは、あなたがどれだけうまくフィットするかを決める重要な要素です。
2. 社内でコーディングする代わりに、サードパーティを購入する頻度。
3. 彼らはオープンソースソフトウェアについてどう思いますか。彼らは、コードを変更する柔軟性を持っていることに気付いていますか。サードパーティを購入するのと同じように見ていますか。
4. 特定の抽象化レイヤーで作業します。インターフェイスするチームがあなたのインターフェイスを決定しますか？インターフェースのどのレイヤー/チーム/サイドが意思決定においてより強力です。
5. 監督が決定を下す際にプログラマーにどれだけ耳を傾けますか。プログラマーが赤旗を投げたとき、監督者は停止して決定を確認します。
6. 管理経験のあるプログラマーを検討していますか？彼らは自分の経験をどのように見ていますか？彼らの経験は有効ですか？彼らは時代遅れの経験が意思決定に影響を与えているのでしょうか？
7. コードベースはどの程度粘着性がありますか？
8. プログラミングツール（IDEなど）を更新する頻度

これらの質問に対する答えは、あなたのドグマに合っているかどうかを確認するよりも、プログラミングライフスタイルをどのように評価するかによく合っています。

ドグマは必然的に壊れます（Xを更新する時間がありません）。ただし、優先順位によって、そのスタイルと意思決定との衝突の程度が決まります。

全体の一部としてこれを比較検討する必要があると思います。私は最初の仕事の1つが、オブジェクト指向のC ++をやっていると言ったグループの役職だったことを思い出します。

彼らの自己評価は間違っていました-彼らはやや分厚いCをしていました。それはまだ本質的に非常に機能的に設計されていたので、printfとgetfや私が学んだことのない他のCメカニズムを学ぶためにC本を手に入れなければなりませんでした。チームの誰もCが自分のコードを好きであることに気づいていないという事実は、この「C ++デザイン」がどれほど落ちたかを指摘しています。当時の私の目標はオブジェクト指向開発を行うことでした。

しかし、最終的には、チームに固執したことを嬉しく思います。彼らは非常に頭の良い人たちのダイナミックなグループであり、私はたくさんの難しい問題で足をぬらしました。チームが機能分野で行っていた仕事は素晴らしかったし、私は今でもその製品とその仕事の経験をとても気に入っていると思う。より良い-私は今でもそれらの人々のいくつかと仕事をしています（後にいくつかの会社）、彼らはまだインスピレーションであり、私たちはまだ良い仕事をしています。

コーディング言語のベストプラクティスの完全な実装は、優れた仕事の経験や優れたチームの成功または失敗だとは思いません。品質、チームには適切な労働条件（ジョエルテストなど）があり、チームは賢く物事を成し遂げる人々でいっぱいであり、実装の完成度は二次的です。良い仕事、良い人、良い労働条件などの要素を取り除いてください-そして、コードが奇妙に組み立てられているかどうかに関係なく、それを維持する価値はありません。

どれほど基本的か独断的か？プログラマーはどの程度まで自分の原則に固執するべきでしょうか、それとも仕事をするコードを書くべきでしょうか？

ここで覚えておくべき最も重要なことは、あなたの目的は何ですか？

ほとんどの企業では、人生の目的は完璧なコードを書くことではありません。あなたの目的は、ユーザーに価値を提供することです。通常、優れたコードを記述することは、メンテナンス、トラブルシューティング、開発も容易な優れた製品を提供するための最良の方法です。

優れたコードは、優れたROIが得られる場所に適用する必要があるツールです。

いくつかの例：

1. API、特にビジネス層のAPIの設計とコーディングに多くの時間を費やしていました。他の多くのプログラマーがそれらを使用する予定です。適切に設計されていれば、多くの時間と問題を節約できます。
2. プレゼンテーション層のルールを少し緩和します。そこで、より多くの機能を追加するために、コードの「完全性」を犠牲にする傾向があります。

結論として、原則を持っている必要がありますが、価値よりも害をもたらすような原則を破るのに十分な柔軟性も必要です。

私は数年間電子商取引の小売業者で働いていました。私がそこで始めたとき、彼らの内部アプリケーションのコードはすべてMS Access用のVBで書かれていましたが、控えめに言っても恐ろしいものでした。私は3人の開発者からなるチームを持っていましたが、今後数年間でこれを適切なVB.Netアプリケーションに置き換えました。

しかし、私の雇用予算は非常に限られていたので、私はジュニアプログラマーしか買う余裕がありませんでした。そして、もちろん、彼らが作成したコードはそれほど素晴らしいものではありませんでした。しかし、それは機能し、同社は毎日これらのアプリケーションを使用して収益を上げていました。

そして、私は仲間と働き始めました。OOD、データベース設計、MVC、およびC＃の少しのトレーニング。そして、長年にわたって状況は改善されました。4年後に辞めたとき、コードベースはまだ素晴らしいものではありませんでしたが、始めたときよりも100倍優れていました。

あなたが説明するような状況は、多くの場合、利用可能なリソースで間に合わなければならない結果です。私たちは理想的な世界に住んでいません。同時に、これは実際に変化をもたらす素晴らしい機会です。

ところで：これらのアプリケーションの一部はまだ使用されており、約3年前とほとんど変わらず、まだ収益を上げています。

あなたの原則を守ることはとても重要だと思います。与えられた制約の範囲内で可能な限り最高のコードを生成するよう常に努力する必要があります。ただし、原則のリストに「悪いコードを読んだり変更したりしてはならない」と追加すると、仕事を見つけるのが非常に困難になります。プログラマの50％がクラスの下半分を卒業したことを思い出してください。一人のチームであっても、「先月のあなた」よりも「今日のあなた」の方が問題を解決するのに適しています。理想的でないコードで作業できることは、仕事の一部にすぎません。

多くの雇用者はそれを認識しているので、彼らがあなたに読んでもらうコードは、彼らのコードベースで最高ではなく最悪のコードを代表しているかもしれません。コンテキストからそれが明確でない場合は、質問する必要があります。私が時々インタビューする同僚の1人に、インタビューの質問として使用するために意図的に作成したコードのページがあります。

ケースの99％で、「ドグマ」に固執する必要があります。ドグマは長年の経験を経て経験を積んだ人によって作成されますが、ある時点で実際的であると思われることは実際にはそうではありません。これは通常、その問題を適切に処理するのに十分ではないという事実よりも重要です。

しかし、盲目的にドグマに従ってはいけません。人々がその教義に従うように導く結論を思い出してください。従うべきではないケースのごく一部を見つけるからです。とにかく、これらのケースは非常にまれであり、そのような決定を下す前に、常に他の経験豊富なプログラマーと話し合う必要があります。

重要な場合は厳しくしてください。ブレーススタイル（または他のコーディング規約）？関係ありません。ショップが使用するものを使用してください。正当な理由がないのにカプセル化（または他の基本的なプログラミングの原則）を破る？それほど些細ではありません。

Stack Exchangeはレイアウトにテーブルを使用します（他の多くの主要なWebサイトが収益を上げているように）。純粋主義者の耳から煙が出ますか？確かにそうです。しかし、プラグマティズムは毎回、純度よりも勝ちます。出荷する製品は、毎回完璧に仕上げることに勝ちます。

全体的なドメインレイヤー、永続化レイヤー、プレゼンテーションレイヤー、単体テストは、歴史的な観点からはまだ比較的新しいものです。クライアント/サーバーモデルをまだ使用しているソフトウェアが大量にあり、「優れている」という理由だけで最新のアーキテクチャスタイルに変更されることはありません。