剛進公司的那會，導師出差了，就跟著一個公司號稱很牛的人一起開發一個工具。那哥們整天喜歡搞一些很神奇的技巧，簡簡單單的一個邏輯檢查工具搞什么多線程，多線程就不說了，確實是有必要的，可惜他開發出來的框架，讓我們這些寫具體實現的小嘍啰學習了將近一個多星期也沒有整明白，不但沒有設計文檔，代碼里面一切注釋欠奉，別人去問他怎么搞，總是說你去看代碼就知道了哦，當時作為新人確實是比較郁悶哦，想說也不敢說哦，記得當時實在是受不了跑去向該牛人請教一下他提供的接口該怎么用的時候，聽到了一句俺一生都記得住的話：程序員之間是靠代碼交流的，你去看我的代碼！
狗屁哦！如果我有一天是老板了，我手下的員工要是敢說出這樣的話，立馬叫他滾蛋哦，真是shit！一份沒有提供對外接口詳細實現的文檔的代碼就不能接受了，如果加上在關鍵實現的地方沒有注釋的代碼那就更不能原諒了，最可惡的要是負責提供公共方法的程序員居然神神道道的說讓別人去看什么文檔注釋都欠奉的代碼來了解公共接口怎么用，這樣的員工不是浪費大家的時間嗎，每個程序員編程的風格都是不一樣的，實現同一個問題的思路也是不同的，你讓別人去看你的代碼，那要你實現公共方法有什么用哦，還不如讓別人自己都來寫方法算了哦！
記得這個事情曾經和現在的老大在外面抽煙的時候聊過，他的分析我就覺得很有道理哦，公司招人來編程是要效率的，每天的程序員的工資也是不便宜的，你讓別人做一些重復的不必要的工作就是在浪費公司的資源，浪費公司的資源那就降低了效率，降低了效率那就是害群之馬哦! 現在編程說是技術又能有多大的門檻，找幾個中人之資的人基本上是可以抵得上一個在技術上比較牛的人了，什么技術找幾個人每個人專門搞這玩意的一個方面，總是能趕得上一個牛人的。那你作為牛人一個人搞定了一件事，可是這件事情只有你一個人知道怎么做，不告訴其他的同事怎么去做，大家作為一個團隊，整體的效率其實是低下的。
想想也是哦，當時我們小組的七個人寫實現，花了一個多星期才弄明白那哥們寫的框架是怎么搞的，這個框架整明白了，還要整他提供的公共接口又花了好幾天的時間。呵呵，算起來也抵得上一個人搞兩個月了哦，那工具讓我一個寫，我現在想起來以我當時一個對業務邏輯完全不熟悉的人估計一個月也能整出來哦，這樣來算減法其實是浪費了不少時間的哦。再說啦，那所謂牛人寫的工具的框架也不怎么樣哦，整的是多線程可是深究下去其實還是單線程的設計思想，基本上沒有體現多線程的優點，什么都往內存里面搞，跑起來隨隨便便就4G的內存消耗，線程之間的調度也是垃圾的要死，到這哥們離職的時候工具還動不動就掛掉了哦，早聽我的在后臺建立一個監控線程來調度各個線程也不用通宵調bug也找不來為什么了哦，呵呵幸虧中途離開了那個小組，導師回來的真是時候哦，要不然接手了那個爛攤子不把自己搞死哦，順便為接受爛攤子的難友默哀一下！
呵呵，廢話這么多 終于引出第一篇Blog的主題，沒有文檔的代碼就是垃圾，我覺得一個項目開始開發的時候做的第一件事就是編碼風格的確定，編碼風格包括很多啦，不過其中的重點就是公共接口的規范化命名，注釋的寫法，文檔的規范，這些東西允許有不同意見，可以在小組會議上提出來，大家經過討論，哪怕是相互爭吵，只要是有道理的就應該采納。不過，不管怎么樣只要確定了編碼風格一定要強制執行，如果組員寫出了不符合規范的代碼，一定要讓其重寫，這樣對以后的開發是大有好處哦！還有就是設計文檔一定要同步于代碼哦，俺們公司雖然是過了CMMI 3可這最基本的一點都做的不好啊，不過我們項目做的還是不錯的啦。