是不是曾經很納悶， Google、Facebook、Apple 不是世界頂尖的軟體公司嗎？怎麼連這個小東西都會有 bug，這 bug 看起來也太愚蠢了吧～！
今天小弟就稍稍介紹一下軟體開發的世界，希望可以讓各位更瞭解這個世界到底是怎麼運作的。
那就從一句話激怒軟體人起手吧！
寫程式不就是一堆 if else 兜一兜？我以前也寫過 blah blah 啊！很困難嗎？
註： if else 可自行更換其他關鍵字，blah blah 可自行更換為 hello world、列印金字塔、猜數字、計算機、寵物雞、初音 ...。
軟體分類。
老實說這句話我一時也不知道該如何反駁，的確就是一堆東西兜一兜阿。那我們先來看看下面這張圖：
此圖中用四個象限來表示不同層次的軟體，圖中的「x N」，表示花費成本為 N 倍。軟體不光光是「大小」，更有這幾種層次之分，就算是兜也有大兜小兜。
簡單說明一下四個象限的意義：
- 工具軟體 / 程式
缺乏可擴充性，沒有明確的介面，程式碼呈現高耦合度。 - 軟體系統
由組件組成。具有高可擴充性，有明確介面以便擴充組件。 - 軟體產品
具有說明文件，與未來版本具有相容性。 - 軟體系統產品
軟體系統 x 軟體產品。
變是唯一不變的。
軟體除了上述的層次有許多的不同以外，在開發中具有的最大的特色就是變。相較硬體開發來說，軟體的變更異動，看起來根本就是零成本，怎麼可能不改呢？老闆要什麼就改什麼，市場端要什麼就改什麼，甚至蓋了十層樓突然想挖個地下室都得硬著拳頭挖呢！「變」就是軟體開發面臨的最大挑戰。
軟體成長的關隘。
接下來補充一個可以不知道的冷知識：
軟體的生命也是有盡頭的，工程師只是盡可能地延長他的壽命，期許他在有生之年能夠造福更多的人們。
硬體設備用久了會壞很容易理解，但軟體用久了會壞？嗯...這裡指的並不是用久了會壞，軟體用再久就是這個樣，不壞。壞的是它再也沒辦法擁有更多的功能，到達了開發年限。很難理解是嗎？那就用積木組合來想像，把軟體開發想像成堆積木，這邊說個故事：
- 老闆說，經過了市場調查，五層積木高的好棒棒塔是客戶最想要的組合，那就蓋個五層好棒棒塔吧！
工程師表示游刃有餘，順道加點顏色變化不收費。完美的巧思阿！ - A 客戶覺得不錯，但覺得右邊長個長長的藍棒棒應該更好。
加上了藍棒棒，但為了避免架構崩壞，上頭再壓個灰積木。 - 因應新的市場需求，A 客戶覺得希望在左邊也蓋個粉紅棒棒。
加上了粉紅棒棒，一樣避免架構崩壞，移除了之前保持平衡用的灰積木，蓋上了粉紅棒棒。 - 可想而知，接下來相同於 2、3 的需求會一直不斷的出現，終究有一天，任何一小塊積木就再也堆不上去，或是每堆上一塊積木，在不知名處就會有積木位移、崩落。然而，這就是軟體生命的盡頭了，處於一個恐怖平衡，再也無法繼續增加任何功能。
從這個堆積木的故事，可以看見更多軟體開發中有趣的現象。
- 軟體開發：簡單化、穩定的過程；軟體維護：複雜化、混亂的過程。
（步驟 1 夠簡單吧，輕鬆愜意；步驟 2 之後開始有挑戰了...） - 為了新功能，往往需要變更舊功能的設計。
（步驟 3 ，舊有的藍棒棒稍稍位移了。） - 當新功能不斷的增加，逐漸的，不斷的在修正舊問題所導致的新問題上，而不是在修正原有的架構錯誤。
（步驟 3 ，只是移除了舊的灰積木，而不是擴大基座提高穩定性。）
尷尬的開發時程。
小測驗：
軟體程式碼只有 1000 行的時候，加一個 A 功能要 1 天； 若程式碼長大到 10,000 行的時候，加一個大小與 A 功能相仿的 B 功能，約莫要耗時多久？
A) 1天 B) 10天 C) 30天 D) 100天 E) 300天
根據公式：費力程度 ＝ 常數 x (程式碼數量) 1.5，答案是 「C）30天」。但想像一下若今天你是老闆，你會給這個員工 30 天去開發 B 功能嗎？反之，想像一下你是員工，老闆就算給你 30 天，你有能力將 30 天耗費的淋漓盡致確保 B 功能及原來所有功能運作正確嗎？很顯然，答案大多是否定的，這就是為何軟體總是滋生一堆 bug 的原因啊！！
困窘的人力需求。
大型的專案要在時限內完成，勢必需要投入更多的人力。然而軟體開發，又是重度依賴溝通的工作。一旦投入大量的人力，溝通成本又是指數上昇。沒錯，又是一個指數！當團隊人數成長到一定的界線時，生產力就不再上昇，反倒會開始下降。
以上種種看起來挺絕望的，那怎麼辦呢？
這篇文章只是淺談，這就不提了。但也就是存在這些困難，軟體工程師才不會失業，優秀的工程師會解決這一切的！
之後可以再來整理分享我所知道的解決方式。
※ 以上文章眾多內容、數據是參考軟體工程經典「人月神話」一書。
