坑1:做不明确的需求
在大多数公司，大多数的开发人员眼中的产品经理是不靠谱的，很少能将一个需求描述的清楚，不求天衣无缝，但连基本的业务逻辑都没理清这就蛋疼了。
对于一句话需求，“做的跟XXX一样”、“就按照XXX来”、“参照XXXApp的逻辑和界面交互”，往往令人开发人员蓝瘦~
但是活还是得干，毕竟项目周期在那摆着。做不明确的需求，会碰到哪些坑呢？做完了，产品一看，“咦，这不是我想要的啊！？”，如果时间还来得及可能就要改上一番了，如果时间来不及，可能就直接将需求放到下一期。
所以，做开发的一定要切记，千万不要做不明确的需求，在做之前先跟产品沟通清楚，不然宁可撕逼也不要轻易的码代码，毕竟最后需求做错了还是你改代码~
坑2:产生这个BUG很简单的错觉
有时候一个BUG的产生，一方面是写代码的失误，另外一方面就是产品业务逻辑上的自相矛盾导致的。
代码上存在的BUG还好解决，但是一旦产品业务逻辑上产生了一个死结，就算代码再怎么改，BUG肯定还是有的，而且还很难解决，碰到这种问题，千万别自己死脑筋非得把一个错误的问题答正确，而是去分析业务逻辑上的问题，如果有就让产品去改，如果逻辑说得通，那么再考虑代码层面的问题。
坑3:提交一个自认为没问题的代码到主分支
也许很多开发人员在将代码提交到主分支时，都自测过一遍。这个习惯很好，但是自测没问题不代表测试测的时候没问题，如果在测试测试期间提出的BUG，特别是偶现的问题（一般都可以通过代码造假异常数据复现）一定要记得在解决这种测试提交的BUG时，最好在本地切一个分支专门解决，然后将Fix Bug的分支包提交测试，如果没有问题再合入到主干分支。
最后如果临近发包突然发现之前改的Bug还是有问题，那就蛋疼了。轻则临时加班解决问题，重则代码回滚(之前的Bug依旧)。一般这种最后才发现的Bug是最蛋疼的，时间紧不好解很容易出锅。
小记
有时候觉得需求不明确，一样可以开发（一边开发一边沟通）。有时候觉得项目管理和版本控制多此一举。
只能说Too Young，Too Naive ~
项目流程看似复杂麻烦，但是为了规避未知的问题，还是尽量在产品需求及开发的过程中重视这个流程。
很多软件开发流程的制定，其目的一是为了规避项目的问题，另外一方面就是为了保护我们这些开发人员，免遭SX产品的蹂躏。
最后，搬砖不易，且搬且撕逼~
记一次CD的填坑之旅
