是什麼在影響我們的開發效率？

01-05

1、迭代去修改代碼時，發現好多代碼都改不動。面向過程的思維方式，一個方法只能被調用一次。完全沒有擴展性和重用性
2、有沒有相關的輸入輸出的方法，來搭建好架子，剩下的只是往下填充就可以了

影響開發效率的因素有很多，但本回答想抓住時間碎片化這一點，把它講透。如果因為此文，讓程序員讀者們有更多完整時間來享受編程的創造感，實是我幸。

為珍惜你的時間。在這次的回答中，你將讀到：

談談災難是什麼：如果時間碎片化地做開發軟體，到底有多影響效率？

談談時間開銷：開發時間怎麼就碎片化了？

解決之道：如何優化管理，讓時間聚沙成塔？

乾貨在哪：實踐策略在文中以?形式表示出。

+++以下正文

"為什麼討論時間的碎片化 ?

產生有效成果的智力活動，總是需要連續的時間來保證。許多忘我思考的典故都證明了這一點。軟體開發是一種智力活動，因此也遵循這一道理。打斷某人的工作，不論是智力工作還是體力工作，對工作的效率和產出總會產生負面影響。只不過與體力勞動不同，智力勞動受到這方面的負面影響要大得多。對一名建築工人，如果他連續工作的60分鐘被打斷成3個不連續的20分鐘，其產出與連續工作60分鐘相比，是基本一致的。而對一名軟體開發人員，3個不連續的20分鐘內的工作成果，恐怕只能相當連續的40分鐘的成果。有20分鐘的時間被丟失了。為什麼會這樣？誰偷走了他的時間？下文試圖給出解釋。

時間如何破碎？

仔細觀察我們每天的工作時間花費就不難發現，存在天然的時間斷點把我們本來連續的工作時間碎片化。午休、倒咖啡、去洗手間等等。除此之外，一些偶發的事件也能打斷我們的思緒，比如一個電話，一個郵件提醒，或一個 MSN 消息。我們不是古廟裡的僧侶，因此塵世中的干擾總是存在。但這些不是討論的內容。我想討論的，是在軟體開發管理中不合理的做法導致的時間碎片化。

我認為以下做法是? 不合理的（注意規避）。

- 一人多任務

- 過分強調面對面溝通

- 過多的全體會議

一人多任務

有些管理者喜歡讓開發人員同時在幾個任務上展開工作，而不是順序地完成它們。這樣做可能基於以下理解：

- 任務越早展開，越能儘早暴露問題，從而便於及時解決，降低管理上的風險。

- 開發任務緊，多任務安排可以增大開發人員的負荷，防止他們偷懶。

- 多個任務具有相同的優先順序，而且彼此之間沒有依賴關係，因而應該同時展開。

任務啟動的早，並不能消除問題，只是把問題提前了。從這個角度講，問題的總量並不會減少。既然這樣，過早地暴露出問題有什麼好處呢？在項目的可用資源（人力、時間）一定的情況下，我看不到這樣做的好處。如果項目資源可以增加，一人多任務的情況就不會出現，也就沒必要討論了。

通過多任務來提高開發人員的工作強度並防止他們偷懶的做法，我認為是幼稚的。管理者應努力和開發人員建立起信任關係，並通過其他方式激發他們的幹勁。當他們像負重的駱駝一樣被對待時，作為會說話的智能生物，開發人員知道如何把超額的重物放在原地，而令管理者覺得他們在負重前行一樣。

一人多任務的安排的問題在於，人不是多核系統。他只能採用交替工作的方式來「同時」展開多項任務。當他在不同任務間切換時，特定任務上的工作時間就不再連續了。就像單核CPU執行多任務一樣，這是讓開發人員的大腦應用 TDM 技術。不幸，人腦不是高效的 TDM 設備。

? 無論如何，一人多任務的安排都應該努力避免。如果僅僅因為優先順序相同，那這些任務可以隨機地順序安排。

*[TDM]: Time-division multiplexing，即時分多路復用。

過分強調面對面溝通

面對面溝通是敏捷開發實踐中強調的一個重點。許多管理者據此在整個組織內鼓勵面對面的交流。我不認為這是一個好的做法。敏捷開發隊伍是由自組織（self-organized）的小團隊構成。敏捷開發中面對面溝通是指自組織團隊內部的溝通。這種內部的溝通，被證明是高效的。但是，把這種方式推廣到自組織團隊的邊界之外，則是糟糕的做法。外部的溝通以受控的、相對正式的方式進行，是對自組織的團隊的保護，使之免受干擾。自組織團隊就像封裝良好的軟體組件。它應該是內聚的，外部只能通過定義良好的介面與之交互。

很多時候，面對面交流，僅僅是提高了交流發起者的效率而已。（甚至這一點也值得懷疑，因為經過仔細斟酌寫下的文字，通常要比現場發揮的言語表達的更清楚）。? 當你禮貌地找某人談話時，你已經禮貌地打碎了他的時間。你在損害他的效率。（以後這麼做前請斟酌）

說到這裡，請讀者不要誤解。我不是在鼓勵開發人員成為像患有自閉症一樣的程序怪人。我只是想強調，過多的當面交流會導致時間的碎片化，從而影響整個團隊的效率。有其他溝通方式（? 比如郵件），能把對他人的干擾降低。

過多的全體會議

喜歡召開全體會議的團隊領導者，? 在召開全體會議前請思考（思考下面的問題後再決策），會議內容是否是每個人都必須知道的？是否是必須口頭傳達給每個人的？如果是一場討論會，是否這些人都需要參與到討論中來？由於全體會議打斷了每個參與者的時間，時間碎片化效果擴展到了全體，因而影響更大。

時間碎片化的帶來了什麼後果？

時間碎片化有兩個主要後果，即有效工作時間的減少和發生缺陷的可能性增大。

有效工作時間的減少

軟體開發工作是劇烈的腦力活動。象引擎一樣，人的大腦在進入高速運轉前，需要一個預熱和啟動過程。讓我姑且稱這裡消耗的時間為「思維引導時間」（ Mind Bootstrap Time ， MBT ）。這一時間的長短，取決於你面對問題的複雜性（和昨晚的睡眠質量？）。比如，某人的談話如果被打斷後，他可能會問「我剛才講到哪裡了？」。要繼續之前的談話，他就需要重新思考交談的內容並從被打斷處開始。這裡花費的時間，就是 MBT 。對一段談話來講， MBT 可能只需幾秒鐘。對軟體開發活動，則可能需要好幾分鐘。

現在已經不再是一個文本編輯器解決所有問題的軟體開發時代了。比如對一個典型的 JEE 開發項目，我們應該很容易理解一個程序員早上寫下第一行代碼前所做的以下操作：

- 打開 Eclipse IDE 。在 Eclipse 歡迎界面下的滾動條努力向前的時候，

- 啟動開發用資料庫服務（比如 HSQLDB ）。在資料庫服務啟動日誌還在 DOS 窗口翻滾的時候，他

- 打開資料庫 GUI 客戶端。接著，

- 啟動 tomcat 。

- 在 Eclipse中打開昨天工作中的Java源文件，開始編寫今天的第一行代碼。

我把這一過程所花費的時間，稱作「環境準備時間」，即Environment Preparation Time（EPT）。如果連續的開發時間被打斷，開發人員可能需要重複這一過程。 EPT 會因開發環境的不同而長短不同，但這部分時間總是存在的。

讓我把 MBT 和 EPT 稱作斷點時間。斷點時間不是有效的工作時間，因為它們不能帶來直接的產出。這裡想強調的是，有效工作時間是必需的消耗，而斷點時間總是可以通過減少時間碎片來減少或避免的。如果時間連續性已經被打斷，斷點時間還能被消除嗎？我認為答案是否定的。

碎片化的時間，就像被田埂分割的土地。分割的越多，實際可種植面積就越少，不論田埂修的多狹窄。

*[MBT]: 思維引導時間，即 Mind Bootstrap Time。

*[EPT]: 環境準備時間，即Environment Preparation Time。

*[JEE]: Java Enterprise Edition 。 Java開發企業應用軟體的一套規範、工具、以及框架。

*[IDE]: Integrated Development Environment，即集成開發環境。

*[Eclipse]: 一款流行的 Java 集成開發工具。

*[tomcat]: 一款流行的java web（servlet）伺服器。

*[HSQLDB]: 一款Java開發的輕量的關係資料庫系統。

發生缺陷的可能性增大

打碎的玻璃杯子被重新粘合後可恢復完整並繼續使用。但粘合的痕迹讓它不再美觀。更重要的是，重新粘合可能引入缺陷：接縫處未對齊的話會產生縫隙；粘合材料和杯子本身材質的不同會使整個杯子的應力不均，從而使它比以前更容易炸裂。

通過重新進入狀態並找到上次離開時的工作點，開發人員可以接續之前被打斷的工作。但就象重新粘合的杯子一樣，這裡不僅有直接的有效工作時間損失，更有可能引入後續問題。「我剛才寫到哪一行了？」，重新回到代碼前的程序員可能會這樣問自己。通過回想，他找到了離開時正在完成的switch結構並繼續編寫下一個case子句。不幸的是，前一個case子句遺漏了本該有的break。一個bug就這樣產生了。修復此bug的時間可能是撰寫這部分代碼的數倍[1]。

這個引入bug的例子很容易應用到其他開發工作上，比如需求分析、系統設計、測試等。簡單講，時間的碎片化使得開發過程中發生缺陷的可能性增大。人腦雖然比電腦複雜的多，但在斷點管理方面，可比後者差很多。

結束語

時間碎片化是開發工作直接的危害之一。? 雖然很多時間斷點無法避免，但管理方式的改進能減輕這方面的危害。? 減少對開發人員的干擾，提高他們工作時間的連續性，是高效管理的必要手段之一。理解了這一點，把團隊拉到偏遠的酒店或關到一個單獨的房間進行所謂的「封閉式」開發，就顯得不是那麼必要了。

[1] 這即為「fall through」 bug。定位此bug所花費的時間，通常取決於其所處組件的邏輯複雜程度。

感謝本文原作者：
王錦全，男，本科學歷，1996年畢業於中南大學機電工程學院。王錦全長期從事軟的研發和管理工作，先後擔任過軟體工程師、系統架構師、CTO等職務。曾服務於多家公司，包括世界100強、國內大中型國有、私營軟體企業等，也有過自主創業的經歷。他目前是杭州一家中型軟體企業的技術總監，主要負責公司的管理制度優化、敏捷研發推廣以及大數據技術研發等工作。他是資深的 Java 和 Python 程序員，也是 Clojure(Lisp) 愛好者。讀書和思考是他的愛好。您在其 linkedin主頁（ John Wang | LinkedIn ）可了解他的更詳細經歷。
編輯自InfoQ公眾號：軟體開發如何規避時間碎片化的坑？

再來一打推薦閱讀：

程序員的生產力始於什麼？『需求』還是『工具』？

應對組織代碼可能遇到的所有情況，只需四大策略

需求設計。基本上到現在我就沒見到過合格的釐清疑問、細化細節的需求設計。很多人過來一個需求，就幾句話，這算什麼需求？
低效的溝通。有的人只會浪費時間寫很長的郵件，卻不拎起電話，或者當面來問。有的人不願意在晚上稍微花點時間在網上找一下大洋彼岸的同事，寧可寫郵件。一件事情可以反覆來回好幾天，而本來可以只花十多分鐘。
不切實際的項目進度安排。我發現很多項目經理只會強調早就失去意義的截止日期。我們搞工程，如果做出來的是個垃圾產品，死守預設日期有什麼意義？
過多的會議。很多會，是和工程項目無關的。往往在大公司這種情況比較常見，因為個人往往會被攤上很多亂七八糟的事情，越往上越多。
垃圾網路。國情，不解釋。
豬隊友。很多問題，歸根結底都是人。比如：

對技術缺乏「工匠精神」，能完成任務就好，從來不考慮其它方面、是否能進一步改進等等。
對新技術缺乏敏感度，甚至抵觸。
缺乏團隊精神，喜歡強調自己的職責範圍，不在他所認為的範圍內的事情，就不管不問。
缺乏謙虛，自以為是，沒有相互學習的精神。很多討論，變成站隊、甚至面子問題。

只談程序員自身因素，06年寫過的一段，供參考

熟練人員經過多年的積累加上自己的CodeSnip的總結，基本不用額外再查找資料。而一般的開發人員在開發過程中會花掉10-20%時間去查找資料。

熟練人員注意代碼復用，並且時刻注意重構和抽取公用代碼。一般開發人員是代碼拷來拷去完成功能。

熟練人員非常注意查找，定位，標籤等各種快捷鍵的使用，定位查找方便快捷，IDE環境也根據習慣定義到最方便狀態。

熟練人員編碼前先思考清楚整個流程，在頭腦或紙張上規劃好整個實現方式和方法函數的劃分。一般人員想到哪裡寫到哪裡。

熟練人員寫了50行以上或更多代碼才Debug一兩次，一般人員寫了幾行代碼就要Debug多次，完全通過Debug來驗證代碼正確性。

熟練人員注重代碼的質量，單元測試和可維護性，注重各種業務邏輯的驗證和邊界條件的校驗。一般人員只注重簡單功能的簡單完成。

熟練人員提交測試的代碼BUG很少，返工工作量很小。一般開發人員由於自測不完善BUG較多，造成大量的返工工作量。

熟練人員合理分配自己的時間，規劃好每天工作任務，開發過程各位專註。一般開發人員一心多用，邊開發邊聊Q。

熟練人員善於知識的總結和積累，形成自我的知識庫和經驗庫。

熟練人員善於發現問題，分析不足而自我持續改進。一般人員在外力干預俠被動改進。

熟練開發人員開發重點已經專業到對業務的深刻理解，一般開發人員考慮的是開發上編程的語言和工具。

熟練人員善於從各種影響自己開發效率的因素中擠時間，善於使用各種輔助開發工具。而一般人員則不善於這種總結。

沒看懂各位的回答，是否問題被改過？

就問題中的描述而言，代碼該重構了。

--------------------

一開始不要考慮太多將來如何擴展的事情。等擴展的要求真的來了，再改寫，也就是重構。考慮太多擴展的可能性也是降低開發效率的罪魁禍首之一。

需求

被中斷打擾！

領導叫開會是硬中斷；

測試求支持是軟中斷；

自己設計方案，碼代碼是進程上下文；

當正常的流程總是被中斷打擾時，開發效率成指數下降。

所以我常常寧願把碼代碼的工作拿回家做，只圖個清靜！

公司網路許可權全開，並且沒有記錄員工上網行為。

以我實際工作中所遇到的談一下是什麼影響到開發效率。

人員的問題

某些人守著自己的一畝三分田，不在乎配合和方便其他人。

用人的問題

放任一些年輕單身的和不願盡家庭義務的員工肆意加班，不重視效率高的員工。

組織的問題

所謂扁平化架構，出主意定具體方案的沒權，難以推行，出問題沒人負責，有權的不了解細節。

排期的問題

進度制定很空洞，權責失衡，搞得某些組天天加班沖里程碑的同時，還要求著別的組抓緊配合。並且，過緊的進度導致質量低下。

溝通的問題

偏向口頭溝通，同時人員的表達和接受能力低下。事情扯不清，結論只有溝通的雙方知曉，無法回溯。打斷工作，時間碎片化。

激勵的問題

讓人發現加班可以賺獎金。

我個人覺得，這些問題的主要原因是組織架構的問題。好的組織架構是合理的架構把合適的人放在合適的位置並給予合適的報酬。

另外，效率低下的另一個原因是工作內容的多變。涉及兩方面，一個是業務需求的變化多端，一個是人員太年輕不知道什麼是最佳實踐。可能非互聯網行業會好一點。

流程沒整好。

技術問題都是小事，你願意的話重寫一遍就好了。影響開發效率的都是一些瑣碎的小事，非要我在進入狀態的時候來打斷我。

很不喜歡自己在做事的時候被人打擾，思路斷了很討厭。希望可以設個時間段，除了該時間段請勿打擾。

剛畫好設計圖，準備擼起袖子好好寫一大段代碼的時候，被通知去開會。。。開會。。。

有些低效率是必須的，這點可能很多人沒有意識到。

比如一些界面上的設計等等。就要開會，就要變化，不停的變。沒有它法。水至清則無魚。一定的低效率才能夠保證其他時候的高效率。

這個問題每個人每個團隊的答案其實都是不一樣的，所以，想嘗試著先來說說在什麼情境下開發效率會最高，再來分析一下什麼影響開發效率，最後再列一些自己的經驗。

1、開發人員清楚的知道自己要做什麼

這就是軟體工程的「需求」問題。這也就是為什麼幾乎所有研發人員都會抱怨需求不清楚，需求變更過於頻繁的原因。對於大部分開發工程師（高精尖科技除外）來說，如果能知道自己到底要做什麼，誇張點兒說，剩下來的工作其實就是COPY/PASTE（反對的人不用著急，請直接看後面幾點），工程師的區別真的就只有經驗多寡，用心是80%和60%的區別而已。

2、開發團隊對團隊之間的協作充分了解

這是軟體工程的「設計」問題，也叫「架構」問題。任何設計都可以抽象為3個問題：

系統是由那些組件構成？

組件之間的介面有哪些？介面之間的數據是什麼樣子的？

介面之間的交互關係是什麼樣子的？

以上三個問題由於系統的複雜程度，使用的語言或者開發模式不同，「組件」可以用子系統、模塊、構件、序列、函數、調用等等表示。

把設計無限細分到每一個開發人員都清楚的知道自己的任務（請記得第一點，他還記得需求），嗯，剩下來的工作真的就是COPY/PASTE了。

3、開發人員清楚的知道自己要用什麼技術和方法

這才是軟體工程的「編碼」問題，嗯，也是現在流行說是開發問題，這才是很多開發工程師理解的工作，我要說這是碼農哦不對是程序員的的工作，肯定有人不愛聽。

但這真的才是體現研發人員本身的能力的地方。

將以上三點結合起來，理想的開發效率是這樣的：每一個人都知道自己要做什麼，也知道彼此之間如何協作，於是，他們回到自己的電腦前面，鍵指如飛，讓觀眾目眩神迷，不知道時間過了多久，忽然間，只見程序員主角啪敲了一下回車，往椅背上一靠：走你！觀眾心裡想要的完美的呈現在他的面前。

哇，多麼完美。

現實是：

1，需求不清楚，需求變更頻繁

越是簡單的系統，需求就越模糊。這種模糊一種是需求提出者自己也不清楚，但更多的是因為簡單，需求提出者自己意識不到需求的重要性。

你給我做個杯子，什麼樣的杯子？這你都不知道，喏，就是張三手上那種，但是給我加個蓋子，隨便加一個就行，主要是遮灰。

什麼？這是我要的杯子嗎?我講得那麼清楚了，你還給我做成這樣子，隨便加個杯子蓋啊，你就給我加成這種醜樣，你自己到底有沒有腦子啊？（看到第三條的同學，麻煩一定要回頭看看第三條）

嗯，不錯，你小子還是有點兒水平的嘛。最近流行那叫什麼遊戲來著，把他們那個什麼xx加在蓋子上，就明天能給我了吧。

什麼？加上xx是這個樣子的，不行不行，算了，還是原來那個吧。

嗯，不錯，你小子還是有點兒料的。

.....

哎呀，燙啊！什麼，原來張三的杯子外面還有也給隔熱套.....

======================好像有點兒啰嗦了==

總之啊，越是簡單的需求，越能折騰死人。對於開發工程師來說，做第一個杯子時還興緻勃勃，做第n個杯子的時候，再厲害的架構，再厲害的程序員也會吐的。

不相信。麻煩你盯著自己的名字看個一分鐘，看看那還是不是你自己。

最後啰嗦一句。軟體開發的需求問題，就是所有工作的「目標」問題。目標搞不清楚，南轅北轍可不是一個笑話。

2，設計不合理與編碼水平不高

我做軟體研發管理這麼多年，50%的垃圾抱怨來源於開發者對需求的抱怨，另外50%就是對開發者的抱怨。

他們的架構要是設計得合理一點兒，能這點兒變化都應付不了嗎？

他們這代碼能再爛一點兒嗎，跟上次不就是那一點兒變化嗎，剩下來的代碼不能重用嗎？來自當年寫得代碼巴啦啦巴啦啦.....

2個人的團隊，1個人寫完了，另1個人的代碼還沒寫完，終於寫完了還編譯不過，終於編譯好了一跑一個bug，改完一個，冒出來更多。想想，如果是20個人的團隊，200個人的團隊......

3，管理問題

在需求、設計和編碼都完美的情況下是不需要管理者的，但現實不是，於是管理者被請進團隊，於是，開發效率就........更低......了。

其他同學的答案里也已經提到了：無效率的會議，跟著客戶跑的進度，總是被打斷的開發思路......

======================只知道抱怨的程序員不是好的需求工程師==

我這答案最想說的其實在這裡：

對軟體開發從業者來說，抱怨需求問題，毫無意義。需求在系統快要上線時還沒有100%清楚，干係人不了解需求，需求工程師說不清楚需求，產品經理說不清楚要求，需求變更等等，這是我們軟體開發的常態，也是我們軟體開發者的競爭力所在。在這個變化的世界裡，我們一定要充分認識到這一點。（別著急反駁，請問度娘敏捷原則第二條，也許是第三條？）

思想糾正了，行動上，業界已經有很多好的辦法（原型、迭代、Sprint、快速跟進、撒嬌耍賴），雖然不能包治百病，但會讓開發效率這件事情開始得更順利。

對軟體開發者來說，完美架構永遠值得努力，但不能作為唯一目標。我認識的優秀開發者，在努力修鍊完內功後發現自己還是做不好軟體之後，通常就2條路，第一條抱怨需求，第二條就是潛心研究架構，希望找到一個一勞永逸的解決所有需求的架構......我不是好的架構者，不敢胡亂說不行，只是，這麼些年還沒遇上那個完美的架構，讓我心力交瘁想說浪費時間浪費金錢而不敢而已。（也許我沒遇上更好的架構師？）

對於軟體開發者來說，不斷提升自己的技術能力是職責所在。做一天和尚撞一天鐘，對吧？就算需求不好，架構不好，寫好程序改變不了大局，但至少看著自己的代碼能輸出東西和輸出不了東西總有差別的吧？

======================軟體開發管理之提升開發效率==

那麼，對於軟體開發的管理者，又該如何協助軟體開發者提升開發效率呢？解決需求、設計與代碼問題是激勵因素：

1，用管理方法協助客戶釐清需求；

2，範圍變更要找合適的時機傳遞給團隊；（這似乎是我的核心競爭力，很多人沒法學會。）

3，找到好的架構師，做好的架構；

4，搭配好的團隊；

讓開發人員擁有良好的開發氛圍是保健因素：

11，要創造條件鼓勵研發人員對需求（目標）、架構、技術有疑問時及時得到幫助；

12，制定進度計劃時考慮好需求風險（需求永遠會變化）和架構風險（架構總是在完善）和技術風險（你的工程師總會犯錯）；

13，讓研發工程師自己的決定他可以決定的事情；

14，保持壓力；

說下當今互聯網或遊戲研發團隊遇到的效率低下問題把。

對於程序團隊的外部因素：

1、現在基本都是產品，程序，美術，測試，這四大部分人坐在一起開發了。並且工位設計沒有格擋了。全部開放式。但當團隊不太「專業」的時候，然後你就看到各種被打斷的情況。產品突然過來跟程序說改點什麼。美術過來跟程序說圖片需要什麼格式的。測試不確定是不是BUG的情況下，也過來問程序他發現了一個BUG，應該不應該提？程序最最討厭的就是打斷工作了。

2、而且有時候工作起勁的時候基本就靠「吼」來溝通了。直接坐工位上就開始喊了出來。導致工作環境特別惡劣。影響程序人員工作思路。

3、白天因為上述問題，再加開會。導致各種被打斷。然後效率低下。只能晚上趁沒人，加班加點的把白天的工作補回來了。

對於程序團隊的內部因素：

1、程序框架設計考量不夠。導致維護困難。編碼困難。當產品人員提出修改的時候更是困難。

2、開發周邊工具製作的易用性不夠好。比如代碼生成，數據轉換這些工具。給程序內部用的工具設計的有點unix哲學好不好。各種工具都可以跑個命令行有什麼困難的，悟性高點的就知道可以將一堆命令行重複性工作的工具整合一起，多方便。要不就走另一條路。完全GUI的情況設計的要多傻瓜有多傻瓜就好了。我覺得要是給產品，美術，用的工具這樣做最好。畢竟對於他們圖形化的易用性顯然比命令行友好的多。悟性在高點的，GUI的工具調用自己寫的命令行工具。隨意組合使用了。開發之前這些工具如果做的好一些。之後的日子用起來每次都節省一點時間。累加起來可就多了。

程序人員自身的因素：

1、理解需求要透徹。現在互聯網產品開發常講的敏捷的基本思想里也是有徹底理解需求這一條吧。順便提升下自己的產品設計能力。避免被產品新人「坑」。如果他提的需求不明確，連續幾個追問基本就能問出他設計的問題了。

2、不需要TDD的時候，自己寫完了多測測也是好的。都搞定了再交給測試團隊。避免反覆。

3、在遇到BUG之後，別嘗試什麼「撞大運」一類的編程思想。有時間的情況下一定要找到問題根源。避免反覆。（當然緊急線上情況處理可能先採取一些暴力辦法能最快速度解決線上問題最好）。

4、花點時間學習一些腳本語言。

5、花點時間將自己的開發環境弄的舒服一些。

既然知道面向過程有問題，那就先用類來模仿現實事物，儘可能做得標準化一點。

產品沒有定位和方向，開發人員只能陪著產品經理找感覺，再加上boss和各種老大的影響，很難有個明確的需求。導致開發人員疲於奔命，精力和熱情一點點消耗掉。

缺少統一的規範和整體的設計。最終代碼質量下降，誰也懶得看，更別說重構了，後續開發和維護成本越來越高。

為啥沒人說休息的時候逛知乎呢？

我發現絕大部分回答這個問題答案的都是在上午9-11點。

莫非你們已經是午休時間了？

我發現主要原因有:

1 根本沒理解清楚需求，對於要做什麼不了解。

2 對使用的東西不熟。

3 容易分神。本人屬於好奇心重，加多動症患者，俗稱「」坐不住」，所以這條很嚴重。

4 最後一條，身體原因。比如沒有合理安排作息，導致精神狀態不好，難以集中精力！

睡不飽