1. 写代码的目的

唯一的目的就是解决需求。但是代码的质量体现的是个人工作能力。

如果接受上面的论述，那么请在开工前，确定需求，然后重视代码质量。

所谓确定需求，就是需求描述落到官方文档，且描述不具有二义性。有一个经验：需求描述越冗长，这个需求越有可能是混沌的。所以要警惕这样的需求。

所谓的代码质量：规范性、正确性、高效性、鲁棒性。

• 代码书写延续规范
• 程序正确完成需求
• 程序运转高效
• 程序能抵御一定的恶意输入，并提示：参数错误，注入攻击，请求攻击，。

2. coding开始前的准备工作

回顾需求：是否明确。

这部分工作用于预防是否存在需求变更或者需求理解偏差的情况。

设计方案：是否能覆盖需求

这部分工作用于预防工作结果无法达成需求的情况。

回顾解决流程：是否有流程图

这部分工作用于类似于提笔忘字的情况。好记性不如烂笔头。

简化的流程图方案：注释块

简化版的流程图方案，在注释块里标记上代码逻辑的步骤，有利于展开coding工作，也利于后期的维护工作。

3. 代码的样子

变量控制：

代码应该看起来像是一台机器，一把电笔戳到节点上就可以得到正确与否的结论。我个人的建议是通过一个布尔型的变量来标识流程是否应该继续往下走。

有始有终：

不论是发生什么事情，代码都是可以从第一行一直运行到最后一行。这个地方就代表我们要避免在代码中加入return或者直接对外抛异常的逻辑。避免这种情况，也意味着避免了维护的困难。

以一个controller类的接口方法为例子，他应该是三部分构成，首先是初始化部分，再来是业务逻辑部分，最后是输出部分。

在业务逻辑部分通过一个布尔值的变量flag来控制业务逻辑的行为。如果有异常信息要携带，可以赋值给相应的变量。

当到达输出部分的时候，通过flag来确认是正常输出，还是报错的输出。

 4. 写代码的坏习惯

4.1 手先动起来

不管三七二十一就开始在键盘上噼里啪啦敲打。然后写到一半，卡壳。盯着屏幕半天不知道写到哪里了。

解决方案：注释块与流程图。

4.2   重复的代码逻辑

图方便就复制一份到一个地方。方便的同时，也带来了未来多处修改的隐忧。

解决方案：重复的内部逻辑，提炼为内部方法。重复的外部逻辑，提炼为工具方法。重复使用的内部变量，提炼为内部静态变量，重复使用的外部变量，提炼为全局的静态变量。

4.3   随意的命名规则

命名一个变量叫a，未来的某一天，自己都不知道这个a是apple还是amen了。稍好的一种情况是用拼音命名，guanliyuan来代表一个管理员变量。某些工程师甚至会搞中英文结合，比如zongManager表示总经理这样的情况。

解决方案：小驼峰风格的英文变量命名规则。名称+状语来表达完整的意义，比如dateInSystem。动词+名词用来命名方法，比如getValue。

4.4 缺席的注释

代码写得飞起之后，不留下任何注释。是为了保护知识产权么？未来的某一天，自己都不知道该程序的用途。

解决方案：最低限度是注释块。高一点的需求，每个程序块（if-else，循环体）在入口处都应该增加注释。

4.5  trick

trick是指采用一种不考虑后续维护，只追求快速解决需求或者bug的方法。这种行为会导致后期维护的困难。以引入新问题为代价，解决老问题。

举例1：将自定义字段的数据以json形式的字符串放入关系型数据库进行存储的方案。

问题：违背数据库第一范式：字段不可分。导致进行join,字段排序存在困难。

举例2：把数据库所有的字段全部返回给前端。

问题：暴露数据库结构，违背数据安全性。

举例3：把输入参数以字符串拼接的形式构建SQL语句进行执行。

问题：SQL注入攻击

4.6  陷入细节（过度设计）

每个需求总存在一个边界，当边界变得难以覆盖，那么考虑暂时放弃边界是可以接受的。

举例：地产开发的拆迁模式：并不等待全部拆迁户都满意的状态就开始施工。

举例：操作系统的鸵鸟算法：经过长期观察，发觉死锁现象的出现概率极低，则认为系统不会出现死锁。

举例：google

以上两个例子都是以2-8法则处理问题，不以完美方案为目标，而是覆盖百分之八十的大需求。引用一下《数学之美》里的一个观点，一把AK47，简单结构输出猛烈火力。