大型系統的軟體開發工作就像掉進了焦油坑裡。
當你掉入焦油坑中，越是掙扎，焦油就纏的越緊。軟體工程某種程度就像是這樣的東西
首先，先來個大哉問吧，你知道軟體工程是什麼意思嗎？
如果你認為，軟體不過就是寫寫程式而已，並沒有什麼工程的成分存在，那麼你不妨可以想像一下，為什麼有那麼多的「程式」天才，每年從台清交成的資工系畢業，卻沒有多少個成功的「程式」？
這個問題的關鍵在於，在市場上，真正有價值的，並不是程式，而是通過繁瑣的程序，最後終於成功上線的「軟體系統產品」。程式天才可能擅長設計程式，但他們卻不擅長處理更現實層面的工程問題。
不知道大家有沒有聽過一個玩笑話說，學校作業寫的東西就是玩具而已？其實我認為這個比喻還蠻有趣且適合的。
如果一個程式，只能解決一個特定的問題。只能從黑白的終端機介面操作。只能用複雜難以記憶的指令控制。發生錯誤的時候，一般人沒有辦法處理。
這樣的程式，是沒辦法拿出去賣錢的，只有設計者本人玩得很開心，所以說是玩具。
「程式」跟「軟體系統產品』的差異。
軟體系統產品，可以分成「軟體產品」跟「軟體系統」兩個面向來看：
軟體產品，代表這是一個可以讓任何人執行、測試、修改、和擴充的程式，並且適用於多種操作環境，以及不同的情況。要成為通用的軟體產品，程式必須要做到符合一般通用的標準，也必須要經過徹底的測試，滿足各種常見的狀況，更需要完整的文件，可以指引別人使用，甚至修改、擴充。
軟體系統，多個程式彼此互動，作為組件，組成了一個軟體系統。不同的程式之間要能夠順暢溝通，需要通用的介面。每支程式可以分別運作良好，但多個程式交互作用，就可能發生意想不到的狀況，讓每個組件能夠運作順暢，提供服務，才是一個好的系統。
天才程式設計師可以快速地完成程式，但要讓程式可以成為軟體系統產品，還需要一段距離，沒有走完這段，這支程式就只能躺在創作者的電腦裡面，沒有辦法創造商業價值。
人月神話書中給的數字是，從程式到軟體產品，大概需要花費至少 3 倍的時間；從程式到軟體系統，大概也是至少 3 倍的時間，所以從程式到軟體產品系統，總共會是至少 9 倍的時間。這就是為什麼，要將程式產品化，是一條漫漫長路，而且總是比預期的還要久。
但是，「軟體產品系統」才是「軟體工程」想要達到的目標。
舉個例子
試著根據我自身的經驗舉一個例子。
例如，要寫一支結帳的程式，根據購物車內的金額去呼叫第三方 API 進行付款，付款成功就扣除對應的庫存，成功後訂單成立。
但是為了能夠讓產品上線不會發生問題，我們必須要處理一些問題，如果第三方 API 打不通怎麼辦？如果庫存不夠了怎麼辦？如果不明原因重複結帳怎麼辦？如果系統流量太大系統造成錯誤怎麼辦？
要處理這些問題，除了要使用各種測試的方法來驗證，也要花費很多的力氣額外寫程式，來處理這些不是結帳主要流程的問題。而這樣的過程，總是會不小心創造出一些難以發現的 Bug，隨著邏輯越來越多，Bug 也來越刁鑽難找。
天啊，光是稍微想像一下就累了，就一個結帳，打API，扣庫存的過程，還不用去考慮什麼優惠券，什麼活動，就有一大堆例外跟測試需要處理，確實大部份的時間都在處理結帳以外的其他事情。
軟體工程的樂趣與苦難
書中對於軟體工程的有著這樣的敘述：「軟體工程的任務和挑戰就是以現有的資源並在時效之內，找到實際的方法去解決現實的問題」。
軟體工程的核心當然還是寫程式，單純的寫程式，也就是做玩具，是很有樂趣的，因為不用管現實面的問題，只要滿足自己內心的需求而已。看著自己寫的程式實際動起來，做出心目中預期的反應，肯定是相當痛快的。
然而回歸現實面，軟體工程師要創造出產品，創造商業價值，就不能夠只是自我滿足，必須要寫出符合他人期待的程式。也必須要跟他人合作，接受別人寫得不如自己預期的內容。甚至要去解別人創造出來的 bug。在軟體系統中，各種組件糾纏不清，有時候造成的 bug 真的就是如同陷入焦油坑中，每多一個測試案例就多發現一大堆 bug，怎麼解都解不開。
而作者在這本書的目的，就是試圖在這樣的焦油坑上，鋪上一條步道。
個人想法
作為一個有工作經驗的軟體工程師，我們自然知道程式要上線，需要經過一些流程。但我們可能都沒有想過，一支程式跟一個合格的產品，距離差異在哪裡。
我曾經跟一個新人說，你這支程式不行，對方當時很生氣，認為是我不懂。雖然當時我可能經驗也還不是很深，實在是沒辦法好好解釋，但現在的我可能也會懶的解釋，應該會直接叫他去讀人月神話。
對人月神話有興趣嗎？點此前往博客來購買