作為一名程序員，我渴望我加入的應該要是一支“30%的時間在寫代碼，而70%的時間在喝著咖啡討論著如何將產(chǎn)品做好”的團隊。我覺得軟件工作應該成為一項技術和藝術融合的高智力活動，我們的項目經(jīng)理應該是一個高度理解質(zhì)量、范圍和進度客觀規(guī)律的明白人，“高效工作，快樂生活”才應該是我們的座右銘。
可現(xiàn)實情況卻是，團隊在一邊超負荷的做著需求，一邊改著沒完沒了的Bug。過點前夕，項目經(jīng)理熬著通紅通紅的眼睛盯著我們整晚整晚的加班，質(zhì)量專員一遍一遍的催促質(zhì)量數(shù)據(jù)還不夠，軟件工作已經(jīng)無可挽回的淪落成了體力勞動，別說快樂生活，生活都沒了。
好吧，以上可能都對，項目經(jīng)理和質(zhì)量專員是一個不懂客觀規(guī)律并且毫無同情之心的大魔頭，讓我們程序員們毫無尊嚴卑賤的活著。
只是，有句話憋了很久了：“醒醒吧，所有的這些，都是因為你的代碼寫的太爛，你制造了太多的Bug！”。你可能會抱怨這分明是需求變更太快，領導計劃太緊導致的。嗯，聽著挺有道理，但是要知道需求變更本身就是軟件的客觀規(guī)律，而領導要求進度，呵呵，你也可以認為是客觀規(guī)律。
這不是一篇證明誰導致程序員加班太多的論證文，也不想給大家灌雞湯，讓大家一夜之間都變成編程高手，但是至少說一些實實在在的經(jīng)驗和方法?？傊尨蠹叶嗫匆稽c就多獲得一點實際的價值。
01 不要一上來就開始寫代碼
你可能性子急，也可能早已按耐不住躍躍欲試昨天剛學會的一個編程小技巧，我想要告訴你的是，不急，收起你那磨刀霍霍的表情，在你拿到需求準備寫出你第一行代碼之前還有更重要的事情要做。我想怎么強調(diào)這件事情的重要性都不為過，在我以前寫的自己非常滿意的代碼經(jīng)歷中，我都采用了這個方法，它能消滅原來可能會被測試提的90%的Bug單，甚至做到零缺陷，當然做到這點可能需要一個過程。
