なぜ一部のプログラマーは、理論と実践の間に対照があると思いますか？[閉まっている]

ソフトウェアエンジニアリングと土木工学を比較すると、私は異なる考え方を観察して驚いた：土木技師なら誰でも、庭に小さな小屋を建てたいなら、材料を手に入れて建てることができるのに対して、 10階建ての家（または、たとえばこのようなもの）では、崩壊しないことを確認するためにかなりの計算を行う必要があります。

対照的に、一部のプログラマーと話したり、ブログやフォーラムを読んだりして、次のように定式化できる幅広い意見をしばしば見つけます。理論と形式的方法は数学者/科学者向けであり、プログラミングは物事を成し遂げることです。

ここで通常暗示されているのは、プログラミングは非常に実用的なものであり、形式的な方法、数学、アルゴリズム理論、クリーン/コヒーレントなプログラミング言語などは興味深いトピックかもしれませんが、すべてが必要な場合は必要ないことです完了しました。

私の経験によれば、100行のスクリプト（小屋）をまとめるのにそれほど理論は必要ありませんが、複雑なアプリケーション（10階建ての建物）を開発するには、構造化された設計が必要です。定義されたメソッド、優れたプログラミング言語、アルゴリズムを検索できる優れた教科書など。

したがって、IMO（適切な量の）理論は、物事を成し遂げるためのツールの1つです。

私の質問は、なぜ一部のプログラマーが理論（形式的手法）と実践（物事を成し遂げる）の間に対照があると考えるのですか？

ソフトウェアエンジニアリング（ソフトウェアの構築）は、例えば土木工学（住宅の構築）と比較して多くの人が容易に認識してい ますか？

または、これらの2つの分野は本当に異なりますか（ミッションクリティカルなソフトウェアは別として、ソフトウェアの障害は建物の障害よりもはるかに許容されます）。

これまでの回答から理解したことを要約しようと思います。

1. ソフトウェアエンジニアリングとは対照的に、土木工学では、特定のタスクに必要な理論量（モデリング、設計）がはるかに明確です。
2. これは、土木工学が人類と同じくらい古く、ソフトウェア工学が数十年しか存在していないという事実に一部起因しています。
3. 別の理由は、ソフトウェアがより不安定な種類のアーティファクトであり、より柔軟な要件（クラッシュする可能性がある）、さまざまなマーケティング戦略（すぐに市場に出すために良いデザインを犠牲にすることができる）などであるという事実です。

結果として、適切な設計/理論の量がソフトウェアエンジニアリングに適切であるかを判断するのははるかに困難です（少なすぎる->乱雑なコード、多すぎる->私は決して終わらない） （多くの）経験が役立ちます。

したがって、あなたの答えを正しく解釈すると、 理論が実際にどれだけ必要かについてのこの不確実性が、一部のプログラマーが理論に対して抱く愛と憎しみの混合の原因になります。

主な違いは、土木工学では、現実世界の物理学が理論を正気に保ち、悪い慣行を制限する一定の強力な現実チェックとして機能するのに対し、ソフトウェア工学では非現実的な象牙の塔の概念を維持する同様に強い力がないことだと思います見掛け倒しの技量として。

多くのプログラマーは、暴走理論が物事を成し遂げるための積極的な障害になるという悪い経験をしてきました（「実行可能なUML」、超官僚的な開発プロセスなど）。反対に、最終的にはゆっくりですが、汚いハッキングやパッ​​チは、あなたをかなり気の遠くなるようなものにします。最後の段落で見たように、通常、失敗は最終的なものではないため、問題にはなりません。

ソフトウェア工学と土木工学にはほとんど共通点がありません。土木工学の取り組みは、材料の物理的特性と環境によって制限されています。土木技師は、土壌の特性と材料特性について多くの時間を費やします。ソフトウェア開発は、プロセッサの速度と利用可能なストレージによってのみ物理的に制限されます。これらは両方とも理解しやすく、私たちはそれらの研究に多くの時間を費やしません。ソフトウェア開発の主な制限は人間の知性です。また、2人の開発者は似ていません。このコードは保守可能ですか？誰によって？Haskellでのクイックソートの3行実装は、一部の人には明らかに正しいかもしれませんが、他の人には理解できません。2人のチームは1か月で申し込みを完了することができますが、10人のチームは1年で苦労します。

ソフトウェア開発はすべて設計であり、設計されているアーティファクトは、製造された記事よりもはるかに複雑であり、それぞれがユニークです。

多かれ少なかれ誠実な機械エンジニア（土木）がプログラマーになり、CS（AI）博士号、教師、そしてプログラマー（すみません、ソフトウェアエンジニア）になりました。この一般的な主題。

従来のエンジニアリングでは

• あなたは数学と科学を知るべきです
• 分野の「ヒーロー」とは、新しいものを発明し、新しいアイデアを発見し、解決不可能と考えられる問題を解決する人々です。

ソフトウェアに適用される「物理学」があります-情報理論ですが、ソフトウェアエンジニアはそれにほとんど触れず、確かに何も適用されません。彼らが得る最も理論は、計算可能性とビッグOです。

また、私はプログラミングを知っているだけで十分だと思う人々に絶えず驚いており、彼らは彼らのプログラムが何であるかという主題を理解する必要はありません。

さらに、独創性は奨励されません。最小公分母のグループ思考法を支持し、「読みやすさ」を装って推奨されていません。（航空技術者または原子力技術者が、後輩にとって理解しにくいかもしれないことを何もしないように奨励されていると想像してください。）

Webアプリのプログラミング方法など、彼らが学ぶことは大きな価値があります。配管工や電気技師のスキルも同様ですが、エンジニアリングではありません。

私がほとんどのソフトウェアでコーナーを切り、最高の設計ではないが、仕事を成し遂げる何かをすれば、誰も死なないでしょう。庭の小屋が10階建ての建物と同じ基準を必要としないのと同じ理由です。ただし、facebookのような非常に大きなアプリを作成することができます。もしそれが台無しになり、データなどが失われたとしても、それほど大したことではありません。また、10階建ての建物の基礎を置き換えるよりも、事後に大型アプリの基礎を修正する方が簡単です。それはすべて、コンテキストとリスクの計算に帰着します。

また、安全かつ簡単にアプリに追加し続けることもできます。10階建ての建物の新しい3階に簡単に放り込むことはできません（11階建てにします）。必要に応じて、毎日、大規模なアプリに新しい機能を追加できます。

現在、優れた設計により、これらすべてがプログラミングで簡単になります。しかし、貧弱な設計では不可能ではなく、リスクは...バグの多いソフトウェアです。通常は死にません。

これで我慢してください。ポイントがあります。

教授に、先延ばしにすることでより先延ばしになると言われたことがありますが、大抵の人は一晩中、紙の書き込み/詰め込み/プログラミングを急いで行った後、「もう二度とやりません。次回は早めに始めましょう早く終わらせてください。」完璧な先延ばし者としての私の経験では、これが真実であることがわかりました。そして、ここに教授の説明があります：先延ばしの経験がどれほど不快であっても、ほとんどの場合、あなたは相対的な成功を達成しました。これは、高リスク/高報酬の行動です。しばらくすると、あなたは不快感のすべてを忘れて、報酬だけを覚えています。したがって、最後に成功したので、先延ばしにする次の誘惑はますます魅力的です。

ここでは、よく見かける「物事を成し遂げる」プログラミング手法に類推できると思います。プログラマーまたはプログラマーのチームは、おそらく無知、怠laz、または真の時間的制約から、プログラミングに「物事を成し遂げる」アプローチを取り、すべての理論と数学と優れた実践を窓から追い出します。そして、あなたは何を知っていますか？彼らは物事を成し遂げます。エレガントでも、きれいでも、保守しやすいものでもありませんが、仕事は完了です。セマフォのセミコロンを知らない技術者ではない上司が「物事を成し遂げる」ことに対して高い評価を与えるかもしれません。したがって、プログラマーがプログラミングにこの緩いアプローチを採用するように誘惑されたとき、それはすべて簡単です。あなたの貧しい人でない限り、それは「簡単な」方法です。

私はあの貧しい、不幸な魂であり、おそらくあなたの多くもそうでした。私はあなたのすべてを懇願します。簡単な方法をとらないでください！:)

あなたの前提には欠陥があります。土木技師が大規模な建物、橋、トンネルなどを設計するときに工学を使用する主な理由は、必要な安全基準を満たす最小限の材料（コンクリート、構造用鋼など）を使用することです。材料や労働のコストが問題にならない場合、数学の方法をあまり使わずに高い建物を建てることは完全に可能です（たとえば、古代エジプトとマヤの文明のピラミッド）。素材をより効率的に使用できるようにします。

大規模なソフトウェアシステムの設計には、多少異なるダイナミクスがあります。どちらかといえば、通常は設計が不十分ですが、これは設計が作業の進行に合わせて動的に変更される可能性があり、土木工学プロジェクトでは簡単に変更できないためです。

共通の要因はコストです。従来の土木工学プロジェクトでの設計はコストを削減しますが（実際、材料の観点、および負債の観点から）、設計のコストが返される値を超えて増加するソフトウェア開発のポイントがあります。

また、エジプト人の時代から人類が「土木工学」に相当することを行ってきた他のいくつかの優れた対応に加えて、物事の一般的な理論を完成させるのに多くの時間を費やしたことも指摘します。終わり。私たちは約70年ほど前からソフトウェアを構築してきました（最初の「ソフトウェア」と考えるものによって異なります）。つまり、同じ種類の経験を開発するのに同じ時間はなかったということです。

建築家/土木技師の設計図は、「完成した」計画とほとんど同じではありません。常に変化します。どうして？「未知の未知数」があり、常に存在するためです。あなたが知っているので計画することができるもの、あなたが知っていることは知られていない、そしてあなたは調査し、推定することができるものがあります。「驚き」。できることをすべて学ぶことで、ほとんどのシステムでこれらを排除することを目指していますが、必要なのは、1つの小さな建物コード違反（建物が概念化されていた2年前には存在しなかったルールに基づく場合があります）とすべて-包括的マスタープランは、時には大幅に変更する必要があります。

ソフトウェアはこのようなものです。常に未知の未知があります。ただし、土木工学や構造工学とは異なり、ソフトウェア開発は本質的に、未知の未知のものが生み出す問題に基づいた変化にはるかに寛容です。10階建ての建物を建設していて、設計に使用する基礎の耐荷重能力を過大評価した場合、10階建てに建物を建てることができないか、かなりの量の作業を引き裂かなければなりません。基盤に戻り、それを強化または再構築します。ただし、ソフトウェアでは、ソリューション構造全体の特定の層に対する要求を過小評価した場合、他のすべての作業を無効にすることなく、その層を修正するための多くのオプションがあります。単一のDBサーバーをより強力なサーバー、またはレプリケーション/フェールオーバークラスターに置き換えることができます。または負荷分散/分散クラスター。ウェブサーバーでも同じです。入力サイズの誤った仮定に基づいて非効率的でシンプルなアルゴリズムをコーディングした場合、ほとんどの場合、アルゴリズムを知っている他のコードに影響を与えることなく、比較的外科的な方法で実装を削除して書き換えることができます（呼び出しを入力し、それ、またはそれからの出力を期待しています）。

この比較的容易な変更により、ソフトウェアエンジニアは、自分が知らないことを過度に心配することなく、自分が知っていることに基づいてコーディングすることができます。これにより、理論の緩い適用と事前の概念設計が可能になります。飛び込み、それを成し遂げ、コーディングの途中で変更が必要なものを見つけ、それらを変更します。問題が明らかになったとき、原因を特定して解決策を作成するのに役立つのは問題であるため、概念と理論をまだ知っている必要があります。しかし、「分析麻痺」に屈することなく、簡単な決定を下すことができます。なぜなら、もしあなたが「計算」を知らなかった、または考慮しなかった何かに基づいて間違った決定をしたなら、間違いは簡単に修正できます。

違いは主に既知の要件のためです：

• 理論面では、すべてが事前に定義されているため、開始する前に必要なものを正確に知ることができます。
• 実際には、すべてがそこにあるわけではありません。あるいは、実装の途中で何かを再設計しなければならない何かを発見した場合もあります。したがって、少なくとも初歩的なデザインでジャンプする方がはるかに良いので、これらの問題を早期に発見できます。

さらに、「理論」について話すとき、通常はソフトウェアエンジニアリングではなく、コンピューターサイエンスの理論面を意味します。これはコンピューターサイエンスの一部であり、その主な目的は、より優れた効率的なアルゴリズムを見つけ、何かが可能か不可能かを証明することです（たとえば、PやNPなど）。これらを心の奥に置いておくのは良いことですが、ソフトウェア開発ではあまり頻繁に登場しません。

私たちはそのようなことのために可能な限りライブラリを使用しています。

実際、構築しているソフトウェアが何をしているかに応じて、ソフトウェアエンジニアリングのレベルはかなりあります。

NASAは宇宙の有人シャトルを制御するソフトウェアを必要とするため、当然、エンジニアリングプロセスのレベルはロケットの写真を表示するウェブサイトを構築するレベルよりもはるかに厳密です。

NASAで働いていた同僚の1人は、ソフトウェアエンジニアリングプロセスについて、数百ページの正当化と数百時間の会議を記述して、1行のコードを記述することを正当化すると説明しました。

誤解しないでください。私はこれを言っても失礼に聞こえるつもりはありませんが、時間、リソース、数十億ドルのスペースシャトルがまだ爆発したにもかかわらずです。

土木技師でさえ、どれだけ多くの理論を設計に入れたとしても、最終的にそれが壊れてしまうので、緊急時対応計画を立てる必要があることも知っています。

ソフトウェアを構築するとき、クラッシュのコストが命を失うことはめったにないので、すぐにそこに物を投げて試運転するのがはるかに簡単です。物事を迅速に完了すると、コードが弱くなることに同意しましょう。これが常に当てはまる場合でも、ソフトウェアの実際の動作を確認することは、開発者がソフトウェアの弱点と強化の必要性を判断する最良の方法です。積み荷。

要約すると、Premature optimization is the root of all evil または上司がいつも言うようにShipping is a feature!

ここにはたくさんの良い答えがありますが、コンピューターサイエンスと土木工学の比較には欠陥があると思います。

厳密に言えば、プロのソフトウェア開発者が行うことは、コンピューターサイエンスというよりもソフトウェアエンジニアリングに似ています。より良い類推は、コンピューターサイエンスがソフトウェアエンジニアリングの物理学であるということです。同様に、Civil Engieeringは、物を実際に構築するための物理学の単純化および近似のコレクションです。

土木技師が仕事をする際に一般相対性理論を考慮する必要はほとんどないと思います。土木工学の多くは、ニュートン力学で安全に構築できます。同様に、ソフトウェアエンジニアリングは、理論的なコンピューターサイエンスを大体おおよそ理解することで、非常に成功することができます。

大きな違いは、橋梁、高層ビル、その他の土木工学製品がかなりよく理解されていることです。ソフトウェアエンジニアは、斬新な構造を構築したり、斬新な方法を使用してよく理解されたものを構築したりすることがよくあります。ソフトウェアエンジニアリングは、土木工学ほどFARほど成熟しておらず、近い将来に当てはまる可能性があります。

TL; DR：ソフトウェアエンジニアリングでは、理論と実践は他のどこにでもあるように異なります。適切な例えは、ソフトウェアエンジニアリング：土木工学::コンピューターサイエンス：物理学です。しかし実際には、それよりも少し複雑です:)

だから私の質問は、なぜ一部のプログラマーが理論（形式的手法）と実践（物事を成し遂げる）の間に対照があると考えるのでしょうか？

ソフトウェアの構築は、ブリッジの構築とは異なります。ソフトウェアには、開始時に定義される場合とされない場合がある多くのオブジェクトが構築されます。メンテナンスや開発者の共同作業を容易にするための標準が存在し、任意の数式やその他の理想を順守するものではありません。たとえば、変数に基づいて動作を選択する場合、スイッチを使用することが理にかなっている場合があります。メンテナンスの容易さと、パフォーマンスの問題などの特定された問題点に依存します。

別の例は、データ操作で作成できます。多くの場合、.NETのコンテキストでデリゲートを使用することは理にかなっています。Javaでは、.NETが持つ関数型プログラミングスタイルのフレームワークサポートがないため、それほど簡単ではありません。言い換えれば、一般的な場合、状況YでXを実行することは不可能です。これは、XとYがN個の可変因子に依存しているという事実によるものです。

ソフトウェアエンジニアリング（ソフトウェアの構築）は、例えば土木工学（住宅の構築）と比較して多くの人が容易に認識していますか？

「簡単」が正しい用語かどうかわかりません。明確な証拠の欠如は、作業が行われていないという認識につながる可能性があります。または、同様に、既存の作業は簡単に変更できます。

または、これらの2つの分野は本当に異なりますか（ミッションクリティカルなソフトウェアは別として、ソフトウェアの障害は建物の障害よりもはるかに許容されます）。

従来のエンジニアリングとソフトウェアエンジニアリングは、すでに述べた理由により大きく異なります。

ここではあなたの認識が間違っているか、十分に複雑なソフトウェアを書いていない人々からの多くのリソースが含まれている可能性があります。

あなたの経験は、私が知っているほとんどの人（十分に複雑なソフトウェアを設計および作成した人）が言うことと一致しています。

とはいえ、ほとんどのプログラマーの場合、何かを書くタスクが彼らに伝わると、設計（つまり「数学」）は既に建築家/リードなどによって行われています。書くタスクの前に彼らに届きます。そのため、最前線レベルからそのように見えるかもしれません。

この対比の理由は、ソフトウェアプロジェクトとハードウェアまたはアーキテクチャプロジェクトのライフサイクルが異なるためだと思います。ほとんどのソフトウェアは徐々に進化しますが、最初から最後まで計画されていません。ソフトウェア開発者は、反復的なアプローチを開発に適用できます。フィードバックの計画、実装、および聞き取りです。フィードバックが肯定的である場合、続行しますが、そうではありません-一歩下がって戦略を再考してください。ソフトウェア開発者がアジャイル開発、最小限の実行可能な製品などを持っているのはそのためです。

土木技師にはそんな贅沢はありません。彼らにとって、何かが計画されたら、ソフトウェアのように簡単に変更することはできません。そのような変更のコストは恐ろしいからです。一方、ソフトウェア開発の場合、それほど費用はかかりません。これは、利点を生かすために使用できます。

しかし、ソフトウェア開発のすべての部門がそのようなアプローチに対応できるわけではありません。たとえば、航空または医療サービス用のソフトウェアを作成するには、非常に慎重な計画と多くの事前計算が必要です。

私には同じようです。標準ブロック、標準強度コンクリート、標準鋼から大きな建物を構築します。標準ライブラリから大きなアプリを構築します。

100階建ての建物の波動関数を作成しようとしないのと同じ方法で、大きなアプリが正しいことを数学的に公式に証明しようとしない

20年ほど前に自分の適性がソフトウェアにあることを発見する前は、機械エンジニアおよび製造エンジニアでした。私はあなたがレイアウトした多くの要素に同情します。

問題の本質は、私たちがどのように物事を成し遂げるかということだと思います。私たちは今、私たちの集団ベルトの下で10年ほどのアジャイル開発を手に入れました。そのメッセージは明確です。レイヤーごとに進まないでください。機能ごとの進捗。確かに、レイヤーごとに進行する必要があるプロジェクト（たとえば、Webサーバーの前にネットワークスタックを構築する）がありますが、実際のプロジェクトの大部分については、作業機能を提供するレッスンを学びました。巨大な未検証の理論を構築し、それらを実装しようとすると、はるかに効果的です。

小屋の例を見てみましょう（私は通常、川にログを投げて長さ1キロメートルの吊り橋を渡って橋を作ることについて話します...）、それをソフトウェアエンジニアリングの世界に持ち込みます。私が見る主な違いは、ソフトウェアでは、作業の大部分が、成功するために大きな事前のモデリングを必要としない規模のものであることです。初心者の間違いは、物事が実際に必要とするよりも多くのことを必要とすることであることが多く、私たちのほとんどにとっては、何度かその間違いを犯したので、何度も何度もやり直すのが面倒です。

議論なし-17人のソフトウェアアーキテクトから成る委員会から始める必要があるプロジェクトがあります。実際には、20カラットのダイヤモンドほどまれです。

アナロジーに欠陥があると思います。私の知る限り、土木工学はコンピューターサイエンスと同じような理論的根拠はありません。コンピューターサイエンスは、チューリングマシンのような理論数学から生まれました。土木工学とは、母なる自然に抵抗し、さらには美しく見える構造を作り出すことです。繰り返しになりますが、私は土木工学についてはあまり知りませんが、P対NP、巡回セールスマンなどの土木技師に相当するものや、あなたの脳を打ち負かす他の楽しいものがあるとは思いません。そして、私たちのコンピュータサイエンス理論には間違いなく場所があります。誰かが巡回セールスマンや停止する問題を解決すれば、私たちは多くの驚くべき新しい進歩を遂げることになります。しかし、ソフトウェアを設計することをビジネスとするソフトウェアエンジニアにとって、このような問題は本当に楽しいゲームです。

さて、それはあなたが「理論」によって何を意味するかにかかっていると思います。私たちはデザインパターンを話しているのか、それとも補題をポンピングしているのか？優れたソフトウェアエンジニアになるためには、設計パターンをしっかりと理解することが絶対に重要だからです。ただし、大規模なソフトウェアシステムを設計する場合、P / NPの問題に関する理論化は役に立ちません。その意味で、ソフトウェア工学と理論的なコンピューターサイエンスの間には非常に明確な対照があると思います。

または、理論はアルゴリズムを指しますか？アルゴリズムクラスで学んだアルゴリズムを記述するタイミングの多くを費やす必要はありません。どうして？通常、特定の場合にのみ必要なため（そして、検索して調査する場合）、または既に作成されているライブラリを使用するためです。別のベイジアン分類器を記述する必要はありません。抽象化は、コンピューターサイエンスの重要な原則です。ソフトウェアエンジニアは、必要になるまでアルゴリズムの仕組みを学ばない傾向があると思います。

別の理由は、現在、効果的ないくつかの一般的な「やる」ソフトウェア開発方法があることです。たとえば、アジャイル開発では、事前にシステム全体を設計しません。これは、構築しているものがまだ正確にわからないためです。作成しているものを柔軟にし、新しい情報や要件に適応させる必要があります。最初からすべてを設計し、それを構築するだけでは、必ずしも最高のソフトウェアが生成されるとは限りません。しかし、それはすべての解決策ではありません。たとえば、分散コンピューティングクラスタクレイジーな新しいものを設計しているとします。ナプキンスケッチをいくつか実行して、スクラムを開始することはできません。

TL; DR。私は「理論」という言葉の周りにいくらかの曖昧性があると思う。伝統的に、理論はコンピュータサイエンスの理論的な数学的側面を指します。コンピューティングの新しい方法を研究しているのでない限り、理論的なコンピューターサイエンスの大部分は、ソフトウェアエンジニアの日々の生活に関与していません。ソフトウェアエンジニアは、設計パターンとシステムアーキテクチャを重視します。特定のアルゴリズムの具体的な実装の詳細は重要ではありません。多くの場合、それほど複雑ではないアイデアでは、多くを設計せずにコーディングを開始することが適切です。そして、プログラマーが理論を好まないというアイデアがここから生まれたと思います。

現時点では、理論と実践のギャップは大きすぎます。理論を実行すると、3つの公理が与えられ、その後、1行の定理には1000ページの証明があるか、まったく証明がないことが示されます。ソフトウェアエンジニアリングでは、数千の関数からなる一貫性のないAPIが提供されます。これにより、指定不足の機能を実装する無数の（悪い）方法が提供されます。

実際のソフトウェアエンジニアリングは、正式な分野の人々のほとんどを狂わせ、実際の数学的ソフトウェア開発はエンジニアリングの人々を狂わせます。どちらの分野にも異なる適性の人々が必要であり、適性がしばしば重複するとは思わない。

形式理論では、製品のようにすべてを事前に正確に計画でき、ソフトウェアは同じ環境内に無期限に存在し、一般的な抽象的な問題を解決することが常に目標であると想定しています。これは、製品としての4Dソフトウェアのライフサイクル（設計、開発、展開、完了）を想定しています。形式理論は、分析、抽象化、一般化、および将来の変化の予測を使用して、ソフトウェア設計の問題を解決することです。これは、簡単に分析可能で、予測可能で、かなり静的な簡単なドメインで明確に定義された問題がある場合に適しています。

実用的なプログラミングとは、適切な方法（ソフトウェア設計の問題ではない）を今すぐ正しい方法で解決することです。そうすることで、同僚は仕事をより良く/速く/まったくできるようになります。多くのソフトウェアは製品のようなものではなく、決して「行われた」ものではなく、生物のようなものであり、1つの生態学的なニッチのために高度に専門化され、さまざまな寿命を持ち、その間に予期せぬ新しい問題を解決する必要があります多種多様な絶えず変化する環境。ビジネスの世界では、政治や合法性、競争、絶えず変化する組織、構造、傾向により、要件はしばしば曖昧であり、あらゆる種類の特殊なケースに複雑で複雑に定義されており、急速な予期せぬ変化にさらされています。分析、予測、静的ではありません。多くの場合、論理的または合理的ではありません。このソフトウェアは、20年後もまだ使用されているのと同様に、2週間で無関係になる可能性があります。それは多くを知らないか多くのことを知らずに世界にやって来ます。そして、強く、柔軟で、絶えず変化する環境と新しい問題に適応できるように、その生涯を通じて育成、手入れ、訓練する必要があります。出生後にそれを無視すると、それが十分に長く生き残ると野ferになり、痛みと苦痛を引き起こし、鈍い力で問題を解決します。

形式理論は、実際のビジネスソフトウェアの多くのニーズに対応していません。ソフトウェアを設計して実行できると信じ込ませます。時々固定、研磨、または物を貼り付けることができる製品であるが、生涯にわたって適切な注意と注意を払って適切に飼育する必要のある生物ではないこと。したがって、非常にugい野生のレガシーコードになりますが、正式な理論はおそらくそれを助けなかっただろう。

それはすべてかなり否定的に聞こえますが、実際には形式理論を使うのが大好きです。美しいデザインはいつも私の顔に笑顔をもたらします。ただし、それは主に私の趣味のプログラミングであり、ビジネスの変遷の影響を受けません。職場では、私は主にオーガニックコードを扱っていますが、適切に成長し、誇りに思って、それを処理する必要のある他の人に不快で失礼にならないように十分注意を払うことを願っています。

利害関係はより低く、仕事はより簡単であり、経営陣は優れたデザインの価値を見ることはめったにありません。システムの不安定性、保守性、および整合性は「IT」の問題であり、「ビジネス」の問題ではありません。すべての幹部には共通点が1つあります。彼らは95％がお金に焦点を合わせているか、誰かに報告します。

残りの戦いは、仲間のプログラマーとのものです。それらの多くは、コーディングを開始する前に問題について考えることをコミットできないか、コミットしません。上記の理由により、これらの人々の多くは上級開発者であり、優れた設計を実稼働に移すことをさらに難しくしています。

私は、プロジェクトリードが最初は岩だらけだったプロジェクトにアドホックな機能と修正を追加するのに何年も無駄に費やしていることを見てきました。経営陣が日常的に自分の刑務所を建設していることを認めないため、避けられない運命への主要なプロジェクトのスパイラルを見るのは楽しいことではありません。ただし、多くの開発者が目撃しているのは残念な現実であり、良くも悪くも学ぶことができます。

作品の中から媒体を見つけようとしています。「汚染された」プロジェクトには、絶対に必要なコード以上のコードを書くことはありません。あらゆる機会を利用して、それらから機能を削除します。「プロジェクト間」では、実際に制御しているプロジェクトの設計とクリーンアップに時間を費やしています。

結局のところ、世界のプログラマーの75％が腹を立てないのは、政治と個人の完全性の大きな混乱です。私はほとんど我慢できません。

まず、この質問が大好きです。私は3つの1000の単語の回答のように書いたが、それらが終わるまでにすべてが恐ろしく間違っていた。

この2つを類似したものとして比較しようとすることの問題は、プログラミングは、あなたが望むように抽象的であるか、具体的に固く結びつくことができるモデリングプロセスであると思います。

一方、構造工学理論は、準拠しなければならない非常に具体的な現実ベースの法律のセットに密接に結びついています。コンテキストや法律を変更することはできません。問題自体はこれらの法律に根ざしています。ただし、プログラミングでは、ソリューションが実際に質問の性質を変更したり、単に異なるコンテキストに配置したりすることがあります。

たとえば、MVCパターンが完全に適合するかどうかは、そのコンテキストに大きく関係しています。通常、デスクトップアプリケーションは1つの言語と1つの言語のみを扱い、構成ファイルはカウントしません。

一方、Webアプリのフロントエンドは、主に2つの宣言型（非プログラミング）言語とJavaScriptで構成されています。完全に抽象化できない物理的なことの1つは、サーバーとブラウザーの間で物事を追い詰めるために、このhttp壁が常にあるという事実です。コードに埋め込む方法に関係なく、時間と非同期設計が必要です。

明らかに、MVCのような一般的でよく知られているパターンを使用して、デスクトップアプリのコンテキストで処理する方法を変更せずに、Web上のフロントエンドの問題を排他的に処理することはできません。実際、MVCが便利になる理由を知っておく必要がありますが、MVCを特に厳密な方法または大規模な方法で実装しようとはしません。Webアプリのパラダイムは、すべてのLook-At-Meのものがユーザーのブラウザーによって処理され、すべてのデータ/モデルのようなものが通常どこかのサーバー上にあるという点で独特です。しかし、それはコントローラーをどこに残すのでしょうか？サーバー上のすべてですか、フロントエンド上のすべてですか？誰かがそれを所有しなければなりません。または、MVCはシナリオに100％最適ではありません。.NETのバックエンドのものには良くない。特定のUIウィジェットのコンテキストではひどいものではありません。

家を建てることで問題は解決します。ただし、典型的なプログラミングの問題は、多くの場合、問題内の問題の解決を伴い、解決策は外側の問題を再定義することです。残念ながら、現実はその考えに特に熱心ではありません。

グレンヴァンダーバーグは、ソフトウェアエンジニアリングと従来のエンジニアリング分野との違いについて素晴らしい見解を提示しています：http : //www.youtube.com/watch? v=NP9AIUT9nos

土木技師が、最終的なものを構築する前に費用なしで設計をテストできれば、理論の使用ははるかに少なくなります。数秒以内に、橋が壊れる時期をテストするために何千回も橋を架けることができれば、理論的にはブレーキをかけるかもしれないときに計算するのに月を費やすのではなく、そうするでしょう...

ソフトウェア開発では、まさにそれがあなたのすることです。アルゴリズムの理論上の速さを計算する代わりに、数秒以内にアルゴリズムをテストして答えを知ることができます。

実際、今日のほとんどのソフトウェアは、計算能力やメモリなどの物理的制約によって制限されなくなりました。ソフトウェアの制限は、より大きなシステムで複雑になることです。システムを人間が理解できる状態に保つことでこの複雑さを管理しているため、今日のプログラミングにおける大きな課題となっています。