悪いプログラミング慣行はソフトウェア業界で一般的ですか？
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。
- あなたが質問で引用した原則は、それだけです...原則。それらは義務ではありません、法律または命令。
- これらの原則を思いついた人々はとても賢いですが、絶対的な権威ではありません。彼らは自分の洞察とガイダンスを提供している人々です。
- プログラムに「正しい」方法はありません。これは、私たちが行う「受け入れられた」方法が変化し、時間とともに根本的に変化し続けているという事実によって証明されます。
- 多くの場合、商品の発送は、「正しい」方法よりも優先されます。これは非常に普及しているため、名前はTechnical Debtです。
一般的に使用されている一部のソフトウェアアーキテクチャは理想的ではありません。 ベストプラクティスは、大規模なモノリシックアプリケーションから、疎結合のモジュールコレクションに向けて進化しています。
コンテキストは重要です。多くのアーキテクチャの原則は、largeプログラムで作業している場合にのみその価値を証明します。特定のドメイン。たとえば、継承はmostly深くネストされた密結合の配置から利益を得るUI階層およびその他の構造に役立ちます。
では、荒野から抜け出すために、「正しい」道、原則的な道をどのように辿りますか？
- 正確さではなく、研究の妥当性、。ソフトウェア開発で何かを行う「正しい」方法は、特定の要件を最も効果的に満たす方法です。
- 調査のトレードオフ。ソフトウェア開発のすべてがトレードオフです。メモリ使用量を増やしたいですか、それとも減らしたいですか？実践者がほとんどいない非常に表現力豊かなプログラミング言語、または多くの開発者が知っている表現力の少ない言語が必要ですか？
研究は時代を超越しています。いくつかの原則は、時間の試練に耐え、常に関連性があります。型システムは普遍的です。ファーストクラスの機能は普遍的です。データ構造は普遍的です。
実践主義を学ぶ。実用的であることは重要です。数学的純粋さ、クリスタル大聖堂の建築、象牙の塔の原理は、出荷できない場合は役に立ちません。
- 熱心ではなく、職人になってください。最高のソフトウェア開発者は、ルールを知っていて、そうすることが理にかなっているときにそれらを破る方法を知っている人です。彼らはまだ問題を解決し、自分で考える方法を知っている人です。彼らは原則を使用して、選択を通知するのではなく、指示するのです。
- コードを記述します。たくさん。ソフトウェア設計の原則は、大量のコードを記述し、それらを正しく適用する方法についての本能を開発するまでは、時期尚早の最適化です。
それは珍しいことではありません。理解しておくべきことの1つは、ソフトウェア業界が信じられないほど多様であることです。一部の企業は最先端を進んでいます。有力な大学や革新的なソフトウェア企業（大企業のラボも！）や4人組のような恵まれた人々やグループは、物事を行うための一般的な方法で発生する問題を分析し、新しい言語、機械、ツール、パターンを発明しています。新しい会社は、多くの場合、スピンオフまたはスプリットオフであり、それらを商業的に使用しようとし、時には驚くべき成功を収めます。 FacebookやGoogleを考えてください。
しかし、ソフトウェアは最近ほとんどどこでも使用されており、おそらくほとんどが実際にはソフトウェア企業ではない企業で使用されています。私は主に運輸業界（自動車と鉄道）で働いており、さまざまな経験があります。しかし、それらのどれも「最先端」に近いところはありませんでした。時々彼らはすることができません。安全関連のソフトウェアは、十分に吟味されたツールに依存しています（現在、1990年代の検証済みC++コンパイラを使用しています）。時には彼らは適切な人々を持っていません。多くの場合、ソフトウェアは他の分野のエンジニアによって開発され、ソフトウェアがますます重要になったときに、たまたま会社のソフトウェア開発に滑り込みました。彼らがソフトウェア工学の原則を知ったり使用したりすることを期待することはできません。
考慮すべきもう1つのことは、現実世界のエンジニアにとって重要なことです。多くの場合、当面の課題は、文字通り、ロケット科学ではありません。ソフトウェア以外の企業におけるパンとバターの問題は、適度なソフトウェア手段で解決できます。優れたソフトウェアエンジニアでさえ有用であり、優れたソフトウェアエンジニアであることは、部分的には優れた一般的なエンジニアになります。責任を持って作業を整理し、文書化します。協力的であること。適切なコストと時間の見積もりを作成します（見積もりの妥当性は実際のコストと時間よりも重要です！）。できることとできないことを理解する。ここで目立って欠けているのは、「最先端のツールと手順を理解して使用する」ことです。あなたが説明しているのは、彼らのために機能するツールセットとプロセスを確立している会社です。彼らはおそらくセクシーなものや並外れたものを生み出すことは決してないでしょうが、十分な収益の安定した流れを生み出すのに十分なほど顧客の要求を十分に満たします。それが工学の定義かもしれません;-)。
そうはい：あなたが大学で学ぶことは実際には多くの分野で一般的ではありません。
慰めの一片、またはより明るいノートを追加したいと思います。あなたが学んだことは、窓から投げ出されるべきではありません。あなたはそれが物事を壊さない毎日の仕事でより良い原則を適用することができます。おそらく、新しいツールやデザインパターンを紹介する機会があるでしょう。物事の古いやり方が同僚にとって不愉快な場合、または複雑さの管理やメンテナンスの問題（イノベーションによって対処される最も深刻な2つの問題）に遭遇した場合に、チャンスは最良です。機会があれば改善を提供する準備をしてください。ポジティブな影響力を持ち、方法とツールを段階的に改善します。認められるところに知識を広める。
C＃.Net Webformsを使用し、コードビハインド内のほとんどすべてを非常に小さな外部クラスで実行します。
そこにあなたの説明があります。ご存じない場合は、すぐに使用できるWebフォームのコードがOOP、SOLID、DRY、YAGNI、デザインパターン、SRPなどと正反対です。公式の例でも数年前のマイクロソフトからのあなたは今日あなたをうんざりさせるでしょう。
Webフォームは、コントロールクリックなどによってトリガーされるいくつかの偽の「イベント」を使用して、手続き型フローに自分自身をプッシュします。 Webフォームの作成に多くの時間を費やした開発者も、通常はWebフォームから離れることに消極的です。おそらく、ページライフサイクルと動的にレンダリングされるコントロールの学習に多くの時間を費やしているため、今は知識を捨てられなくなっているためです。より新しい/より良い方法に直面して。沈没コストの誤解の無意識バージョン。これらの開発者は何年もかけてWebフォームを解決する方法を学び、今ではその専門知識から容易に逸脱することはないため、「メンテナンス」時間についての話をしています。
そして、これは.NET Webフォームの分野ではかなり一般的です。
これはソフトウェア業界でどのくらい一般的ですか？
ごく普通。配管工が配管を破壊するのとほぼ同じこと、大工がジャンクを届ける、または安価な仕立て屋が不適切なスーツを作るのとほぼ同じです。つまり、すべて人間です。
これが起こるのには十分な理由があります。本当に訓練されていない（または熱狂的でない）人々は、プレッシャーのもとで何かを実装する必要があります。
これは主にこれらの人々の問題ではなく、通常、その会社のソフトウェア開発を取り巻く構造の問題です。たとえば、企業には多数のインターンが社内ソフトウェアを開発している場合があります。これらのインターンは明るく知識が豊富な場合でも、数週間または数か月間しか存在せず、所有権は頻繁に切り替わります。
あるいは、プログラマーではなくドメインで優れた人物が、VBAなどのアプリケーションをハッキングする可能性があります。
または、適切に作成されたアプリケーションがメンテナンスフェーズで終了し、すべての優れた開発者が先に進み、その後、それについてほとんど知らない、ドキュメントがないなどの少数の人々（最悪の場合：1人）が引き続き開発します。
OOPと関連する原則を確実に把握するにはどうすればよいですか？余暇に練習しているのですが、OOPをより良くするためには、経験豊富な開発者のもとで作業する必要があります。 。
考えられる答えは2つあります。
- どちらか：上司と話し合って、クリーンなプロジェクトに参加するようにしてください。不可能な場合は、新しいボスを探します。
- または、自分で責任を負ってください。それは自分でそれを行うことを意味します-あなたの余暇に、または可能であれば会社で、しかしあなた自身が（おそらく）運転することで。
2番目の答えが皮肉すぎると思われる場合は、そうではないことをお伝えします。家に木工所がある大工はmostがいない大工よりも確かに優れた大工になります。
たとえば、Rubyのような新しい言語を掘り下げるなど、一部の人にとってlotの楽しみは絶対に可能であり、構文だけでなく、詳細な特別なOO側面、そして本当に深く掘り下げます。あなたの余暇にはすべて、あなたの仕事に関係なく、それはただの趣味ですが、あなたがそうであるように訓練された専門家であることは、同じくらい効果的です（またはそれ以上）リード開発者の隣に座って、彼らがしていることを追おうとすることです。これは、厳密にあなたの個人的な開発とあなた自身の楽しみのためになります。これを行う楽しみがない場合、または単にあなたが気づいた場合理解できず、それをスクラッチして、最初の答えに戻ることができません。
あなたを訓練しているそのリード開発者はかなりおそらくこのようにそのことを学んだでしょう...
開発者は通常、会社で何年も経つと、分析やプロジェクト管理などのより多くの管理領域に昇格するため、スペインでは不変だと思います。その結果、ピアレビューは行われず、コードは通常、経験の浅い人によって書かれます。
これらの経験豊富な人々の失敗は修正されることはありません。代わりに、仕事を遂行するための彼らの唯一の焦点です。その結果、ますます間違ったプラクティスがコードに蓄積されます。
結局、いくつかの賢いお尻は、最良の「解決策」は、よりクリーンでメンテナンス可能なコードを生成する新しいテクノロジーに変更し、新しいアプリケーションを作成することだと言います。まるでテクノロジー自体がそれを行うことができるかのように。
繰り返しになりますが、経験の浅いプログラマーはその新しいテクノロジーで作業することになり、誰もコードをレビューせず、サークルは再び閉じられます。
学校で学ぶ「ベストプラクティス」の一部は、実際のプロジェクトでは実用的でも費用効果的でもありません。私が気付いた最大の変更点の1つは、書式設定とコメントです。ほとんどの私の教授はあなたのコードを広範囲に文書化することの重要性を強調しましたが、現実の世界では、良いコードはしばしば（常にではありません！）コメント。
高品質のソリューションよりもボイラープレートの必要性が少ないショートカットやアンチパターンを使用して、時間をかけられているプログラマーを時々見かけます。
しかし、私が多くのチームやプロジェクトで気付いた最大の問題の1つは、新しいことを学ぶ意欲がないです。私が話を聞いた古いプログラマーの多くは、資格が始まり、コードを書く意欲で終わったソフトウェアエンジニアリングの「ワイルドウエスト」時代にキャリアをスタートさせました。彼らはしばしば完全に異なる分野を専攻し、機会が生じたときに正式な教育をほとんどまたはまったく受けずにプログラミングに飛び込みました（たとえば、雇用主にはプログラマーがいなく、社内ソフトウェアを構築するために誰かに学ぶ必要がありました）。これらの古い学校の独学のプログラマーの一部は、現代のコーディングプラクティスを学ぶ努力を決してせず、彼らが数十年前に学んだほぼすべてのスタイルでコーディングを続けています。彼らが年功のために新しいプロジェクトを担当することになると、彼らはプロジェクトを保留し、全体的なコード品質を損なう傾向があります。
もちろん、上記はすべての古いプログラマーに当てはまるわけではなく、新しい世代のプログラマーも同様に有罪になる可能性があります。私は多くの若いプログラマーと協力して、大学を卒業したばかりのときにいくつかのツールやライブラリーを手に入れ、その後完全に学ぶのをやめました。 IDEまたはライブラリを1度ダウンロードし、会社が必要としない限り更新しません（ライブラリの古さに基づいて、プログラマが卒業した年を推測できる場合があります）。彼らは選択した言語の新機能に追いついておらず、新しい言語を習得することもありません。新しいプログラミング戦略を習得せず、より適切な代替手段を知らないためにパターンやパラダイムを誤用する可能性があります（ああMVC、どれほど酷使されているのか）時が経つにつれ、ワークフローはますます古くなり、資産よりも負債になっていきます。
要約すると、乱雑なコードベースの最大の原因の2つは、期限が迫っていることと、古くなったまたは不完全な知識を持つプログラマーです。残念ながら、両方の問題の責任は、上司またはCTOに大きくかかる可能性があります。上司またはCTOは、締め切りが現実的であること、およびスタッフが彼らの知識とスキルについて最新であることを確認する必要があります。上司が適切なプログラミング方法について何も知らない場合は、できる限りの最善策は、変更を提案してみて、提案が受け入れられることを期待することです。残念ながら、彼らはOOPを理解せず、10,000行のクラスを書くことを好む上級プログラマーの言葉を信頼する傾向があるかもしれません。
悪いプログラミング慣行のいくつかは、数十年前に最初に開発を始めたレガシーソフトウェアを使用しなければならないことに起因します。巨大で複雑なソフトウェアがある場合、すべてを書き換えることは選択肢にならないかもしれません。コードが実際に実行しているすべてのことを理解することは非常に難しいことさえあるかもしれません。何も壊さずにできる場合は、より良いプログラミング手法を統合すると同時に、機能するものを単にコピーすることをお勧めします。
善悪を区別するだけでなく、あらゆる善悪の背後にあるreasonsを知ることが重要だと思います。理由がわかれば、結果を予測できます。本で説明されているからではなく、なぜこれまたはその原理を使用するのかではなく、それがどのように役立ち、exactlyが発生すると何が起こるかを知っているためです。ときに何が起こるかを知っている場合は、長所と短所を比較検討して決定を下すことができます。これは、毎回自分の立場を主張するのにも役立ちます。 SOLID and OOPを使用すると、メンテナンスを減らすこともできます。
独断的に使用すると、SOLIDは、あまりにも多くのクラスとメソッドにつながりますが、これもそれほど良いものではありません。無理しないでください。彼らはしばしば適切な正当化なしにアイデアを宣伝しようとするので、これは一部には私たちの教科書とチュートリアルの大きな問題です。 OOPにも短所があります。多くの原則とパラダイムは互いに矛盾しています。トップに立つ必要はありません。すべてを合理的、正当化、エレガント、シンプルにする必要があります。
また、これはあなたの最初の仕事なので、これらのプログラマーはあまり熟練していない可能性があります。しかし、再び、彼らはおそらくそれほど難しいスキルではなく、スキルの低い安価なプログラマーによって給与が下がるほど難しいタスクで信頼されています。これが経済学の仕組みです。それぞれの職場は異なります。
あなたの気持ちを理解しています。 パニックにならないでください。あなたはあなたが知っていることを必要とするでしょう、おそらくすぐにはではありませんが、それはあなたを助けるでしょう。たぶん別の職場で、場合によっては。先に進む時間があります。