坑1:做不明確的需求
在大多數公司，大多數的開發人員眼中的產品經理是不靠譜的，很少能將一個需求描述的清楚，不求天衣無縫，但連基本的業務邏輯都沒理清這就蛋疼了。
對於一句話需求，“做的跟XXX一樣”、“就按照XXX來”、“參照XXXApp的邏輯和界面交互”，往往令人開發人員藍瘦~
但是活還是得幹，畢竟項目週期在那擺着。做不明確的需求，會碰到哪些坑呢？做完了，產品一看，“咦，這不是我想要的啊！？”，如果時間還來得及可能就要改上一番了，如果時間來不及，可能就直接將需求放到下一期。
所以，做開發的一定要切記，千萬不要做不明確的需求，在做之前先跟產品溝通清楚，不然寧可撕逼也不要輕易的碼代碼，畢竟最後需求做錯了還是你改代碼~
坑2:產生這個BUG很簡單的錯覺
有時候一個BUG的產生，一方面是寫代碼的失誤，另外一方面就是產品業務邏輯上的自相矛盾導致的。
代碼上存在的BUG還好解決，但是一旦產品業務邏輯上產生了一個死結，就算代碼再怎麼改，BUG肯定還是有的，而且還很難解決，碰到這種問題，千萬別自己死腦筋非得把一個錯誤的問題答正確，而是去分析業務邏輯上的問題，如果有就讓產品去改，如果邏輯說得通，那麼再考慮代碼層面的問題。
坑3:提交一個自認爲沒問題的代碼到主分支
也許很多開發人員在將代碼提交到主分支時，都自測過一遍。這個習慣很好，但是自測沒問題不代表測試測的時候沒問題，如果在測試測試期間提出的BUG，特別是偶現的問題（一般都可以通過代碼造假異常數據復現）一定要記得在解決這種測試提交的BUG時，最好在本地切一個分支專門解決，然後將Fix Bug的分支包提交測試，如果沒有問題再合入到主幹分支。
最後如果臨近發包突然發現之前改的Bug還是有問題，那就蛋疼了。輕則臨時加班解決問題，重則代碼回滾(之前的Bug依舊)。一般這種最後才發現的Bug是最蛋疼的，時間緊不好解很容易出鍋。
小記
有時候覺得需求不明確，一樣可以開發（一邊開發一邊溝通）。有時候覺得項目管理和版本控制多此一舉。
只能說Too Young，Too Naive ~
項目流程看似複雜麻煩，但是爲了規避未知的問題，還是儘量在產品需求及開發的過程中重視這個流程。
很多軟件開發流程的制定，其目的一是爲了規避項目的問題，另外一方面就是爲了保護我們這些開發人員，免遭SX產品的蹂躪。
最後，搬磚不易，且搬且撕逼~
記一次CD的填坑之旅