在埋頭打碼的時候，總會雲遊天外思考點人生問題，回過神來吐槽自己：開發效率為何這麼低！
明明實現的業務邏輯並不是很複雜，**量也不會太多，為什麼專案的開發要那麼久？時間到底去哪了？
一次兩次的問題，或許我們不會在意。
但頻頻爆發的問題，這就值得我們深思了。
這不是個單因單果的問題，找出潛在的可能因素，才能給出針對性的優化方案。在這裡我以自身經歷描述。
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. 不在狀態
這沒什麼好說，別讓工作打亂自己的思考。
環境和時間會慢慢打磨乙個人，勿忘初心，方得始終。
大多時候，我們都發現了這些問題，卻不怎麼在意，或是沒能有效解決而放棄。
逃避解決不了問題。要麼快速解決，要麼阻止發生。
懶於改變現狀，或畏懼改變，可見的未來並不是我們真正想要，不試怎麼知道自己真的無可救藥。
select 為什麼效率低
索引知識延申 3.索引是建的越多越好嗎 增大網路開銷 有時會誤帶上如log iconmd5之類的無用且大文字字段，資料傳輸size會幾何增漲。如果db和應用程式不在同一臺機器，這種開銷非常明顯 即使 mysql 伺服器和客戶端是在同一臺機器上，使用的協議還是 tcp，通訊也是需要額外的時間。準確來說...
MTP效率這麼低，為什麼還被眾多手機採用？
比如檢視手機上的 資料夾，mtp要幾分鐘才顯示完畢所有檔案。傳大量小檔案的速度更是慘不忍睹。如果android手機的sdcard以mtp模式掛載到pc機上，sdcard的控制權其實還是屬於手機。只不過智慧型手機通過mtp協議向pc機構建了乙個虛擬檔案系統。pc機操作其中的檔案時，都會通過標準mtp協...
「暴力抗法」的成本為什麼這麼低？
暴力抗法 的成本為什麼這麼低？春節還沒有過去，就看到了一則令人心情沉重的訊息 福州台江區城市管理執法局執法人員遭到暴力抗法，兩名執法人員被人用刀捅成重傷。事件的起因是福州市多部門節後聯合出動，整治非法三輪車營運。一位車主林晨 化名 在自己的三輪車被收繳之後，突然手持電工刀對執法人員施暴。2月2日 東...