谷歌翻譯
這篇文章出現在
和news.ycombinator.com
上。請參閱
羅馬尼亞語版
、俄語版
、愛沙尼亞語版
、葡萄牙語
（我無法證實它們都說同樣的話）。
雖然我的天賦在於軟體，但我的研究生學習是計算機工程（設計和構建數字計算機）。
乙個觀察總是讓我印象深刻：計算機工程似乎比電腦科學（構建軟體）更簡單。
有一套工程設計規則需要遵循，工程專案比軟體專案更有可能成功。
是的，有一些引人注目的工程失敗，但從經驗上看，可靠和有用的軟體更難實現。
為了說明我的觀點，請考慮我們在整個太陽系中傳送的驚人的太空探測器。
太空飛行器本身工作得非常好，通常壽命超過其設計壽命。
另一方面，他們的控制軟體必須在飛行中不斷調整和修補，以保持任務一致。
我並不是說工程很容易。
它不是。
我的目標只是解釋為什麼軟體比一般的物理建設專案更難做好，以及為什麼「軟體工程」是乙個不恰當的術語。
《經濟學人》雜誌（2004 年 11 月 27 日，第 71 頁）引用了 standish group 的估計：
...所有軟體專案中有 30% 被取消，近一半超出預算，60% 被發起這些專案的組織視為失敗，10 個中有 9 個遲到。文章接著指出，雖然很少有大型基礎設施專案能夠按時並按預算完成，但最終您通常會有所收穫。
您必須進入軟體（或軍事）領域才能花費數十億美元而一無所獲。
造成這種揮霍浪費的最大原因在於，雖然部分完成的有缺陷的建築或基礎設施專案仍然有用，但軟體要麼工作要麼不工作。
因為軟體很難正確處理，所以我們常常一無所獲（例如，
fbi dumps botched computer overhaul
，fbi faces new setback in computer overhaul
）。為什麼編寫軟體不像工程？
答案在於乙個具有深遠影響的根本區別：工程受到現實的物理世界的限制，而軟體則不受。
雖然很明顯，但這是解釋為什麼軟體開發更難正確的關鍵區別。
接下來的幾節將**這些後果。
物理工程專案更容易視覺化，因此更容易構建；
哎呀，您實際上可以用手觸控元件和最終產品。
你越遠離我們在日常生活中所經歷的牛頓對物理世界的看法，這個專案就越困難。
量子物理學很困難，因為粒子的行為不像岩石。
弦理論是建模量子物理學的最有希望的方法，主要是難以理解，因為它處理的維度超出了通常的三個空間維度。
想象一下嘗試在
calabi-yau 歧管
上設計和建造房屋（右圖是 3-d 投影）。
軟體甚至沒有維度的概念。
您可能會說沒有可以著色的線條。
至少對於量子水平以上的工程專案，沒有人期望找到「違反物理定律」的結構。
這限制了您可以物理構建的內容以及構建它的方式，但至少它提供了乙個定義明確的工作世界。
軟體的空靈世界沒有這種奢侈，但我們的工具正在變得更好。
發明物件導向的程式設計是為了讓我們的狩獵採集者的大腦更熟悉編寫軟體；
也就是說，使軟體元件具有類似於現實世界中的物件的屬性和行為。
工程比軟體的風險更小，因為工程經歷的組成元件互動更少。
雖然汽車結構某一部分的微小變化很容易影響另一部分的碰撞穩定性，但車頂燈的設計缺陷導致間歇性發動機熄火是不尋常的。
在家庭建設專案中，每次有人按門鈴時，您都必須非常努力地衝馬桶。
另一方面，在構建軟體時，您必須高度警惕以避免這些不良互動。
許多程式設計師喜歡純函式式程式設計的原因之一是它沒有***——當門鈴響起時，馬桶根本不可能不小心沖水。
在沒有固有緩衝區溢位保護的 c++ 等語言中，情況更糟。
遠端**片段可以更容易地無意中改變整個應用程式的行為。
事實上，大多數黑客利用的正是這個特殊的弱點。
通過導致緩衝區溢位，攻擊者可以強制程式在其防禦中開啟乙個漏洞。
軟體比工程專案更難做好的最後乙個原因是中途設計變更。
物理世界不像軟體的非實體世界那樣具有延展性，因此，客戶的期望值較低。
國會不會在登月計畫中途去 nasa 並要求他們去火星。
大多數工程專案都能夠實際使用瀑布設計方法：確定功能需求、設計、實施、測試。
對於大多數軟體專案來說，這是災難的根源。
不幸的是，軟體設計的中途變化一直在發生——每次客戶看到正在執行的軟體時。
事實上，敏捷軟體開發方法是對不斷變化的設計需求的直接響應。
程式設計師被要求將變化視為乙個機會。
儘管如此，設計的不斷變化阻礙了開發工作，開發人員必須不斷地重構軟體，以防止它變成乙個糾結的、無法維護的爛攤子。
您可能會問，如果軟體很難做到正確，為什麼飛機不會從天上掉下來。
事實證明他們偶爾會這樣做，而糟糕的軟體通常是罪魁禍首。
例如，**空中巴士 320 的電傳飛行墜毀
. 然而，大多數情況下，飛機、汽車和醫療裝置的硬體控制軟體都按預期工作。
提高可靠性的原因有三方面。
首先，有生命危險，人們可能會更加小心。
其次，軟體開發人員在開發過程中不被要求從根本上改變軟體。
例如，螺旋槳驅動的飛機不會成為處於開發過程中的噴氣式飛機。
工程團隊會重新開始，而軟體團隊通常被要求在中途進行徹底的改變。
最後，此類軟體處理控制物理裝置並開始獲得物理工程專案提供的一些優勢。
那麼，如果軟體開發不像工程，那又是什麼呢？
我們稱這門學科為電腦科學，但我也不確定這個術語是否完全合適。
您可能還記得乙個古老的笑話，「如果一門學科的標題中有『科學』，那可能不是。」
在我看來，科學就是用
科學的方法
發現和描述物理現象。
merriam-webster 將科學方法描述為：
系統地追求知識的原則和程式，涉及問題的識別和表述，通過觀察和實驗收集資料，以及假設的制定和檢驗。這種描述更像是
除錯而不是編寫軟體的行為。
電腦科學是關於構建工程之類的東西，但沒有從物理世界中獲取的工具箱和元件的奢侈。
沒有人像工程師為物理專案所做的那樣，制定出可靠和有效的程式來構建大型軟體。
正如 alan kay 所說，軟體是「一種工程......但只是通過蠻力完成的」。
與艾倫·凱的對話
：
如果你從工程歷史的角度來看今天的軟體，它肯定是一種工程——但它是沒有拱門概念的人所做的那種工程。寫作軟體最類似於寫**。今天的大多數軟體非常像埃及金字塔，數百萬塊磚相互堆疊，沒有結構完整性，而是通過蠻力和成千上萬的奴隸完成的。
寫**也是一種在不受約束和空靈的媒介中創作的行為，幾乎沒有完善的構建規則。
當我們看到它時，我們就知道好的寫作，但很難教。
寫作經驗和來自更好作家（編碼員）的反饋是成為一名優秀作家（編碼員）最可靠的方法。
如果沒有乙個很好理解的過程，軟體將更多地是一門藝術而不是一門科學。
術語「軟體工程」更多的是乙個目標，而不是我們實際編寫軟體的方式。
為什麼應該學好軟體工程？
我大學學的專業是通訊工程，設定的課程裡沒有軟體工程相關的課。畢業後從事軟體測試工作，作為測試人員，與開發人員溝通是重要的工作內容之一，所以做測試的十多年來，接觸了很多的開發人員，有些開發人員留下了深刻的印象，當然這個印象有好的也有差的。在這些開發人員中，有些人fix bug的速度超快，還不會引入新的...
軟體工程 軟體的估計為什麼這麼難
前兩年在網上看到乙個笑話集錦,列舉電視劇集中的穿幫情節。其中乙個是在某纏綿冗長的言情劇中,乙個叫 書桓 的角色沉痛地說 長達八年的抗日戰爭就要開始了 書桓同學當時是怎麼估計到抗日戰爭要打八年的?這一技術讓軟體工程師和專案經理望塵莫及。軟體專案計畫的乙個重要環節就是估計專案各類工作 特別是各種功能 所...
為什麼要做軟體過程改進工程師
說實話，寫東西是被領導逼出來的，在此之前，從來沒有寫東西的習慣，最多是年底的時候被領導，或者被人力部門的考核逼著，應付著做個年度考核的ppt，或者象徵性地寫寫今年的收穫啦 不足啦 明年的期望啦什麼的，這麼認真而且堅持地寫東西，長這麼大還是頭一次。好了，言歸正傳，說說我為什麼要做軟體過程改進工程師。在...