悪いプログラミングの慣行は、ソフトウェア業界では一般的ですか？[閉まっている]

私は1ヶ月以上前にソフトウェア開発者として最初の仕事を始めました。OOP、SOLID、DRY、YAGNI、デザインパターン、SRPなどについて私が学んだことはすべて窓から捨てられます。

C＃.NET Webformsを使用し、コードビハインド内のほとんどすべてを、オブジェクトとは呼ばない、ごく少数の外部クラスで実行します。カスタムコントロールを使用して再利用します。使用されるオブジェクトは、Entity Frameworkのみです。クライアントごとにコードビハインドを再利用します。それらには、すべての種類の処理を行う400行のメソッドがあります。新しいクライアントの場合、aspxとaspx.csを取得し、クライアントコードを削除して、新しいクライアント固有のコードの追加を開始します。

彼らの最初の言い訳は、それが追加のメンテナンスを追加し、より多くのコードがより多くのメンテナンスであることです。私を含む3人の開発者の小さなお店です。1人の開発者には30年以上の経験があり、もう1人の開発者には20年以上の経験があります。1つはゲーム開発者で、もう1つは常にCとC ++で働いていました。

これはソフトウェア業界内でどのくらい一般的ですか？OOPおよび関連する原則を確実に把握するにはどうすればよいですか？空き時間に練習していますが、OOPをより良くするためには、より経験豊富な開発者の下で働く必要があると感じています。

1. 質問で引用した原則は、まさにそれです... 原則です。 それらは義務、法律、または命令ではありません。
2. これらの原則を思いついた人々は非常に賢い一方で、絶対的な権威ではありません。彼らは単なる洞察とガイダンスを提供する人々です。
3. プログラムするための「正しい」方法はありません。 これは、私たちの「受け入れられた」方法が時間とともに根本的に変化し、変化し続けているという事実によって証明されています。
4. 製品を出荷することは、「正しい」方法で行うよりも優先されることがよくあります。これは非常に一般的な慣行であり、その名前は技術債務です。

5. 一般的に使用されている一部のソフトウェアアーキテクチャは理想的ではありません。 ベストプラクティスは、大規模なモノリシックアプリケーションから、疎結合モジュールのコレクションへと進化しています。

6. コンテキストは重要です。 多くのアーキテクチャの原則は、大規模なプログラムまたは特定のドメインで作業している場合にのみその価値を証明します。たとえば、継承は、UI階層や、深くネストされ、密結合された配置の恩恵を受けるその他の構造に最も役立ちます。

それでは、どのようにして荒野から出られるように、「正しい」道、原則的な道をたどりますか？

1. 正しさではなく、適切性を研究してください。ソフトウェア開発で何かを行う「正しい」方法は、特定の要件を最も効果的に満たす方法です。
2. トレードオフを検討します。 ソフトウェア開発のすべてはトレードオフです。より高速にしたい、またはメモリ使用量を減らしたいですか？実践者がほとんどいない非常に表現力の高いプログラミング言語が必要ですか、それとも多くの開発者が知っている表現力の低い言語が必要ですか？

3. 時代を超越した学習。 いくつかの原則は時の試練に耐えており、常に関連しています。型システムは普遍的です。一流の機能は普遍的です。データ構造は普遍的です。

4. 実用主義を学ぶ。 実用的であることは重要です。出荷できない場合、数学的純度、水晶大聖堂のアーキテクチャ、および象牙の塔の原理は役に立ちません。

5. 熱狂者ではなく、職人になりましょう。 最も優れたソフトウェア開発者は、ルールを知っており、それが理にかなっているときにルールを破る方法を知っている人です。彼らは問題をどのように解決し、自分自身で考えるかをまだ知っている人です。彼らは、原則を使用して、選択を通知およびガイドします。
6. コードを書きます。 それがたくさん。ソフトウェア設計の原則は、多くのコードを記述し、それらを正しく適用する方法の本能を開発するまでの時期尚早な最適化です。

珍しいことではありません。認識すべきことの1つは、ソフトウェア業界が非常に多様であることです。一部の企業は最先端です。一流の大学や革新的なソフトウェア会社（大規模なラボでも！）、4人のギャングのような祝福された人やグループは、物事を行い、新しい言語、機械、ツール、パターンを発明する一般的な方法で発生する問題を分析します。多くの場合、スピンオフまたはスプリットオフの新しい会社は、それらを商業的に使用しようとし、時には驚くべき成功を収めます。FacebookやGoogleを考えてください。

しかし、ソフトウェアは最近ほとんどどこでも使用されており、おそらくほとんどが実際にはソフトウェア会社ではない会社で使用されています。私は主に運輸業界（自動車と鉄道）で働いてきましたが、さまざまな経験があります。しかし、それらのいずれも「最先端」に近い場所にはありませんでした。時にはできないこともあります。安全関連のソフトウェアは十分に吟味されたツールに依存しています（現在、1990年代から検証済みのC ++コンパイラを使用しています）。時々彼らは適切な人を持っていません。多くの場合、ソフトウェアは、ソフトウェアがますます重要になったときにたまたま会社のソフトウェア開発に滑り込んだ他の分野のエンジニアによって開発されています。ソフトウェアエンジニアリングの原則を知っている、または使用することを期待することはできません。

考慮すべきもう1つのことは、実世界のエンジニアにとって重要なことです。多くの場合、目の前のタスクは、文字通り、ロケット科学ではありません。非ソフトウェア会社の基本的な問題は、控えめなソフトウェア手段で解決できます。有用で、おそらく優秀なソフトウェアエンジニアであるのは、部分的には優れた一般的なエンジニアであるということです。仕事を責任を持って整理し、文書化する。協力する; 適切な費用と時間の見積もりを作成します（見積もりの​​有効性は実際の費用と時間よりも重要です！）。できることとできないことを理解する。ここで際立って欠けているのは、「最先端のツールと手順を知り、使用する」ことです。あなたが説明するのは、彼らのために働くツールセットとプロセスを確立した会社です。彼らはおそらくセクシーなものや並外れたものを決して生み出さないでしょう。しかし、彼らは十分な収益の安定したストリームを生成するのに十分十分に顧客の需要を満たしています。それがエンジニアリングの定義かもしれません;-)。

はい。大学で学んだことは、実際にはほとんどの分野で一般的ではありません。

私は慰めの部分、またはより明るいノートを追加したいと思います。学んだことを窓から捨ててはいけません。物事を壊さない、より良い原則を日常業務に適用できます。おそらく、新しいツールまたは設計パターンを導入する機会の窓があるでしょう。古いやり方が同僚にとって不快な場合、または複雑さやメンテナンスの管理に問題が生じた場合（イノベーションによって対処された2つの最も有害な問題）に最適です。機会があれば改善を提供する準備をしてください。積極的な影響を与え、方法とツールを徐々に改善します。感謝されるところに知識を広める。

C＃.Net Webformsを使用し、コードビハインド内でほとんどすべてを外部クラスをほとんど使用せずに実行します。

そこにあなたの説明があります。気付いていない場合、すぐに使用できるWebフォームコードは、OOP、SOLID、DRY、YAGNI、Design Patterns、SRPなどとは正反対です。数年前のMicrosoftの公式な例でも今日はうんざりします。

Web Formsは、手続きの流れに向かってプッシュします。コントロールのクリックなどにより、いくつかの偽の「イベント」がトリガーされます。Webフォームの作成に多くの時間を費やした開発者は、ページライフサイクルの学習に多大な時間を費やし、動的にレンダリングされたコントロールを実行してその知識を捨てるのを嫌がるので、通常はWebフォームからの離脱にも消極的です。新しい/より良い方法に直面して。沈没コストの誤acyの無意識のバージョン。これらの開発者は何年もかけてWebフォームを圧縮する方法を学びましたが、今ではその専門知識から容易に逸脱することはないため、「メンテナンス」時間について話します。

そして、これは.NET Web Formsスペースではよくあることです。

これはソフトウェア業界内でどのくらい一般的ですか？

ごく普通。配管工が配管を破壊したり、大工がジャンクを配達したり、安価な仕立て屋がフィットの悪いスーツを作ったりするのとほぼ同じ共通性。すなわち、それはすべて人間です。

これが起こる理由は十分にあります。実際に訓練されていない（または熱心でない）人は、プレッシャーの下で何かを実装する必要があります。

これは主にこれらの人々の問題ではありませんが、通常はその会社のソフトウェア開発を取り巻く構造の問題です。たとえば、企業では社内ソフトウェアを開発する多くのインターンがいる場合があります。それらのインターンが明るく知識が豊富であっても、彼らは数週間または数ヶ月しか滞在せず、所有権は頻繁に切り替わります。

または、ドメインでは優れているがプログラマーではない人は、VBAなどのアプリケーションを最初から簡単にハッキングするかもしれません。

または、よくできたアプリケーションが保守フェーズになり、すべての優秀な開発者が次へ進み、その後、ほとんど知らない少数の人々（最悪の場合は1人）によって開発が続けられます。

OOPおよび関連する原則を確実に把握するにはどうすればよいですか？空き時間に練習しているので、OOPをより良くするためには、経験豊富な開発者の下で働く必要があると感じています。

考えられる答えは2つあります。

• どちらか：上司とこれについて話し合い、クリーンなプロジェクトに入るようにしてください。不可能な場合は、新しいボスを見つけます。
• または：これについては自分で責任を負います。それはあなた自身でそれを行うことを意味します-あなたの空き時間に、または可能であれば、会社で、しかしあなた自身によって駆動される可能性は低いです。

2番目の答えがあなたにとって冷笑的すぎると思われる場合は、そうではないことを保証させてください。自宅で木工所を持っている大工がします最も確かにしないものよりも良い大工なります。

例えば、それは絶対に可能であり、多くの何人かの人々のための楽しいのは、例えば、Rubyのような新しい言語を掘り下げる構文、だけでなく、その言語の徹底的な特殊なOOの側面だけでなく、学び、そして本当に深く潜るします。仕事とはまったく関係なく、すべての時間を空いた時間に。ただの趣味になりますが、訓練を受けたプロフェッショナルであるため、リード開発者の隣に座って彼らがやっていることを追いかけようとするのと同じくらい効果的です（またはそれ以上）。これはあなたの個人的な発展とあなた自身の楽しみのために厳密になります。これを行うのが楽しくない場合、または単に理解を達成できないことがわかった場合は、それをスクラッチして、最初の答えに戻ります。

あなたを訓練されていることをリード開発者がいる、非常に可能性の高い、まさにこのように、その原料を学びました...

開発者が会社で何年も経つと、開発者は通常、分析やプロジェクト管理などの管理領域に昇進するため、スペインでは不変だと思います。その結果、ピアレビューは行われず、コードは通常、経験の浅い人々によって書かれています。

これらの経験豊富な人々の失敗は決して修正されません。代わりに、仕事を成し遂げるための唯一の焦点です。結果として、ますます多くの間違った慣行がコードに蓄積されます。

最終的には、いくつかのスマートなロバは、最良の「解決策」は、よりクリーンで保守可能なコードを生成する新しいテクノロジーに変更し、新しいアプリケーションを作成することだと言います。テクノロジー自体がそれを行うことができるかのように。

繰り返しますが、経験の浅いプログラマーはその新しいテクノロジーで働くようになります。誰もコードをレビューせず、サークルは再び閉じられます。

学校で学ぶ「ベストプラクティス」の一部は、現実のプロジェクトでは実用的でも費用対効果も高くありません。私が気づいた最大の変更点の1つは、書式設定とコメントにありました。私の教授のほとんどは、あなたのコードを広範囲に文書化することの重要性を強調しましたが、現実の世界では、良いコードはしばしば（必ずしもそうではありません！）コメント。

高品質のソリューションよりも定型的なものを必要としないショートカットやアンチパターンを使用して時間を追われているプログラマーを時々目にするでしょう。

しかし、多くのチームやプロジェクトで私が気づいた最大の問題の1つは、新しいことを学ぼうとしないことです。私が話した多くの古いプログラマーは、資格が始まり、コードを書く意欲を持って終了したソフトウェアエンジニアリングの「ワイルドウェスト」時代にキャリアを始めました。彼らはしばしば完全に異なる分野を専攻し、機会が生じたとき、ほとんどまたはまったく正式な教育を受けずにプログラミングに飛び込みました（たとえば、雇用主にプログラマがなく、社内ソフトウェアを構築するために学ぶ人が必要でした）。これらの昔ながらの独学のプログラマーの中には、現代のコーディングプラクティスを学ぶ努力を決してせず、数十年前に学んだおおまかなスタイルでコーディングを続けています。年功のために新しいプロジェクトを担当することになった場合、彼らはプロジェクトを控え、全体的なコード品質を損なう傾向があります。

もちろん、上記はすべての古いプログラマーに当てはまるわけではなく、新世代のコーダーも同じように有罪になる可能性があります。私は大学を卒業したばかりのいくつかのツールやライブラリを手に入れた後、完全に学習をやめた若いプログラマーと仕事をしました。IDEまたはライブラリを1回ダウンロードし、会社が必要としない限り更新しません（ライブラリがどれだけ古くなっているかに基づいてプログラマが卒業した年を推測できる場合があります）。選択した言語の新機能に追いついておらず、新しい言語を学ぶことはありません。彼らは新しいプログラミング戦略を学ばず、より適切な代替手段を知らないため、パターンやパラダイムを誤用する可能性があります（ああ、MVC、どれほどアートを酷使しているのか）。時間が経つにつれて、彼らのワークフローはますます時代遅れになり、資産よりも負債になります。

要約すると、乱雑なコードベースの最大の原因の2つは、期限が迫っていることと、知識が古いか不完全なプログラマです。残念ながら、両方の問題に対する責任は上司またはCTOに大きく委ねられる可能性があります。上司またはCTOは、期限が現実的であり、スタッフが知識とスキルについて最新であることを保証する必要があります。上司が優れたプログラミング慣行について何も知らない場合、あなたができる最善のことは、変更を提案し、それらが提案に対してオープンであることを願うことです。残念ながら、OOPを理解しておらず、10,000行のクラスを書くのが好きな上級プログラマーの言葉を信頼する傾向があります。

悪いプログラミング慣行のいくつかは、数十年前に開発を始めたレガシーソフトウェアを使用しなければならないことに起因します。ソフトウェアの巨大で複雑な部分がある場合、すべてを書き直すことはオプションではないかもしれません。コードが実際に行っていることをすべて理解することは非常に難しいことさえあります。最良の選択肢は、機能するものをコピーするだけでなく、何も壊さずにコピーできる場合は、より良いプログラミング手法を統合することです。

私は、単に間違ったことを正しく伝えるのではなく、あらゆる善悪の背後にある理由を知ることが重要だと思います。理由がわかれば、結果を予測できます。本またはその原則を使用する理由は、それが本で説明されたからではなく、それがどのように役立つか、そしてそれを破った場合に正確に何が起こるかを知っているからです。いつ何が起こるかを知っていれば、長所と短所を比較検討し、決定を下すことができます。これは、毎回自分の立場を議論するのにも役立ちます。SOLIDとOOPを適切に使用すれば、メンテナンスも削減できます。

独断的に使用すると固すぎると、クラスやメソッドが多すぎてあまり良くありません。無理をしないでください。教科書やチュートリアルでは、適切な正当化なしにアイデアを宣伝しようとすることが多いため、これは部分的に大きな問題です。OOPにも短所があります。多くの原則とパラダイムは互いに矛盾しています。トップに立つ必要はありません。すべてを合理的で、正当化され、エレガントでシンプルにする必要があります。

また、これがあなたの最初の仕事であるため、これらのプログラマーがあまり熟練していない可能性があります。しかし、繰り返しますが、彼らはおそらくそれほどスキルがなくても、低スキルの安価なコーダーが低い給料で行うことができるそれほど難しくないタスクで信頼されています。これが経済学の仕組みです。職場はそれぞれ異なります。

あなたの気持ちを理解しています。パニックにならないでください。すぐにではないかもしれませんが、あなたが知っていることを必要としますが、それはあなたを助けます。たぶん、別の職場で、場合によっては。さらに先に進む時間がある。