来源：blog.csdn.net/chenleixing/article/details/44173985
有关开发效率和协作的几点建议与心得体会
1、小提交:
把大的任务拆分成多个独立小任务，每完成小任务确保无 Bug 后就可以提交合并到主分支甚至发布；频繁提交有利于自己把控项目进度、降低风险、同其他人协作和代码 Review ; 每天可以提交合并多次。每个小任务是 1-2 个小时可以完成的粒度，最大的一天完成。并行做多个任务的时候，优先做最短时间能够实现的任务。
git分支的开发方式是十分实用的。在自己的分支开发，然后再合并到对应的开发分支上。都是小分支小提交。方便自己开发，也不容易出现大量重冲突。本地开发小分支是不会推送到远程仓库的，从而不会导致远程仓库的混乱。
2、命名规范:
尽量避免无意义的字符做变量 比如 a, b, t 。可以逐步改善，可以参考:http://google-styleguide.googlecode.com/svn/trunk/javaguide.html
这里主要体现出代码的易读性上。变量命名最好能让人一眼看出含义。可能并不需要遵循特殊的规范。
3、避免过度设计:
能够用简单方式实现的功能，不引入复杂的类，对象，避免不必要的 new 对象，避免引入不必要的泛型、线程。开发初期冗余大于抽象和依赖。避免自己重新实现比较通用的组件和函数。调研多种实现方式的时候，选用做简单的实现方式。尽量少写代码。
个人观点：
技术性能和代码开发是两种东西。其实最后的目的都是又快又好的完成功能。设计一定要落地接地气，不能过度追求技术的良好性。100行代码 提升了0.0001秒的性能 不如用10行代码直接完成代码编写。有时候整齐，清澈见底的代码才是好代码。性能问题只会出现少数接口上，针对部分问题单独进行优化未免不可。编写代码信奉 先有后无。有设计讨论的时间，先把他实现了。
4、Web 工程尽量避免在应用内部保存“状态”，这样可以适应频繁发布、重启无影响。
5、善于用打日志的方式调试，在程序关键点打日志。尽量少用断点方式，日志方式可以批量调试一批功能，效率相对高。
6、避免一屏显示不下的超大函数。
7、添加必要、简洁的注释：
循环中的 continue, break 尽量加上单行注释；尽量避免非函数结尾的 return，必要的时候加注释。类自动生成 toString() 方法，方便调试和打日志。
8、不把自己局限到做某个功能，每个人都是整个项目的 Owner ，尽量交叉 Review ，交叉开发。
只做自己一块内容，对于代码设计很容易失去大局观。
9、遇到问题及时和其他人沟通，避免浪费时间。
避免自己死扛，有时候问别人5分钟就能解决问题。
10、从最终产品的目标审视自己细小的设计，熟悉自己负责部分的上下游代码。时刻关注最终产品(Web 界面和日志)，发现 Bug 和可以改善的地方。
考虑问题从全局 ，产品出发，考虑设计的合理性，避免闭门造车。
