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