流程的嚴密性

普通人：

我今天要買一斤蘋果。

程式設計師：

我今天要買一斤蘋果。

因為我只喜歡紅富士蘋果，所以我只買紅富士蘋果。

我能接受的最高價格是10元/斤。

正常情況下一斤蘋果用一個袋子能裝下，但是為防萬一，我會帶兩個袋子。
我知道附近的3家水果店，所以我會依次訪問這3家水果店。

根據上述條件，我設計出以下的買蘋果的流程：

這個流程怎麼樣？我來設計一些測試樣例，測試一下這個流程。

測試發現一個問題：如果水果店0和水果店1都有紅富士蘋果並且價格都低於10元/斤，而且水果店1的價格比水果店0更低，那麼我希望買水果店1的蘋果，但我設計的流程會讓我買水果店0的蘋果。

為了解決這個問題，我應該先詢問所有水果店的價格，然後去價格最低的那一家買蘋果。

經過修改，我重新設計出以下的買蘋果的流程：

現在這個流程是不是完美了呢？不是，我還能發現很多問題。

如果3家水果店都有紅富士蘋果但都不到一斤，但是三家店加起來能達到一斤，那麼我不應該結束流程回家，而是應該把三家店的紅富士蘋果都買下來。

如果我向水果店詢問價格的時候這家店還有紅富士蘋果，但我詢問完所有水果店的價格後這家店的紅富士蘋果賣完了，那麼我的流程會讓我試圖處理不存在的紅富士蘋果。

我走路的過程中可能會遇到突發事件，比如發現了新的水果店，比如袋子破掉了蘋果掉一地，對於這些情況我的流程都無法進行處理。

啊問題太多了我懶得再改流程了。我還是去X寶買吧。
那麼接下來我要設計一個在X寶買紅富士蘋果的流程……

==========================================================

測試

一個測試工程師走進一家酒吧，要了一杯啤酒；

一個測試工程師走進一家酒吧，要了一杯咖啡；
一個測試工程師走進一家酒吧，要了0.7杯啤酒；
一個測試工程師走進一家酒吧，要了-1杯啤酒；
一個測試工程師走進一家酒吧，要了2^32杯啤酒；
一個測試工程師走進一家酒吧，要了一杯洗腳水；
一個測試工程師走進一家酒吧，要了一杯蜥蜴；
一個測試工程師走進一家酒吧，要了一份[email protected]!&*(@；
一個測試工程師走進一家酒吧，什麼也沒要；
一個測試工程師走進一家酒吧，又走出去又從窗戶進來又從後門出去從下水道鑽進來；

一個測試工程師走進一家酒吧，又走出去又進來又出去又進來又出去，最後在外面把老闆打了一頓；
一個測試工程師走進一家酒吧，要了一杯燙燙燙的錕斤拷；
一個測試工程師走進一家酒吧，要了NaN杯Null；
一個測試工程師衝進一家酒吧，要了500T啤酒咖啡洗腳水野貓狼牙棒奶茶；
一個測試工程師把酒吧拆了；

一個測試工程師化裝成老闆走進一家酒吧，要了500杯啤酒並且不付錢；
一萬個測試工程師在酒吧門外呼嘯而過；
一個測試工程師走進一家酒吧，要了一杯啤酒';DROP TABLE 酒吧；

測試工程師們滿意地離開了酒吧。
然後一名顧客點了一份炒飯，酒吧炸了

複雜性的持續增加

如果編寫一段寫完就扔的程式碼（如運維修復），那其實是可以很快做好的，想不通的地方繞一繞總也能搞得定。

但當你編寫的是一段大規模使用，需要持續改進，並且不斷有新功能需要新增的程式碼。那麼難度就急劇增加了（這也是我認為的程式設計的主要難處）。

一方面，最開始編寫程式碼的時候就要考慮到以後的擴充套件性，而這個考慮又永遠不可能是完備的，也不應該是完備的（不要過早優化）。只有一些基本的原則，比如保持單模組的獨立性，避免模組間的耦合，這些原則的運用需要豐富的經驗，並且不一定總是用好了。

另一方面，在程式碼的持續演進過程中，需要對抗程式碼的腐化。當原來拍著胸脯保證的確定因素突然變成不確定因素；當代碼引入了不合理的功能（如需要理解上層邏輯）；當有新的人來維護程式碼。程式碼腐化的結果是大大增加了工作量和減少了程式碼的穩定性。（程式碼腐化只有一個好處，天天加班，顯得事情很多，搞不好能把領導唬住）

需求