關於那些軟體開發的隱喻

如果你認為開發軟體類似於建造房子，你會犯的第一個錯誤就是把它當成一個工程專案（project）。一個專案有開始和結束，一旦你到達終點，工作就完成了。

只有不成功的軟體才會完結。成功的軟體是持久續存的。如果你有幸開發出成功的軟體，當完成一個發行版本後，你會繼續開發下一個版本，這可以持續好幾年。一些成功的軟體會持續存在幾十年。

一旦你建好了房子，人們就可以搬進去。你需要維護它，但其成本只是建造它的一小部分。誠然，像這樣的軟體是存在的，特別是在企業領域。只要你建好了一個內部業務線（line-of-business）的應用程式，它就完成了，而使用者也就被束縛其中了；當專案完成，這樣的軟體就進入了維護模式。

但大多數軟體並不是這樣的。與其他軟體競爭的軟體是永遠都不會完成的。如果你陷入建造房子的隱喻中，可能會把它想成是一系列的專案；你可能計畫在九個月內發行產品的下一個版本，但卻驚恐地發現你的競爭對手每三個月就發佈一次改良版。

所以你努力地使該「專案」的時程縮短；當你終於能夠每三個月交付一次時，你的競爭對手卻達到了每月一次的發行週期。你可以看到這個的結局，對吧？

它的結局是Continuous Delivery（持續交付）。就是這樣，或者你最終倒閉了。根據研究，Accelerate一書令人信服地論證道，區分高績效和低績效團隊的關鍵是不加思索，毫不猶豫就發佈的能力。

若能做到這點，軟體開發專案的概念就不再有意義了。

軟體作為一種工藝

把軟體開發看作是一門工藝（craft），當成本質上的技術工作（skilled work），這似乎很有說服力。　

身為一名專業的軟體開發人員，你所需要的技能往往是情境式的。學習這個特定的源碼庫之結構為何。學習如何使用那個特定的框架。忍受在生產環境中花費三天的時間來排除一個錯誤的折磨。類似這樣的事情。

做得越多，你就越熟練。如果待在同一家公司，在同一個源碼庫中工作多年，你可能會成為一個專業的權威，但如果你決定去別的地方工作，這對你有幫助嗎？

透過從一個源碼庫移到下一個源碼庫，可以學習得更快。嘗試一些後端開發（back-end development），做一些前端開發（front-end development）；也許嘗試一些遊戲程式設計（game programming），或一些機器學習（machine learning）。這將使你接觸到廣泛的問題，而這些問題將作為經驗積累起來。

這與歐洲古老的journeyman years（學徒期滿的職工年）傳統驚人地相似。像木匠或屋頂工人這樣的工匠會在歐洲各地旅行，在一個地方工作一段時間後再去下一個地方。這種方式使他們接觸到解決問題的替代做法，使他們的手藝變得更好。把軟體開發人員想成這樣是很有說服力的。The Pragmatic Programmer一書的副標題正是From Journeyman to Master。

從某種意義上說，我的「軟體工藝」那幾年是一個徹底的幻滅期。當時我認為技能只不過是積累的經驗而已。在我看來，軟體開發是沒有方法論（methodology）的，一切都取決於環境。做事情的方法沒有對或錯。

這種觀點的問題是，它似乎並不具有規模擴充性。為了「創造」新的程式設計師，你必須把他們當作學徒，直到他們學到足夠的知識，成為了學徒期滿的職工（journeymen）。從那時起，掌握技能還需要幾年的時間。

將程式設計視為一種藝術或工藝的另一個問題是，它也不符合現實。2010年左右，我開始意識到，我在程式設計時遵循的是啟發式方法（heuristics），即經驗法則（rules of thumb）和一些指導方針（guidelines），這些都是可以教授的。

起初，我並沒有太注意到這點。然而，多年來，我經常發現自己處在指導其他開發者的位置上。當我那樣做的時候，我經常會制定以特殊方式編寫程式碼的理由。

我開始意識到，我的虛無主義可能是錯誤的。也許，指導方針可能是將程式設計變成一門工程學科的關鍵。

早期的軟體工程概念

軟體工程（software engineering）的概念可以追溯到60年代末。它與當代的軟體危機（software crisis）有關，即人們逐漸意識到程式設計是很困難的。

那時的程式設計師實際上對他們所做的事情有很好的把握。我們行業中的許多傑出人物都活躍在那些日子裡：Edsger Dijkstra、Tony Hoare、Donald Knuth、Alan Kay。如果你問當時的人們是否認為程式設計會在2020年代成為一門工程學科，他們可能會說是。

你可能已經注意到，我把軟體工程的概念當作一個理想的目標來討論，而不是日常軟體開發的一個事實。世界上有可能存在一些實際的軟體工程，但根據我的經驗，大多數軟體開發是以不同的風格進行的。

並不是只有我覺得軟體工程仍然是一個未來的目標。Adam Barr說得很好：

「如果你和我一樣，夢想有一天，軟體工程能以一種深思熟慮、有條不紊的方式進行研究，而提供給程式設計師的指導也能建立在實驗結果的基礎之上，而非根據搖擺不定的個人經驗。」

隨著軟體工程往前邁進

工程師是做什麼的？工程師負責設計和監督事物的建造，從橋樑、隧道、摩天大樓和發電廠等大型結構，到微處理器等微小物體。

程式設計師不會那樣做。軟體開發主要是一種設計活動。當我們在編輯器中輸入程式碼時，就相當於工程師在畫圖紙，而非對應到工人在建構東西。

「真正」的工程師遵循通常會導致成功結果的方法論。這也是我們程式設計師想要做的，但我們必須小心翼翼地只複製那些在我們的環境下有意義的活動。當你設計一個實體物品，真正的建造是很昂貴的。我們不能建造一座橋，測試一段時間後才決定它不好，然後把它拆掉重新開始。因為現實世界的建造過程是昂貴的，工程師們從事計算和模擬。計算一座橋的強度比建造它需要更少的時間和材料。

有一個完整的工程學科與物流（logistics）有關。人們從事細緻的規劃，因為那是建造實物最安全且最不昂貴的方式。

那是工程中我們不需要複製的部分。

但還有很多其他的工程方法論可以啟發我們。工程師也做創造性、人性化的工作，但那往往是在一個框架內結構化進行的。特定的活動之後應該有其他的活動。他們對彼此的工作進行審查和簽字。他們遵循檢查表（checklists）。你也可以那樣做。

那就是這本書的內容。它是我發現有用的啟發式方法之導覽。恐怕這更接近於Adam Barr所說的搖擺不定的個人經驗（the shifting sands of individual experience），而不是一套有科學根據的定律。

結論

今日，我們擁有比五十年前先進得多的程式語言，可以存取Internet（包括以Stack Overflow形式出現的業界標準線上說明）、物件導向和函式型程式設計（functional programming），自動化的測試框架、Git、整合式開發環境，等等。

另一方面，我們仍在軟體危機中掙扎，儘管已經持續了半個世紀的東西是否可以被稱為危機是值得商榷的。

儘管做出了認真的努力，軟體開發行業仍然不像是一門工程學科。工程和程式設計之間存在著一些根本性的差異。除非我們理解這一點，否則我們無法取得進展。

好消息是，你可以做到許多工程師做的事情。有一種思維方式，以及一系列你可以遵循的流程。

正如科幻作家William Gibson所說：「未來已然到臨，只是分佈得不是很均勻」正如Accelerate一書所描繪的那樣，一些組織今天就使用了先進的技術，而其他組織則落在後面。未來確實是不均勻分佈的。好消息是，那些先進的理念可以自由取得。是否要開始使用它們，由你決定。（本文摘錄整理自《Code That Fits in Your Head》，碁峰資訊提供）

 書名  Code That Fits in Your Head：軟體工程的啟發式方法

Mark Seemann／著；黃銘偉／譯

碁峰資訊出版

定價：580元

 作者簡介  Mark Seemann

Mark Seemann是一位平庸的經濟學家，他找到了程式設計師作為第二天職，並在90年代末開始從事Web和企業的軟體開發工作。他原本想成為一名搖滾明星(rock star)，但既沒有天賦也沒有長相，於是他成為了一名Certified Rockstar Developer。他寫過一本關於Dependency Injection的獲獎書籍，在國際會議發表過上百次演講，並為Pluralsight和Clean Coders製作過影片課程。圖片來源／Amazon