對(duì)于軟件工程師來(lái)說(shuō)，工作也許意味著許多東西 -- 穩(wěn)定的收入、做自己感興趣的項(xiàng)目、找一份更好工作的跳板，或者你只是喜歡與其他程序員共事。但說(shuō)到“效率”，強(qiáng)調(diào)的是在一定時(shí)間內(nèi)按質(zhì)完成項(xiàng)目的能力。Phil Chu根據(jù)自己的經(jīng)驗(yàn)提出了高效程序員應(yīng)該養(yǎng)成的七個(gè)習(xí)慣。
1.理解你的需求
成為一個(gè)有效率的程序員首先要知道如何正確的支配自己的時(shí)間。對(duì)時(shí)間最大的浪費(fèi)莫過(guò)于去做那些沒(méi)有用處或者永遠(yuǎn)不會(huì)上線的項(xiàng)目。而導(dǎo)致這種結(jié)果的根源往往是對(duì)需求理解的偏差。
要最大程度避免這種情況的發(fā)生，最好的辦法是快速建模，盡可能讓演示系統(tǒng)早點(diǎn)出來(lái)。對(duì)于客戶來(lái)說(shuō)，只有看得到摸得著的產(chǎn)品擺在面前，他們才會(huì)有興趣去試用觀察，才會(huì)在實(shí)際的操作中發(fā)現(xiàn)供需雙方在需求理解上的偏差。否則即使你寫(xiě)上幾百頁(yè)的需求分析文檔也只能是自己的一面之詞，客戶可沒(méi)耐心去檢查這些文檔寫(xiě)的是否準(zhǔn)確。
另一方面，你應(yīng)該讓每一個(gè)階段的開(kāi)發(fā)成果都能夠盡早的提交給客戶。讓他們以完全不考慮操作合理性和業(yè)務(wù)邏輯性的傻瓜級(jí)操作來(lái)發(fā)現(xiàn)程序員編程中的固有思維局限。尤其必須讓QA盡早的介入到項(xiàng)目開(kāi)發(fā)中來(lái)。如果能夠每天提交一份測(cè)試版本給QA自然是最理想的了，但大多數(shù)項(xiàng)目開(kāi)發(fā)做不到這樣的粒度，那么就爭(zhēng)取每周提交一份可測(cè)試版本。重要的是應(yīng)該讓QA和開(kāi)發(fā)能夠保持交錯(cuò)并行狀態(tài)。只有這樣，才能讓QA盡早發(fā)現(xiàn)bug，降低每個(gè)bug的修復(fù)成本，同時(shí)縮減獨(dú)立測(cè)試周期的跨度。
程序員往往不愿意把半成品代碼交付給測(cè)試人員，相反他們更喜歡在所有代碼都完工，達(dá)到自己滿意的程度之后再讓別人來(lái)測(cè)試。因?yàn)樵谶@之前的代碼往往存在很多程序員自己知道需要修改（或者故意留待后續(xù)補(bǔ)全）的流程缺失和Bug，測(cè)試人員并不知道哪些是真正的Bug，哪些只是臨時(shí)性的運(yùn)行錯(cuò)誤，每次都會(huì)一股腦兒作為Bug反饋給程序員。這往往讓程序員們心煩。同時(shí)測(cè)試人員有時(shí)候也不喜歡測(cè)試這種很多分支都走不通的中間版本。
但不管喜不喜歡，測(cè)試并發(fā)現(xiàn)問(wèn)題是測(cè)試人員的工作；程序員則應(yīng)該認(rèn)識(shí)到，Bug反饋得越早就越是件好事情。QA和開(kāi)發(fā)之間的關(guān)系往往很敵對(duì)，可實(shí)際上雙方的目標(biāo)是一致的。“忠言逆耳”古訓(xùn)有之，對(duì)于程序員來(lái)說(shuō)就應(yīng)該“有則改之，無(wú)則加勉”?？偤眠^(guò)項(xiàng)目完成之后才發(fā)現(xiàn)一堆的問(wèn)題，到那時(shí)候再要做修改，基本上都會(huì)牽一發(fā)而動(dòng)全身，痛苦的還是程序員自己。
?
2.保持真實(shí)性
盡可能讓你的系統(tǒng)運(yùn)行在最接近真實(shí)環(huán)境配置下面，使用有實(shí)際意義的數(shù)據(jù)和真實(shí)的編譯版本，并經(jīng)常性進(jìn)行模塊整合。如果你的測(cè)試環(huán)境使用的數(shù)據(jù)都是些胡亂添加的東西，那么將來(lái)和測(cè)試數(shù)據(jù)大相徑庭的真實(shí)數(shù)據(jù)這塊大冰山早晚會(huì)撞沉你的程序。另一方面如果你只在開(kāi)發(fā)環(huán)境來(lái)編譯運(yùn)行測(cè)試，會(huì)發(fā)現(xiàn)正式發(fā)布之后有各種各樣莫名其妙的問(wèn)題產(chǎn)生，到最后原來(lái)都是因?yàn)榄h(huán)境配置與開(kāi)發(fā)環(huán)境有些不起眼的差異所導(dǎo)致。把所有模塊整合進(jìn)行編譯聯(lián)調(diào)，看上去應(yīng)該是最后作的一項(xiàng)附加工作，但實(shí)際上這是一項(xiàng)需要在開(kāi)發(fā)過(guò)程中經(jīng)常性進(jìn)行的工作。只有這樣QA才能有最完整的東西拿來(lái)測(cè)試，得到更多的Bug反饋，同時(shí)降低模塊整合的難度。
3.理解你的代碼
書(shū)寫(xiě)規(guī)范的代碼，并保持代碼的整潔。Coding是一門藝術(shù)。正如寫(xiě)作一樣，同樣的文字在文豪的筆下就能夠熠熠生輝，讀起來(lái)賞心悅目；在普通人的筆下大概就只是詞能達(dá)意的效果了；在某些人的筆下或許就需要研究半天才能猜出個(gè)大概來(lái)。當(dāng)然不可能人人都成為藝術(shù)家，但至少你可以學(xué)會(huì)欣賞藝術(shù)、學(xué)習(xí)藝術(shù)。書(shū)寫(xiě)漂亮的代碼是對(duì)自己工作的尊重，也是對(duì)其他程序員的尊重。如果你的代碼中間充斥著大段過(guò)時(shí)的注釋、可讀性差的變量/函數(shù)，怎么去要求別人或者自己以后能夠理解它們？
4.最優(yōu)編程
把你的時(shí)間花在代碼的功能上, 而不是去把現(xiàn)有的代碼改得對(duì)自己胃口（尤其對(duì)于那些copy/paste過(guò)來(lái)的代碼）；要找到系統(tǒng)的瓶頸進(jìn)行優(yōu)化，而不是對(duì)那些無(wú)益于系統(tǒng)整體性提高的地方做無(wú)用功。
5.管理好你自己
也許有人會(huì)說(shuō)計(jì)劃和進(jìn)度控制是PM的事情，但一個(gè)好的程序員應(yīng)該比PM更了解自己目前工作的進(jìn)度。不論上頭給的進(jìn)度計(jì)劃是否合理，你都應(yīng)該有自己的原則和概念，清楚知道每天該做什么怎么去做。
6.持續(xù)教育
只有不斷的學(xué)習(xí)、實(shí)踐、犯錯(cuò)誤，你才會(huì)真正有所提高。在我看來(lái)，對(duì)于程序員來(lái)說(shuō)最好的老師不在學(xué)校，而在書(shū)本、網(wǎng)絡(luò)、社區(qū)。學(xué)會(huì)自我學(xué)習(xí)才能保持與時(shí)俱進(jìn)。
7. R-E-S-P-E-C-T
互相尊重是一切的基礎(chǔ)。