---
title: "什么是可行的静态分析"
url: https://www.exakat.io/%e4%bb%80%e4%b9%88%e6%98%af%e5%8f%af%e8%a1%8c%e7%9a%84%e9%9d%99%e6%80%81%e5%88%86%e6%9e%90/
date: 2015-09-12
modified: 2015-09-12
author: "David 戴炜"
description: "[caption id=\"attachment_875\" align=\"alignleft\" width=\"320\"] 可行的静态分析：当标准已经定义，静态分析工具就会开始扫描[/caption] 静态分析指在不执行代码的情况下审查代码。这样的代码审查可以是一个项目的一个阶段，或者当代码被转移给一个新的程序员（他也可能是6个月后的你自己）的时候自然发生。在两种情况下，目的都是通过阅读代码找到缺陷，理解它和找到不可能的情况。 不像测试，代码审计发生于当代码被写出来以后，因为，当然，在没写代码之前没有任何东西可以去审计。然而，被写出的代码拥有比仅仅肉眼能看到的更多的东西。在没有考虑两个不同方面的情况下，是不可能进行代码审计的；这两个方面是：它（代码）的架构和它的独特性。 代码架构 代码架构是一个组织代码的规则框架。比如，设计模式或 MVC 范式帮助分隔不同部分的代码，并且给事情的实践带来一些清晰（的概念）：控制器，模型和视图都拥有不同特定的任务。一般来说框架提供了很多这种架构。 代码架构在代码本身来说是很难阅读的。它需要（很多）前提知识：确实，在使用任何框架之前，一个人需要阅读它的文档，学习教程，然后开始写代码。范式的转换包括通过像从调用“echo”命令到写一个.phtml的文件。静态分析工具不可能通过代码学习知道一些类是不是控制器：这个必须事先就被知道。 项目的独特性 还有一些架构方面的规则只对应于一个项目。文件系统的结构通常在不同项目中有不同结构，Wordress 文件结构, Magento 文件结构, Code Igniter。还有用来存放缓存，临时文件，模块，第一版或第二版，测试等等的目录。这些必须学习了解而且不能在一个项目到另外一个项目之间重用（或者，基于经验，非常少）。 其他的项目的特性来源于业务逻辑，比如数据格式或算法。而且一些架构也从这些而来，比如帮助(helpers)或相关的REST服务。 通常的缺陷 最后，还有通常的缺陷。那些导致Bugs的代码问题，不和任何业务逻辑或项目的规则相关。这有可能是对一门(编程)语言的经典的误解, 或者一个快速黑客的情况。 之前的这些问题的主要不同是这些规则都关于PHP，对这些一个人可能找到各种不同的建议。学习这些应该已经做过，不应该属于和某个项目特例或架构选择问题。 作为一个总结，下面的表格显示了静态分析将会发现的各种代码和缺陷： 代码中可见 架构中可见 通常缺陷 静态分析能够找到的问题：孤立指引错误(Dangling reference..."
categories:
  - "Code auditing"
image: https://www.exakat.io/wp-content/uploads/2015/08/container-crane.320.jpg
word_count: 86
---

# 什么是可行的静态分析

[![container-crane.320](http://178.62.231.40/wp-content/uploads/2015/08/container-crane.320.jpg)](http://178.62.231.40/wp-content/uploads/2015/08/container-crane.320.jpg)可行的静态分析：当标准已经定义，静态分析工具就会开始扫描

静态分析指在不执行代码的情况下审查代码。这样的代码审查可以是一个项目的一个阶段，或者当代码被转移给一个新的程序员（他也可能是6个月后的你自己）的时候自然发生。在两种情况下，目的都是通过阅读代码找到缺陷，理解它和找到不可能的情况。

不像测试，代码审计发生于当代码被写出来以后，因为，当然，在没写代码之前没有任何东西可以去审计。然而，被写出的代码拥有比仅仅肉眼能看到的更多的东西。在没有考虑两个不同方面的情况下，是不可能进行代码审计的；这两个方面是：它（代码）的架构和它的独特性。

## 代码架构

代码架构是一个组织代码的规则框架。比如，设计模式或 [MVC](http://symfony.com/legacy/doc/book/1_0/en/02-Exploring-Symfony-s-Code) 范式帮助分隔不同部分的代码，并且给事情的实践带来一些清晰（的概念）：控制器，模型和视图都拥有不同特定的任务。一般来说框架提供了很多[这种](http://framework.zend.com/manual/1.12/en/learning.quickstart.intro.html)架构。

代码架构在代码本身来说是很难阅读的。它需要（很多）前提知识：确实，在使用任何框架之前，一个人需要阅读它的文档，学习教程，然后开始写代码。范式的转换包括通过像从调用“echo”命令到写一个.phtml的文件。静态分析工具不可能通过代码学习知道一些类是不是控制器：这个必须事先就被知道。

## 项目的独特性

还有一些架构方面的规则只对应于一个项目。文件系统的结构通常在不同项目中有不同结构，[Wordress 文件结构](https://developer.wordpress.org/plugins/the-basics/best-practices/), [Magento 文件结构](http://www.amicontech.com/blog/magento-file-structure-and-workflow/), [Code Igniter](https://selftaughtcoders.com/codeigniter-application-folder-structure-files/)。还有用来存放缓存，临时文件，模块，第一版或第二版，测试等等的目录。这些必须学习了解而且不能在一个项目到另外一个项目之间重用（或者，基于经验，非常少）。

其他的项目的特性来源于业务逻辑，比如数据格式或算法。而且一些架构也从这些而来，比如帮助(helpers)或相关的REST服务。

## 通常的缺陷

最后，还有通常的缺陷。那些导致Bugs的代码问题，不和任何业务逻辑或项目的规则相关。这有可能是对一门(编程)语言的[经典的误解](https://github.com/dseguy/clearPHP/blob/master/rules/no-dangling-reference.md), 或者一个[快速黑客](https://github.com/search?l=php&q=quick+hack&type=Code&utf8=%E2%9C%93)的情况。

之前的这些问题的主要不同是这些规则都关于PHP，对这些一个人可能找到各种不同的建议。学习这些应该已经做过，不应该属于和某个项目特例或架构选择问题。

作为一个总结，下面的表格显示了静态分析将会发现的各种代码和缺陷：

| | 代码中可见 | 架构中可见 |
| --- | --------------- | --------------- |
| 通常缺陷 | 静态分析能够找到的问题：孤立指引错误(Dangling reference error) | 静态分析找到踪迹（traces），但是不能下结论:只有模型对数据库做查询；只有模板文件含有HTML(如果适用） |
| 项目特性 | 当特别的规则定义好后，它有可能被静态分析找到：一个电话号码的格式必须是(\d\d)-(\d\d)-(\d\d)-(\d\d)-(\d\d) | 需要特别的规则和对架构了解：电话号码存于CHAR(10)字段，没有分隔符(i18n在模板文件里做) |

## 可行的静态分析

静态分析的一个主要的限制是列出可以强制执行的规则。对PHP有一组规则，比如[PSR](http://www.php-fig.org), [ClearPHP](https://github.com/dseguy/clearPHP)或者 [object Calisthenics](http://williamdurand.fr/2013/06/03/object-calisthenics/)提供了一个很好的通用的参考。

下一步是对一个项目提供一组独特的规则。这个包括：

- 从其他各种参考中选择一些规则
- 帮助Helpers方法
- 数据格式（日期，电话号码，ISBN的解析，验证，显示和操作）
- 配置（变量名字，定义，访问）
- 存储结构（类和存储直接的连接，必须被存储的对象）
- 算法（CC信用卡验证，VAT数字的验证）
- 业务逻辑
- 对象代理（永远不调用数据API，永远使用这个对象...)
- 项目的可做和可不做的东东（添加一些人性的味道）

很常见的情况是，这些规则都是一步一步在进行中完善的。尽快地收集它们使得每个人可以撰写合法的代码。它也允许加入一个静态分析的工具，那样可以监控应用程序的代码并基于规则提供系统的反馈。只要是代码标准(conding standards)不可知，它们是不可能查询和应用上。

## 面向对象实践Object Calisthenics( Cal • is • then • ics - /ˌkaləsˈTHeniks/)

作为一个例子，这个是 [面向对象实践(Object Calisthenics)](http://williamdurand.fr/2013/06/03/object-calisthenics) 编程练习在上面的表里几个规则。由于这是不仅仅局限于PHP的哲学(规范)，这里没有“通常缺陷”。在你的自己的项目中适用它们。

| | 代码中可 | 架构中可见 |
| --- | ------------ | --------------- |
| 通常缺陷 | | - 不要使用 ELSE 关键字
- 每个方法只有一层缩进
- 保证所有的实体很小
- 没有类拥有多于2个以上的实例变量
- 没有Getters/Setters/Properties |
| 项目特性 | - 扩展所有的原始数据类型和字符串
- 一行只有一个 -> | - 第一地位的集合类 |

[Don't Abbreviate](http://williamdurand.fr/2013/06/03/object-calisthenics/#6-don-t-abbreviate)：属于代码约定，不在这里讨论。

English: http://178.62.231.40/applicable-static-analysis/