架构篇--代码质量手册

目前团队缺少SA（研发经理）的角色，大家代码写的有点随意，老板让我写一份开发手册。嗯！！！当时我稍微纠结了一下，感觉这个似乎不是我的工作范畴，但是本着"我就是块砖，哪里需要往哪搬"的工作态度，还是应下了这个工作。

遥想当年，大学时我去应聘了学校学生处的秘书，很幸运在学生处历练了2年，当时还是学到了一些写作的本事。感谢当时的老师，还有学姐！！！特别是学姐，那是手把手教我~嗨！都是往事，都是故事！

各位道友，下面是我写的研发手册，虽然不是文采飞扬，但是本着实事求是的态度，还是描述清楚了手册的重要性。

正文如下：

为什么要有代码质量手册

一些事实

只有当出现“严重”的性能问题时，我们才会开始着手进行性能优化。在优化过程中，面对无数细小的“不良”代码，往往又力不从心。相比得到的些许性能改善，庞大的工作量又不得不令人放弃。不得不承认的是，无数细小的“不良”代码所累加的性能问题是严重的。这些看似“细小“的问题总是得不到重视。

一个软件的生命周期中，80%的花费用于维护。几乎没有一个软件，在其整个生命周期中，均由最初的作者来维护，工程级代码需要所有工程师去维护。

代码首先是用来实现和完成功能需求的，但更多时候是写给身边的队友和自己看的，是需要长期维护的。

写好代码不容易，写烂代码很容易。代码清晰，比奇技淫巧重要。模式、规范只是手段，代码清晰才是目的。在烂代码的熏陶下很难理解什么是好代码。

大多数时候，文档和代码是不同步的，而且文档往往是滞后的。这就更要求有清晰的代码了。而优秀的代码大部分是可以自描述的，好于文档和注释。

工程级代码要求：功能实现（执行力） > 代码可读性（责任心） > 运行性能（对极致的追求）。

规范制定的目的

我们需要这个规范吗？
推荐大家仔细阅读Google Java Style Guide和《重构-改善既有代码的设计》。另外，阿里开源了阿里巴巴Java开发手册，有不少实战干货，很多思想是通用的。
规范的制定是长期以来对工作的积累与沉淀的产物，帮助我们更快、更好、更高效的完成工作，制作规范的主要目的在于：

• 无论团队人数多少，代码风格都应该师出同门。细节体现一个coder和团队的专业程度。
• 避免低级的错误发生。
• 规范是多人良好协作的前提，它能降低每个成员介入项目的门槛，提高工作效率。
• 统一的代码风格，可以培养团队良好的协作和编码习惯，可以减少无谓的思考，团队内部阅读或调整代码，将会变得非常轻松。
• 规范化的最终目的，一个是提高开发效率，另一个是确保团队开发的可持续性，减少“坑”出现的几率。

面对规范的态度

规范，意味着约束。可能会带来一定程度的束缚甚至反感。意味着不能由着自己的性子做事了。 但是，在一个团队里面做事，更多的是要确保把事情做成、做好。

为保证规范不会引起开发者强烈的反感与束缚，规范里面，并没有很多强制性的字眼，更多的是一种理念、建议。

好的编码规范能帮助团队提升效率。为了不让它成为效率的绊脚石，大家都可以参与到这份规范中来，好的建议，都可以加进来。或者有意见可以一起讨论。

坚持制定好的代码规范。实际上也会潜移默化的给个人带来正面的影响，时间越长，正面的影响就越大。即使有一天，因为某些原因，没有遵循相关规范，从而打破了规则。也能做到心中有数----你知道什么时候可以打破这些规则。

约定

• 开发环境
• 编码约定
• 开发工具
• 标准工程结构
• 代码规范
• 命名规范

资料

• 模块介绍
• 数据表结构
• 常用工具类
• 问题总结

各位道友，上述就是手册的概要，各个模块的详情没有放入链接，多少还是涉及到写公司内容的。请各位道友多多指教~

人道渺渺,仙道茫茫~