做了一個半月，終於可以交差了，也僅僅是可以交差而已。

這一個半月來，最大的感觸就是，做產品型的軟體時，必須要仔細的瞭解客戶的需求，並且在動工寫程式碼之前，首先需要列出來一個產品的功能構想和使用流程圖給客戶看，如果客戶滿意了，就動工寫程式碼，不滿意的話就針對客戶提出的意見進行修改，直到客戶對產品的功能和流程圖滿意了之後，再動工寫程式碼。

這次出來遇到的最大的麻煩就是，自己的老闆有一套思路，工廠的老闆有一套思路。這個專案雖然交了差，但是到現在還是稀裡糊塗的不知道當時是怎麼籤的合同，碼農和客戶的思路都沒有達成一致，就動工寫程式碼了，結果寫出來的程式碼不能讓工廠老闆滿意。這尼瑪是必然的好不好，不按人家的思路做，結果自己這麼做的理由還不能說服人家。。。想到這裡，我都覺得老闆接這個專案可能完全是出於情面，象徵性的收點錢然後幫哥們的忙，因為如果是為賺錢的話，當然得遵循“客戶就是上帝”的原則啊。

吐槽結束，進入正題。下面列出此次專案中找到的自己的軟肋（其實事實是一個塊硬肋都木有好吧T^T）。

1.沒有養成模組化程式設計的思維：

問題：

剛開始做時，為了趕工期，對系統的修改總是東一磚西一瓦，力求改的東西最少。但是做到後來發現，這樣做其實反而低效，因為寫出來的程式碼基本不能重用，就算可以，還是要修修改改之後才可以。這樣就導致，發現一段程式碼有問題，就需要改複製了這段程式碼的其它程式碼，這樣就導致很可能有些地方漏改。

解決方案：

以後再實現某一功能是時，首先抱著這種態度——這個功能以後一定會重用，然後按這個思路來設計輸入輸出介面。要做的這點，必須先要對接下來要實現的功能做一個抽象，把這個功能分成兩部分，一部分是通用部分，一部分是非通用部分。通用部分的介面是面向重用的，非通用部分的介面是面向特定系統的。

其實個人覺得模組化思維還是跟專案經驗有關係，只有寫過不好的程式碼，才能意識到好的程式碼應該是什麼樣的。

2.對資料的封裝做的不好

問題：剛開始做時，覺得資料分類越清晰越好，於是就建了很多表。這樣做有好處，也有壞處。好處就是查詢的效率比較高，壞處就是程式碼的重用度很低，因為資料庫是為了適應某個專案而建立的，再換一個專案，有些資料就沒有用了，而且需要再新增另一些資料，這樣一來，不同系統中操作資料庫的程式碼的重用度就降低了。

解決方法：

以後再做專案時，首先要根據客戶已經接收的流程圖，來對資料做一個規劃，抽象出來通用資料和專用資料，先建立資料庫結構，然後再寫程式碼。