“成為優秀技術人員的兩點建議”,這篇部落格裡面提到一個很重要的程式員面對任務的態度問題,覺得很有意思和感觸,就寫了這篇文章。
第一.Don't treat the code you not own as blackbox
這個在現實中,由於時間的關係往往做不到,主要是中國現實外包加工或老闆以任務進度來進行項目控制以及績效考核,不過這種方法是一個程式員從普通通往優秀的必經之路,想想我們不要做天天在敲鍵盤的工人。你想想真正有思想的程式員,完成一段代碼不過是有幾分鐘而已,真正要話大量的時間的是思考過程,而有效解決考慮時間過長的問題就是要熟知整個系統的組件以及組件關係。另外一個功利的想法,我要是設計整個系統,我自己開公司去,這不又加速自己主動去學習其他的組件了吧:) 雖然這種方法不可取。
第二. Don't assume, just confirm
的確我們在碰到問題的時候,特別是調試的時候,總是覺得這個肯定沒有問題,那個肯定沒有問題,那麼問題究竟出在哪裡呢,唯一的辦法就是建立checklist一個一個confirm。
看了評論,想到了服裝生產管理裡面的計件工資與計件工資考核。現在中國普遍採用的是計件工資制度,我們大部分的程式員在績效考核的時候都是解決了多少個問題來評定這個人幹了多少活。而且Boss總是要求你快點把活幹完。老闆關心的是進度與成本以及收益。由於上層的這種意識導致程式員圖快而不圖好,你想想大家都要養家糊口的啊,我不快點怎麼行。
剛好看到一個在實施計件工資制度的案例,裡面講到,一個經理去實行這個制度,搞得大家都抱怨罷工,最終經理被調到另外分廠。而另外一個經理也要實行這種計件工資制度,不過這位經理實施的是先提高大家的水平,同時嘗試部分施行這種制度,最後在10個月後順利在全公司範圍內實施。
所以作者提出的兩個觀點是程式員素質提升的有效方法,不過由於現階段我們的現狀導致我們成為代碼工人(和服裝廠的加工工人一樣),如果企業高層沒有意識到這個問題,那麼就不從根本解決企業軟體的品質問題,更無從提高軟體品質。 因為代碼工人都是以完成任務為出發點,不管品質的,但往往是這種態度又浪費了很多的時間,導致整體品質下降。所以為了更好的解決這個問題,首先項目要給大家一定的適應時間以及技能提高時間,再加強品質檢測(QC),才能是一個雙贏的局面。如果是做項目外包的,由於項目周期短,那麼可以考慮建立一種長期的相互學習的機制(實際上應該是屬於企業文化的範圍),敏捷開發裡面講到的結對程式設計應該就是要建立一個相互學習、相互提高、相互交流的機制來提高項目的品質。