所以，我的判斷標(biāo)準(zhǔn)，也很簡單。如果寄給我的代碼，沒有附帶測試用例，我就自己運(yùn)行他的程序，隨意的亂找，找到一個(gè)我認(rèn)為是bug的，那就是有bug了。如果寄給我的代碼，附帶了足夠的測試用例，我只要Run一次，看到綠條，這一關(guān)就算是過了?！芎唵伟伞?/div>
也許有人會(huì)說，那如果他的測試用例很簡單呢？豈不是不能說明什么問題？怎么不能說明問題呢？首先可以說明：這是一個(gè)會(huì)寫測試用例的程序員！其次，我會(huì)看看他的測試用例的代碼，大概覆蓋了多少的功能特性。當(dāng)然，這是更進(jìn)一步的能力判斷。但是至少，他的代碼已經(jīng)達(dá)成了他自己的設(shè)計(jì)了呀。
孟老師最近有點(diǎn)煩，
面試了一個(gè)剛畢業(yè)大學(xué)生，結(jié)果發(fā)現(xiàn)那家伙一問三不知。隨后的跟帖也是常見的感嘆：
“現(xiàn)在的大學(xué)生過于浮躁”
“真不明白本科都在學(xué)什么”
還有一位臺灣同胞說：“本來還以為只有在臺灣有這種情形，原來兩岸的情都相同?！?/div>
?
因此，打算寫這篇blog，介紹一下我是怎么招人的。其實(shí)，招人并不難。
?
1、寫招聘廣告
2、收簡歷，初步了解背景情況，然后讓加我的MSN
3、在MSN里，就問一個(gè)問題：以下幾種技術(shù)，你哪一種最熟悉，哪一種最不熟悉
4、你就用最不熟悉的那種技術(shù)，做一個(gè)demo給我，沒有時(shí)間限制，要求如下：
?。紫仁莇emo的質(zhì)量，一定不能有任何bug
－其次是代碼的質(zhì)量，要干凈，明白，好懂。
?。袆?chuàng)意
－在功能創(chuàng)意與時(shí)間進(jìn)度之間，自行平衡
5、拿到代碼之后，先看看能不能正常運(yùn)行，看看有沒有bug。
6、在Google里搜索代碼的關(guān)鍵段落，看看有沒有抄襲，或者了解一下借鑒的程度
7、看他的代碼，是不是足夠干凈，足夠合理，足夠樸素
8、如果一個(gè)人能夠在很短的時(shí)間里，自行快速學(xué)習(xí)一種新的技術(shù)，并交出足夠質(zhì)量的代碼。這樣的員工，我就準(zhǔn)備要了。至于面試，無非是談?wù)劰べY的高低意向罷了。
?
這樣的招人辦法，要點(diǎn)在于：
1、我不關(guān)心他的學(xué)歷，工作經(jīng)驗(yàn)，年齡和技術(shù)背景，因?yàn)檎械揭粋€(gè)出色的員工，他會(huì)持續(xù)的自我學(xué)習(xí)，不斷的進(jìn)步。
2、有bug的一律不要
3、代碼最能夠說明問題，其他一切判斷都要在我看過他的代碼之后。一個(gè)人，不要玩弄聰明，不要炫耀技巧，寫老老實(shí)實(shí)，干干凈凈的代碼，合理的貼切的變量命名、方法命名、類命名，合理而不多不少的類間關(guān)系。這樣的代碼，就是漂亮的代碼。能寫出這樣的代碼的人，就有足夠好的思維和品性。
4、快速學(xué)習(xí)的能力要比過去的工作經(jīng)驗(yàn)更加重要，因?yàn)槟敲炊喙ぷ鹘?jīng)驗(yàn)，也要有助于完成今后的工作，才能體現(xiàn)出價(jià)值。
5、不抄襲，有創(chuàng)意，這樣的人才很難得。
6、有計(jì)劃的實(shí)現(xiàn)功能，能夠在功能和時(shí)間進(jìn)度之間合理決斷。這就是有大局觀的人才。
?
當(dāng)然，這樣招人的基礎(chǔ)是，你自己的代碼水平要夠高。很多公司根本就沒有這樣的水平，只能靠筆試來判斷人家的水平。
?
我工作過的公司，曾經(jīng)有一個(gè)小伙，他的代碼，縮進(jìn)不是靠Tab，而是“按下空格鍵，任代碼隨意后退”，他的代碼，彎彎曲曲，難看至極。前兩天，他跟我說“我筆試得了90多分，當(dāng)場拿到了4.5K的Offer?！笨梢姡P試是毫無意義的測試手段。
?
btw：還有問題，這樣招人效率不是很高，也比較累，緊急招人的情況不適用。當(dāng)然，緊急招人的項(xiàng)目，通常肯定是搞不好的。
posted @
2006-05-30 16:11 讀書、思考、生活 閱讀(29038) |
評論 (36) |
編輯 收藏 大多數(shù)程序員，都極度痛恨寫文檔。Coding是愉快的，而Write是痛苦的。有一部分原因，其實(shí)是要?dú)w咎于程序員自身，以我的經(jīng)驗(yàn)，很多程序員往往會(huì)“艱于表達(dá)”，尤其是用“文字、圖表、PPT、Word”之類的Office Document來表達(dá)。當(dāng)然，還有一部分原因，是由于很多項(xiàng)目開發(fā)實(shí)踐中，文檔的前后矛盾、形式主義、反復(fù)修改、歧義重重，常常讓程序員們抓狂。
?
UML是一個(gè)比較好的工具，但是，僅僅靠UML，是無法將項(xiàng)目的知識描述清楚的。也有不少項(xiàng)目組在引入了UML之后發(fā)現(xiàn)，文檔的工作量不但沒有減少，而是更多了。隨著項(xiàng)目的進(jìn)展，需要維護(hù)的設(shè)計(jì)文檔數(shù)量，也更多了。也因此造成了更多的前后矛盾，形式主義，反復(fù)修改。
?
根本的痛苦，并不在于一開始寫一份文檔，而在于所有寫下的文檔，都必須跟隨項(xiàng)目的進(jìn)展而隨之變化。當(dāng)我們寫出來的文檔越多，需要被持續(xù)維護(hù)的文檔也就越多，需要反復(fù)檢查文檔間的可能存在的矛盾也就越多，所有扔出去的石頭，最后都會(huì)落回到自己頭上。
?
于是，還有不少項(xiàng)目組，將文檔工作與代碼工作截然分開，文檔就寫一次，用來應(yīng)付上面的管理層，而代碼自管自的繼續(xù)開發(fā)。對于小型項(xiàng)目來說，這其實(shí)是一個(gè)不錯(cuò)的權(quán)宜之計(jì)。但是一旦項(xiàng)目越來越龐大、復(fù)雜。所有的隱性的知識，都僅僅存在于程序員的腦子里，所有成文的東西，都可能是錯(cuò)的，而真實(shí)的情況，卻隱藏在代碼之中。如果代碼質(zhì)量再糟糕一些，后來維護(hù)的朋友，就遭遇火坑了。
?
文檔，寫還是不寫，這是一個(gè)問題！
?
還記得測試驅(qū)動(dòng)開發(fā)嗎？為自己的每一個(gè)方法，每一個(gè)類，都寫出單元測試來。不但如此，更加徹底的做法是，在寫代碼之前，先寫測試用例。這樣才能保證不會(huì)忘記寫測試用例。更大的好處在于，這樣有助于思考、有助于獲得更加完善的設(shè)計(jì)，有助于寫出更加高質(zhì)量的代碼，有助于安全的重構(gòu)，有助于自動(dòng)化的持續(xù)集成實(shí)踐?？傊?，是好得不能再好的一項(xiàng)開發(fā)實(shí)踐。
?
這一實(shí)踐之所以可行，就在于他將繁雜的集中的測試工作，分解為日常的，必須不斷進(jìn)行的工作。當(dāng)你每天都在寫測試用例，當(dāng)你的每一個(gè)測試用例，都能夠與代碼完全對應(yīng)時(shí)，壓力反而減輕了，工作量也更少了，更重要的，一些優(yōu)良的習(xí)慣也因此被養(yǎng)成了。
?
在兩年前，我要開始一個(gè)全新的P2P網(wǎng)絡(luò)電視項(xiàng)目時(shí)，也在考慮關(guān)于文檔的問題。當(dāng)時(shí)我發(fā)現(xiàn)了Open Source的WikiPedia。這是一個(gè)PHP的WIKI，最大的應(yīng)用是維基百科全書。因此，這個(gè)項(xiàng)目的質(zhì)量就絕對值得信賴。我就將它拿過來，作為我們項(xiàng)目文檔管理的工具。
?
用Wiki來管理項(xiàng)目文檔，基于以下一些考慮：
文檔是項(xiàng)目的知識，這些知識必須集中管理、容易獲取、人人可以編輯。
項(xiàng)目在生長，代碼在增加，文檔也必須能夠跟隨項(xiàng)目自然生長，強(qiáng)行劃分設(shè)計(jì)階段和開發(fā)階段，是不可取的。
Wiki不是傳統(tǒng)的項(xiàng)目文檔，而是一個(gè)應(yīng)交流需要，可能隨時(shí)增刪改的知識庫。項(xiàng)目組的成員，遇到問題，就應(yīng)該首先查看Wiki，如果這是Wiki中沒有，那么他應(yīng)該找人詢問。而那個(gè)知道答案的人，如果他不想再今后不斷的回答同一問題，就應(yīng)該把這個(gè)答案寫入Wiki，這就是Wiki條目增長的自然動(dòng)力。
傳統(tǒng)文檔最大的問題在于浪費(fèi)，而Wiki通過持續(xù)修改，按需提供的方式，保證了所有寫下的文字，一定有超過一個(gè)人需要讀它。
?
在Wikipedia的基礎(chǔ)上，我又做了一些增強(qiáng)，以更好的輔助項(xiàng)目的管理。
Include功能，增加include標(biāo)簽，可以在一個(gè)條目中，引入其他條目的全文，而不是僅僅增加一個(gè)link。
文檔的層次結(jié)構(gòu)，當(dāng)項(xiàng)目的文檔條目逐漸增加，分門別類的條目，更加便于查找，也可以有效的避免條目重名的問題。
一個(gè)Click，就能夠創(chuàng)建新一個(gè)條目，用于填寫當(dāng)天的工作安排。
相應(yīng)的管理制度，也必須建立起來。
每日15分鐘文檔制度，基于“填寫當(dāng)日工作”的功能，我規(guī)定每個(gè)項(xiàng)目組成員，每天要花三個(gè)5分鐘來寫文檔，早上的5分鐘，填寫當(dāng)日工作計(jì)劃。中午的5分鐘填寫上午的工作情況，下班前的5分鐘，填寫下午的工作情況。這樣，每天的文檔工作相當(dāng)輕松，但是文檔能夠保證持續(xù)的跟隨項(xiàng)目成長下去。更進(jìn)一步的，這樣的制度，對于項(xiàng)目的進(jìn)度控制，也很有幫助。
User Case條目驅(qū)動(dòng)，所有分解出去的User Case，在分配到責(zé)任人之后，該責(zé)任人的第一項(xiàng)工作，就是在Wiki中寫下對于這個(gè)User Case的理解。隨后項(xiàng)目進(jìn)展，也應(yīng)該持續(xù)的維護(hù)這個(gè)條目。
同時(shí)進(jìn)行Bug的管理，Bug也作為Wiki中的條目，以便于和其他條目項(xiàng)目引用。
每次Check In CVS時(shí)，必須寫注釋。這是更加細(xì)節(jié)的文檔，然后我還做了一個(gè)小程序，能夠自動(dòng)的從CVSTrac中讀出當(dāng)天Check In代碼的注釋。供每個(gè)人在寫當(dāng)天文檔的時(shí)候引用。
總而言之，我對于項(xiàng)目文檔的看法，并不是非此即彼的極端主義者。在我看來，好的項(xiàng)目文檔管理政策，應(yīng)該有助于集中團(tuán)隊(duì)知識和智慧，同時(shí)不要讓程序員痛苦和反感。這樣才叫做有效的項(xiàng)目管理。仿造Martin Fowler的著名文獻(xiàn)《持續(xù)集成》，我給這篇Blog起這樣一個(gè)名字《軟件開發(fā)文檔的持續(xù)集成》，希望能夠引發(fā)更多的、更深入的思考。
posted @
2006-05-12 14:23 讀書、思考、生活 閱讀(28651) |
評論 (3) |
編輯 收藏