一、 代码规范
定一个规范的主要目的，是为了让不同的开发人员写的代码能保持一致性，方便别人看自己的代码。另外，对个人来说，也能起到让自己看着舒服的作用。
1. 基本
* 使用UTF-8编码
* 使用Tab进行缩进
* 对待旧代码的态度：许多旧代码的风格比较乱，我们没有必要专门全部改一遍，只需要“顺带手”改了就好，例如你改了一个旧的函数，那就顺便把里面的代码风格都统一一下就好，自己看着也舒服
* 采用Java标准方式写大括号，即大括号跟在代码的最右边而不是另起一行：
void funcName() {
if(a == 0) {
//...
}
}
2. 命名
* 所有Java代码采用驼峰命名法：isFavorite、ActivityMain
* 所有xml文件、资源文件采用下划线命名法，首字母小写：activity_main.xml、ic_launcher.png
* 所有类名首字母大写：BaseAPI
* 所有方法首字母小写：requestList()
* 所有变量首字母小写，且成员变量推荐采用小m开头：mContext
* 所有常量全大写，使用下划线连接：DEBUG_PRINT
3. 注释
* 注释的作用是让别人容易看懂我们的代码，所以注释只需要在必要的地方出现即可，更多的时候，我们应该通过起一个好名字（函数、类、变量、常量）来减少注释
* 以下地方必须要有注释：类的说明、类对外提供的函数的说明、类对外提供的变量及常量，且应该使用 /** 式的注释，这样在IDE里能够直接把鼠标放上去看到东西
* 在关键程序段，应该添加注释，例如某段很拗口的逻辑，应该要说明它是做什么用的，注释应主要说明 目的 而不是 过程
* 函数的注释应该说明各个参数的作用，以及返回值
* 要养成做好事留名的习惯，在自己创建的类，应该在类说明里留自己的名字。如果在别人的类里加函数，应该在函数里留下自己的名字。变量、常量也类似
4. 关于第三方库
* 对待第三方库的态度：第三方库能够大大减少我们的工作量，但是使用不当也会让我们陷入泥潭，一般来说遵循一些简单的规则就可以帮助你选择第三方库：
** 复杂度：如果某个功能需要考虑大量异常处理和细节，而且又是十分通用的，那么就应该考虑使用第三方库，典型的例子是：网络访问（Volley）、图片加载（UniversalImageLoader）、JSON解析（FastJSON、GSON）
** 成熟度：一般来说，我们应尽量选择成熟的第三方库，判断的标准包括：发布地点（例如Github）、是否持续维护（看提交记录）、通过搜索查看排名、通过Github搜索查看排名
** 修改规模：有些第三方库我们拿过来并不能直接用，可能需要进行一些修改，这时候我们就需要注意了。如果需要修改的部分（或者是未来可能需要修改的部分）不少，那我们很可能需要考虑自己来写，因为有时候修改花得时间比自己写还要多的多，事实上，无数前车之鉴已经展示了这一点。此外，尽量不要修改第三方库，因为许多第三方库本身会进行升级
* 此外，引入第三方代码有两种方法：
** 把第三方库作为外部库的方式引用：即在工程属性里添加依赖关系，这样做的好处是可以保持工程的独立性，缺点是工作环境下会有好多工程，而且如果修改了依赖的工程，需要clean一下才会生效。
** 把第三方库代码直接放到主工程里：这样的好处是不会有很多外部工程，但缺点是需要把资源文件（res等）也加进来，如果哪天你要删掉这个库，那就蛋疼了。
其实权衡的方法也很简单，如果第三方库的资源文件特别多，那我建议用外部库方式，如果第三方库代码文件比较少，可以考虑直接放到主工程里。
二、 多人协作
多人协作时需要注意的问题是如何合理分工，同时保证效率，降低沟通成本，有一些基本经验：
* 划分模块：一般按照界面进行划分是比较合理的，对于公用的数据模型及网络访问函数，可以统一由一个人写，也可以让负责某个界面的人来负责对应的网络函数；
* 不重复造轮子：有些界面控件是通用的，就不要重复写，有些网络访问函数是通用的，就用一份。要做到这些，最重要的是主动沟通，在意识到别人有可能需要自己的代码时尽早沟通；
* 防止svn冲突：两个人写同一个文件（特别是网络访问类）时，容易出现冲突，一些小技巧：
* 把可能会多个人同时写的文件分区块，用多个回车分隔开，然后用注释写上是谁的区域。。。
* 尽量一个文件只有一个负责人。。。
* 养成经常更新代码的好习惯。。。
三、 版本发布
在发布版本时，需要按照一定步骤，另外需要注意一些svn的操作方法：
1、 首先，完成各个功能的开发，进行自测；
2、 自测没问题后，使用dealmoon下的dealmoon.key进行签名，密码在代码目录的说明文档里。把apk给测试人员测试；
3、 测试人员测出问题，各个模块的负责人进行修改；
4、 经过若干轮修正，基本没有大bug，这时就可以发布了，将最后定稿的apk交给产品经理进行发布；
5、 确定发布版本后，使用svn，创建一个发布分支，在/branches/release_Vx.x目录下，其中Vx.x是版本号，用于备份发布的版本；
如果发布版本迟迟没有确定，而主线版本又要做下一个功能，可以先创建发布分支，然后如果有bug，就在发布分支修改，然后将改动merge到主线上。注意：一定要保证merge的单向性，即只从发布分支合并到主干，而不是从主干合并到发布，那样一会就乱了；