なぜ一部のプログラマーは理論と実践の間にコントラストがあると思いますか？
土木工学とソフトウェア工学を比較して、私は別の考え方を観察して驚いていました：土木技師なら誰でも庭に小さな小屋を建てたいなら、材料を手に入れてそれを建てることができますが、作りたければ10階建ての家（または、たとえば this のようなもの）は、バラバラにならないようにかなりの数の計算を行う必要があります。
対照的に、一部のプログラマーと話をしたり、ブログやフォーラムを読んだりすると、多かれ少なかれ次のように定式化できる幅広い意見を見つけることがよくあります。理論とプログラミングは数学者/科学者向けです物事を成し遂げることについての詳細です。
ここで通常暗示されているのは、プログラミングは非常に実用的なものであり、正式な方法、数学、アルゴリズム理論、クリーン/コヒーレントプログラミング言語などが興味深いトピックである場合でも、物事を成し遂げる。
私の経験によれば、100行のスクリプト（小屋）を組み立てるのにあまり理論は必要ありませんが、複雑なアプリケーション（10階建ての建物）を開発するには、構造化された設計が必要です。 -定義されたメソッド、優れたプログラミング言語、アルゴリズムを調べることができる優れた教科書など.
したがって、IMO（正しい量）理論は、物事を成し遂げるためのツールの1つです。
私の質問は、なぜ一部のプログラマーは、理論（形式的方法）と実践（物事を成し遂げる）の間にコントラストがあると思うのですか？
ソフトウェアエンジニアリング（建築用ソフトウェア）は、土木工学（建築用住宅）などと比較してeasyと多く認識されていますか？
または、これらの2つの分野は本当に異なりますか（ミッションクリティカルなソフトウェアを除いて、ソフトウェアの障害は、建物の障害よりもはるかに受け入れられます）？
これまでの回答からわかったことをまとめてみます。
- ソフトウェアエンジニアリングとは対照的に、土木工学では、特定のタスクに必要な理論（モデリング、設計）の量がはるかに明確です。
- これは一部には、土木工学は人類と同じくらい古く、ソフトウェア工学は数十年しか使われていないという事実によるものです。
- もう1つの理由は、ソフトウェアがより不安定な種類のアーティファクトであり、より柔軟な要件（クラッシュする可能性がある）、さまざまなマーケティング戦略（市場に迅速に投入するために優れたデザインを犠牲にすることができる）などです。
結果として、ソフトウェアエンジニアリングに適切な設計/理論の適切な量を決定することははるかに困難です（少なすぎる->乱雑なコード、多すぎる->決して終わらない）。 （多くの）経験が役立ちます。
だから私があなたの答えを正しく解釈すると、どれくらいの理論が本当に必要であるかに関するこの不確実性は、一部のプログラマーが理論に対して抱いている愛/憎しみの感情の混合に貢献しています。
主な違いは、土木工学では、現実世界の物理学は、理論を正気に保ち、悪い慣行も制限する一定の強力な現実チェックとして機能するのに対し、ソフトウェア工学では、非現実的な象牙の塔の概念を維持するための等しく強い力はないということです見掛け倒しの出来映えとして。
多くのプログラマーは、暴走理論が物事を成し遂げるための積極的な障害となるという悪い経験をしました（例えば、「実行可能なUML」、超官僚的な開発プロセス）。逆に、ダーティなハックやパッチを適用すると、最終的にはゆっくりですが、かなり気が遠くなることがあります。そして、最後の段落で確認したように、通常、失敗は最終的なものではないため、それほど問題ではありません。
ソフトウェア工学と土木工学にはほとんど共通点がありません。土木工学の取り組みは、その材料と環境の物理的特性によって制限されます。土木技術者は、土壌の特性や材料の特性について学ぶことに多くの時間を費やしています。ソフトウェア開発は、プロセッサの速度と利用可能なストレージによってのみ物理的に制限されます。これらはどちらも理解しやすく、学習に多くの時間を費やしていません。ソフトウェア開発の主な制限は人間の知性です。そして、2人の開発者が似ているわけではありません。このコードは保守可能ですか？誰によって？ Haskellでのクイックソートの3行の実装は、明らかに正しい人もいれば、理解できない人もいます。 2人のチームが1か月で申請書を完成させる一方で、10人の別のチームが1年で納品するのに苦労しています。
ソフトウェア開発はすべて設計であり、設計されているアーティファクトは製造されたどの製品よりも桁違いに複雑であり、それぞれがユニークです。
多かれ少なかれ正直なところ、機械工学者として（ある程度の土木を使って）プログラマー、次にCS（AI）博士、次に教師、そしてプログラマー（失礼しますSoftware Engineer）、私はこの一般的なテーマについて不満を持っています。
伝統的な工学では
- 数学と科学を知る必要がある
- フィールドの「ヒーロー」は、新しいものを発明し、新しいアイデアを発見し、解決できないと考えられる問題を解決する人々です
ソフトウェアに当てはまる「物理学」-情報理論がありますが、ソフトウェアエンジニアはそれにほとんど触れず、確かに何も適用されていません。彼らが得る最も理論は計算可能性とbig-Oです。
また、プログラミングを知っていれば十分だと思っている人たちにも絶えず驚かされます。彼らはプログラムの内容について主題を理解する必要はありません。
さらに、独創性は推奨されません。 「読みやすさ」を装った、最小公約数のグループ思考方法を支持することは推奨されません。 （航空技術者や原子力技術者が、後輩にとって理解するのが難しいかもしれないことは何もしないように促されたと想像してください。）
ウェブアプリのプログラミング方法など、彼らが学ぶことは非常に価値があります。配管工や電気技師のスキルもそうですが、それはエンジニアリングではありません。
mostソフトウェアの隅を切り、最良のデザインではないが、仕事を成し遂げることができるなら、誰も死ぬことはありません。それは、庭の小屋が10階建ての建物と同じ基準を必要としないのと同じ理由です。しかし、facebookのような非常に大きなアプリを作成することができ、それが失敗してデータなどが失われたとしても、それほど大きな問題ではありません。 10階建ての建物の土台を置き換えるよりも、実際に大きなアプリの土台を修正する方が簡単です。それはすべてコンテキストに帰着し、リスクを計算します。
安全にアプリを追加し続けることもできます。 10階建ての建物の新しい3階（11にする）を簡単に投げることはできません。必要に応じて、新しい機能を毎日大きなアプリにトスすることができます。
現在、優れた設計により、これらすべてのプログラミングが容易になります。しかし、貧弱な設計では不可能ではなく、リスクは...バグの多いソフトウェアです。通常は死ではない。
これで私と一緒に耐えなさい。ポイントがあります。
教授に、先延ばしにするともっと先延ばしになると教えてもらいましたが、ほとんどの人は、一晩中紙に書いたり、詰め込んだり、プログラミングしたりして、「もう二度とそれはしません。次回は早めに始めます。早く終わらせて」完全な先延ばし屋としての私の経験では、これは真実であることがわかりました、そしてここに教授の説明があります：先延ばしの経験がどんなに不愉快であっても、たいていの場合、あなたは比較的成功して成し遂げられます。これは高リスク/高報酬の行動です。しばらくすると、不快感をすべて忘れ、報酬だけを覚えます。したがって、あなたが最後に成功したので、先延ばしする次の誘惑はますます魅力的です。
ここで、私たちがよく目にする "物事を成し遂げる"プログラミング手法にたとえることができると思います。プログラマーまたはプログラマーのチームは、おそらく無知、怠惰、または本物の時間的制約から、プログラミングに「物事を成し遂げる」アプローチを採用し、理論と数学および優れた実践のすべてを窓の外に捨てます。そして、あなたは何を知っていますか？彼らは物事を成し遂げる。エレガントでも、きれいでも、保守もしやすいわけではありませんが、仕事をこなしてくれます。たぶん、セマフォからセミコロンを知らない非技術的な上司が彼らに「物事を成し遂げる」ことに対して高い評価を与えます。したがって、次にプログラマーがプログラミングにこの緩やかなアプローチを採用するように誘惑されたとき、それははるかに簡単です。それは、数年後にそのようなアプリケーションを継承し、それを維持しなければならないあなたの貧しい不幸な魂でない限り、「簡単な」方法です。
私はその貧しい、不幸な魂であったので、おそらくあなたの多くもそうです。皆さんにお願いします。簡単な方法をとらないでください！ :)
あなたの前提には欠陥があります。土木技術者が大きな建物、橋、トンネルなどを設計するときにエンジニアリングを使用する主な理由は、必要な安全基準を満たす最小限の量の材料（コンクリート、構造用鋼など）を使用していることを確認するためです。材料費と労働力のコストが問題にならない場合は、数学をあまり使わずに高層ビルを構築することは完全に可能です（たとえば、古代エジプトおよびマヤ文明のピラミッド）。彼らは彼らがより効率的に材料を使用するようにします。
大規模なソフトウェアシステムの設計には、多少異なるダイナミックがあります。どちらかといえば、それらは通常設計不足ですが、これは、設計が作業の進行に応じて動的に変更される可能性があるためです。
共通の要素はコストです。従来の土木工学プロジェクトでの設計は、コストを削減します（材料の観点からは実際、および責任の観点からの可能性の両方）。一方、ソフトウェア開発では、設計のコストが返される値を超えて増加するようになります。
エジプト人の時代以来人類が「土木工学」と同等のことをしてきた他のいくつかの優れた反応に加えて、私は物事の一般的な理論を完成させるために多くの時間を費やしてきました終わり。私たちは約70年ほど前からソフトウェアを構築してきました（最初の「ソフトウェア」とみなすものによって異なります）。つまり、同じような一連の経験を開発するのに同じ時間はありませんでした。
建築家/土木技師の青写真は、「完成した」計画と事実上まったく同じではありません。常に何かが変わります。どうして？ 「未知の未知数」が存在し、常に存在するからです。あなたが知っているために計画できることがあり、あなたが知っていることは未知であり、それゆえにあなたは研究や見積もりをすることができます。 「驚き」。ほとんどのシステムでこれらを可能な限り学ぶことで排除することを目指していますが、必要なのは1つの小さな建物のコード違反（2年前には建物が概念化されていたときに存在しなかった規則に基づく可能性があります）とすべて-包括的マスタープランは変更する必要があります。
ソフトウェアはこのようなものです。常に未知の未知数があります。ただし、土木工学や構造工学とは異なり、ソフトウェア開発は本質的に、未知の未知数が生み出す問題に基づいて、変化に対してはるかに寛容です。 10階建ての建物を建設していて、設計に組み込んだ基礎の耐荷重能力を過大評価した場合、建物を10階建てに建てることができないか、かなりの量の作業を取り除いて、基盤に戻って、それを補強または再構築します。ただし、ソフトウェアでは、ソリューション構造全体の特定の層に対する要求を過小評価した場合、他のすべての作業を無効にすることを含まない、その層を修正するための多くのオプションがあります。単一のDBサーバーをより強力なDBサーバー、レプリケーション/フェイルオーバークラスター、またはロードバランシング/分散クラスターに置き換えることができます。 Webサーバーについても同様です。入力サイズの誤った仮定に基づいて非効率的でシンプルなアルゴリズムをコーディングした場合、アルゴリズムを知っている他のコードに影響を与えることなく、ほとんどの場合、実装を比較的簡単に削除して書き換えることができます（入力を呼び出して渡す）それ、またはそれからの出力を期待します）。
この比較的簡単な変更により、ソフトウェアエンジニアは、自分が知らないことを過度に心配することなく、自分が知っていることに基づいてコーディングすることができます。これにより、理論の緩やかな適用と事前の概念設計が可能になります。あなたは飛び込んでそれを成し遂げ、そしてあなたがコード化したものを見つけ、それを変更する必要があるものを見つけ、それらを変更します。問題が明らかになったとき、それは原因を特定して解決策を作成するのに役立つものなので、概念と理論を知っておく必要があります。しかし、「分析麻痺」に屈することなく、簡単な決定を下すことができます。なぜなら、あなたが知らない、または「計算」を考慮に入れていないことに基づいて間違った決定をしたことが判明した場合、間違いを修正する方が簡単です。
違いは、主に既知の要件によるものです。
- 理論的な面では、すべてが事前に定義されているため、開始する前に必要なものを正確に知ることができます。
- 実際には、すべてが存在するわけではないか、実装の途中で何かを再設計しなければならない原因を発見することがあります。したがって、少なくとも初歩的な設計でジャンプする方がはるかに良いので、これらの問題を早期に発見できます。
さらに、「理論」について話すとき、それは通常、ソフトウェアエンジニアリングではなく、コンピュータサイエンスの理論的な側面を意味します。これは、コンピュータサイエンスの一部であり、主に、より優れた、より効率的なアルゴリズムを見つけ、何かが可能か不可能か（PやNPなど）を証明することなどです。これらのことを頭に入れておくことは良いことですが、ソフトウェア開発で頻繁に登場することはありません。
私たちはそのようなことのためにできるだけライブラリを使用します。
構築しているソフトウェアが何をしているのかに応じて、ソフトウェアエンジニアリングにはかなりのレベルがあります。
NASAは宇宙で有人シャトルを制御するソフトウェアを必要とするので、当然、エンジニアリングプロセスのレベルは、ロケットの写真を表示するWebサイトを構築するレベルよりもはるかに厳格です。
NASAで働いていた私の同僚の1人は、以前にソフトウェアエンジニアリングプロセスについて、何百ページもの正当化と何百時間もの会議を書いて、1行のコードを正当化することを説明しました。
私がこれを言っても失礼なことを言うつもりはありませんが、その時間、リソース、そして数十億ドルのコストがかかった後でも、スペースシャトルはまだ爆破しているので、誤解しないでください。
土木技師でさえ、設計にどれほど多くの理論を適用しても、最終的にはそれを壊してしまうため、緊急時の計画を立てる必要があることも知っています。
ソフトウェアを構築する際に、そのコストがクラッシュしてもめったに人命が失われることはないので、すぐに物を捨てて試運転する方がはるかに簡単です。物事をすぐに終わらせるとコードが脆弱になることに同意しましょう。これが常に当てはまる場合でも、ソフトウェアの動作を確認することは、開発者が弱点で強化する必要がある場所と比較して、弱点であり続ける必要があるよりも何倍も強力である必要がある場所を確認するための最良の方法です。積み荷。
総括する、 Premature optimization is the root of all evilまたは上司がいつも言うようにShipping is a feature!
良い答えはたくさんありますが、コンピュータサイエンスと土木工学の比較には不備があると思います。
厳密に言えば、プロのソフトウェア開発者が行うことは、コンピュータサイエンスというよりもソフトウェアエンジニアリングに似ています。より良い例えは、コンピュータサイエンスがソフトウェアエンジニアリングの物理学であることです。同様に、Civil Engieeringは、実際に物を構築するための物理の単純化と近似のコレクションです。
土木技術者が自分の仕事をするときに一般相対性理論を考慮に入れる必要があることはめったにないと思います。土木工学の多くは、ニュートン力学で安全に構築できます。同様に、ソフトウェアエンジニアリングは、理論的なコンピューターサイエンスを大まかに理解することで、非常にうまく達成できます。
大きな違いは、橋、超高層ビル、その他の土木工学の製品は、かなりよく理解されていることです。ソフトウェアエンジニアは、新しい構造を構築したり、よく理解されたものを構築するために新しい方法を使用したりしています。ソフトウェアエンジニアリングは、土木工学ほど成熟していないため、近い将来も当てはまるでしょう。
TL; DR：ソフトウェアエンジニアリングの理論と実践は、他の場所と同じように異なります。適切な例えは、ソフトウェアエンジニアリング：土木工学::コンピュータサイエンス：物理学です。しかし実際には、それよりも少し複雑です:)
だから私の質問は、なぜ一部のプログラマーは理論（形式的方法）と実践（物事を成し遂げる）の間にコントラストがあると思うのですか？
ソフトウェアの構築は、ブリッジの構築とは異なります。ソフトウェアには、最初から定義されている場合と定義されていない場合とではなく、ビルドされるオブジェクトが多数あります。標準は、保守と開発者のコラボレーションを容易にするために存在し、任意の数式やその他の理想に固執するものではありません。たとえば、変数に基づいて動作を選択する場合、スイッチを使用することが理にかなっている場合と、ファクトリパターンが使用されている場合があります。これは、メンテナンスの容易さと、パフォーマンスの問題などの特定された問題点に依存します。
別の例は、データ操作で作成できます。 .NETのコンテキストでデリゲートを使用することはしばしば意味があります。 Javaは、.NETのような関数型プログラミングスタイルのフレームワークサポートがないため、それほど簡単ではありません。つまり、一般的なケースでは、Xを単に実行することはできません状況Y。これは、XとYがN個の可変要素に依存するという事実によるものです。
ソフトウェアエンジニアリング（建築用ソフトウェア）は、土木工学（建築用家屋）などと比較して、多くの人が簡単に認識できますか？
「簡単」が正しい用語かわかりません。明確な証拠の欠如は、作業が行われていないという認識につながる可能性があります。または、同様に、その既存の作業は簡単に変更されます。
または、これらの2つの分野は本当に異なりますか（ミッションクリティカルなソフトウェアを除いて、ソフトウェアの障害は、建物の障害よりもはるかに受け入れられます）？
すでに述べた理由により、従来のエンジニアリングとソフトウェアエンジニアリングは大きく異なります。
あなたの認識はここで間違っているかもしれません、またはそれは十分に複雑なソフトウェアを書いていない人々からの多くのリソースを含んでいます。
あなたの経験は、私が知っているほとんどの人（十分に複雑なソフトウェアを設計して書いた人）が言うことと一致しています。
そうは言っても、ほとんどの場合programmers、何かを書く作業が彼らに伝わるとき、設計（つまり、「数学」）はすでに建築家/リードなどによって行われています。書く仕事の前に、彼らに届きます。したがって、それは最前線レベルからそのように見えるかもしれません。
この対比の理由は、ソフトウェアプロジェクトとハードウェアまたはアーキテクチャプロジェクトのライフサイクルが異なるためだと思います。ほとんどのソフトウェアは徐々に進化し、最初から最後まで計画されていません。ソフトウェア開発者は、開発に反復的なアプローチを適用できます。つまり、計画、実装、フィードバックを聞いてください。フィードバックが肯定的である場合は続行し、そうでない場合は-一歩下がって、戦略を再検討してください。そのため、ソフトウェア開発者はアジャイル開発、最小限の実行可能な製品などを持っています。
土木技術者にはそのような贅沢はありません。彼らにとって、いったん何かが計画されると、そのような変更のコストは悲惨なものになる可能性があるため、ソフトウェアのように簡単に変更することはできません。一方、ソフトウェア開発の場合、それほどコストはかかりません。これは、その利点のために使用できます。
しかし、ソフトウェア開発のすべてのブランチがそのようなアプローチを提供できるわけではありません。たとえば、航空または医療サービス用のソフトウェアを作成するには、非常に慎重な計画と多くの事前計算が必要です。
私も同じようです。標準的なブロック、標準的な強度のコンクリート、標準的な鋼から大きな建物を建てます。標準ライブラリから大きなアプリを構築します。
あなたは100階建ての建物の波動関数を書き込もうとしないのと同じ方法で、大きなアプリが正しいことを数学的に正式に証明しようとしないでください。
20年ほど前に自分の適性がソフトウェアにあることを発見する前に、私は機械および製造エンジニアでした。あなたがレイアウトした要素の多くに共感します。
問題の本質はhowにあるのではないかと思います。私たちは今、集団ベルトの下で10年ほどのアジャイル開発を行っており、メッセージは明確です。レイヤーごとに進行しないでください。機能ごとの進歩。確かに-レイヤーごとに進行する必要がある場合（たとえば、Webサーバーの前にネットワークスタックを構築する場合）のプロジェクトがありますが、実際のプロジェクトの大部分については、1つまたはいくつかの機能を提供するというレッスンを学びました。時は、テストされていない巨大な理論を構築し、それらを実装しようとするよりはるかに効果的です。
あなたの小屋の例を取りましょう（私は通常、1キロの長さの吊り橋ではなく、小川を横切って丸太を投げることによって橋を作ることについて話します...何でも！）、それをソフトウェア工学の世界に持っていきます。私が目にする主な違いは、ソフトウェアでは、ほとんどの作業が成功するために大きな事前のモデリングを必要としない規模のものであることです。初心者の間違いは、実際に必要なものよりも多くのことが必要であると想定することであることが多く、私たちのほとんどにとって、その間違いを何度かしたので、私たちは何度も何度もそれをやり直したくてたまらないです。
議論の余地はありません-17名のソフトウェアアーキテクトの委員会から始める必要のあるプロジェクトがあります。実際には、20カラットのダイヤモンドと同じくらい珍しいものです。
この類推には欠陥があると思います。私の知る限り、土木工学にはコンピュータサイエンスと同じような理論的根拠はありません。コンピュータサイエンスは、チューリングマシンのような理論的な数学から生まれました。土木工学は、母なる自然に抵抗し、多分美しく見える構造を作成することです。繰り返しになりますが、土木工学についてはあまり詳しくありませんが、P対NPに相当する土木技師、巡回セールスマンなど、頭を悩ませるための楽しいことはないと思います。そして、私たちのコンピュータサイエンス理論には間違いなく場所があります。誰かが出張中のセールスマンや、多くの素晴らしい新しい進歩のために私たちが抱えている停止問題を解決した場合。しかし、ソフトウェアを設計することをビジネスとするソフトウェアエンジニアにとって、このような問題は本当に楽しいゲームにすぎません。
さて、それはあなたが「理論」によって何を意味するかにも依存すると思います。 私たちは設計パターンについて話しているのでしょうか、それとも、補題を汲み上げていますか？優れたソフトウェアエンジニアであるためには、設計パターンをしっかりと理解することが絶対的に重要です。ただし、大規模なソフトウェアシステムを構築する場合、P/NP問題について理論化することは役に立ちません。その意味で、ソフトウェアエンジニアリングと理論的なコンピューターサイエンスの間には非常に明確なコントラストがあると私は信じています。
それとも理論はアルゴリズムを指しますか？アルゴリズムのクラスで学んだアルゴリズムを作成するために、多くのタイミングを費やす必要はありません。どうして？通常、それらは特定の場合にのみ必要です（そして、それを調べて調べます）、またはすでに作成されているライブラリを使用します。別のベイジアン分類器を書く必要はありません。抽象化は、コンピュータサイエンスの重要な原則です。ソフトウェアエンジニアは、アルゴリズムがどのように機能するかを必要になるまで学習しない傾向があると思います。
もう1つの理由は、現在有効なソフトウェア開発方法として人気のある「実現」ソフトウェアがいくつかあることです。たとえば、アジャイル開発では、システム全体を事前に構築する必要はありません。その理由は、まだ何を構築しているかは正確にはわかりません —作成しているものを柔軟にして、新しい情報や要件に適応させたいためです。最初からすべてを設計し、それを構築するだけでは、常に最高のソフトウェアが生成されるとは限りません。ただし、それはすべての解決策ではありません。たとえば、分散コンピューティングクラスタークレイジーな新しいものを設計しているとします。ナプキンのスケッチをして、スクラムを開始することはできません。
TL; DR。 「理論」という言葉については、いくらか疑問点があると思います。伝統的に、理論はコンピュータサイエンスの理論的な数学的側面を指します。より新しいコンピューティング方法を研究しているのでない限り、ほとんどの場合、理論的なコンピューターサイエンスはソフトウェアエンジニアの日常生活には関与しません。ソフトウェアエンジニアは、設計パターンとシステムアーキテクチャに関心があります。特定のアルゴリズムの具体的な実装の詳細は重要ではありません。多くの場合、それほど複雑ではないアイデアで、多くを設計せずにコーディングを開始するのが適切です。そして、これは、プログラマーが理論を好まないというアイデアから生まれたものだと思います。
現在、理論と実践のギャップは広すぎます。理論を実行すると、3つの公理が与えられ、その後、1行の定理に1000ページの証明があるか、まったく証明がないことが示されます。ソフトウェアエンジニアリングでは、指定されていない機能を実装する無数の（悪い）方法を提供する、何千もの関数からなる一貫性のないAPIが提供されます。
実際のソフトウェアエンジニアリングは、フォーマルな分野のほとんどの人を狂わせ、実際の数学的ソフトウェア開発は、エンジニアリングの人を狂わせます。どちらの分野でも適性の異なる人が必要で、適性が重複することはあまりないと思います。
形式理論では、製造された製品のようにすべてを事前に正確に計画でき、ソフトウェアが同じ環境内に無期限に存在し、一般的な抽象的な問題を解決することが常に目標であると想定しています。これは、製品としての4Dソフトウェアのライフサイクル（設計、開発、展開、完了）を想定しています。形式的な理論は、分析、抽象化、一般化、および将来の変化の予測を使用してソフトウェア設計の問題を解決することです。これは、簡単に分析でき、予測可能で、かなり静的である単純なドメインで明確に定義された問題がある場合に適しています。
実用的なプログラミングとは、適切な問題（ソフトウェア設計の問題ではない）を今すぐ適切な方法で解決することです。これにより、同僚は仕事をより速く、またはより速く、または収益を企業に流入させることができます。多くのソフトウェアは、製品のようなものではなく、「実行されない」ものではなく、生物のようなもので、1つの生態学的ニッチに特化して始まり、さまざまな寿命があり、その間に新しい予期しない問題を解決する必要があります。変化し続けるさまざまな環境。ビジネスの世界では、政治と合法性、そして競争と絶え間なく変化する組織、構造、および傾向により、要件は多くの場合、あいまいであり、あらゆる種類の特殊なケースで複雑であり、明確に定義されておらず、予期しない急速な変化の影響を受けます。それらは分析可能でも予測可能でも静的でもなく、論理的でも合理的でもありません。ソフトウェアは、20年間まだ使用されているのと同じように、2週間では無関係である可能性が高くなります。それは、あまり知られていないか、多くのことを行うことができない世界に入り、強力で柔軟に成長し、絶え間なく変化する環境や新しい問題に適応できるように、生涯を通じて育成、調整、トレーニングする必要があります。出生後にそれを怠ると、それが十分に長く存続すると野生になり、痛みと苦痛を引き起こし、鈍力の問題を解決します。
形式的な理論は、実際のビジネスソフトウェアの多くのニーズに対応していません。ソフトウェアを設計して実行できると信じ込ませます。それは時々固定、磨き、または物事に取り掛かることができる製品ですが、生涯を通じて常に注意と注意を払って適切に育てる必要がある生き物ではありません。だから私たちは本当に醜い野生のレガシーコードになってしまいますが、正式な理論はおそらくそれを助けなかっただろう。
それはすべてかなり否定的に聞こえますが、実際には形式理論を使用することが大好きです。美しいデザインはいつも笑顔になります。しかし、それは主に私の趣味のプログラミングであり、ビジネスの変動の影響を受けません。仕事では主にオーガニックコードを扱いますが、正しく成長し、私を誇りに思うようにし、それに対処する必要がある他の人に不快で失礼にならないように十分注意することを願っています。
利害関係はより低く、仕事はより簡単であり、経営者は優れた設計の価値をめったに見ません。システムの不安定性、保守性、整合性は「IT」の問題であり、「ビジネス」の問題ではありません。すべての幹部には、1つの共通点があります。彼らは95％がお金に焦点を合わせているか、そうである誰かに報告します。
残りの戦いは、あなたの仲間のプログラマーとの戦いです。それらの多くは、コーディングを開始する前に問題について考えることはできません。上記のため、これらの人々の多くは上級開発者であり、優れた設計を製品化することはさらに困難になっています。
私はプロジェクトが何年にもわたってアドホックな機能と修正を追加してプロジェクトを開始し、最初はロッキーだったプロジェクトを見て、混乱を秩序立てようとするあらゆる試みを「複雑すぎる」または「時間の浪費」のようなフレーズで撃ち落としています。経営陣が日常的に自分たちの刑務所を建設していることを経営陣が認めないため、主要なプロジェクトが避けられない破滅へのスパイラルを見るのは楽しいことではありません。しかし、多くの開発者が目撃し、そして良くも悪くもそれから学んだことは不幸な現実であると私は恐れています。
自分の作品の中でメディアを見つけようとしています。 「汚染された」プロジェクトでは、絶対に必要なコード以外は記述せず、あらゆる機会に機能の移動outを行います。 「プロジェクト間」では、私が実際に制御しているプロジェクトの設計とクリーンアップに時間を費やしています。
結局のところ、世界のプログラマの75％が腹を立てているのは、政治と個人の誠実さの大きな混乱です。私はそれをほとんど我慢できません。
まず、この質問が大好きです。私は3つの1000 Wordの回答のように書きましたが、最後までたどり着くまでに、すべてがひどく間違っていました。
2つを同じように比較しようとすることの問題は、プログラミングは、必要に応じて抽象化したり、具体的に緊密にバインドしたりできるモデリングプロセスであることだと思います。
一方、構造工学理論は、ユーザーが準拠しなければならない現実ベースの法律の非常に特定のセットに密接に結びついています。コンテキストや法律を変更することはできません。問題自体はそれらの法律に根ざしています。ただし、プログラミングでは、ソリューションが実際に質問の性質を変更したり、単に別のコンテキストに配置したりすることがあります。
たとえば、MVCパターンが完全に適合するかどうかは、そのコンテキストに大きく関係しています。デスクトップアプリケーションは通常、1つの言語と1つの言語のみを扱い、構成ファイルはカウントしません。
一方、Webアプリのフロントエンドは、主に2つの宣言型（非プログラミング）言語とJavaScriptで構成されています。完全に抽象化できない物理的なものの1つは、サーバーとブラウザの間で物事をつなぐこのhttpウォールが常に存在するという事実です。コードに埋め込む方法に関係なく、これには時間と非同期設計が必要です。
明らかに、MVCのような人気の高い評判の高いパターンを使用して、デスクトップアプリのコンテキストでの処理方法を変更せずに、Webのフロントエンドの懸念事項だけを処理することはできません。実際、私は主張するでしょう。MVCの有用性を認識している必要がありますが、特に厳密な方法や大規模な方法で実装することはできません。すべてのlook-at-me要素はユーザーのブラウザーによって処理され、すべてのdata/model-ish要素は通常サーバーのどこかにあるという点で、Webアプリのパラダイムは独特です。しかし、それはコントローラーをどこに残すのでしょうか？すべてサーバーにあるのか、それともフロントエンドにあるのか？誰かがそれを所有しなければなりません。または、MVCがシナリオに100％最適ではないかもしれません。 .NETのバックエンドに適しているわけではありません。特定のUIウィジェットのコンテキストではひどくない。しかし、一貫性を保つためにそれをすべてに適用しようとするのは、悪い動きかもしれません、IMO。
家を建てることは問題を解決します。ただし、典型的なプログラミングの問題は、多くの場合、問題内の問題の解決を伴います。解決策は、外側の問題を再定義することです。残念ながら現実はその考えに特に熱心ではありません。
Glenn Vanderburgは、ソフトウェアエンジニアリングとより伝統的なエンジニアリングの分野の違いについて素晴らしい見解を示しています。 http://www.youtube.com/watch?v=NP9AIUT9nos
土木技師が最終的なものを構築する前にコストをかけずに自分の設計をテストできれば、理論の使用ははるかに少なくなります。数秒以内にブリッジを1000回無料で構築して、いつ破壊されるかをテストできたら、理論上ブレーキがかかる可能性のある時期を計算するのに何ヶ月も費やす必要はありません...
ソフトウェア開発では、まさにそれがあなたの仕事です。理論的にはアルゴリズムの速度を計算する代わりに、アルゴリズムをテストして数秒で答えを知ることができます。
実際、今日のほとんどのソフトウェアは、計算能力やメモリなどの物理的な制約によって制限されなくなっています。ソフトウェアの制限は、ますます大規模なシステムになる複雑さです。今日のプログラミングで大きな課題となっているのは、人間がシステムを理解しやすい状態に保つことによって、この複雑さを管理することです。