程序員不是在改bug，就是在找bug的路上。

我覺得軟件工作應(yīng)該成為一項(xiàng)技術(shù)和藝術(shù)融合的高智力活動(dòng)，我們的項(xiàng)目經(jīng)理應(yīng)該是一個(gè)高度理解質(zhì)量、范圍和進(jìn)度客觀規(guī)律的明白人，“高效工作，快樂生活”才應(yīng)該是我們的座右銘。

可現(xiàn)實(shí)情況卻是，團(tuán)隊(duì)在一邊超負(fù)荷的做著需求，一邊改著沒完沒了的Bug。過點(diǎn)前夕，項(xiàng)目經(jīng)理熬著通紅通紅的眼睛盯著我們整晚整晚的加班，質(zhì)量專員一遍一遍的催促質(zhì)量數(shù)據(jù)還不夠，軟件工作已經(jīng)無可挽回的淪落成了體力勞動(dòng)，別說快樂生活，生活都沒了。

好吧，以上可能都對(duì)，項(xiàng)目經(jīng)理和質(zhì)量專員是一個(gè)不懂客觀規(guī)律并且毫無同情之心的大魔頭，讓我們程序員們毫無尊嚴(yán)卑賤的活著。

只是，有句話憋了很久了：“醒醒吧，所有的這些，都是因?yàn)槟愕拇a寫的太爛，你制造了太多的Bug!”。你可能會(huì)抱怨這分明是需求變更太快，領(lǐng)導(dǎo)計(jì)劃太緊導(dǎo)致的。嗯，聽著挺有道理，但是要知道需求變更本身就是軟件的客觀規(guī)律，而領(lǐng)導(dǎo)要求進(jìn)度，呵呵，你也可以認(rèn)為是客觀規(guī)律。

這不是一篇證明誰導(dǎo)致程序員加班太多的論證文，也不想給大家灌雞湯，讓大家一夜之間都變成編程高手，但是至少說一些實(shí)實(shí)在在的經(jīng)驗(yàn)和方法。總之讓大家多看一點(diǎn)就多獲得一點(diǎn)實(shí)際的價(jià)值。

***

不要一上來就開始寫代碼

你可能性子急，也可能早已按耐不住躍躍欲試昨天剛學(xué)會(huì)的一個(gè)編程小技巧，我想要告訴你的是，不急，收起你那磨刀霍霍的表情，在你拿到需求準(zhǔn)備寫出你***行代碼之前還有更重要的事情要做。我想怎么強(qiáng)調(diào)這件事情的重要性都不為過，在我以前寫的自己非常滿意的代碼經(jīng)歷中，我都采用了這個(gè)方法，它能消滅原來可能會(huì)被測(cè)試提的90%的Bug單，甚至做到零缺陷，當(dāng)然做到這點(diǎn)可能需要一個(gè)過程。

拿到需求之后你首先要問下自己對(duì)需求是不是已經(jīng)充分理解了，得到肯定的回答之后，我們就可以開始了：

• 1)先在你忙碌的工作中，找出你能完全掌控的一個(gè)小時(shí)時(shí)間段，這一個(gè)小時(shí)完全屬于你自己，保證這一個(gè)小時(shí)不會(huì)有任何打擾，或者任何能影響到你執(zhí)行不下去這個(gè)方法的打擾。要記住這一個(gè)小時(shí)非常重要，比你后面要執(zhí)行的所有活動(dòng)的時(shí)間都重要，它絕對(duì)值得。
• 2)在***張白紙的上方寫下“該需求特性的正常流程和影響范圍”，然后在白紙下方逐條開始寫下該需求特性正常流程包含的內(nèi)容，大概會(huì)使用到哪些庫函數(shù)，會(huì)提供出哪些接口，是否會(huì)影響版本升級(jí)，是否影響資源文件，是否影響原有的接口等等。
• 3)在第二張白紙上方寫下“該需求特性所有的異常場景和本人以往經(jīng)常會(huì)犯的一些錯(cuò)誤點(diǎn)”，然后在白紙下方一條一條的開始往下寫。
• 4)不斷重復(fù)第2)、3)步。

你可能會(huì)覺得這不就跟寫的需求澄清材料差不多嗎，我要告訴你的是這是兩回事，它不是一項(xiàng)質(zhì)量專員要求你做的質(zhì)量過程活動(dòng)，這是你自己和自己之間的一次深層次對(duì)話，這不需要告訴任何人，不需要向其他領(lǐng)域輸出任何交付物，這是對(duì)自己要寫出優(yōu)秀代碼的一次自我驅(qū)動(dòng)。

一開始你可能會(huì)覺得很難，寫幾條就寫不出來了，或者閃過“這玩意兒是不是真的有用”的念頭，不用著急，起身去窗戶邊呼吸一口新鮮空氣或者去打杯水喝，總之不要中斷，除非辦公室著火了不要去干讓這件事繼續(xù)不下去的事情。

當(dāng)你慢慢往下寫到第20或者第30條答案的時(shí)候，你可能突然會(huì)有一種“這么隱晦的一個(gè)異常點(diǎn)都被我發(fā)現(xiàn)了，簡直太牛了!”的情感涌出，這個(gè)時(shí)候你會(huì)暗暗驚呼有點(diǎn)難以抑制自己的興奮，這說明你快要接近成功完成了，后面每寫出來的一條都會(huì)讓自己感動(dòng)。記住，中間不要放棄，你堅(jiān)持下去的決定會(huì)將這一個(gè)小時(shí)變成你整個(gè)需求實(shí)現(xiàn)當(dāng)中最重要的一個(gè)小時(shí)。

第二

忘掉后面還有該死的質(zhì)量活動(dòng)

所有編碼之外的質(zhì)量活動(dòng)，都是基于公司對(duì)于你寫代碼水平的不信任產(chǎn)生的。也就是說公司花了大量的錢招來質(zhì)量專員、網(wǎng)元測(cè)試、解決方案測(cè)試這些人都是因?yàn)槟銢]把代碼寫好造成的浪費(fèi)。

常見一些開發(fā)人員，剛來的時(shí)候?qū)|(zhì)量專員安排的質(zhì)量活動(dòng)頗有微詞，“我以前公司做項(xiàng)目根本不需要做這些東西還不是一樣能把項(xiàng)目做完”，“這些質(zhì)量活動(dòng)，簡直就是對(duì)編碼時(shí)間的侵占”。說這些都沒問題，但是你一邊說著這些一邊寫完代碼后Bug就烏泱烏泱上來，是不是有點(diǎn)不要臉?質(zhì)量專員設(shè)計(jì)的這些活動(dòng)，就是為了不讓你的爛代碼一瀉千里的沖到客戶面前設(shè)計(jì)的一個(gè)個(gè)檢查站，當(dāng)你對(duì)于“寫出好代碼”什么事都沒做，只想著取消這些質(zhì)量活動(dòng)的話，就只能理解為耍流氓了。

那么，做好質(zhì)量活動(dòng)就能“寫出好代碼”嗎? 答案是不能。質(zhì)量活動(dòng)只是質(zhì)量專員的監(jiān)管手段，它既不是目標(biāo)甚至也不是方法，你寫代碼的目標(biāo)不是要滿足質(zhì)量活動(dòng)標(biāo)準(zhǔn)，而是要追求零缺陷，也不會(huì)因?yàn)槟鉝bit測(cè)試做的好就能寫出好代碼。你要做的一個(gè)是“不要一上來就開始寫代碼”,另外一個(gè)就是掌握盡量多的重構(gòu)方法，重構(gòu)思維方式，掌握重構(gòu)并不一定是要對(duì)原來代碼的重構(gòu)，而是下筆之前就知道好代碼該怎么寫。

我讓大家忘記質(zhì)量活動(dòng)，不是讓大家不聽質(zhì)量專員的話，而是大家在寫代碼的時(shí)候要心中存有敬畏，代碼寫完之后所有的活動(dòng)都是你造成的浪費(fèi)，你要為消除這些浪費(fèi)而竭盡全力。

第三

記住，你寫的代碼是給人看的

我之前聽一位同事講他上一家公司的一件聽來十分驚悚的故事，他原來公司的一位同事離職了，留下的是一堆十分復(fù)雜，看了會(huì)讓人神經(jīng)錯(cuò)亂的C++代碼，他走了之后，發(fā)現(xiàn)整個(gè)項(xiàng)目組的人沒有一個(gè)人能接手得了他的模塊，項(xiàng)目經(jīng)理不得不高價(jià)加請(qǐng)客吃飯的方式讓他過來給全項(xiàng)目組的人講兩天他的代碼。 這個(gè)家伙大有“看吧，只有我才能搞定”的“衣錦還鄉(xiāng)”姿態(tài)。我好奇的是這個(gè)項(xiàng)目經(jīng)理為什么沒有盡早的開除他，簡直就應(yīng)該報(bào)警啊。

好的代碼是讓人看來賞心悅目的，任何能力不夠或者炫技成分的增加人的閱讀障礙的行為都需要被改進(jìn)，你能不能三兩句話就能說清楚你自己寫出來的代碼的脈絡(luò)，當(dāng)然這同樣涉及到你要掌握盡量多的重構(gòu)方法和重構(gòu)思維方式。

另外還有一個(gè)自我評(píng)判的標(biāo)準(zhǔn)，就是你捫心自問一下，“你寫了這么多代碼，你曾經(jīng)為之動(dòng)心過嗎?”你是否寫完之后會(huì)忍不住的反復(fù)閱讀自己寫完的代碼，并連連暗暗驚嘆代碼之美?

作為一名程序員，希望在你某天離開公司后回想起的若干個(gè)開心時(shí)刻中，有一個(gè)會(huì)是因?yàn)槟忝鎸?duì)自己剛剛出爐了一份讓自己心動(dòng)的代碼的那份感動(dòng)，而不要成為上面提到的那個(gè)“離開后，公司才知道他有多么重要”的家伙。

第四

現(xiàn)在開始，刻意練習(xí)

你是否發(fā)現(xiàn)自己長期維持著“剛剛好能完成story”的代碼水平，寫了好幾年代碼仍然會(huì)被測(cè)試人員追著屁股提單?種種疑惑是因?yàn)榇a能力的提高跟你寫了多少年代碼沒有直接關(guān)系，你需要做的是刻意練習(xí)。

比如把我前面提到的01、02、03中提到的方法反復(fù)練習(xí)，或者把你自己琢磨出來的方法分解成一項(xiàng)項(xiàng)的環(huán)節(jié)，刻意的去練習(xí)，從測(cè)試那里得到反饋，然后不斷加以改進(jìn)，慢慢你就會(huì)從一個(gè)整天被測(cè)試人員追著跑的人，變成發(fā)現(xiàn)自己很容易就能達(dá)到質(zhì)量過程標(biāo)準(zhǔn)的人，再慢慢就會(huì)發(fā)現(xiàn)你寫出來的代碼測(cè)試人員越來越難發(fā)現(xiàn)問題，***只要你狀態(tài)好點(diǎn)就能經(jīng)常性的寫出零缺陷的代碼。

其實(shí)有些道理我們貌似都知道，但是我覺得離真正懂得還差了兩步，***就是你需要親身去經(jīng)歷、踐行這些道理和方法，第二就是你要能夠轉(zhuǎn)述并讓其他人也能夠明白。所以***的學(xué)習(xí)方式就是親身經(jīng)歷，然后寫下來分享給大家，這樣才能讓你真正懂得那些你原來認(rèn)為懂得了其實(shí)未必懂得的道理。

作為曾看到一段話：作為一名程序員，我渴望我加入的應(yīng)該要是一支“30%的時(shí)間在寫代碼，而70%的時(shí)間在喝著咖啡討論著如何將產(chǎn)品做好”的團(tuán)隊(duì)。

這樣的憧憬估計(jì)每個(gè)程序員都會(huì)有吧?但是首先要考慮你自己作為一名程序員，有沒有做到上面文中提到的四點(diǎn)呢?