今年吃了不少的苦頭，但是自己的技術得到了質的飛躍，在這麼多次苦逼的加班當中，總結了自己的一些開發預估時間的問題，因為有些時候的加班時因為錯誤的評估才搞的自己很難堪的。

增刪改查

一個新的專案免不了增刪改查，本人最快的時候一天做了4個，但是一般的時候就是做2個，如果加上自己需要重新寫前端的話，一天一個足矣了，不能再加了，不然準備加班吧！

模組

如果開發的功能是一個模組，一般估計時間是2到3天，當然如果需求都不懂的，最好預估點時間來搞需求，也許是一個上午，但是必須估計到，不然加班吧！

瞭解需求

一般的需求就是一個上午，如果不是特別難的話，後來發現特殊情況再來交流，如果是自己一點都不知道的需求，必須給自己多留一點時間，一般留1天或者兩天，特別坑的就死皮賴臉了，不然需求不明白可千萬不要動手。

新技術

對於新技術，最容易的也得一個上午吧，如果有點難度的還需要研究的，最少要一個晚上，如果感覺有難度，給個兩天時間也足夠了，基本可以搞定一個demo，應用於專案當中

sql查詢資料量的評估

在做專案之前就要評估資料量，以大概知道需要用到哪些技術，這樣就可以很好的預估時間了，別把很多東西想的很理想化，可能有些環境都要自己搭建什麼的，很多都要自己寫的時候，時間就不夠了

調整好測試資源

在現有程式碼框架體系下面增加新功能或者新模組，很多時候並不是技術上的坑，而是業務上的坑，可能經歷過很多個產品經理了，所以裡面還有很多相容的寫法，所以唯一驗證自己的修改是否正常的方法除了驗證自己的功能要求實現了之外，還需要測試，讓測試人員從不同的角度來驗證，這樣才能儘量減少bug的發生
 

技術方案

一個稍微大一點的專案是要有技術方案的，把技術方案拿出來，然後大家一起討論一下，這樣可能在討論階段就可以減少很多的坑了，因為有些業務你可能真的考慮不到，必須通過交流才能明白的。

最後期限

任何一個事情都要有一個時間的評估，也就是最後期限，這也是需要努力提高的地方，本人之前做過這樣的評估，但是在中間過程leader總是會插入一些比這優先順序重要的工作，所以也只能先完成重要的工作了，手頭的不急的工作自然要往後排，提醒自己一句，得學會多程序工作。

結束語

希望大家來吐槽，希望和大家一起交流，共同進步.