开发前先明确工作模式，下方是常见的工作模式：
需求评审->设计评审->UI评审->排期->功能开发->验收->测试->UAT->生产。
实际中工作模式相对上述内容会有增加或者减少，但是，确认需求、开发、测试、上线这个主体流程是固定的
一、需求评审
最重要的阶段，确认需求的可行性和难度，梳理功能场景和业务逻辑，明确整体需求而不是只关注自己负责的功能。
一篇相对贴近实际需求分析的文章：
在大部分工作时间可能并不能参与到需求分析和需求评审这个阶段，在这种情况下，一定要仔细阅读需求文档，在备份文档中进行功能汇总，并且记录相关疑问点，在和产品沟通明确需求后再开始后续的工作。
二、技术评审
一篇相对全面的介绍性文章：juejin.cn/post/684490…
很少有人能幸运的参与到一个全新的项目开发，现在很多开发模式都是直接套用以前设计好的模板，或者是在现有项目中进行功能添加，并不能参与到设计评审这一阶段，感兴趣可以想一下现有项目的设计思路，如果项目中有一位优秀的架构师，可以平时多问一下。
在实际工作中技术评审，主要关注点在于设计能否完整覆盖需求点，主干功能是否能够逻辑闭环。至少需要保证主干功能的正确，再进行后续的工作
三、UI评审
没参与过，注意针对一些花里胡哨的功能要思考是否有必要，工作经验是设计越简单越好用，设计越灵活实际效果越不好用
四、排期
看开发时间评估部分，相当实用的思路：
五、功能开发
1、遵守默认约定和项目统一格式
2、开发中发现需求与设计的问题时，一定要整理后尽快确认
3、开发中存在风险点时，提前暴露给项目负责人，不要等到没法解决时再反馈
4、对可复用的业务组件在有时间的前提下尽量提取为公共业务组件
5、开发完成后一定要进行自测，前端可在提测前通过页面将功能完整的进行一次验证，
六、验收，测试
这个阶段主要就是保持耐心，配置产品和测试对功能进行保障。
注意点在于：
1、对于验收阶段提出的新增需求，估计难度和必要性，复杂功能可以另外排期，而不是立马添加，否则可能会因为新增需求项而导致意外问题。
2、并不是所有的问题都是可以解决的，非功能性问题可以沟通后先保持遗留。
七、UAT，生产
一般会有专人维护，在工作中保证发布版本与完成测试的版本一致即可
需要自己维护时注意项：
1、一份完整的部署手册
2、服务器软硬件配置信息记录
3、统一的部署工具或部署脚本
4、日志的分割和收集
5、服务器资源占用情况监控
......
