第一篇：優(yōu)秀程序員是如何處理糟糕代碼的

優(yōu)秀程序員是如何處理糟糕代碼的

可能你一行不好的代碼也從來(lái)沒有寫過。這是有可能的，但在現(xiàn)實(shí)中又不太可能。

現(xiàn)實(shí)情況是，和這個(gè)星球上的其他所有程序員一樣，你會(huì)產(chǎn)出安全漏洞、UI元素偏移，等等等等的代碼。這并不能說明你是一個(gè)不好的開發(fā)人員。只是因?yàn)槟闶侨祟惗选环N不可避免會(huì)犯錯(cuò)的生物。

正是這種每個(gè)開發(fā)人員都有的“人性”缺陷，驅(qū)使那些優(yōu)秀的開發(fā)人員敢于承擔(dān)代碼和底層基礎(chǔ)架構(gòu)的不足，有準(zhǔn)備有計(jì)劃地行動(dòng)。下面是他們將做的事情。

假設(shè) 幾年前，Netflix開源了Chaos Monkey和Simian Army的其他部分（Simian Army是一套工具，用來(lái)管理基于云的軟件）。從本質(zhì)上說，Chaos Monkey的范圍貫穿亞馬遜Web服務(wù)的基礎(chǔ)設(shè)施，能夠隨意終止實(shí)例。從根本上說，它是一種通過創(chuàng)建最壞的可能方案來(lái)做最壞打算的方法。

正如Netflix的Cory Bennett和Ariel Tseitlin于發(fā)行之時(shí)在博客上這樣寫道，“代碼會(huì)失敗，并且你越不希望失敗或一點(diǎn)也沒有準(zhǔn)備的時(shí)候，反而更加不可避免會(huì)出現(xiàn)故障。如果你的應(yīng)用程序不能容忍實(shí)例故障，那么你是愿意凌晨3點(diǎn)被召喚呢還是在辦公室里通宵？”

使用不可預(yù)測(cè)的方式來(lái)模擬故障，Netflix強(qiáng)迫注重基礎(chǔ)設(shè)施的彈性。與其假設(shè)最佳的情形，還不如做一個(gè)最壞的打算。這樣我們就能愉快地進(jìn)入下一個(gè)進(jìn)程了。測(cè)試

上面我們說了一個(gè)提高基礎(chǔ)設(shè)施的偉大方法，那么代碼呢？

Jeff Atwood，一個(gè)程序員的答案是：“你需要折騰你的代碼。”他寫道： 我相信，每個(gè)專業(yè)程序員職業(yè)生涯的一個(gè)關(guān)鍵轉(zhuǎn)折點(diǎn)，就在當(dāng)你意識(shí)到你才是自己最大的敵人，以及減輕這種威脅的唯一辦法就是接受它的時(shí)候。將自己當(dāng)作最大的敵人。打破你的用戶界面。打破你的代碼。折騰你的軟件。

在實(shí)踐中，這意味著“程序員至少需要對(duì)常見錯(cuò)誤有一定的了解，然而，很多程序員往往不會(huì)這么去做，甚至是反著來(lái)。”這意味著你作為“編程之神”的責(zé)任也包括成為“測(cè)試之神”，通過“折騰”代碼積極地來(lái)消除里面的錯(cuò)誤。

Andre Medeiros補(bǔ)充認(rèn)為我們應(yīng)該對(duì)調(diào)試“精益求精”，因?yàn)殚_發(fā)人員需要對(duì)他們的代碼做更多的事情。

“為了防止bug，你寫出來(lái)的代碼得讓任何程序員都覺得簡(jiǎn)單。為了修復(fù)bug，你得理解你的代碼。為了精密地了解代碼，你需要列舉和驗(yàn)證你的假設(shè)，如果有必要，你還需要構(gòu)建調(diào)試工具。”

貧民窟上的摩天大樓

當(dāng)然，對(duì)于我們的代碼，其最大的問題之一是，它繼承了如此多其他的代碼。特別是在已建立的企業(yè)中，我們常常構(gòu)建在舊代碼上，從而導(dǎo)致了各種后續(xù)延伸問題。以下是Zeynep Tufekci的精彩描述：

將它比喻成造房子的話——也就說你將要在已經(jīng)造好的底層基礎(chǔ)上造二樓。但房子一開始造的時(shí)候并沒有造好，沒有打好地基，你也不知道哪面是承重墻。你只能盡可能地去猜，然后造好了一個(gè)樓層——用你的手指。然后你接著這樣做。很多舊但控制著基礎(chǔ)設(shè)施關(guān)鍵部分的軟件系統(tǒng)就是這樣運(yùn)行的。在某一段時(shí)間內(nèi)它也的確是可以工作，但每一個(gè)新樓層的建造意味著增加了更多的漏洞。我們正在代碼中建設(shè)貧民窟上的摩天大樓——而且，還在地震區(qū)。很顯然，我們對(duì)于改善這種情況束手無(wú)策，除非我們能夠致力于去除技術(shù)債務(wù)。

但也許，只是也許，在心甘情愿折騰代碼的過程中，你會(huì)發(fā)現(xiàn)消除技術(shù)債務(wù)是如此之重要。【編輯推薦】

是誰(shuí)炒出來(lái)個(gè)程序員泡沫？

程序員痛苦的源頭：一個(gè)bug

國(guó)外程序員常去的14個(gè)頂級(jí)開發(fā)社區(qū)

成為核心程序員的一些建議

程序員保值的4個(gè)秘密

第二篇：程序員如果做到每天寫代碼？

對(duì)于程序員來(lái)說，如何做到每天都寫代碼呢？可汗學(xué)院計(jì)算機(jī)科學(xué)學(xué)院院長(zhǎng)暨jQuery創(chuàng)始人John Resig撰文分享了自己的心得和體會(huì)。下面，一起看看他是如何做到的----首先他給自己定下了幾條規(guī)則：

1.每天必須寫代碼。可以寫文檔、博客或者其他的文章，但是必須要加進(jìn)自己寫的代碼。

2.代碼必須是有用的。不要格式化、重構(gòu)的代碼。

3.代碼必須在午夜之前寫好（為了避免不想熬夜而草率地寫代碼）。

4.代碼必須是開源的，且要放到Github上（這樣強(qiáng)迫自己小心寫代碼，并會(huì)考慮代碼重用性及怎么創(chuàng)建項(xiàng)目前期的模塊）。

當(dāng)然，以上這些規(guī)則是靈活的。John Resig之所以制定這么嚴(yán)格的規(guī)則，是想提高自己業(yè)余項(xiàng)目的開發(fā)效率。他已經(jīng)在連續(xù)20周的時(shí)間里每天寫代碼，這給他帶來(lái)了好的工作習(xí)慣。鑒于此，John Resig為大家分享了自己堅(jiān)持每天做業(yè)余項(xiàng)目后的心得體會(huì)：

利用最小化的時(shí)間寫好代碼。

我強(qiáng)迫自己每天花不少于半個(gè)小時(shí)來(lái)寫代碼（這真不是一件容易的事，尤其還得回憶前一天寫了什么），在工作日期間一般不超過一個(gè)小時(shí)，但在周末我會(huì)花多一些時(shí)間做業(yè)余項(xiàng)目。

讓寫代碼成為習(xí)慣。

要知道我并不關(guān)心自己在Github上的排名，因?yàn)槲矣X得做業(yè)余項(xiàng)目是自己的事，不要為了取悅別人而做。減肥和鍛煉也是同樣的道理，如果你不在乎提升自己，你永遠(yuǎn)都不會(huì)取得成功。

與不良情緒作斗爭(zhēng)。

在開始實(shí)施每天寫代碼的計(jì)劃前期，我時(shí)常焦慮項(xiàng)目沒有很大的進(jìn)展，畢竟業(yè)余項(xiàng)目沒有時(shí)間限制。后來(lái)我意識(shí)到有這樣的不良情緒對(duì)項(xiàng)目進(jìn)展一點(diǎn)幫助都沒有，反而會(huì)阻礙。所以要與不良情緒作斗爭(zhēng)，現(xiàn)在我能心平氣和地完成大量的工作，再也不會(huì)像以前那樣為工作的事情忙得焦頭爛額了。

安排、利用好周末時(shí)間。

對(duì)大多數(shù)人來(lái)說，利用周末時(shí)間做業(yè)余項(xiàng)目是項(xiàng)目取得大進(jìn)展的絕好機(jī)會(huì)。而對(duì)于我來(lái)說，如果直到周末業(yè)余項(xiàng)目才能做好我會(huì)對(duì)自己很失望。之前我很少能完成所有自己想做的工作，這也就強(qiáng)迫自己不參加諸如參觀博物館、游公園等自己喜歡的周末娛樂活動(dòng)，把時(shí)間留給工作。然而現(xiàn)在我強(qiáng)烈地意識(shí)到盡管業(yè)余項(xiàng)目很重要，但是也不應(yīng)該忽略個(gè)人生活，所以學(xué)會(huì)安排時(shí)間很重要。

潛意識(shí)思考。

每天做業(yè)余項(xiàng)目寫代碼有一個(gè)有趣的副作用，那就是大腦會(huì)在潛意識(shí)里思考。因此，當(dāng)我在散步、淋浴或從事其他非腦力活動(dòng)時(shí)，我還在想著下一步代碼該怎么寫、出現(xiàn)問題了有什么解決的好方法，以前我每星期或者隔一個(gè)星期寫一次代碼從沒出現(xiàn)過這樣的情況。時(shí)間用來(lái)思考自然就不會(huì)再為業(yè)余項(xiàng)目取得的進(jìn)展少而焦慮了。

每天寫一點(diǎn)代碼不易忘。

當(dāng)接頭做業(yè)余項(xiàng)目時(shí)總要付出“上下文切換”的代價(jià)，然而不幸的是思考是很難接上頭的。所以我每天都做一點(diǎn)業(yè)余項(xiàng)目，讓自己不容易忘記。

管理好時(shí)間，平衡工作、生活、業(yè)余項(xiàng)目。

現(xiàn)在的我已簡(jiǎn)單地學(xué)會(huì)了如何更好地維持工作、生活、業(yè)余項(xiàng)目的平衡，我知道自己每天都要做業(yè)余項(xiàng)目，所以我會(huì)更好地管理時(shí)間。如果我晚上有活動(dòng)且很晚才能回家，那么我會(huì)在開始工作之前就做好當(dāng)天的業(yè)余項(xiàng)目。假如當(dāng)天的業(yè)余項(xiàng)目沒有做完，那么不論多晚我都會(huì)完成，做到今日事今日畢。

要及時(shí)跟外界溝通。

當(dāng)自己養(yǎng)成了新的習(xí)慣后跟外界溝通這是很有好處的。我的伙伴們都知道我每天寫代碼這個(gè)習(xí)慣，因此有活動(dòng)安排時(shí)我會(huì)跟他們說：“等我寫完代碼再去。”他們一點(diǎn)都不會(huì)介意也很理解我的行為。

代碼積少成多。

我很難相信自己在過去的幾個(gè)月寫了很多的代碼。我新建了幾個(gè)網(wǎng)站，重新寫了框架并創(chuàng)建了大量節(jié)點(diǎn)模塊。我已經(jīng)寫了這么多以至于有時(shí)我都忘記自己寫了些什么，但是我真的很高興我寫了這么多的代碼。

好的習(xí)慣能帶來(lái)巨大的成功，武漢北大青鳥光谷校區(qū)專業(yè)老師指出，像每天寫代碼做業(yè)余項(xiàng)目這件事只要你堅(jiān)持做下去，一定會(huì)有意想不到的效果。

第三篇：代碼審查是由若干程序員和測(cè)試員組成一個(gè)審查小組

代碼審查是由若干程序員和測(cè)試員組成一個(gè)審查小組，通過閱讀、討論和爭(zhēng)議，對(duì)程序進(jìn)行靜態(tài)分析的過程。代碼審查分兩步。第一步，小組負(fù)責(zé)人提前把設(shè)計(jì)規(guī)格說明書、控制流程圖、程序文本及有關(guān)要求、規(guī)范等分發(fā)給小組成員，作為審查的依據(jù)。小組成員在充分閱讀這些材料后，進(jìn)入審查的第二步，召開程序?qū)彶闀?huì)。

走查與代碼審查基本相同，其過程分為兩步。第一步把材料先發(fā)給走查小組每個(gè)成員，讓他們認(rèn)真研究程序，然后再開會(huì)。開會(huì)的程序與代碼審查不同，不是簡(jiǎn)單地讀程序和對(duì)照錯(cuò)誤檢查表進(jìn)行檢查，而是讓與會(huì)者“充當(dāng)計(jì)算機(jī)”，即首先由測(cè)試組成員為被測(cè)程序準(zhǔn)備一批有代表性的測(cè)試用例，提交給走查小組。走查小組開會(huì)，集體扮演計(jì)算機(jī)角色，讓測(cè)試用例沿程序的邏輯運(yùn)行一遍，隨時(shí)記錄程序的蹤跡，供分析和討論用。

------------------

我們把代碼審查叫做CR，即Code Review。它是項(xiàng)目進(jìn)展到編碼階段非常重要的品質(zhì)保證活動(dòng)。但是很多時(shí)候，我們的CR工作都流于形式，在CR過程中不能發(fā)現(xiàn)本質(zhì)問題，主要有以下四點(diǎn)原因：

一，CR時(shí)的目的性不強(qiáng)，缺乏針對(duì)性。CR的根本目的是保證品質(zhì)，但不能把它做為一次CR活動(dòng)的直接目標(biāo)，這樣的目標(biāo)太泛泛，讓我們?cè)贑R活動(dòng)過程中抓不住重點(diǎn)。二，CR活動(dòng)時(shí)參與的角色不合理。參與CR活動(dòng)的人大多是技術(shù)合格，但業(yè)務(wù)不合格，這樣對(duì)于一些復(fù)雜的業(yè)務(wù)邏輯問題就很難發(fā)現(xiàn)，從而使得這些業(yè)務(wù)邏輯問題在CR的保護(hù)傘下，堂而皇之的蒙混過關(guān)。

三，CR活動(dòng)過于集中，一次CR的代碼量太大。在有限的幾個(gè)小時(shí)內(nèi)，面對(duì)上千行，甚至更多的代碼時(shí)，再有耐心的人也難免產(chǎn)生視覺疲勞。

四，準(zhǔn)備不足，對(duì)于要CR的代碼缺少必要的審查規(guī)范和標(biāo)準(zhǔn)。在代碼審查過程中，我們往往只有代碼編寫規(guī)范，但是代碼的設(shè)計(jì)規(guī)范、業(yè)務(wù)的邏輯規(guī)范和標(biāo)準(zhǔn)等準(zhǔn)備不足。那么，我們應(yīng)該怎樣做，才能使CR工作保質(zhì)而且高效呢？一個(gè)標(biāo)準(zhǔn)的CR活動(dòng)應(yīng)該分為三個(gè)階段：

一，事前準(zhǔn)備階段。在一次CR前，以下對(duì)以下內(nèi)容進(jìn)行充分準(zhǔn)備。

1．CR的對(duì)象。在準(zhǔn)備CR代碼對(duì)象時(shí)，我們要注意代碼的數(shù)量，如果代碼量比較大，要對(duì)代碼進(jìn)行必要的分解，確定其中的關(guān)鍵代碼，對(duì)關(guān)鍵代碼進(jìn)行CR，可以達(dá)到舉一反三的目的。

2．CR內(nèi)容。我們對(duì)代碼的審查內(nèi)容很多，如代碼的編寫是否規(guī)范（注釋的書寫格式、命名規(guī)范等）、技術(shù)處理規(guī)范（異常處理、日志處理、代碼組織結(jié)構(gòu)等）、業(yè)務(wù)實(shí)現(xiàn)等。我們不能希望通過一次CR活動(dòng)，完成所有這些內(nèi)容的審查，因此我們必須設(shè)定本次CR活動(dòng)內(nèi)容界限，確定審查重點(diǎn)；

3．評(píng)審規(guī)范和標(biāo)準(zhǔn)。在CR前設(shè)計(jì)確定評(píng)審規(guī)范和標(biāo)準(zhǔn)是必要，通過規(guī)范和標(biāo)準(zhǔn)我們?cè)趯彶檫^程中可以有據(jù)可依，有理可循，而且還可以做到標(biāo)準(zhǔn)統(tǒng)一。

4．選擇CR活動(dòng)的參與者。在CR開始前，必須把本次CR活動(dòng)的對(duì)象、審查內(nèi)容以及審查的規(guī)范和標(biāo)準(zhǔn)通報(bào)給所有的參與者。

5．選擇CR活動(dòng)的實(shí)施方式。CR活動(dòng)有很多形式可供我們選擇，我們可以根據(jù)實(shí)際情況選擇桌面式CR、演示講解式CR、一對(duì)一的座位CR等等。

二，實(shí)施階段。充分的事前準(zhǔn)備，只是做好CR活動(dòng)的前提，在CR實(shí)施過程中，我們要做好以下工作。

1．準(zhǔn)確記錄。對(duì)于CR過程發(fā)現(xiàn)的問題，我們必須清晰準(zhǔn)確的記錄，可以使用問題點(diǎn)

記錄單，明確記錄的項(xiàng)目和內(nèi)容。

2．CR過程中，要采用代碼作者講解和審查者提問方式。審查者不能只在發(fā)現(xiàn)問題時(shí)提問，同時(shí)也要根據(jù)本次審查的內(nèi)容要求代碼作者對(duì)某個(gè)特定問題的講解。

3．對(duì)事前確定的審查內(nèi)容，要逐項(xiàng)審查，不能因?yàn)闀r(shí)間不足等因素一掃而過。

4．實(shí)施審查時(shí)，要營(yíng)造一個(gè)討論問題、解決問題的氛圍，不能把審查會(huì)搞成批判會(huì)，這樣會(huì)影響相關(guān)人員的積極性。

三，事后跟蹤跟蹤。CR結(jié)束后，對(duì)發(fā)現(xiàn)的問題，首先需要確定以下內(nèi)容。

1．問題點(diǎn)的難易程度以及影響的范圍；

2．解決問題的責(zé)任者和問題點(diǎn)修正結(jié)果的確認(rèn)者；

3．解決問題點(diǎn)的時(shí)限。

其次是對(duì)于修正問題責(zé)任者，在問題點(diǎn)的修正過程中，要三方面內(nèi)容的記錄。

1．問題點(diǎn)的原因；

2．解決問題點(diǎn)的對(duì)策；

3．修正的內(nèi)容。

做為修正結(jié)果的確認(rèn)者，必須按照事前約定的時(shí)限及時(shí)的對(duì)修正結(jié)果進(jìn)行全面的確認(rèn)。工作流管理系統(tǒng)是“一種在工作流形式化表示的驅(qū)動(dòng)下，通過軟件的執(zhí)行而完成工作流定義、管理及執(zhí)行的系統(tǒng)”，其主要目標(biāo)是對(duì)業(yè)務(wù)過程中各活動(dòng)發(fā)生的先后次序及同活動(dòng)相關(guān)的相應(yīng)人力或信息資源的調(diào)用，進(jìn)行管理而實(shí)現(xiàn)業(yè)務(wù)過程的自動(dòng)化。

在企業(yè)的日常工作中，絕大多數(shù)屬于流程類工作，比如業(yè)務(wù)的分級(jí)審批工作、各類申請(qǐng)表單、公文簽審、業(yè)務(wù)處理等。通過現(xiàn)代的技術(shù)手段將企業(yè)內(nèi)諸多繁瑣復(fù)雜的業(yè)務(wù)流程自動(dòng)化，并對(duì)其進(jìn)行有效地管理便是工作流需要解決的問題。

傳統(tǒng)的系統(tǒng)設(shè)計(jì)方式將業(yè)務(wù)流程以編碼的方式固化在應(yīng)用系統(tǒng)中，在業(yè)務(wù)流程和組織結(jié)構(gòu)發(fā)生改變的情況下，需要將系統(tǒng)進(jìn)行重大修改，甚至重新設(shè)計(jì)。實(shí)際上，業(yè)務(wù)流程的改變是導(dǎo)致許多應(yīng)用系統(tǒng)失敗的最主要的原因。

工作流管理系統(tǒng)的出現(xiàn)使得上述情況發(fā)生了改變。應(yīng)用系統(tǒng)的開發(fā)人員通過可視化的方式分析和設(shè)計(jì)業(yè)務(wù)流程，并將各個(gè)應(yīng)用模塊聯(lián)接在一起。在組織結(jié)構(gòu)和業(yè)務(wù)流程發(fā)生變化的時(shí)候，能夠在很少修改甚至不修改原來(lái)應(yīng)用的情況下，僅僅通過適當(dāng)調(diào)整或重新定義工作流程就能適應(yīng)變化了的情況。

采用工作流管理系統(tǒng)有以下優(yōu)點(diǎn)：

提高系統(tǒng)的柔性，適應(yīng)業(yè)務(wù)流程的變化，建設(shè)各類信息系統(tǒng)的重要工作之一就是發(fā)現(xiàn)用戶的工作流程，進(jìn)行分析建模，并把它體現(xiàn)到信息系統(tǒng)的設(shè)計(jì)中。

企業(yè)都在隨著時(shí)間不斷地改革工作流程，使企業(yè)各部門能夠更好地發(fā)揮服務(wù)職能、提高工作效率。

-------------------------代碼審查（code review）是軟件開發(fā)過程的一個(gè)階段，在這個(gè)階段中，代碼創(chuàng)造者和審查人員，可能還有質(zhì)量保證（QA）測(cè)試人員，一起進(jìn)行代碼審查。能在該階段中就找出并更正存在的錯(cuò)誤，相對(duì)來(lái)說比較合理，因?yàn)槿绻陂_發(fā)軟件后面的階段或者軟件交付給用戶后才來(lái)處理、查找和修改程序缺陷的話，會(huì)花費(fèi)更多成本。

審查人員需要很仔細(xì)地檢查代碼，包括：

? 缺陷或者潛在缺陷

? 和整個(gè)程序設(shè)計(jì)的一致性

? 評(píng)論的質(zhì)量

? 遵守編碼標(biāo)準(zhǔn)代碼審查通常能很好地檢測(cè)出安全漏洞問題。有一些專門的應(yīng)用程序可以幫助進(jìn)行代碼審查。自動(dòng)代碼審查系統(tǒng)可以有效地系統(tǒng)化地檢測(cè)源代碼的潛在問題，如緩沖區(qū)溢出、競(jìng)態(tài)條件、內(nèi)存泄露、代碼塊大小問題和重復(fù)語(yǔ)句等。另外，代碼審查也常用于檢測(cè)補(bǔ)丁質(zhì)量。安全代碼審查的目的是要識(shí)別出會(huì)導(dǎo)致安全問題和事故的不安全編碼技術(shù)和漏洞。雖然可能很耗時(shí)，但代碼審查必須是項(xiàng)目開發(fā)周期中的常規(guī)事件，這是因?yàn)樵陂_發(fā)時(shí)修復(fù)安全缺陷會(huì)比以后在產(chǎn)品部署或維護(hù)修復(fù)周期中再做這項(xiàng)工作節(jié)省大量的成本和工作量。

代碼走讀與審查

目的主要檢查軟件代碼編寫質(zhì)量，是否與設(shè)計(jì)相符，與開發(fā)目的（需求）是否一致；是否符合編碼規(guī)范；有沒有存在明顯的缺陷；

與測(cè)試的不同是測(cè)試通過一系列的測(cè)試活動(dòng)(運(yùn)行程序?yàn)橹?來(lái)發(fā)現(xiàn)BUG，而代碼審查走讀則一方面通過瀏覽代碼，檢查語(yǔ)法結(jié)構(gòu)，調(diào)用關(guān)系，以規(guī)范度，注釋率，類化程度，耦合度，復(fù)用度等等指標(biāo)來(lái)衡量代碼的質(zhì)量，達(dá)到防范問題發(fā)生；另一方面檢查代碼與設(shè)計(jì)的偏差，問題是否得到正確解決。

代碼審查的階段

一般的代碼審查活動(dòng)通常發(fā)生在軟件完成時(shí)提交測(cè)試前，主要的目的是檢查軟件代碼結(jié)構(gòu)，評(píng)估軟件質(zhì)量，防止軟件出現(xiàn)重大缺陷，把質(zhì)量問題解決在測(cè)試之前。

近年來(lái)隨著軟件行業(yè)的發(fā)展，軟件開發(fā)設(shè)計(jì)和控制能力不斷提高，但軟件依然存在BUG，不停地發(fā)放補(bǔ)丁，問題依然存在。對(duì)軟件測(cè)試后的修改，也越來(lái)越謹(jǐn)慎，考慮得也越來(lái)越周全，因此，修改bug的代碼改動(dòng)也越來(lái)越重要，軟件行業(yè)開始對(duì)代碼修動(dòng)進(jìn)行了走讀和審查，目的是防止問題的再次發(fā)生并且防止修改引發(fā)新的問題。

第四篇：公司規(guī)章制度之程序員代碼管理制度

公司規(guī)章制度之程序員代碼管理制度

第一章

總則

為規(guī)范公司程序源代碼管理制度，保持良好的工作秩序和工作環(huán)境。根據(jù)《中華人民共和國(guó)勞動(dòng)法》的有關(guān)規(guī)定，結(jié)合無(wú)錫博達(dá)信息技術(shù)有限公司的實(shí)際狀況,特制定本規(guī)定。本規(guī)定適用于公司所有負(fù)責(zé)程序開發(fā)的員工。

第二章

程序源代碼管理

1、程序員需在每周五和程序有較大更改/更新時(shí)，將程序源代碼及說明書整理好交給程序保管員（QQ：***郵箱：***，優(yōu)先發(fā)送至QQ；聯(lián)系方式如有變更將另行通知）；

2、每個(gè)項(xiàng)目的源代碼中應(yīng)有完整詳細(xì)的說明書，寫清楚每一個(gè)程序包的名稱及用途等；程序有變化時(shí)需同時(shí)更新相關(guān)文檔，并注明相對(duì)上個(gè)版本的更改之處；

3、程序員有義務(wù)管理好各自所負(fù)責(zé)的工作項(xiàng)目的源代碼以及相關(guān)賬戶權(quán)限，如非代碼編寫的需要和總經(jīng)理同意，不得轉(zhuǎn)交給他人；

4、程序員在公司任職期間，因職務(wù)需要及為公司項(xiàng)目開發(fā)的程序源代碼，公司擁有所有權(quán)。

第五篇：技術(shù)總監(jiān)談好的程序員如何寫代碼

技術(shù)總監(jiān)談好的程序員如何寫代碼

2010-01-04 16:55 |

2846次閱讀 | 來(lái)源：風(fēng)輕揚(yáng)官方博客 【已有17條評(píng)論】發(fā)表評(píng)論

感謝carlkxiafhwfhw的提供 | 收藏這篇新聞

要判斷一個(gè)程序員是不是好的程序員，主要看他寫的代碼，因?yàn)槌绦騿T最重要的事是寫代碼。

即便不去理解代碼的意圖，只要看一眼，好的程序員寫的代碼與差的程序員寫的代碼基本上就可以看出來(lái)。好的程序員寫的代碼，整潔而規(guī)范，視覺上自然有一種美感。空白錯(cuò)落有致，注釋恰到好處，命名和排版遵守統(tǒng)一的規(guī)范。差的程序員寫的代碼則經(jīng)常出現(xiàn)過長(zhǎng)的函數(shù)，前后不一致的命名方式和排版，過深的嵌套結(jié)構(gòu)，非常復(fù)雜的表達(dá)式，隨處可見的數(shù)字等毛病。

再去粗粗閱讀，對(duì)好的程序員還是差的程序員就會(huì)更有把握。好的程序員寫的代碼，有一種精心雕琢而成的一致性。好的程序員一致會(huì)遵守統(tǒng)一的命名方式，如camelCase，而差的程序員的變量命名時(shí)不時(shí)的就會(huì)偏離統(tǒng)一規(guī)范。好的程序員的代碼中拼寫錯(cuò)誤幾乎不可見，而差的程序員的拼寫錯(cuò)誤要多得多。好的程序員對(duì)于同一類動(dòng)作，不會(huì)忽而用這個(gè)動(dòng)詞，忽而又用那個(gè)同義詞，如add/insert混用。好的程序員采用一致的簡(jiǎn)寫規(guī)則，差的程序員則時(shí)而不簡(jiǎn)寫，時(shí)而簡(jiǎn)寫。好的程序員會(huì)很注意名稱中形容詞與名詞誰(shuí)在前誰(shuí)在后，而差的程序員沒有規(guī)則，時(shí)而在前時(shí)而在后。好的程序員很少會(huì)寫出大段大段的重復(fù)代碼，差的程序員卻經(jīng)常搞不定重復(fù)代碼，他們難以將重復(fù)的代碼抽取出一個(gè)統(tǒng)一的概念進(jìn)行重用。好的程序員對(duì)于對(duì)外的API會(huì)注重注釋與代碼的一致性，差的程序員經(jīng)常注釋中的參數(shù)名稱與函數(shù)定義都不一致。好的程序員很少會(huì)留下被注釋掉的或用#if 0括起的垃圾代碼，他們意志堅(jiān)決，代碼有用就要，沒用就不要，差的程序員則不一樣，他們經(jīng)常不確信一段代碼是否真的需要，他們?nèi)狈Ρ３执a整潔的習(xí)慣，因此他們讓垃圾代碼留著。

如上，即便你不懂他所用的語(yǔ)言，不卻關(guān)心程序的邏輯，對(duì)好的程序員還是差的程序員就能做到八九不離十的判斷。程序的好壞幾乎總是取決于它們是否漂亮，不漂亮而好的程序，除了C++ STL源碼，我再也沒見過（如果你稍仔細(xì)看，STL的源碼雖然不夠漂亮，但仍然滿足這里提出的一致性原則）。而又好又漂亮的代碼則隨處可見，如Linux Kernel，InnoDB，JDK，JUnit等等。

如果再仔細(xì)閱讀，就能更準(zhǔn)確。好的程序員寫的代碼，好似渾然天成，簡(jiǎn)單而直白。函數(shù)通常較短小，函數(shù)的名稱準(zhǔn)確的反映函數(shù)要完成的工作。邏輯簡(jiǎn)單而自然，讓你讀的時(shí)候由衷的發(fā)出啊，就應(yīng)該是這樣的感嘆，而差的程序員的代碼經(jīng)常讓你發(fā)出怎么是這樣？這是再干什么呀？的疑問。好的程序員會(huì)在緊要關(guān)頭加以畫龍點(diǎn)睛般的注釋，差的程序員要么沒注釋，要么注釋只是代碼的重復(fù)，純粹是廢話，更差的是注釋是錯(cuò)的，是誤導(dǎo)。

好的程序員未必是語(yǔ)言律師，即那種非常清楚的了解語(yǔ)言的各個(gè)細(xì)節(jié)，在編程時(shí)到處使用的家伙。好的程序員也不常炫技，在代碼中精心構(gòu)造一些獨(dú)具匠心的片斷，他們偶而會(huì)，但大多數(shù)時(shí)候總是用直白的語(yǔ)言來(lái)表述。

從代碼也可以看出一個(gè)程序員的團(tuán)隊(duì)協(xié)作精神。注意團(tuán)隊(duì)合作的程序員，會(huì)嚴(yán)格按照?qǐng)F(tuán)隊(duì)規(guī)范寫代碼，而風(fēng)格與團(tuán)隊(duì)規(guī)范不一致的程序員則很可能欠缺團(tuán)隊(duì)精神。注意團(tuán)隊(duì)合作的程序員會(huì)注意給模塊的對(duì)外接口加以重要的說明，如前置條件、后置條件、參數(shù)能否是NULL等等，不注意團(tuán)隊(duì)合作的程序員懶于處理這些細(xì)節(jié)。

好的程序員與差的程序員的生產(chǎn)力差別巨大，項(xiàng)目的周期越長(zhǎng)，項(xiàng)目越復(fù)雜，項(xiàng)目對(duì)質(zhì)量的要求越高，好的程序員的價(jià)值就越大。好的程序員與差的程序員，管理成本也差別巨大，好的程序員只需要與他共同確定設(shè)計(jì)，代碼可以不看，差的程序員的代碼經(jīng)常需要經(jīng)過多次review，且仍有可能達(dá)不到理想的質(zhì)量。

要成為好的程序員，首先要樹立要成為好的程序員的志向，再勤加練習(xí)，天長(zhǎng)日久，就會(huì)越來(lái)越好，這些人不怕老。沒有志向永遠(yuǎn)成不了好的程序員，這些人若不在老去之前成為經(jīng)理就會(huì)變成廢人。

通過兩個(gè)小時(shí)的筆試和半個(gè)小時(shí)的面試對(duì)于判斷程序員來(lái)說是不夠的。通過筆試與面試，你可以判斷一個(gè)程序員是否具備算法與數(shù)據(jù)結(jié)構(gòu)等基礎(chǔ)知識(shí)，可以判斷他對(duì)編程語(yǔ)言的特性是否掌握，可以判斷他對(duì)技術(shù)是否關(guān)注，然而要知道他能否真的能很好的完成工作，不寫代碼是不夠的。

那些顯得對(duì)技術(shù)充滿熱情的，未必是好的程序員。這些人可能非常樂意從事有新意的工作，但后續(xù)的編碼、測(cè)試、調(diào)試、文案工作則可能讓他們感到厭煩。他們可能會(huì)提出好的創(chuàng)意，但卻經(jīng)常不能夠有始有終的將其完成。公司不需要多少這樣的人。

因此招聘的方式需要改善。招聘是最重要的，因?yàn)檫M(jìn)來(lái)后就難以出去，即便是試用。轉(zhuǎn)正條件白紙黑字寫的很清楚，只要合格就可以轉(zhuǎn)正，要達(dá)到合格并不是很困難。今年部門里進(jìn)了很多新人，并不是人人都很優(yōu)秀，但確實(shí)也都合格，自然也應(yīng)該轉(zhuǎn)正。

改善招聘的方法，就是讓他寫程序，可以出兩道題，一道讓他寫程序，一道讓他重構(gòu)一個(gè)已有的較長(zhǎng)的程序，一天之內(nèi)完成。假使可以考他半個(gè)月，那么重構(gòu)是不太需要的，但一天的時(shí)間太短，通過重構(gòu)可以考察閱讀并理解代碼，并通過重構(gòu)化腐朽為神奇的能力。那些不愿意寫別人的代碼，不愿意接受別人的代碼，經(jīng)常要重來(lái)一遍的人是不理想的。今年有兩個(gè)人采用了類似的方法。有一位簡(jiǎn)歷很優(yōu)秀的人，做了兩道編程題被拒了，有一位簡(jiǎn)歷及面試一般的人，通過編程測(cè)試，錄用了。我感覺比單純的筆試與面試要準(zhǔn)確。