所有的事物都有他们的生命周期，同样，没有“生命”的项目也有他的生命周期，如果管理项目的生命周期。
作为一个开发人员，可能有部分人或者说初期开发者认为做项目，完成所有的功能需求，交付给产品，之后基本就和自己没有关系了。个人认为，一个合格的开发人员，可以做的远不止这些。下面说说我个人对项目生命周期的理解。
需求期
-
充分理解需求，根据自己的理解，完善需求。
对于产品需求可能有考虑不全的地方，在充分理解需求，如果需求文档有理解不透的地方，要多和产品沟通，完善需求文档，在充分了解需求核对需求之后，自己基本对产品有一定的了解。 -
根据经验，提出合理化建议
在了解产品的基础上，我们可以根据自己之前做项目的开发经验，看看需求文档的需求设计是否合理，或者说是否可以有更好的方式，如果不合理，完全可以讨论或者去掉部分不合理需求。 -
审核需求的连贯性
有些时候，我们在开发的过程中，突然发现，整个需求完全有问题，需求前后无法闭合，导致开发无法进行或者需要重新开需求评审，为了避免这样的情况，一定需要审核需求的连贯性。 -
最终交出一个较好的需求文档
在需求了解及讨论之后，给出一个更完善的
开发期
在需求确定之后，基本上不会有什么大的需求改动，这个时候开始设计自己的开发流程。
-
分析产品特点
产品面向的群体是哪些？产品的流量会有多少？产品是否需要权限控制？......。这个都是在开发初期需要考虑的问题，面向的群体不同，权限控制的粒度和安全级别的控制也会不同。流量如果很大就需要考虑高并发，如果流量不大，完全不用考虑高并发，可以提高开发效率，对于产品的分析，考虑的越多，最后需要对项目重构可能性就越低，健壮性就越好。 -
分析项目的难点
麻雀虽小，五脏俱全。每个项目不论大小，都是自己的相对难点，如果难点分析的清楚，设计的好，对设计过程了如指掌，后期开发会得心应手。 -
开发框架选择
如果在一个小公司，开发框架也许比较单一，但是在一个大型的公司，一般有很多的开发框架，开发语言可以选择，根据自己的需求特点选择框架，但是个人认为用主流的框架会更能适应变化。例如最近对项目的架构重构（jfinal->springboot），主要原因是jfinal接入soa或者CICD比较不方便。而这只是架构调整，完全没有新功能，如果当如选择使用sprinboot主流框架，重构的工作量完全可以省去。 -
项目拆分
如果一个项目很大，业务模块很多，可以在项目初期的时候，考虑对项目进行拆分，拆分成多个微服务，多个微服务之间相互通信。如果不这样做，后期如果需要拆分，会有很多的技术债务（同一个项目交接很多人，有很多看不见的坑，改动起来比较麻烦）；每个模块耦合太深，牵一发而动全身，后期拆分很痛苦；随着项目业务的耦合，引入的jar越多，项目启动越慢，效率越低。 -
是否使用缓存
项目使用有需要频繁访问而变动不大的数据，为了防止频繁访问数据库导致数据库性能降低，可以选择缓存部分数据，以提高系统的整体性能。 -
sql优化
对于需要频繁访问数据库的sql和需要关联多张表或者子查询的语句，要注意sql的效率问题，因为一个项目的健康状态，不是看项目初期，而是在项目在若干年之后，随着数据量和流量的增加，性能依然如初，没有多大变化，有些系统，功能完好，性能越来越差，很大一部分原因，都是因为sql的效率不高，sql优化的方式很多，具体可以看我关于sql优化的文章，仅供参考。 -
关键路径日志跟踪
日志的方便之处，在于帮助查找和分析问题，而日志打的好不好，直接影响发现和分析问题的效率。有些日志在开发过程中可以打印（debug），在生产环境打印info级别以上的log
网友评论