你加班太可能是由於你的代碼寫的爛

做爲一名程序員，我渴望我加入的應該要是一支「30%的時間在寫代碼，而70%的時間在喝着咖啡討論着如何將產品作好」的團隊。我以爲軟件工做應該成爲一項技術和藝術融合的高智力活動，咱們的項目經理應該是一個高度理解質量、範圍和進度客觀規律的明白人，「高效工做，快樂生活」才應該是咱們的座右銘。

 

可現實狀況倒是，團隊在一邊超負荷的作着需求，一邊改着沒完沒了的Bug。過點前夕，項目經理熬着通紅通紅的眼睛盯着咱們整晚整晚的加班，質量專員一遍一遍的催促質量數據還不夠，軟件工做已經無可挽回的淪落成了體力勞動，別說快樂生活，生活都沒了。

 

好吧，以上可能都對，項目經理和質量專員是一個不懂客觀規律而且毫無同情之心的大魔頭，讓咱們程序員們毫無尊嚴卑賤的活着。

 

只是，有句話憋了好久了：「醒醒吧，全部的這些，都是由於你的代碼寫的太爛，你製造了太多的Bug！」。你可能會抱怨這分明是需求變動太快，領導計劃太緊緻使的。嗯，聽着挺有道理，可是要知道需求變動自己就是軟件的客觀規律，而領導要求進度，呵呵，你也能夠認爲是客觀規律。

 

這不是一篇證實誰致使程序員加班太多的論證文，也不想給你們灌雞湯，讓你們一晚上之間都變成編程高手，可是至少說一些實實在在的經驗和方法。總之讓你們多看一點就多得到一點實際的價值。

 

01 不要一上來就開始寫代碼

你可能性子急，也可能早已按耐不住躍躍欲試昨天剛學會的一個編程小技巧，我想要告訴你的是，不急，收起你那磨刀霍霍的表情，在你拿到需求準備寫出你第一行代碼以前還有更重要的事情要作。我想怎麼強調這件事情的重要性都不爲過，在我之前寫的本身很是滿意的代碼經歷中，我都採用了這個方法，它能消滅原來可能會被測試提的90%的Bug單，甚至作到零缺陷，固然作到這點可能須要一個過程。

 

拿到需求以後你首先要問下本身對需求是否是已經充分理解了，獲得確定的回答以後，咱們就能夠開始了：

1）先在你忙碌的工做中，找出你能徹底掌控的一個小時時間段，這一個小時徹底屬於你本身，保證這一個小時不會有任何打擾，或者任何能影響到你執行不下去這個方法的打擾。要記住這一個小時很是重要，比你後面要執行的全部活動的時間都重要，它絕對值得。

2）在第一張白紙的上方寫下「該需求特性的正常流程和影響範圍」，而後在白紙下方逐條開始寫下該需求特性正常流程包含的內容，大概會使用到哪些庫函數，會提供出哪些接口，是否會影響版本升級，是否影響資源文件，是否影響原有的接口等等。

3）在第二張白紙上方寫下「該需求特性全部的異常場景和本人以往常常會犯的一些錯誤點」，而後在白紙下方一條一條的開始往下寫。

4）不斷重複第2）、3）步。

 

你可能會以爲這不就跟寫的需求澄清材料差很少嗎，我要告訴你的是這是兩回事，它不是一項質量專員要求你作的質量過程活動，這是你本身和本身之間的一次深層次對話，這不須要告訴任何人，不須要向其餘領域輸出任何交付物，這是對本身要寫出優秀代碼的一次自我驅動。

 

一開始你可能會以爲很難，寫幾條就寫不出來了，或者閃過「這玩意兒是否是真的有用」的念頭，不用着急，起身去窗戶邊呼吸一口新鮮空氣或者去打杯水喝，總之不要中斷，除非辦公室着火了不要去幹讓這件事繼續不下去的事情。當你慢慢往下寫到第20或者第30條答案的時候，你可能忽然會有一種「這麼隱晦的一個異常點都被我發現了，簡直太牛了！」的情感涌出，這個時候你會暗暗驚呼有點難以抑制本身的興奮，這說明你快要接近成功完成了，後面每寫出來的一條都會讓本身感動。記住，中間不要放棄，你堅持下去的決定會將這一個小時變成你整個需求實現當中最重要的一個小時。

 

02 忘掉後面還有該死的質量活動

 

全部編碼以外的質量活動，都是基於公司對於你寫代碼水平的不信任產生的。也就是說公司花了大量的錢招來質量專員、網元測試、解決方案測試這些人都是由於你沒把代碼寫好形成的浪費。

常見一些開發人員，剛來的時候對質量專員安排的質量活動很有微詞，「我之前公司作項目根本不須要作這些東西還不是同樣能把項目作完」，「這些質量活動，簡直就是對編碼時間的侵佔」。說這些都沒問題，可是你一邊說着這些一邊寫完代碼後Bug就烏泱烏泱上來，是否是有點不要臉？質量專員設計的這些活動，就是爲了避免讓你的爛代碼一瀉千里的衝到客戶面前設計的一個個檢查站，當你對於「寫出好代碼」什麼事都沒作，只想着取消這些質量活動的話，就只能理解爲耍流氓了。

 

那麼，作好質量活動就能「寫出好代碼」嗎? 答案是不能。質量活動只是質量專員的監管手段，它既不是目標甚至也不是方法，你寫代碼的目標不是要知足質量活動標準，而是要追求零缺陷，也不會由於你Wbit測試作的好就能寫出好代碼。你要作的一個是「不要一上來就開始寫代碼」,另一個就是掌握儘可能多的重構方法，重構思惟方式，掌握重構並不必定是要對原來代碼的重構，而是下筆以前就知道好代碼該怎麼寫。

 

我讓你們忘記質量活動，不是讓你們不聽質量專員的話，而是你們在寫代碼的時候要心中存有敬畏，代碼寫完以後全部的活動都是你形成的浪費，你要爲消除這些浪費而不遺餘力。

 

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

 

我以前聽一位同事講他上一家公司的一件聽來十分驚悚的故事，他原來公司的一位同事離職了，留下的是一堆十分複雜，看了會讓人神經錯亂的C++++代碼，他走了以後，發現整個項目組的人沒有一我的能接手得了他的模塊，項目經理不得不高價加請客吃飯的方式讓他過來給全項目組的人講兩天他的代碼。 這個傢伙大有「看吧，只有我才能搞定」的「衣錦還鄉」姿態。我好奇的是這個項目經理爲何沒有儘早的開除他，簡直就應該報警啊。

 

好的代碼是讓人看來賞心悅目的，任何能力不夠或者炫技成分的增長人的閱讀障礙的行爲都須要被改進，你能不能三兩句話就能說清楚你本身寫出來的代碼的脈絡，固然這一樣涉及到你要掌握儘可能多的重構方法和重構思惟方式。

 

另外還有一個自我評判的標準，就是你捫心自問一下，「你寫了這麼多代碼，你曾經爲之動心過嗎？」你是否寫完以後會忍不住的反覆閱讀本身寫完的代碼，並連連暗暗驚歎代碼之美？

做爲一名程序員，但願在你某天離開公司後回想起的若干個開心時刻中，有一個會是由於你面對本身剛剛出爐了一份讓本身心動的代碼的那份感動，而不要成爲上面提到的那個「離開後，公司才知道他有多麼重要」的傢伙。

 

04 如今開始，刻意練習

 

你是否發現本身長期維持着「剛恰好能完成story」的代碼水平，寫了好幾年代碼仍然會被測試人員追着屁股提單？種種疑惑是由於代碼能力的提升跟你寫了多少年代碼沒有直接關係，你須要作的是刻意練習。

 

好比把我前面提到的0一、0二、03中提到的方法反覆練習，或者把你本身琢磨出來的方法分解成一項項的環節，刻意的去練習，從測試那裏獲得反饋，而後不斷加以改進，慢慢你就會從一個成天被測試人員追着跑的人，變成發現本身很容易就能達到質量過程標準的人，再慢慢就會發現你寫出來的代碼測試人員愈來愈難發現問題，最後只要你狀態好點就能常常性的寫出零缺陷的代碼。

 

其實有些道理咱們貌似都知道，可是我以爲離真正懂得還差了兩步，第一就是你須要親身去經歷、踐行這些道理和方法，第二就是你要可以轉述並讓其餘人也可以明白。因此最好的學習方式就是親身經歷，而後寫下來分享給你們，這樣才能讓你真正懂得那些你原來認爲懂得了其實未必懂得的道理。

 

 

 

 

 

 

轉自：https://www.test404.com/post-1116.html