去年這個時候，要開發乙個新的功能，主要就是與別的程式進行通訊，並解釋相應的xml
協議包，根據這些協議包功能進而向伺服器**相應的命令，然後當伺服器回應之後再組
xml協議包傳送給原來傳送命令過來的程式。就這麼樣乙個功能，大概有10個
xml協議包，這個員工設計這個功能，就只寫三個類：接收
xml資料類、解析
xml協議並處理類、回應包
xm協議打包類。這樣的設計，在起初兩三個協議包時，工作起來還是很正常，當協議包達到
10個之後，就發現問題很多了。要麼重發組包不對，要麼解析資料不對，要麼回應之後找不到相應的物件等等。越到後面，發現問題越多，由於此功能還有很多使用者在等著使用，專案緊急，當我去審查**時，發現這樣一種情況，所有**就寫在這三個類裡，每個
cpp檔案都已經超過
7000
行大小，每個函式也很長，要顯示幾屏才可以顯示完，巢狀的迴圈和判斷語句超過四層。剛從這些表象看來，就是一種不好的徵兆，讓人感覺**設計不好，程式設計的習慣不好，這樣的**怎麼可能表現出來高質量？高效率？
由於專案緊急，只能先在原來的基礎上，作了一些基本的修改，主要縮短函式的大小，讓每個函式至少在兩螢幕之內顯示完，另外把多層巢狀迴圈和判斷分成小函式呼叫。經歷過這兩樣修改之後，**質量提公升了不少，解決bug
另乙個問題，就是多層巢狀迴圈和判斷。這個問題，在我以往的文章裡也有寫過，但是還有很多新進入軟體行業的新人，還是前赴後繼，繼續發揮這個「傳統」，這讓我感覺到還是要大力呼喊，大家能否多考慮一下這個問題，能否改掉這個壞習慣？首先，如果巢狀迴圈超過三層，就不要寫第四層了，要立即把第四層內容寫到乙個小函式裡，在前面三層迴圈裡呼叫這個小函式。其次，就是判斷語句的巢狀，如果超過三層，也應立即把裡面的內容改寫到小函式，這樣達到層次不超過三層。最後，通過上面兩點修改，肯定可以把函式變小，從而也達前面函式短小的，乙個函式只做一件事情的目的。
通過上面兩個修改，只能免強可以讓功能實現起來了，基本上能使用。但是擴充套件性、可維護性還是很差，根據沒有高大上的感覺。因為每個cpp
檔案還是很大，達到
7000
多行，當想查詢某乙個功能時，就需要回來滾動，以及重新編譯，你想像一下，乙個
cpp檔案如果只
1000
行，分成
7個檔案，一般情況下只會只修改乙個檔案，那麼編譯時可以只編譯其中乙個檔案
1000
行即可，而不是目前的
7000
行，從這裡來看就可以提公升效率很多。另外，由於設計類過少，這才是個大問題，把很多功能全部融在一起。針對這個問題，在後面的時間裡，立即調整了設計，把所有
xml協議包分成乙個類，這樣每乙個協議包的功能都在乙個類裡，再新增乙個協議，就增加乙個類的方式，這樣擴充套件就很方便了。同時協議類裡採用基類實現相同的功能，不同協議類採用派生類來實現的方式，達到相同**復用，不同功能分成不同類，並且提供相同的虛函式，再通過派生類過載虛函式提供不同的功能處理。經過這樣整理，寫了很多類，每個類功能都實相應的資料結構和演算法，無論從維護和查詢
bug的時間，都大大公升級了。
從這段經歷裡，可看到類不是少就是好，應是多寫一些功能類，同時多寫一些cpp
檔案，這樣可以減少類**的大小，減少
cpp檔案裡**的行數，堅持採用物件導向設計思想：物件+物件
=軟體，資料結構
+ 演算法
= 物件。
企業 需要多一點好創意
有一則寓言 上帝製造了乙個怪結，稱為 高爾丁 死結，並許下承諾 誰能解開 高爾丁 死結，就將成為亞洲王。所有試 開這個怪結的人都失敗了，最後輪到亞歷山卓，他說，我要建立自己的規則。他抽出寶劍，一劍將 高爾丁 死結劈為兩半。於是他就成了亞洲王。寓言深入淺出地道出了 創意 的真諦。創意絕不是一般意義上的...
多一點積極 少一點悲觀
一直想著積極的東西，就像漫步在燦爛的陽光之中，心情也會變得越來越好 一直沉浸在悲觀的想法裡面，整個世界也都似乎被一片厚重的陰霾給籠罩起來。其實事情沒自己想得那麼好，更沒自己想得那麼糟，一切都是自己的假設，由此引發的喜怒哀樂都是清晨的薄霧 花草間的露水，注定是要消失得無影無蹤。只有建立在真實發生了的事...
Unix Linux環境下多一點不如少一點
正如很多人所知道的 path環境變數裡存著一張目錄列表，當使用者要執行某一程式時，系統就會按照列表中的內容去查詢該程式的位置。當程式名前不帶點斜線 時 path就會起作用。對於普通使用者和root使用者 path裡預設是不包含 來指定使用者的當前目錄。這在本機進行指令碼開發的程式設計師來說卻不方便，...