プログラマーは建設業界から何を学ぶことができますか？
ソフトウェアの設計と開発の原則について同僚と話していると、アナロジーの最も一般的なソースの1つが建設業界であることに気付きました。私たちはbuildソフトウェアであり、設計と構造をarchitectureと見なしています。
学ぶ（または教える）ための最良の方法の1つは、アナロジーを分析することです-他のどのアナロジーを構築から引き出すことができますか？（すでに一般的に使用されているかどうか）ソフトウェアかどうか）。
プログラミングの概念が構築の概念にどのように類似しているかについて、説明、または個人的な経験を提供してください。
[クレジット 芸術と人文科学から取ったプログラミングの概念 アイデアについて]
デザインパターンの出所です。
1977 の本「A Pattern Language：Towns、Buildings、Construction」でこの概念を世界に紹介したとされる人物は、クリストファーアレクサンダーでした。そこから、 ザギャングフォー （GoF） ピックアップ 、そして残りは歴史です。
講義中、ソフトウェア開発およびアーキテクチャブックにおいても、建設業界とソフトウェア開発業界の類似点は今もなお広まっています。
私が考えたり思い出したりできるいくつかの類似点と参考文献：
- たとえば、要件の変更建物の建設中に、これがいかに馬鹿げているか、たとえば「OH、そして私はあなたがキッチンを完成させた場所の代わりにガレージが欲しい」とクライアントに明らかになるでしょう。です」。
- scaffolding（- 建設の世界 | ソフトウェア開発 ）のような一時的な支援
- クライアントは維持できません機能を追加するコストがかからなければ、多くの場合、無料で物事をやりたいと思っています。それは建設業界では起こり得ませんでした（ 要件のクリープ を参照）。
- ソフトウェア開発におけるroles：アーキテクトはソリューションの設計の中心です。コンサルタントと請負業者は交換可能な用語にすることができます。労働者はプログラマーです。
- クライアントは、どちらの場合も正確な要件を提供できません。
- 予算と時間の見積もりはしばしば間違っています。
- 製品は実際には最後まで真の形式で表示することはできません。
- 建物は、ソフトウェアがバグと同じように、ビルド後に 建設障害 を持つ可能性があります。
- 製品の仕上がりが悪い場合は、修正するよりも解体してやり直すのほうが好ましい場合があります。
- 質の低い作業の実際の結果と実際の結果について知らないため、クライアントは最も安価なソリューションを求めています。
- オープンソース。 「 すべてのビジネスがオープンソースに基づく理由 」と呼ばれるDoc Searlsからのこの講演を見ていたところ、彼は建設コミュニティが技術や一般的な知識をオープンソースコミュニティのように特許を取得するのではなく共有する方法を語っています、ビル内の一部のものにビルトインの専用製品が含まれている場合でも。
- プロジェクトもっと良くなるすべての人にクライアントが積極的に関与している場合。
（もっと思いついたら追加します）
一般的なアナロジーが正しいとは思わない人もいますが、これの推奨される読み方は ソフトウェア構築アナロジーは壊れています です。また、これに関してSOタイトル ソフトウェアと建物の構造の類似点の何が問題になっているのですか？ >に関する質問があります。
私たちはソフトウェア開発の歴史を通じて建設業界から多くの言葉やアイデアを取り入れてきましたが、実際、私たちは多くの人に取り入れたと思います。
私たちは、顧客が仕様を作成し、次に建築家の計画を立て、エンジニアが設計し、最後に建設業界から実装するサルをコーディングするというプロセス全体を取りましたが、それは完全に誤解されていました。
これは、家を建てるときに、基盤が間違っていると、あなたは疲れ果てているからです。真剣に退廃。建物を持ち上げて基礎を置き換えるには、全体を廃棄してやり直すよりもコストがかかります。しかし、ソフトウェアでは完全に可能です。モデムをサーバールームに移動した以外は、ユーザーが何も気付かずにクライアントソフトウェアをクライアントサーバーソリューションに作り直しました。それは、住民が寝ている間にコンクリートの土台をボートに置き換えるようなものです。
ソフトウェアはではない構築のようなものです。そしてそれが、ソフトウェア業界全体がいたずらの初めに時間を有効にし、プロジェクトを実行する「ウォーターフォール」プロセス全体がほんの数年でアジャイルプロセスに置き換えられた理由です。
wordsに関しては、多くのことが正しく、そして間違って、構築から取られます。
Frameworkは、まだ取り上げていない最も明白なものです。そしてパイプがあります。
私はこのアナロジーを使用しました...ソフトウェアを必要とする人が「便利屋」に相当するものを知っているため、多くのソフトウェアプロジェクトが始まります。彼らはこの人を雇って、庭の小屋に相当するソフトウェアを構築します。小さくて便利な小さなアプリケーションで、非常にうまく機能します。
その後、顧客は作業に満足して便利屋に戻り、ソフトウェアを変更してもう1つ実行するように依頼します。多くの場合、この新しい機能は元の要求とはあまり関係がないため、別の入り口のある庭の小屋の裏に別の部屋を建てるように要求されているように見えます。
次に、彼らは小屋の中にライトを入れたいので、便利屋が戻ってきて、家のメインパネルから単一の回路を実行し、プルチェーンライトスイッチを各部屋の天井に設置して、回路に接続します。
その後、顧客はいくつかの電動工具を使用することを決定しますが、回路ブレーカーを吹き続けます。そのため、彼らはその人に電話をかけ、彼は実際に彼が走った単一の回路をメインパネルに引き離し、より大きな導体と小屋のサブパネル。彼はワイヤーを2回走らせ、2つの電気許可などを払わなければなりませんでした。これは非効率的です。
それからクライアントは何かばかげたことを尋ねます：私の庭の小屋をガレージに変えることができますか？あなたがしたことをやり直してほしくない...車を駐車できるように、もっと大きくしてほしい。次に、多くの場合、便利屋は「顧客は常に正しい」と考え、小屋の3辺に追加を加えてそれを大きくし、間仕切りの間の壁をノックダウンします。もちろん、屋根の端は正しく構築されていないため垂れ下がるなど.
そのため、クライアントはもうそれほど感心していませんが、それでも彼らはもっと欲しがっています。彼らは便利屋に何度か繰り返して部屋を1つ追加するか、この既存の部屋を変更してこれを行うなどしています。あなたは The Burrow のようなものになり、ほぼ建築的に健全です。
現在、ほとんどの人は建設業界でこれを試すのに十分な愚かではありませんが、ソフトウェア業界ではいつでも起こります。
本当に素敵な庭の小屋を建てる資格のある人は、家を建てる資格があるとは限りません。
家を段階的に建設することを事前に知っていたが、それが庭の小屋として開始するだけであった場合は、別の方法で行い、庭の小屋はより多くのコストがかかります（本当に厚いパッド、完成した家の全負荷などに十分な大きさの導体を実行したことを確認してください）。
多くの場合、あるステージから別のステージにアップグレードするには、以前に行われた作業の多くを取り消す必要があり、本来のように思われるよりもコストがかかります。
建設の世界では、設計段階での結果がどのようになるかをお客様によく伝えることができますが、ソフトウェアの世界ではそのような能力はありません。あなたがそれまでにそれを手に入れれば、基本的にソフトウェアのかなりの部分を書いたことになります。
アジャイルマニフェストは、ソフトウェア/構築のアナロジーが壊れていることを認めた結果です。自動化された単体テストや反復的なリリースサイクルのようなものは、構造的には平行関係がありません。これらは、設計からプロトタイプ（コンパイルまたはビルドと呼ぶ）に移行するためのほぼゼロのコストを利用しています。
Finish workおよびTrimという用語が思い浮かびます。
主要な構造上の決定が完了したときのためにいくつかの審美的な選択を延期しても大丈夫であるという考え。
古い格言：2回測定して1回カットします。
編集：チェックリスト宣言 には、Atul Gawandeによるセクションがあり、大規模な建設ジョブの管理について説明しています。彼らが本当に複雑なポイントに達したとき、彼らは問題を再検討し、プロジェクト中に誰もが知っておくべきことが起こったかどうかを確認するために、関係する専門家とのミーティングを行います。我々はおそらくそれらを事前に計画することはできません。
構築とプログラミングの両方に制限があります。
顧客が週末に完成したホテルの建物を拡張し、空港を地下階とペントハウスの滑走路に配置するなど、とんでもない要求をすることができない場合、完成したものですべての調整を受け入れることができないのはなぜですかソフトウェアは可能ですか？これは0と1の魔法の球ではなく、重要ではありませんが、複雑な構造構造ですが、制限もあります。
私は学校を通して建設に携わっていましたが、たとえそれが類推すらできない場所もあり、同じ概念が適用されます。しかし、多くの場合、比較の誘惑は行き過ぎです。
私が仕事の見積もりを作成したとき、何かを行うのにかかる時間にはかなりしっかりした平均があることを知っていました。たとえば、店頭の窓を製造するために、計画からフレーム内のジョイントの数を数えるだけで、それがどのくらいの時間を要するかについてかなり良い考えがありました。プログラミングのように、私たちはスケジュールの中で変数を考慮に入れなければなりませんでしたが、それはあなたの人生を吸う可能性があります。たとえば、配管のクルーが駐車場が舗装されていて、高温のアスファルトが原因で建物に入ることができないことに気付くと、かなり高額になります。
ただし、建設には何千年もの経験があります。貿易の基本的なルールは、これまでと同じ物理法則に基づいています。風荷重と死荷重の計算は、計算尺で行われていたときと同じです。ツールとテクニックの改善が進んでいますが、私たちが経験するものと比較すると氷河期のペースです。
一方で、私たちのパターンや実践の多くには改善の余地が必要であることがまだ発見されています。シングルトンはかつては良い考えでしたが、今ではそれを考えるほとんどの人がIoC/DIパターンを好みます。
私たちにも欠けているのは、意味のあるライセンスと認証です。多くの分野で、設置業者はもちろんのこと、単なる修理業者であっても、配管工はライセンスを取得しているか、誰かである監督者の監督の下で働く必要があります。そのライセンスを取得するには、フィールドでの作業に一定の時間が必要です。私はライセンスについて賛成または反対を主張するのではなく、それが大きな違いであることを指摘するだけです。
もちろん、どちらの分野でも、建築家は実装できないものを描くことができます。
足場、「建物やその他の大きな構造物の建設や修理で人や物資を支えるために使用される一時的な構造物」 [wikipediaからの定義]
プログラミングの足場 は迅速に作成でき、実際の構造が整うまで一時的な機能を提供するため、この概念が機能します。
私はいくつかの建設会社が最低入札者に働きかけ、ずさんな仕事をし、保証義務であるべきものを回避し、品質よりも日付に焦点を当て、そして「完成した」製品にとんでもない利益を請求することを知っています。
しかし、プログラマーやコンサルティング会社がそれらの実践から何かを学んだとは思いません。
あらゆる分野の複雑なエンジニアリングプロジェクトには、基本的なガイドラインがあります。
- 計画、設計図、デザインなどの重要性
- 基礎となる数学の重要性
- 他の同様のプロジェクトからのアイデア/学習の再利用
- 他の誰かが作成した既製のビルディングブロック/コンポーネントを使用する
- ライフサイクルの非常に早い段階で問題を修正する
等。、
建築、土木、ソフトウェアエンジニアリングの各分野の共通点は、主に組立ラインの不在に由来するようです。すべてのプロジェクトは、それ自体が独自のものです。
バグは地獄のように高価になり、人を殺すことさえありますか？
あなたが持っているすべてがハンマーであるとき、すべてが釘のように見えます。 :)
反復性緊張によるけが
それらは両方の産業で職業上の危険であり、それらを防ぐために予防策を講じる必要があります。いったん開始すると、治すのは困難です。
標準、規則、および事前に作成されたコンポーネントの使用。あなたはこの種の問題に遭遇する可能性は低いです。
カスタムビルドのソケットに適合するものは市場で見つかりません。
時間とともに
しかし、建設業界では、労働者は残業代を支払われます。