那些年企业类型项目的一些总结

做企业项目大约快一年多了，依稀记得有不少同事抱怨，企业项目功能简单，但是业务复杂。

单说功能是不难的，可以说初学者都能上手，但是前期业务的理解错一点，到后面的实现出来相差就很大，其次也就突出了企业项目中的开发流程就比较规范，每一步都会要求需求明了，文档清楚，有问题及时提出来。

一、开发流程

---

①.进行串讲从客户或者用户所得到的，有价值的需求，准备进行下一阶段开发(需求串讲)

会后要求：
UI，和前后台，测试必须保证同时到场对于需求提出疑问，同时理解，当然前提是与小组长确定好最近阶段有空闲时间
工作：

• UI，如时间多可进行高保真出图，时间少，先出低保真
• 后台：进行编写接口文档，其中的数据字段，应该与需求，前台商量好，保证是满足需求的，同时也能给前台需要的数据
• 前台：应准备写开发方案，同时小组长，督促各组员将开发时间预估好，并在当天与组员讨论开发存在的难点。讨论结束后，应一并写在文档中。
• 测试：根据需求，编写测试用例

②.开发按照开发文档，按照使用高保真or低保真中的流程所说一遍，其中细节问题当场询问需求(开发反串讲)

串讲中所补充问题，应记录到文档中

③.测试用例串讲

根据测试用例，开发应当补充最后一次开发文档，并将文档上传，并抄送给需求。

④开发中，将根据开发时间和计划严格执行

小组长，每天检查组员的计划完成程度，并及时将风险点往上汇报，尽量做到前紧后松

风险点：

• UI的切图及效果图缺失
• 后台的接口延误
• 开发中的难点无法解决
• 业务的更改及增加

二、测试包，灰度包，正式包，版本号呢

在给测试打包的时候，可能应该开发最开心的时候，因为转测了，但是有时候也是很痛苦的，因为有人太多包要打了。
后面引入了Jenkins持续集成，自己编写打包脚本，让测试能够自己打自己想要的包，也算是解耦了，其实我一直很像明白脚本打包为啥速度比AS快那么多。。。

三、开发中，得严格抓代码规范

企业项目迭代会很快，因为是对内的，需求量会很多，这不同于商业项目，企业项目很容易一下子变成几百个人的大项目，也有可能开发人员流失，转移，这一切的原因都是因为开发周期比较长，同时也有可能有段空档期，所以后来人接受就很困难，所以需要文档清楚，代码规范。

1.因定期举行代码QC，代码赌场，或者黑客马拉松等活动，维护好项目代码，同时与其他项目组，公司学习质量好的代码。

2.小组长也要前期准备代码规范文档，每天有时间去查看项目，与小组成员保持交流。

3.代码提交记录应该也是能够当做日报写的，有摘要，有重点。

开发中工作总结

1.企业项目总是存在各种图标，饼状图，折线图，柱状图，什么的都是浮云，已经玩转MPchat项目了

2.封装Fragment的，并且加入栈管理，使其F，能够更好地被使用，你问我什么时候使用，有意义么，有无数的选择列表，就是使用F的，因为企业选择列表太长，同时层级有比较冗长，一个activity+多个F，适合业务场景。

3.项目中，因为是在插件平台使用的，可能需要多个APP共用一份内存，所以所有界面需做到用完即扔，及时清理界面的缓存，根据业务需求，兼容不同系统版本，封装自定释放view，在界面销毁的时候，自动循环所有层级view，里面有递归的逻辑呢

4.等等。。。。

结语：

自己并不怎么想再去做企业项目了，因为商业价值不大。。。

有问题可以发邮件到[email protected]，互相学习，互相交流