1. 以挑剔眼光review，以团队之collective wisdom保证代码高质量；加强各种形式的讨论
特别是对于重大fix，主要说做了什么，为什么做，对于轻微fix，可以附加在主提交的内部；
另外，强制每位开发者写好commit也是在迫使思考，当前的commit到底干了些什么，能不能清楚地讲明意思，代码写好了，却不知如何用合适的语言讲给别人听，这是大大的遗憾！英文水平不够 ? 那就多补或多讨论吧
3. 大提交，看似很能影响性能的提交，不可直接提到主分支，要有peer review
4. 不使用相同的分支名提交不同功能的代码（习惯多建branch）
5. 不在最新未合并的提交上再建新分支，如果它们最终没通过还要撤消当前的再改，用已经被merge到主分支且最低限度能保证新分支功能能正常完成的那个分支作为新分支的基础分支，这有利于增强开发并发度和独立性；若其它MR被首先merge，也没有关系，只需git pull --rebase即可，冲突也不会很多或很容易修复
6. 对于重要提交，多关联issue，且commit message带上issue号，其他开发者能快速找到与此fix相关的问题上下文，reviewer会对fix有更直观的理解，这就有必要适当地在issue下写下你设计时的考量，一来是给自己参考(确定几年后还记得？)，二来是作为后来者参考设计的重要文档
7. 注释适当写。这一点，不同团队各有讲究，我目前认为，该写就要写，虽说代码说明一切以及容易忘记保持文档同步，但有复杂逻辑和重要trade-off时就应该告知阅读者；且scylla开发人员有一个我认为非常好的习惯，他们会在自己也不是非常肯定或者迫于时间等压力暂时先这样写时，加一个FIXME标记。这绝对是个特别好的习惯，给未来的优化改善提供了搜索关键字，也在提醒别人注意，更重要的是一种谦虚的表现，因为除那些特别有经验的人之外，没有人可以做到不做性能测试就能百分百肯定这地方这么写一定是最好的，或者一定是没有损耗的，所以鼓励大家多用FIXME
8. 如果是在开源项目基本上做内部版本且有可能在未来开源，应保证代码风格、命名风格与原项目一致，个人风格的优先级降低
9. 保持谦虚！
10. 其他
- 所有代码文件以空格分隔书写，防止不同环境下的排版问题
- 基本单元测试要有。可以独立的功能就尽可能增加test case
- 日志打印，可以在不影响release版本性能前提下增加debug,trace日志，当然也不要太多
- 测试结果要放在一个让人容易找得着的地方，issue, wiki, mail都行，做完了不要轻易丢弃，提供后来者chanllenge你的测试方法与结果的机会
- 重视函数命名，起得不合适就得早改