プログラマーは建設業界から何を学ぶことができますか？[閉まっている]

ソフトウェアの設計と開発の原則について同僚と話したとき、類推の最も一般的なソースの1つは建設業界であることに気付きました。私たちはソフトウェアを構築し、設計と構造をアーキテクチャと見なします。

学ぶ（または教える）ための最良の方法の1つは、類推を分析することです。他の類推は構築から引き出すことができますか？ （ソフトウェアですでに一般的に使用されているかどうか）。

プログラミングコンセプトが構築コンセプトにどのように似ているかについて、説明または個人的な経験を提供してください。

^{[ アイデアに対する芸術と人文科学から得られたクレジットからプログラミングへの概念 ]}

それがデザインパターンの由来です。

コンセプトを世界に紹介したとされる人物は、1977年に彼の著書「パターン言語：町、建物、建設」でクリストファー・アレクサンダーでした。そこから、ギャングオブフォー（GoF）が拾い上げ、残りは歴史です。

講義中やソフトウェア開発と建築の本の中でさえ、建設業界とソフトウェア開発業界の類似性は今もなお普及しています。

私が考えたり思い出したりできるいくつかの類推と参考文献：

• たとえば、建物の建設中に要件を変更すると、クライアントにとって、これがいかに馬鹿げているかが明らかになるでしょう。
• 足場などの一時的な援助（建設業界での意味| ソフトウェア開発）
• クライアントは、コストをかけずに機能を追加し続けることはできません。多くの場合、無料でやりたいことがあります。それは建設業界では起こり得ないことです（要件のクリープを参照）。
• ソフトウェア開発における役割：アーキテクトはソリューションの設計の中心です。コンサルタントと請負業者は交換可能な用語にすることができます。労働者はプログラマーです。
• クライアントは両方の場合に正確な要件を提供できません。
• 予算と時間の見積もりはしばしば間違っています。
• 製品は最後まで本当の形で本当に見ることができません。
• 建物には、ソフトウェアにバグがあるのと同じように、建設後に建設上の欠陥がある場合があります。
• 製品の仕上がりが悪い場合は、修理するよりも取り壊してやり直すほうが望ましい場合があります。
• 質の低い仕事の実際の結果と実際の結果を知らないため、クライアントは最も安価なソリューションを望んでいます。
• オープンソース。Doc Searlsの「すべてのビジネスがオープンソースに基づいている理由」と呼ばれるこの講演を見たところ、建築物がオープンソースコミュニティのように特許を取得するのではなく、建築コミュニティがどのように技術や一般的な知識を共有するかを説明しています。独自の製品が組み込まれています。
• クライアントが積極的に関与すれば、プロジェクトはすべての人にとってより良い結果になります。

（さらに思いついたら、それらを追加します。）

一般的なアナロジーが正しいとは思わない人もいますが、これに関する推奨読書はThe Software Construction Analogy is Brokenです。また、SOには、ソフトウェアと建築構造の類似点とは何が問題なのかという質問があります。。

私たちはソフトウェア開発の歴史を通じて建設業界から多くの言葉やアイデアを取り入れてきましたが、実際にはおそらく多くのものに引き継がれたと思います。

顧客が仕様を作成し、次に建築家が計画し、次にエンジニアが設計し、最後に建設業界から実装するコードモンキーを作成するプロセス全体を取りましたが、完全に見当違いでした。

これは、家を建てるとき、土台が間違っていれば、あなたは退屈しているからです。真剣に効果的。建物を持ち上げて交換するには、すべてを廃棄してやり直すよりも費用がかかります。しかし、ソフトウェアでは完全に可能です。ユーザーが気付かないうちにクライアントソフトウェアをクライアントサーバーソリューションに作り直しました。ただし、モデムをサーバールームに移動しました。それは住民が寝ている間にコンクリートの基礎をボートに置き換えるようなものです。

ソフトウェアは建設のようなものではありません。そして、それがソフトウェア業界全体がいたずらの始まりの時期を迎え、わずか数年でプロジェクトを実行する「ウォーターフォール」プロセス全体がアジャイルプロセスに置き換えられた理由です。

言葉くらい当然と誤って、建設から取られています。

フレームワークは、まだ採用されていない最も明白なものです。そして、パイプがあります。

私はこのアナロジーを使用しました...多くのソフトウェアプロジェクトは、ソフトウェアを必要とする人が「便利屋」に相当するものを知っているために始まります。それは非常にうまく機能する、小さくて便利な小さなアプリケーションです。

その後、顧客は作業に満足して便利屋に戻り、ソフトウェアを変更してもう1つのことを行うように依頼します。多くの場合、この新しい機能は元のリクエストとはあまり関係がないため、庭の裏に別の入り口のある別の部屋を建てるように頼んでいるようです。

それから彼らは小屋の内側にライトを置きたいので、便利屋が戻ってきて、彼は家のメインパネルから単一の回路を走らせ、各部屋の天井にプルチェーンライトスイッチを設置し、それらを回路に接続します。

その後、顧客はいくつかの電動工具を使いたいと判断しますが、回路ブレーカーを吹き続けますので、彼らは人に電話をかけ、実際に彼が実行した単一の回路をメインパネルに引き裂き、より大きな導体と小屋のサブパネル。彼はワイヤーを2回走らなければならず、2つの電気的許可などの支払いをしなければなりませんでした。これは非効率的です。

その後、クライアントは不合理なものを求めます。私の庭の小屋をガレージに変えることができますか？あなたがやったことをやり直してほしくありません...私はあなたがそこに私の車を駐車できるようにそれをもっと大きくしてほしいです。その後、多くの場合、便利屋は「顧客は常に正しい」と考え、小屋の3つの側面に追加物を構築して大きくし、パーティション間の壁を倒します。もちろん、屋根は終了します正しく構築されていないため、たるみが発生するなど

そのため、クライアントはそれほど感銘を受けていませんが、それでもクライアントはそれを望んでいます。彼らはただもう一畳の部屋を追加し、またはこれを行うには、この既存の部屋を変更するには何度も戻って便利屋を尋ねるなどあなたのように見えることを何かで終わるバロウは約など建築音です。

現在、ほとんどの人は建設業界でこれを試すほど愚かではありませんが、これらの接続を行わないため、ソフトウェアの世界では常に起こります。

1. 本当に素敵な庭の小屋を建てる資格がある人は、必ずしも家を建てる資格がありません。

2. 前もって段階的に家を建てようとしていることを知っていたが、それが庭の小屋として始まっただけだったら、あなたは別のことをするだろうし、庭の小屋はもっと費用がかかるだろう（あなたは注ぐだろう）本当に厚いパッド、完成した家の全負荷などに十分な大きさの導体を走らせたことを確認してください）。

3. 多くの場合、ある段階から別の段階にアップグレードすると、以前に行われた多くの作業が取り消され、必要以上に高価になります。

4. 建設の世界では、設計段階で結果がどのようになるかを顧客に良いアイデアを与えることができますが、ソフトウェアの世界ではそのような能力はありません。その時点まで到達した場合、基本的にソフトウェアの大部分を作成しました。

アジャイルマニフェストは、ソフトウェア/構造の類推が壊れていることを認めた結果です。自動化された単体テストや反復的なリリースサイクルのようなものは、構築において類似していません。これらのことは、設計からプロトタイプに移行するコストがほぼゼロであることを利用します（これをコンパイルまたはビルドと呼びます）。

Finish workとTrimという用語が思い浮かびます。

主要な構造的決定がいつ完了するかについて、審美的な選択を延期してもよいという考え。

古い格言：2回測定して1回カットします。

編集： Atul GawandeによるThe Checklist Manifestoに は、大規模な建設作業の管理に関するセクションがあります。彼らが本当に複雑なポイントに達すると、彼らは問題を再検討し、プロジェクト中に誰もが知っておくべき何かが発生したかどうかを確認するために関係する専門家との会議を持っています。おそらく事前に計画することはできません。

制限は、構築とプログラミングの両方に存在します。

あなたが顧客として週末に完成したホテルの建物を拡張し、ペントハウスの地下階と滑走路に空港を置くようなばかげた要求をすることができないなら、なぜあなたは完成したものですべての調整を受け入れられないのですか？ソフトウェアは可能ですか？それは0と1の魔法のボールではなく、重要ではないがその制限もある複雑な構築構造です。

私は学校で建設作業をしていましたが、類推すらできない場所があり、同じ概念が当てはまります。しかし、多くの場合、比較の誘惑は行き過ぎです。

仕事の見積もりに取り組んだとき、何かをするのにどれくらいの時間がかかるかについて、かなりしっかりした平均があることを知っていました。たとえば、店頭の窓を作るために、私たちは単に計画からフレームの接合部の数を数え、それがどれくらいかかるかについてかなり良い考えを持っていました。プログラミングと同じように、スケジュールの変数を考慮する必要がありましたが、それはあなたの命を奪う可能性があります。たとえば、駐車場が舗装されていて、道の高温アスファルトのために建物に入ることができないことを見つけるために配管の乗組員を表示することはかなり高価です。

しかし、建設には何千年もの経験があります。貿易の基本的なルールは、いつもの物理法則に基づいています。風荷重と死荷重の計算は、スライドルールで行われたときと同じです。ツールとテクニックの改善が行われましたが、私たちが経験しているものと比較すると、氷河のようなペースです。

一方、私たちのパターンと実践の多くは改善の余地が必要であることをまだ発見しています。シングルトンは以前は良いアイデアでしたが、今ではそれについて考える人のほとんどがIoC / DIパターンを好みます。

私たちも欠けているのは、意味のあるライセンスと認証です。多くの分野では、単にインストーラーはもちろんのこと修理工であっても、配管工は免許を取得するか、誰かの監督の下で働く必要があります。そのライセンスを取得するには、フィールドでの作業に一定の時間が必要です。私はライセンスの賛成または反対を主張しているのではなく、それが大きな違いであると指摘するだけです。

もちろん、どちらの分野でも、アーキテクトは実装できないものを描くことができます。

足場、「建物やその他の大きな構造物の建設または修理で人と物資を支えるために使用される一時的な構造物」。^{[ウィキペディアからの定義]}

この概念は、プログラミングの足場を迅速に作成することができ、実際の構造が整うまで一時的な機能を提供するために機能します。

私はいくつかの建設会社が最低入札者に働きかけ、ずさんな仕事をし、保証義務を怠り、品質よりも日付を重視し、「完成品」製品にばかげた利益を請求することを知っています。

しかし、プログラマーやコンサルティング会社がこれらの実践から何かを学んだとは思いません。

バグは最終的には地獄のように高価になったり、人を殺したりする可能性がありますか？

あらゆる分野の複雑なエンジニアリングプロジェクトのための基本的なガイドラインがあります。

1. 計画、青写真、デザインなどの重要性、
2. 基礎となる数学の重要性
3. 他の同様のプロジェクトからのアイデア/学習の再利用
4. 他の人が作成した既製のビルディングブロック/コンポーネントを使用する
5. ライフサイクルの非常に早い段階で問題を修正する
   など。

アーキテクチャ、土木、ソフトウェアエンジニアリングの各分野の共通点は、主に組立ラインがないことに起因するようです。すべてのプロジェクトは、独自の方法でユニークです。

時間とともに

しかし、建設業界では、労働者は残業代を支払われます。

標準、規約、および事前に構築されたコンポーネントの使用。この種の問題に遭遇する可能性は低いでしょう。

私たちのカスタムビルドソケットに適合するものは、市場で見つけることができません。

あなたが持っているすべてがハンマーであるとき、すべては釘のように見えます。:)

反復的なひずみ損傷

それらは両方の産業での職業上の危険であり、それらを防ぐために予防策を講じなければなりません。いったん開始すると、治療するのは困難です。