前言：
在典型的敏捷开发实践中，都强调简化模式过程，产品团队人员（设计人员、开发人员、测试人员）以简单的方式更多地参与到产品的设计分析中去。在比较极端的TDD、SCRUM实践中，对于user story、unit test、code review的单独强调也非常明显，即使较为缓和的CI模式，也做了严格要求。这对整个团队能力提出了新的要求。
工欲善其事,必先利其器！本文介绍的smart分析工具提供了两方面辅助工具：
1、产品设计分析 2、代码设计分析
我们的目标是：Better results in Less time

第一部分：smart之产品设计分析
1.1 适用分析
从最初瀑布模型的总体概要设计到敏捷实践中的user story，从最直白的黑盒测试，到深入筋骨的unit test，产品团队的角色参与人员一直需要面对的问题：
1、如何清晰的描述user story
2、如何发现设计的疏漏
3、如何比较全面的分析system、function
4、如何在不同角色之间快速达成共识
对于对象（产品、系统）的分析，一般情况下，产品团队成员都可以通过人工梳理、分析的情况完成，代价并不大。各角色按照自己的处理均以足够。但是当场景、算法、逻辑非常复杂的时候，就需要额外的方法工具来支撑你更好的完成。
这就好像一个电线的布线图一样，你可以很容易地通过一个简单的文档从复杂的实现中找到头绪。对于大的项目来说，产品团队人员很容易迷失在复杂的逻辑描述过程中。在这种情况下，使用smart设计辅助工具，能够让PM更容易的描述user story，让开发人员在实现之前有更多的时间思考设计方案与算法细节，让测试人员更全面更早的发现设计bug，编写测试方案与用例。
Smart产品设计分析基于如下两条：
1、如果分析对象足够清晰简单，那么你不需要使用（更多地辅助解决复杂典型场景）。
2、如果想用更短的时间做出更高质量的设计. Please go!
1.2典型设计场景辅助
1.2.1伪代码（流程场景）描述
1.2.1.1基本概念：
伪代码是一个非常不错的方式，让你可以看到你的产品功能是什么，你要写的程序长什么样？根据***(Wikipedia)，伪代码定义: 伪代码是一个紧凑和非正式的从高层描述一个计算机编程算法的结构约定。典型的伪代码一般会忽略那些算法中不需要人去关心的细节。比如:变量声明，系统调用，或是子程序。在伪代码中，编程语言被自然的人类语言所增强而放大，从而更方便、更紧凑。
这对于PM来说肯定是个福音，终于可以以最接近自然语言的方式规则化的描述出产品功能或者user story了。
对于技术人员来说，一些人并不喜欢伪代码，因为他们并不想把同样的代码写两遍，一遍是伪代码，一遍是真代码。这是可以理解的，因为两个copy的东西是比较不好维护的。但是我想，这是可以权衡的，如果的对象很简单，那么就不需要了，如果你的对象比较复杂，比较绕，那么，有一个伪代码提纲挈领将会是一件非常不错的事情。
1.2.1.2 实例分析
一个现实中的例子：（兼顾顺序、条件、循环、选择结构）
考虑一个去超市购物的场景。先想一下我需要买什么，然后看一下需不需要推车，挑选物品的时候看看价格是否合适。买完后结账。那么规则化的语言描述应该是什么：

使用smart设计分析自动生成流程图：
 

当然，如果需要，程序会辅助分析。
进行起始态与终止态的指定，进行路径分析。判断分支个数、条件个数等。
 

 

软件截图 : 

 

 

1.2.2状态场景描述
1.2.2.1 基本概念
对于现实中的典型运用来说，大至业务产品层面，小到代码协议层面，状态场景都非常普遍。状态图说明整个周期事件(讯息、时间、错误、以及状态改变)如何影响物件的状态。举几个实际的例子：
1. PM如何设计客户端、web类的用户场景。
2. 技术人员如何解决协议中的状态跳转。
3. Unit test中的状态覆盖如何兼顾。如何保证没有遗漏。
在这些复杂的状态场景中，smart分析辅助的作用就比较明显了。如经常听到的前端用户场景设计缺失，UT过程中用例的难以维护等等。
既然有更好的方式解决，为什么不试一下。Better results in Less time！
1.2.2.2 实例分析
1、百度HI的状态场景描述（用户场景定义）
 

2、图片首页的状态场景描述（用户使用习惯预置）
 

状态图基本分析
状态基本分析算法核心：
 ※步长覆盖（指定步长进行动作跳转覆盖）
 ※状态设计判断（是否存在不可达状态、不可跳转状态、用户态状态遗失）
 

 

1.2.3 功能Feture描述（脑图）
1.2.3.1 基本概念
直接以user story方式给出。进行需求与功能拆分。最直观最简单，却也是最有价值的方式。不做过多解释。
 

1.2.4多因素多条件场景（全排、正交、组合）
1.2.4.1 基本概念
对于产品设计过程中，经常出现这样的情况。多因素多条件的限定方式。此时采用流程、状态进行设计，比较烦琐，并不合适。这时更多的体现的是数学的排列组合的意味。我们也可以很方便的定义这种场景（对于搜索引擎来说，这个非常普遍）。
1、搜索核心的排序条件组合
2、银行软件系统中的理财组合
3、游戏场景设计中的行为触发
在场景处理过程中的设计分析与行为监测是比较困难的，因为条件与组合的结果非常复杂。为了便于分析问题，通常采取正交的方式对结果进行过滤。当然有一定的学习成本。
1.2.4.2 实例分析
百度图片的前端用户行为组合：
上半部分为可能的操作行为选择，下半部分为条件限制策略。
可以比较清晰地定义用户的行为场景。对于设计遗漏也一目了然。
 

软件分析如下：
 

如果需要过滤结果，则可以设置一下辅助参数进行分析：
 

 

第二部分：smart之代码设计分析
2.1适用分析
当开发模式逐步要求整个团队更关注于产品设计时，技术人员对于代码的要求也会越来越深入。考虑到代码相关的一些分析设计方法,如研发人员关注的（函数调用关系、成员变量跟踪，类封装，代码结构优化，代码设计分析），测试人员关注的（code review，unit test，静态代码分析）都会要求对代码的理解更加深入。因此，设计了smart代码分析工具，回顾一下我们的目标：Better results in Less time。
2.2 代码分析维度
2.2.1程序架构分析
2.2.1.1 函数调用关系图
※函数调用关系图显示
• 显示各个函数与类库的调用关系
• 显示各个函数调用的库以及成员变量 
显示调用关系
• 最快的定位一个功能函数及其所调用的函数
• 展开所有的函数调用图 
实际案例如下（类库声明引用）：
 

2.2.1.2 搜索与分析代码
A、获得函数的总体概括
B、代码格式的更可阅读性

2.2.2 核心函数分析
2.2.2.1 代码的流程图自动分析生成（分析函数所有路径）
• 用最短的时间理解与检查功能
• 检查代码的改动是否正确
源码如下：举一个分析函数生成流程图的例子：
可以用最短的时间理解函数结构，了解判断分析、异常分支。可以快速选中代码块进行具体分析。软件界面显示如下：

 

  

2.2.2.2 变量的跟踪分析
• 检查变量值的计算方式
• 跟踪变量的计算过程
2.2.2.3 函数逻辑划分
• 检查函数中的逻辑划分
• 检查函数调用顺序
函数结构自动划分如图：
 

2.2.3代码细节审查
更多的依赖于静态代码分析工具。将会在后续不断完善。
A、全局变量在何处使用
B、获得程序、函数调用关系
C、获得函数的参数列表
D、检查函数正确性
E、获得成员变量使用情况