用一个域名免费做网站个人如何在企业网站做实名认证
目前团队缺少SA（研发经理）的角色，大家代码写的有点随意，老板让我写一份开发手册。嗯！！！当时我稍微纠结了一下，感觉这个似乎不是我的工作范畴，但是本着"我就是块砖，哪里需要往哪搬"的工作态度，还是应下了这个工作。
遥想当年，大学时我去应聘了学校学生处的秘书，很幸运在学生处历练了2年，当时还是学到了一些写作的本事。感谢当时的老师，还有学姐！！！特别是学姐，那是手把手教我~嗨！都是往事，都是故事！
各位道友，下面是我写的研发手册，虽然不是文采飞扬，但是本着实事求是的态度，还是描述清楚了手册的重要性。
正文如下：
为什么要有代码质量手册
一些事实
只有当出现“严重”的性能问题时，我们才会开始着手进行性能优化。在优化过程中，面对无数细小的“不良”代码，往往又力不从心。相比得到的些许性能改善，庞大的工作量又不得不令人放弃。不得不承认的是，无数细小的“不良”代码所累加的性能问题是严重的。这些看似“细小“的问题总是得不到重视。
一个软件的生命周期中，80%的花费用于维护。几乎没有一个软件，在其整个生命周期中，均由最初的作者来维护，工程级代码需要所有工程师去维护。
代码首先是用来实现和完成功能需求的，但更多时候是写给身边的队友和自己看的，是需要长期维护的。
写好代码不容易，写烂代码很容易。代码清晰，比奇技淫巧重要。模式、规范只是手段，代码清晰才是目的。在烂代码的熏陶下很难理解什么是好代码。
大多数时候，文档和代码是不同步的，而且文档往往是滞后的。这就更要求有清晰的代码了。而优秀的代码大部分是可以自描述的，好于文档和注释。
工程级代码要求：功能实现（执行力） > 代码可读性（责任心） > 运行性能（对极致的追求）。
规范制定的目的
我们需要这个规范吗？
推荐大家仔细阅读Google Java Style Guide和《重构-改善既有代码的设计》。另外，阿里开源了阿里巴巴Java开发手册，有不少实战干货，很多思想是通用的。
规范的制定是长期以来对工作的积累与沉淀的产物，帮助我们更快、更好、更高效的完成工作，制作规范的主要目的在于：
- 无论团队人数多少，代码风格都应该师出同门。细节体现一个coder和团队的专业程度。
- 避免低级的错误发生。
- 规范是多人良好协作的前提，它能降低每个成员介入项目的门槛，提高工作效率。
- 统一的代码风格，可以培养团队良好的协作和编码习惯，可以减少无谓的思考，团队内部阅读或调整代码，将会变得非常轻松。
- 规范化的最终目的，一个是提高开发效率，另一个是确保团队开发的可持续性，减少“坑”出现的几率。
面对规范的态度
规范，意味着约束。可能会带来一定程度的束缚甚至反感。意味着不能由着自己的性子做事了。 但是，在一个团队里面做事，更多的是要确保把事情做成、做好。
为保证规范不会引起开发者强烈的反感与束缚，规范里面，并没有很多强制性的字眼，更多的是一种理念、建议。
好的编码规范能帮助团队提升效率。为了不让它成为效率的绊脚石，大家都可以参与到这份规范中来，好的建议，都可以加进来。或者有意见可以一起讨论。
坚持制定好的代码规范。实际上也会潜移默化的给个人带来正面的影响，时间越长，正面的影响就越大。即使有一天，因为某些原因，没有遵循相关规范，从而打破了规则。也能做到心中有数----你知道什么时候可以打破这些规则。
约定
- 开发环境
- 编码约定
- 开发工具
- 标准工程结构
- 代码规范
- 命名规范
资料
- 模块介绍
- 数据表结构
- 常用工具类
- 问题总结
各位道友，上述就是手册的概要，各个模块的详情没有放入链接，多少还是涉及到写公司内容的。请各位道友多多指教~
人道渺渺,仙道茫茫~