之前聊過(guò)工程師的生產(chǎn)力不應(yīng)該用程序代碼來(lái)衡量，因?yàn)樗麄兊臉O致生產(chǎn)力，是在少寫幾行程序，而不是在多寫幾行程序。今天剛好又看到兩篇文章，可以用不同的面向延伸、解釋這建事情?！　∈紫龋且晃慌苋ト毡窘逃⑽牡那叭诬浖こ處?，發(fā)現(xiàn)了寫程序和學(xué)語(yǔ)言間的共通性，他說(shuō)：
 

這些工程師往往可以輕松的通過(guò)面試，但當(dāng)他們真正開(kāi)始工作，卻讓人大失所望。我讀了很多關(guān)于這個(gè)問(wèn)題的研究，但當(dāng)我越看它，就越發(fā)現(xiàn)這些「殘障工程師」，就好像我的英語(yǔ)學(xué)生一樣。他們有 5,000 字的詞匯，書(shū)里面的每一個(gè)文法都背得滾瓜爛熟，但是就是說(shuō)不出一句話。
我的理論是，程序其實(shí)就跟寫作沒(méi)什么兩樣。多數(shù)的程序概念上一點(diǎn)都不難(跟你想的不一樣)，我們搞不好的原因往往只是寫作能力太差。大部分的工程師根本就不是「流暢」的語(yǔ)言使用者，也沒(méi)有努力想要讓自己變得流暢。他們不去多讀讀他人的程序，看不懂也不會(huì)使用「成語(yǔ)」，更不會(huì)「用程序語(yǔ)言來(lái)思考」。這些人寫出來(lái)的程序很糟，因?yàn)樗麄兏揪褪怯?jì)算機(jī)語(yǔ)言的三歲小孩，卻試著要寫一本小說(shuō)。

　　所以如果你是軟件工程師，多讀讀別人的程序代碼，是很重要的，就跟學(xué)習(xí)寫作一樣。
　　相反的，如果你的程序想要讓人家讀懂，那 documentation 是非常重要的。GitHub 工程師 Zach Holman 發(fā)表了一篇非常棒的文章，詳細(xì)解釋了為什么你要寫文檔，怎么寫。
 

  • Documentation 是個(gè)人的 —— 相信我，你以后一定會(huì)回來(lái)改這些程序，如果要讓未來(lái)的自己更快進(jìn)入狀況，把事情搞定，今天請(qǐng)你務(wù)必把東西寫清楚。
  • Documentation 是清楚的 —— 如果你不把你推出去的程序代碼講清楚，那根本是在幫自己找麻煩，以后一定會(huì)出現(xiàn)一堆 bugs、困惑的同事，最后搞得自己更累而已。
  • Documentation 是可以測(cè)試的 —— 因?yàn)槟惚仨氁殉绦虻倪壿嫿忉屒宄@讓你重新思考自己的寫出來(lái)的東西是不是符合原始精神，有沒(méi)有更好的方式。為了不在寫文件時(shí)陷入無(wú)法解釋的難關(guān)，這也迫使你簡(jiǎn)化每一個(gè)功能，把一個(gè)復(fù)雜的東西切成好幾個(gè)功能。
  • Documentation 是可以比較版本的 —— 好的文件可以讓版本間的比較更容易，也讓團(tuán)隊(duì)合作更有效率。
  • Documentation 是營(yíng)銷 —— 透過(guò)好的文件，可以讓下載你軟件的人更容易開(kāi)始使用，這也大大提升了轉(zhuǎn)換率。
  • Documentation 讓你表現(xiàn)更棒 —— 這點(diǎn) Zach 還在驗(yàn)證，不過(guò)他認(rèn)為建立好的文件讓你很酷，這應(yīng)該對(duì)自信會(huì)有幫助。
     

　　以上，希望這些觀念可以幫助你們更了解工程師、效率和生產(chǎn)力之間的關(guān)系，加油！