因爲手上的項目最近在進行驗收，所以需要根據驗收的問題進行修改，也就是根據驗收報告修改系統的bug或者功能缺陷。但是經過幾次驗收都沒有通過，主要原因是因爲另一位搭檔的模塊總是出問題，後來經過一次驗收之後，我決定自己親自內測他的模塊，結果我也測出了很多問題，把這些問題跟他一討論發現要修改這些問題確實牽涉的地方太多，而且解決了一個問題會導致其他的新問題，後來我發現他的功能之間的耦合度太大，而且對於一個功能的流程設計自己前後都說不通，有的地方前後矛盾，也就是說這個功能在他做的時候並沒有明確確定這個功能的流程，所以導致後面功能出現的意外情況，他自己都不知道這樣是不是對的，模棱兩可，表面上感覺是怎麼使用都可以，其實實質上程序的健壯性和可維護性都太差了，因爲在開始做這個功能的時候邏輯設計的太過寬鬆，沒有經過嚴密的設計，導致後面邏輯中有很多漏洞，而且各個功能之間的邏輯交叉也太多，所以當他要修改一個地方的時候，會非常麻煩，甚至造成他自己都發現不了的新問題，因爲他對這種修改會造成什麼樣的影響都無法預期，所以驗收的時候總是有新的問題出現。
經過總結，我覺得功能設計時，邏輯應該非常清楚才行，千萬不能模棱兩可，而且各個功能之間儘量減小功能之間的耦合度，這會減輕後期的維護負擔。
不過，話說回來，我想到另一個問題，最近我在做一個BBS，我發現當我把所有功能做的差不多的時候，我突然覺得我的設計有點缺陷，但是我發現我想修改一些東西的時候，要修改的地方太多，而且要費勁很多心思去找修改哪些地方，但是我們又不可能一開始就能把一個東西設計的完美，當出現這種情況的時候應該怎麼辦呢？是在原來的設計上修改呢？還是重新設計？如果在原來的設計上修改，顯然很痛苦，而且有修改到最後整個系統會崩潰的危險。如果是重新設計，那前面的設計工作豈不是白費，畢竟前面的設計只是有一些地方設計不合理，並不是完全不合理。所以，這種情況該怎麼辦呢？或許通過一些設計模式可以解決這樣的問題，但是我想當問題域複雜到一定程度時，也沒有什麼設計模式能夠說預期到後期擴展和維護的所有情況，因此，所有的軟件都是有壽命的。
但是，根據我現在的水平，我解決問題的複雜度都不高，我應該可以通過學習儘量去避免這樣的問題，減少後期維護的成本，和擴展的成本。
如果有高人指教，敬請留言。