×

项目开发填坑记

96
追云_似梦
2016.11.26 09:26* 字数 919

坑1:做不明确的需求

在大多数公司,大多数的开发人员眼中的产品经理是不靠谱的,很少能将一个需求描述的清楚,不求天衣无缝,但连基本的业务逻辑都没理清这就蛋疼了。
对于一句话需求,“做的跟XXX一样”、“就按照XXX来”、“参照XXXApp的逻辑和界面交互”,往往令人开发人员蓝瘦~
但是活还是得干,毕竟项目周期在那摆着。做不明确的需求,会碰到哪些坑呢?做完了,产品一看,“咦,这不是我想要的啊!?”,如果时间还来得及可能就要改上一番了,如果时间来不及,可能就直接将需求放到下一期。
所以,做开发的一定要切记,千万不要做不明确的需求,在做之前先跟产品沟通清楚,不然宁可撕逼也不要轻易的码代码,毕竟最后需求做错了还是你改代码~

坑2:产生这个BUG很简单的错觉

有时候一个BUG的产生,一方面是写代码的失误,另外一方面就是产品业务逻辑上的自相矛盾导致的。
代码上存在的BUG还好解决,但是一旦产品业务逻辑上产生了一个死结,就算代码再怎么改,BUG肯定还是有的,而且还很难解决,碰到这种问题,千万别自己死脑筋非得把一个错误的问题答正确,而是去分析业务逻辑上的问题,如果有就让产品去改,如果逻辑说得通,那么再考虑代码层面的问题。

坑3:提交一个自认为没问题的代码到主分支

也许很多开发人员在将代码提交到主分支时,都自测过一遍。这个习惯很好,但是自测没问题不代表测试测的时候没问题,如果在测试测试期间提出的BUG,特别是偶现的问题(一般都可以通过代码造假异常数据复现)一定要记得在解决这种测试提交的BUG时,最好在本地切一个分支专门解决,然后将Fix Bug的分支包提交测试,如果没有问题再合入到主干分支。
最后如果临近发包突然发现之前改的Bug还是有问题,那就蛋疼了。轻则临时加班解决问题,重则代码回滚(之前的Bug依旧)。一般这种最后才发现的Bug是最蛋疼的,时间紧不好解很容易出锅。

小记

有时候觉得需求不明确,一样可以开发(一边开发一边沟通)。有时候觉得项目管理和版本控制多此一举。
只能说Too Young,Too Naive ~
项目流程看似复杂麻烦,但是为了规避未知的问题,还是尽量在产品需求及开发的过程中重视这个流程。
很多软件开发流程的制定,其目的一是为了规避项目的问题,另外一方面就是为了保护我们这些开发人员,免遭SX产品的蹂躏。
最后,搬砖不易,且搬且撕逼~
记一次CD的填坑之旅

洗剑录
Web note ad 1