前言
属于前期文档，略简陋，后续有改动完善补充。
需求管理
使用禅道做产品项目管理工具。以版本来规划开发周期。
产品需求收集
产品需求确认（需求逻辑，技术，ui实现度评审）
产品需求UE/UI完善（Ui评审,技术实现度）
后端接口开发任务，形成接口文档备注到任务，关闭任务。
Android编码开发，特殊情况备注到任务，关闭任务。
测试运行完毕，关闭需求。
版本规范
目的：规范版本命名，方便版本更新与管理。
版本命名：VersiionName， 命名由四部分组成，主版本号+次版本号+修订版本号+日期版本后，可再加_如：beta,dev,debug,release 标识特殊意义的版本。如：2.3.0.170525.dev。前边可加前缀对项目工程进行描述。如ETC_Android_2.3.0.0.debug。对外发布只使用前3个版本号如2.3.0。
版本编号：VersionCode ，递增正数，如136。方便做版本更新判断。
版本控制系统
目的：清晰管理与协同代码。
工具：使用分布式版本控制系统git，图形操作Windows下使SourceTree，服务器使用gitblit。
分支管理：master,主分支，测试过稳定用于上线发布的代码,禁止推送。
dev，开发分支，日常开发用。每次发测试版本打上版本标签。稳定后合并到master.
bugfix_版本号,bugfix分支。测试提出bug后，dev标签处chekout对应bugfix版本，修复后合并到dev。
提交说明:提交的粒度尽可能小，提交描述要清楚。提交前自行简单review一次代码。
git的使用学习有一定成本，请自行学习。
编码规范
目的：使得编码清晰易阅读维护。
力求简单易读，见名知义。避免出现a1,a2。。。an等无意义的命名。具体自行搜索各语言的命名规范。每一个类的作用，作者写好。逻辑上有稍复杂的代码要写好注释。方法的嵌套不超过5层，不超过35行代码，类的方法不建议过多。读代码与读书，篇幅过长不利阅读，逻辑清晰度也受影响。
项目安全
https传输。
关键信息传输加密与本地加密。
统一用户鉴权session与cookie。
token。
前后端数据交互方案
json格式
后端维护接口文档，前端调用即可。一些细节在具体业务在体现。
参考：http://www.jianshu.com/p/35a7b6f5f92e
image.png
url=https://web2.lunkr.cn/lunkr/s/json?func=cim.oabEx:getUserInfo&sid=FAFtMvSSuqnrZKkfTHSSenwnvtSEYoJv,
body={
"list":"#504#U",
"returnAttrs":["mobile_number","company_phone","home_phone","email","true_name","gender","@location","uid","flagged","@ou"]
}
result={
"code":"S_OK",
"var":[{
"uid":"#504#U",
"true_name":"论客机器人",
"email":"ceshi@coremail.cn",
"org_id":"mailtech-mailtech",
"customer_id":"",
"@ou":"mailtech-mailtech/mailtech_x-cs",
"user_type":"U",
"fn":"",
"external_limit":false,
"user_status":0,
"my_trust_level":"supreme",
"other_trust_level":"supreme",
"flagged":true,
"my_contact":true
"primary_email":"ceshi@coremail.cn",
}]}
后端架构
采用LAMP。参考http://www.jianshu.com/p/b80aa249d38b
Android规范
架构：
数据库，ContentProvoider + SQLite 封装。
网络层，okhttp3.2 + Rxjava2 + RxAndroid2。
MVC模式，简单易懂。
类全局变量m开头。简单图片使用svg。其他格式图片放mipmap对应尺寸文件夹。文字与颜色值放置配置文件再到代码中使用
无意义不懂原理的代码不能放到项目中。
bug与数据埋点上报，bug监控
目的：便于系统维护，bug查找，用户行为数据分析。
开发对应的bug上报分析接口，客户端将必要的bug与埋点在一定的时间上传到服务器。
需要考虑数据量问题。
Android使用友盟监控线上bug。
测试管理
自动化测试环境搭建，做到每日构建。由于缺少测试人员，各端有时间自己搭建。
网友评论