工作一年有餘，最近負責專案組內**重構。簡單說下我的體會。
很多時候，我們都在說物件導向程式設計，可物件導向到底怎麼理解，估計每個人的想法都不一樣。很多人會告訴你一些很理論的東西。
比如「封裝」「繼承」「多型」「單一職責」「依賴倒置」等等一系列高大上的名詞。更有甚者會搬出設計模式之類更加高大上的東東。
好像不掌握這些，就寫不出「優雅」的**。
不管別人怎麼想，我覺得，所謂的物件導向方法，並不能嚴格算作程式設計方法，或許叫它**管理方法更合適一點。
它可以算是一種標準，一種組織**的方式。拋卻過度設計的情形，你的**，應該呈現出某種結構，而這種結構，應當使半個月後進行維護修改的人看得懂。
我不太贊成一直埋頭寫**而不去考慮**風格，我所在的公司，存在很強的加班文化，也確實，任務一直都挺趕。但每次加班的時候，我都不會為了趕進度去碼**，而是停下來，想想**裡有哪些可以優化的結構。從某種意義上說，我不能算是個好員工。
可能某天來個任務，讓你實現一塊黑板，讓人可以在上面用白色筆進行畫寫擦除，你分析下，上網找找相關api，在半小時內完成了，然後去趕其他任務，比如登入註冊之類。
兩天後，需求改動，讓這塊黑板上可以用「紅黃藍」三種顏色的筆進行書寫，ok，api稍稍整合下，接著以前的**，繼續寫。
再過兩天，需求又變動，不僅要可以擦除筆跡，還要可以選擇某塊區域選擇性的擦除，ok，再看看api，任務也很快完成了。
再來兩天，產品設計人員又說啦，這畫筆的筆跡要有區分，不然怎麼突出強調呢？於是乎，又加了一塊設定筆跡粗細的**。
再過兩天，產品又說啦，這演示出來的效果不夠炫，不能吸引人，我要再實現一種不同於現在的畫筆的筆，這種筆畫出來的筆跡在3秒後會閃一閃然後消失，恩，就叫螢光筆吧。
於是，又加了一段。基本上**不整理下是不太能看了。沒關係，還能忍。
第二天，產品出差回來：競爭對手也設計了這個模組，他們有個新功能，叫調色盤！我們必須有！否則怎麼和他們競爭！於是乎，你覺得**有點理不出頭緒了。想整理下，臥槽，只給了半天時間開發，明天就要演示，沒時間折騰，草草糊弄個能用的模組，確保演示不出大問題，先拿下訂單再說！
ok，也許這些都還能hold住。半個月後，公司結交個戰略夥伴，他們有個很厲害的識別引擎，於是乎，你的黑板模組，需要整合這個牛哄哄的東西。這需要在書寫筆跡的時候，收集一些點跡座標，你還能找到在哪新增**嗎？ok，你是個大神級人物，記憶力還不錯，照樣在一天之內搞定了。
於是乎，在記錄點跡的時候，還要考慮討厭的板擦。
功能還沒提交，測試又說了，我現在黑板右邊寫個一，再往左邊寫個二，看起來，筆跡是「二一」，你這識別成「一二」，不太合適吧。
再再然後，開發這塊的人找到更好的去處，辭職了。
……這差不多是個真實的故事。等到真正有時間重構這一塊**的時候，可能已經沒有人能夠看得懂了。架構師告訴我，你簡單看下，能用就用，不能用就重寫吧。
試試看吧，還好，蠻獨立的乙個模組，2000多行，從上到下讀一遍，充斥了不少重複函式和亂七八糟的非同步互動，還有耕種各樣的不知何意的命名變數。
放眼望去，「滑鼠按下」「滑鼠移動」「滑鼠抬起」三個大互動函式，然後裡面各種各樣的if...else...
簡單梳理下，拆分了下**，弄出來一堆檔案，每個檔案裡乙個類：
畫筆類，螢光筆類，板擦類，調色盤類（包括改變筆跡粗細的那部分也在這裡），手勢類，引擎識別介面類。
其中，引擎識別介面類只訪問手勢類，手勢類由畫筆板擦生成修改，畫筆和螢光筆類訪問調色盤類。
最後，全部整合成黑板類，對其他模組來說，就好像沒有變一樣。
最初沒有打算弄出手勢這麼個類，但後面發現乙個陣列操作起來確實不怎麼方便。
再再後來，為了簡化，乾脆弄出兩塊畫布，一塊用來讓筆畫，另一塊用來讓黑板擦。這樣判斷滑鼠狀態就省事多了。
理論上蠻簡單，想把這一切全部抽出來相互獨立，還是花了一天時間。
就在我糾結要不要把兩塊畫布按以前的樣子合併成一塊的時候，很快，產品又覺得一點點擦除的設計太蠢，要用滑鼠拖出一塊矩形區域，這個區域內所有的筆跡都要清除。
瞬間就覺得自己很機智的樣子。因為拖拽出矩形是乙個互動過程，畫布上的矩形是要不停的擦除——獲取當前滑鼠位置——繪製更大矩形的過程，而這一過程中，區域內的筆跡是不可以被擦除的。直到滑鼠抬起時，再將下面畫筆的畫布上的筆跡清空。
短的**自然有短**的好處，至少，能夠很快的定位，無論是改bug還是加功能，都比在長**裡面查詢方便的多。
以前我對**風格也不怎麼在意。只是看到專案裡面隨意的命名不爽。也許，要怪自己總是望文生義吧。
這個模組裡paint指代筆跡，stroke指代手勢，到下個檔案可能就變味了。
有些是為了趕任務遺留下的問題，比如，今天，產品腦袋一拍，我們做個資源搜尋的模組出來，展示我們的資源，這功能，就叫資源庫吧！
哼哧哼哧弄出來了，產品又變想法了，恩，這個叫「資源庫」可能不準確，改成「搜尋面板」好了，我來重新設計下「資源庫」的功能。
於是，以前的**裡到處是「reslib」的詞眼，想改動，不好動。於是，這塊乾脆不動了，弄個新模組，到處是「ziyuanlib」的字眼（更糟糕的可能叫「reslib」）。
可能，兩個月後，另外乙個人被要求維護現在的「新」資源庫，然後找半天「reslib」找不到入口**在哪。
亦或者，「資源庫」和「搜尋面板」同時設計，同時完工，快發布上線的時候，出於對產品的考慮，產品決定把已有的「資源庫」對外稱作「搜尋面板」，而「搜尋面板」對外稱作「資源庫」。
經過，兩個版本，人員交替，抽調的抽調，離職的離職，跳槽的跳槽。
再來個人維護，你可以想象下維護者滿臉零亂的表情。
再後來，和其他組合作的時候，我都要求對方把介面裡每乙個固定的字面引數代表什麼含義寫成文件，簽字畫押。。。。
不要以為**裡出現「zhangsan」就真的指代「張三」，說不定原本「張三」叫「李四」，然後哪天產品心血來潮，把「張三」改個名。
不過，看了裡面的原始碼，才明白統一風格對於團隊有多重要。當時看的時候，感覺核心部分還好，蠻一致的。
後來要新增功能，需要我為其加外掛程式了，翻翻其已有的外掛程式，不能說復用性很低，至少可讀性很低。
舉例來說，核心那塊**，用editor指代編輯器本身，用me指代當前模組。
然後有些外掛程式裡面，就用me指代編輯器,然後看**的時候，總造成障礙。
後來，專案做到一半被領導層放棄了，就再沒看過ueditor。不知道現在怎麼樣了。
從那以後，我對開源的大型專案持保留意見。
現在，我所在的專案裡，比較討厭的東西是自定義事件，我覺得，應該存在某種方法把這種太過靈活的程式設計方式廢棄。
用得好，是亮點；用爛了，就成負擔了。
不知道什麼時候什麼東西就在**加上乙個事件，也不知道什麼時候就觸發了這個事件。整個**亂七八糟的。
最後一點點不太理解的東西，就是物件導向裡面的「私有」「公有」「保護」的區別。
直到現在，都不太理解。在程式設計師手上，「保護」型別連自己都「保護」不了，還提什麼「保護」？
只要程式設計師願意，任何時刻都能刪除或改成「公有」。
近期工作小結
初入無線增值行業，就接受了一項比較糾結的任務 系統改造。由於一些特殊的歷史原因，原系統沒有留下任何設計文件，成了唯一的線索。之前的主要工作是編寫業務需求和做一些簡單的系統分析，完全沒有coding的經驗，於是乎頓感窘迫。冷靜下來之後發現，其實整套 的結構還是比較清晰的 1.業務識別 通過每項業務的特...
近期問題小結
前段時間工作上的事情太多了，終於搞定了pvr，這段時間太清閒，於是又拿出自己的板子玩。總結下這段時間的一些筆記，備忘。主要遇到的問題有 1.svc failed to register lockdv1 rpc service errno 111 mount mounting 192.168.1.10...
近期語法使用小結
1 typename 在c 11中 代替 class用於宣告標示符為型別，class主用於宣告或定義類型別和強列舉形式。另外typename增加了類似於 define 這樣的巨集定義功能，不過不是簡單的字元替換，而是高於字元替換級別，將字元1宣告為型別標示符去宣告字元2為變數。2 unable to...