作为一个程序员,平时的工作是与项目来挂钩的,但是有的时候会发现有些项目做得风生水起,有的则做得浑身难受,那么一个项目究竟应该怎么做?
这个阶段是后端最初接触某项目的初始阶段,此时产品会给出最初的需求文档(线框图此时可能没有),甚至是人肉来咨询后端做最初的评估,已确定某些需求的可能性。
讨论结束后产品会根据讨论得到的结果回去开脑洞,项目可能夭折或者继续进行。
产品经过他们自己的讨论设计,给出需求文档线框图(此时设计稿一般没有),召集前后端等项目成员进行需求评审。此时后端同学需要根据需求的合理性、项目的开发周期进行讨论(砍需求)。
砍需求的目的不是为了砍需求而砍需求,需要根据手上已有系统的功能以及新需求做出综合考虑,尽量在相对简单的情况下实现产品的需求。
简单的说就是难的我也能做,但是要花时间,砍需求的目的就在于在项目的 deadline 内能够完成这个项目。实在不行这个需求放在二期,太多的所谓二期需求就没有二期的项目了(可见有时候产品的需求...)
注意,产品会接受开发砍需求,但是开发请对确认后的需求认真估期,保证 deadline。否则又砍需求时间到了又做不完,呵呵。
根据需求评审得到的需求,后端会先做初步的技术调研,需求拆分,在评审结束的1~2天内给出估期。
估期时需要注意,估期很难一次性估准,一个开发对于大于一周以上的估期就可以认为是凭感觉瞎估了,这里有个估期的经验:将需求拆细后拆到开发级别的力度建立对应的 task,对于每个 task 来做估期,当发现一个 task 的时间大于5后(单位为天),则需要拆分子 task,估期时采用斐波那契数列的评估方式: 1 2 3 5 8 13 21,对应于1天 2天 半周 1周 1.5周 2周 3周,可以上下加减0.5。然后根据子任务的时间合估计主任务的时间。
需要注意的是,估期时需要估计前后端联调时间,上线时间,资源申请时间,幺蛾子时间。幺蛾子时间为处理非此项目事件所花费的时间,这个跟开发本身所处的环境有关,可以在总估期的基础上乘以 1.2 ~ 1.5。
复杂事情需要技术评审,尤其是自己做的事情心里也没有底气,需要其他开发一起讨论的时候。技术评审是保证复杂事情可以顺利完成,减少后期返工可能性的一个重要环节。
技术评审开发本身自己需要给出评审文档,包括项目背景,技术选型,主要的技术约束,自己想到的设计实现。
一般一个项目会由多个部门并行开发,例如 数据、后端、前端、客户端,并行的过程中如果某个端开发比较慢,会导致卡另一个端的开发进度,所以需要开发前跟自己的上游约定 api,并给出文档,各个端遵循接口文档进行开发。
根据技术评审后(简单的事情没有评审,自己心里有数)得到的方案以及之前建立的任务进行开发。
开发过程中需要仔细研究设计稿的细节,有任何存疑问的点去找产品确认,确认后的需求记录在某个文档上。开发前几分钟的几句话,会大大降低返工的可能性。
记录后@产品画押,开发和产品的记性都很差,画押非常必要。后期甩锅有用。
开发时注意把某些流程繁琐的事情放在前面做,例如申请某些资源可能需要其他部门同学支持,有额外等候时间。
开发过程中遇到难点及时向其他开发求助,不要憋着。
如果可能遇到延期风险,请及时通知产品,deadline 请尽量遵循(这句话的意思很明显)。
前后端开发完后做整体的联调测试,在扔个产品测试前,请自己测过自己开发的 feature。否则气死产品事小,被产品打死事大。
迎接可能的返工。
上线注意各种细节,例如数据库变更,是否需要热缓存,灰度或者预发布后是否需要 cms 添加某些基础数据等等。
上线前请提供回滚方案。
文档记录下各种链接(需求文档、技术评审、 api),主要的实现,需求的变更即可。
正常情况下,上完线就结束了,也没有人会做这一步,但是如果后端做掉这一步的话,之后维护起来就会节省很多看代码思考逻辑的时间。
请尊重项目的 deadline。
为什么某些人会一直比你优秀,是因为他本身就很优秀还一直在持续努力变得更优秀,而你是不是还在满足于现状内心在窃喜!
合理利用自己每一分每一秒的时间来学习提升自己,不要再用"没有时间“来掩饰自己思想上的懒惰!趁年轻,使劲拼,给未来的自己一个交代!
如何一起学习,有没有免费资料?
欢迎工作一到五年的 Java 的工程师朋友们加入的 Java 架构开发:820251827
本群提供免费的学习指导架构资料以及免费的解答
不懂得问题都可以在本群提出来之后还会有职业生涯规划以及面试指导