爲何開發效率這麼低，時間都去哪了?

在埋頭打碼的時候，總會雲遊天外思考點人生問題，回過神來吐槽本身：開發效率爲什麼這麼低！

明明實現的業務邏輯並非很複雜，代碼量也不會太多，爲何項目的開發要那麼久？時間到底去哪了？

一次兩次的問題，或許咱們不會在乎。
但頻頻爆發的問題，這就值得咱們深思了。

這不是個單因單果的問題，找出潛在的可能因素，才能給出針對性的優化方案。在這裏我以自身經歷描述。

可能的因素

1. 自身能力問題
　　這是個使人悲傷的故事。
　　由於學習時間短，知識的積累不夠，致使在開發中實現能力跟不上邏輯思路。
　　好比開發過程邏輯思路沒毛病，但由於語法障礙不能直接實現，致使爲了實現該目的，而學習其餘知識、嘗試、作其餘處理，多出了工做量。
　　測試報錯定位問題。報錯或警告信息看不太懂或沒有任何報錯提示，不能快速定位問題，致使只能採用低效的暴力嘗試。

2. 技術沉澱與指導
　　某些緣故，公司去年纔有的前端，全公司對前端開發相對熟練的只有公司的CTO和1個工做2年的老員工。
　　公司的規矩：在技術上的問題不許交流和答疑，除非google都幫不了，才能尋求幫助。
　　沒有技術指導，基本只能靠自學。沒有前端技術沉澱，每次開發都是新的開始。

３. 需求不肯定
　　記得Boss給我第一個任務，需求只有3句話：
　　① 給一串json數據，你畫一個圖
　　② 待會讓你看看數據大概長什麼樣，圖大概長什麼樣
　　③ 須要多久能完成
　　這是原話，也是所有的需求。
　　場景未知，具體需求未知，用處未知。
　　僅有這些條件，又不得不先應承下來。
　　只能先設計一個可拓展的組件，起草一份demo來驗證需求。
　　這不是段子，也不是個例。

4. 需求變動
　　程序開發完成，先後端正在聯調。
　　然而此時設計師說忽然發現少考慮了件事，再加個功能……。

5. 設計變動
　　有些時候項目需求的小變動，咱們可以忍受。
　　只要程序寫的夠靈活，拓展性好，坐等對方改需求。
　　然而，讓人出乎意料的是，等來的不是需求變動，而是設計變動。
　　設計的改動通常是較大的變更，基本上是項目整個翻新。

6. 不明確責任
　　有時時間很緊，在沒有明文規定的責任，你們下意識偷懶，而後開始了扯皮大戰。
　　如先後端接口的接口文檔誰寫，測試數據誰造這種小問題。
　　由於沒人規定，以前是誰時間方便誰寫，如今你們都不方便，都不想在小問題浪費時間。
　　趕上脾氣倔的，耗上大半天都沒問題。

７. 概念誤解
　　先後端分離，各自完成好本身的模塊。
　　感受挺容易懂的一句話，不知爲什麼你們總有誤解，概念老是不統一。
　　我所認爲的＂作好本身的模塊＂： 程序開發完成 + 測試。
　　旁邊的前端同事認爲的＂作好＂： 程序開發完成。(無測試：工具不會用，不知怎麼模擬數據，怎麼模擬請求，算了等後臺)
　　旁邊的後臺同事認爲的＂作好＂： 程序開發完成。(無測試：哎，沒時間寫單元測試，接口太多了，直接功能測試吧)
　　而後先後端一聯調，各類報錯，先後端都有問題，從新改代碼。
　　做爲負責人，只能等着，隨時準備救場。

8. 聯調測試太慢
　　先後端克服了種種困難，代碼邏輯正常，自測經過，終於到先後端聯調。
　　然而迷之 bug 登場。
　　一樣的數據在後臺本地運行沒問題，由前端經過接口請求反而報錯！！！
　　嘗試N久，在請求的 url 中發現有個常量的數據大小寫搞錯了。接口文檔被踐踏。
　　接着，繼續痛苦前進，又碰上了迷之bug。
　　前端傳入JSON字符串化的數組在後臺被誤當成數組解析了。
　　懷疑是編碼問題，然而實際是先後端語言類型的差別，後臺的判斷邏輯不夠嚴謹致使。
　　方向錯了，作了無用功，致使白白浪費時間。
　　

9. 工具駕馭不了
　　善用工具能提升工做效率。然而駕馭不了工具就很坑了。
　　VSCode忽然內存泄漏，電腦卡頓（明明插件都禁用了，內存就從沒低過800M，我好懷念使用Sumblime Text的簡捷）。
　　RAP的網站忽然訪問不了，數據的模擬都在那，就這樣被一鍋端了。
　　git的版本控制，忽然發現代碼拉錯地方、代碼推錯地方、代碼被某個混蛋給改了。不知怎麼回退，好慌。
　　google搜索，英語渣看的好費力，信息量太多排查要很久。
　　第三方插件的引入居然被檢查出語法有錯（第三方插件自己沒問題），致使程序打包報錯。

10. 前人留下的坑
　　有次收到Boss的消息，XX有急事回家，但項目未完成，另外需求有變，項目後天交付，但願我過去幫忙。
　　當時我並不知道她的項目狀況，那晚大概瞭解下需求，次日接手代碼。
　　接手別人代碼是件痛苦的事，尤爲是碰上寫死的頁面和數據、混亂的結構、一堆無關的代碼以及有誤的處理邏輯。
　　事情的結果就是比我計劃時間多花了1倍才完成。

11. 不在狀態
　　開發過程常常遇到的問題， I'am not myself.
　　上個廁所，吃個飯回來，思路斷了。
　　碰上某某狀況，老闆請客，中午出去吃一頓。兩三個小時沒了。
　　沒休息好或碰上煩心事，頭腦不清晰，注意不集中，寫多少錯多少。

---

優化方案

1. 基礎能力問題
　　問題關鍵在於時間成本。由於能力不夠耗了時間，隨之學習時間少了，能力上升緩慢，造成惡性循環。
　　前期題海戰術（針對性解決問題），快速入門，以後再思考根源問題。

2. 技術資源問題
　　沒有槍，沒有炮，敵人給咱們……醒醒吧，本身造。
　　若是造不出，那……換坑吧。

3. 需求不明確
　　這是沒法控制的外因。
　　要麼主動儘量的問清楚，並留下記錄。
　　要麼速度快點，起草demo驗證需求。

4. 需求／設計變動
　　逃不過的外因，只能提早預防。
　　程序儘量寫靈活，保證能快速響應變動。
　　不要由於一時偷懶，坑了本身。

5. 分工問題
　　通常自個沒有決策權，找Boss說狀況定規矩，按制度走。
　　雖然可能吃點小虧，但也是爲了大局着想。

6. 概念誤解
　　謹慎確認。特別是有前科的人。
　　若是同事不是特別給力，建議仍是謹慎點，防止被坑，即便對方並非有意（人在江湖，身不禁己）。

7. 聯調測試問題
　　按規矩走，自測經過後，雙方交換測試數據，再自測一遍。排除數據格式出錯的可能。
　　遇到問題別慌，也別急着推卸責任。比起誰的鍋，Boss更關心項目的成果。

8. 工具問題
　　工具的駕馭程度，在前期幫助很大。
　　自個找時間上網找教程，或動手實踐。
　　不要由於畏懼改變，而放棄了好東西。

9. 前人的坑
　　沒法避免的坑。
　　交接時問清楚，留下聯繫方式，有問題一邊試一邊問。
　　另外，祈禱同事坑挖的小點吧。

10. 不在狀態
　　這沒什麼好說，別讓工做打亂本身的思考。
　　環境和時間會慢慢打磨一我的，勿忘初心，方得始終。

---

思考

　　大多時候，咱們都發現了這些問題，卻不怎麼在乎，或是沒能有效解決而放棄。
　　逃避解決不了問題。要麼快速解決，要麼阻止發生。
　　懶於改變現狀，或畏懼改變，可見的將來並非咱們真正想要，不試怎麼知道本身真的無可救藥。