軟體開發!=軟體工程 你真的希望如此嗎?
本文由碼農網 – 王國峰原創翻譯,轉載請看清文末的轉載要求,歡迎參與我們的付費投稿計劃!
端著咖啡,你大步走向書房,只餘腳步聲迴響在空蕩的走廊裡。跨過門檻,停下來咯噠一聲開啟頭頂上的節能燈,放在書桌中央的膝上型電腦一下子映入你的眼簾,明亮的螢幕上圖表正在發出誘惑的光芒。放下咖啡,你決定最後再研究一次,看看還有什麼錯誤或誤算是先前被遺漏的。不斷地熬夜,熬夜,但最後,終於讓你獲得了客戶的認可。
喝一口依然還滾燙的咖啡,你決定最後一次檢查客戶需求。用早餐的位置?有了。四個浴室,其中一個要在天花板上安裝花灑淋浴頭?有了。三車車庫以及寬敞的院子?有了。一切準備就緒,各就各位。最後的審查讓你充滿自信:想必客戶定會滿意,施工也馬上可以開始。合上膝上型電腦,抓起它走出房門,興沖沖地想要展示給客戶看。
正如你所預期的那樣,客戶很滿意!他對院子的大小很滿意,他和他的家人也很喜歡你設計的游泳池和早餐位置。但是美中不足的是….
“你能讓它飛起來嗎?”
這是工藝,而不是工程
上面的故事顯然是荒謬的:只要是思維正常的人都不會要求讓房子飛起來,因為我們都見過房子,它們都是不會飛的。然而,這樣的情景卻經常在軟體開發上重演,一遍又一遍。客戶要求的東西——他認為是合理的,但對我們開發人員而言可能是完全不可能的——至少目前為止我們清楚這是不可能的事情。現在的軟體開發很少有章程,雙方協定的標準就更少了。我們能做的,通常就是,建立的東西儘可能地符合客戶的期望。
幾年前,有一個關於軟體開發是否可以被稱為軟體工程的大辯論,這源於一篇名為《Software Engineering: An Idea Whose Time Has Come and Gone?》的文章,作者是Tom DeMarco。DeMarco認為,短命的軟體工程已經死去,這對於所謂軟體“變革”的建立並不重要。
DeMarco的論文認為由於缺乏測量力度(和“軟體”一詞所代表得深度和廣度),軟體工程已經走向了滅亡。但是我看到的是一種截然不同的現象:軟體工程從未存在過。
首先鄭重宣告,我贊同DeMarco先生的主要觀點。軟體開發不是工程,因為在傳統的工程中輸出是有把握的,且可被反覆衡量和控制的。DeMarco的著名論據“你無法控制你不能衡量的東西”是對此理念的完美總結:如果你不能衡量你將要實施的變化的影響,那麼讓我們怎麼相信你能控制它們呢?
這一點,在我看來,正是我們不能將軟體開發稱為“工程”的首要原因:我們不能衡量將要實施的變化的影響。當然,我們可以執行單元測試,整合測試——我們能想到的所有測試,但我們依然無法準確估計當我們實施所有潛在的變化時,它們對現有系統所造成的影響範圍。我們現在根本沒有足夠的工具來做到這一點,並且據我所知,我們一直以來就沒有這樣的工具。
我認為軟體開發可以當作一門手藝。“工藝”一詞或許能夠更好地描述我們開發人員的實際工作。
工藝和工程之間的主要區別是,後者使用已經廣為人知且公認的知識來解決問題,而前者使用的是更專業的知識,懂這些知識的人不如前者那麼多,甚至這些知識可能是不成文的或並不為大眾所認同。因此,我們可以得出軟體工程一說根本不存在的觀點,因為沒有足夠普遍都接受的知識來證明它可以叫做“工程”。
那麼“軟體工程”可以存在嗎?是否有用?
軟體工程這說法是否可行?
假設將軟體開發的整個領域轉換到工程學科是可能的。然而,我們真的想要這麼做嗎?
在我看來,建立有用的軟體需要具備一定層次的藝術技能,有的形式的創造並不能用數學和工程精確地表現出來。創造力能讓我們面對從未見過的問題時,也能想出新穎的解決方案。但是如果我們不小心,它也會讓我們搬起石頭砸自己的腳。
對我而言,將軟體開發制定為工程學科會消弭大量的創造自由(當然並非全部),從而阻礙我們從多方面思考來解決當前問題。
另一方面,利用工程策略可以顯著提高例如標準規格、可測試性,以及專案管理等理念。此外,它提供的公共知識池,可作為使用來源用於參考解決方案,使它們更容易交叉引用。
既然這樣,那麼共享和控制所有知識是否值得我們失去一些創造的自由?我認為這不值得,哪怕上述權衡真的可以實現。軟體可用於所有基本的事情,與其說偉大的多元化思維自由是我們解決問題的阻礙,倒不如說它是福音。如果硬是將軟體塞進工程領域,那麼就會有太多的變數,太多的問題,太廣泛的問題範圍需要考慮。對所有軟體開發使用工程策略將會是一場災難。
這篇文章開頭的故事,就是一個當我們將軟體開發與工程作比較時,常見但不正確的假設:即將軟體設計比作是蓋房子。這嚴重偏離了事實。房子是有形的,受到物理定律如重力的約束,並且我們已經擁有了上千年的築造歷史,知道如何建築適宜居住的房子。而軟體是沒有這些條件的,因此這樣的比較說好聽點是天真,說難聽點就是誤人子弟。
總之,軟體開發永遠不可能是軟體工程。
我們的專業是一門手藝,我們是工匠。軟體開發是一個過程,作為程式設計師的我們吸取關於專案的專業資訊和設計內容,然後實施滿足客戶需求的解決方案。它是藝術,它充滿了創造性;它不是工程,它也不需要成為工程。這應該成為我們的共識。
你有什麼看法?你認為軟體開發成為軟體“工程”是一個值得追求的目標,還是一項不可能完成的任務?歡迎分享你的評論,請暢所欲言!
譯文連結:http://www.codeceo.com/article/software-development-not-software-engineering.html
英文原文:Software Development != Software Engineering. Do we want it to?
翻譯作者:碼農網 – 王國峰
[ 轉載必須在正文中標註並保留原文連結、譯文連結和譯者等資訊。]
相關文章
- 軟體測試真的比不上軟體開發嗎?
- 軟體工程是教會不懂寫程式的人開發軟體嗎?軟體工程
- 你會寫軟體開發文件嗎?
- 你是“職業”軟體開發嗎?
- 作為軟體開發人員真的需要學歷嗎
- 軟體定製開發真的比SaaS系統好嗎
- 軟體工程--為什麼軟體開發方法論讓你覺得糟糕軟體工程
- 軟體開發工程師常用的工具軟體工程師
- 做軟體測試工程師真的很容易嗎?工程師
- 如此上網如此軟體
- 軟體開發人員真的瞭解SQL索引嗎(聚集索引)SQL索引
- 軟體工程之開發過程軟體工程
- 軟體工程開發日記3軟體工程
- 軟體開發人員薪水差距如此之大
- Python能否開發軟體嗎?Python
- 軟體、軟體危機、軟體工程 (轉)軟體工程
- 對軟體工程課程希望與個人目標軟體工程
- 軟體工程方法論對軟體開發有多大的用處?軟體工程
- 軟體開發與軟體研發
- 軟體工程 第一章 軟體與軟體工程軟體工程
- 軟體開發學習的5大技巧,你知道嗎?
- 軟體工程——軟體測試軟體工程
- 軟體工程——軟體計劃軟體工程
- 軟體“吃”掉了軟體開發
- 軟體開發mac常用軟體Mac
- 資料字典真的有用嗎?--開源軟體誕生12
- 微軟真的改變對開源軟體的態度了嗎?微軟
- 軟體開發:app軟體開發,pc端軟體開發,微商城/小程式開發APP
- 軟體工程-軟體工程層狀模型(EHM)軟體工程模型
- 軟體工程 .軟體工程
- 軟體工程軟體工程
- 自上而下的軟體開發和自下而上軟體開發
- 軟體工程資料 - 優秀的大學怎麼教程式開發和軟體工程課軟體工程
- 軟體工程課程專案“物品復活“軟體開發v1.0軟體工程
- 軟體工程方法論對我們經軟體開發有多大用處?軟體工程
- 軟體工程始發隨想軟體工程
- Ubuntu 的 snap 軟體包封裝真的安全嗎?Ubuntu封裝
- 中國真的沒有軟體生長的土壤嗎?