项目总结

项目总结

　　上周终于完成了项目的1.0开发，下周开始进入其他项目的开发，几个月来积累来一些想法，有关工作的事情已经在公司总结过一次了，总结一下其他方面吧。

　　一个项目的1.0要考虑的事情还是比较多的，首先要考虑到项目的搭建，基于不同的产品形式，需求，技术环境，要准备的东西是不一样的。

1. 首先说的就是项目大小，根据业务线分散与否，如果业务线比较多，相互之间依赖程度低，使用组件化是一个好的方式。否则，组件化的意义不大。
2. 与之类似，如果项目不是特别复杂，mvc已经足够了，如果项目是中大型的，而且时间又不是特别紧迫，mvp是个好的选择。（mvp的写法大同小异，业内用的方式看项目组内个人喜好）
3. 开发相关的规范，一定要在项目开发前定好，包括要适配的分辨率，代码风格，资源的命名规范，变量的命名规范，都是要提前约定好的。（推荐每次保存文件之前都用编辑器的一件格式话Reformat code一下，也是方便提交代码的时候减少冲突，资源变量的命名推荐使用业务线开头加下划线，一个是方便以后组件化，另一个是为了便于查找，命名尽量使用有意义的名字，虽然阿里出过一套android开发的手册，但个人感觉有一些规范不太恰当，大部分可以参考）
4. 项目的物理结构分包，记得以前比较老的项目会把所有的Activity，fragment，都放到一个包内，现在这么做的估计不多了，无论项目复杂度如何，按业务线分包还是有必要的，业务线内文件结构仍然很复杂的话，可以在业务包内分详细一点（Activity，Fragment，adapter，utils等），utils的话，可以放到base包内，utils的话，个人的喜好是分的比较细一些（公用的：timeUtils,deviceUtils,FileUtils,ImgUtils，其他的杂项统统扔到baseutils，只有自己业务用到的，放到自己包下的utils即可），而且项目前期就把常用的加进去，如果只写文件名，不加函数，后期开发用到一个写一个，不仅浪费时间，而且很容易加重复。
5. 公共UI控件，这个考虑到交互问题，需要前期和交互UI方向的同学约定好，一旦封装成公共控件，不要轻易修改，常用到的：titlebar,loading,dialog,toast,emptyView,loadingView,errorView。titlebar常见的功能也就是那些：返回键，title更改文字，右边加一个可以隐藏的图标。loading的样式，看ui需求，可能会有那种如果没超过几百毫秒内加载完成，则不展示loading的需求。dialog和toast相似，没什么特殊需求，可以全局设置成只有一个，这样toast和dialog不会展示多个。xxxview的话，推荐一个MultiStateView，轻量级组件。关于UI控件其他的封装，注意不要重复封装和定义即可。
6. 和后端的交互，主要是网络接口上的，首先看是不是restful风格的，前期最好就约定比较详细的通信风格，活用header和http的规则，公共参数的封装到后期也尽量不要更改（会涉及到版本兼容问题），可能也会有一些url种cookie的需求，最好提前约定好，不同的接口可能是不同的开发写的，统一后端返回的字段风格（同一个字段，不同接口返回的类型要一致，尽量不要返回null之类的数据，有时候会有预留字段，但是绝大多数时候，预留字段也没有用到），定好线下线上地址，这个在打包的时候可以直接配置，dev版本也可以留一个后门，用于切换线上线下。
7. 其他的杂项，引用第三方的库最好是一个稳定版本，如果有条件可以迁到自己的服务器上？方便后期维护？（这个看公司要求吧）加了之后，最好马上加相应混淆配置，不然后期容易漏掉，查找起来比较麻烦。model如果有必要，尽量都实现Serialize（方便后期避免混淆）至于model内的变量是使用public的还是private get set的类型，这个一直没得出最好的结论，目前是看个人喜好，保持统一风格就好。如果一个类不再使用的话，尽快删掉，不必加注解注释，引起后来人的误解。注解方面的话，感觉一些注解纯粹是起到了注释的作用，感觉没必要，注释是个好东西，写的乱一点都没有关系，当然，如果有精力把注释都统一最好了。

　　关于一个项目前期的思考，先总结这些，后期如果想到其他有价值的，可能会继续修改补充。重构项目和新建一个正规项目要思考的东西差别很大，要思考的侧重点也不一样，经历过几次重构，项目组件化，考虑的是将一个项目化繁为简，分类，规范，像收拾屋子一样，只要考虑好现有的规划即可。新建一个项目要考虑更多细节，更依赖产品，前期的规范很重要，像是装修空屋子一样，充满了未知的可能，不会有最佳方案，但乐趣不就在于此吗？