怎样写出好的脚本(1)-流程的开发与建立

xoit

我不是专业的程序员，我也没有太固定的coding style，只是最近在写一个utility，有些许感想，加上在之前网上收集了一些参考资料，遂想整理出来，以享需要之同志。
这个系列暂时还没想好写多少，目前有以下几个议题，在此基础上展开来写：

• 脚本流程的开发与建立（本文）
• 降低维护成本需要的好习惯
• 权衡流程自动化与深入学习之间的矛盾

今天开始将第一个议题：流程的开发与建立

                               
登录/注册后可看大图

flow chart

我是做IC的，大规模集成电路，在我们行业里，一切按流程办事早已成为一种共识，主要是因为集成电路的生产工艺要求很高，生产成本巨大，技术门槛相对较高（专业化），开发周期相对较长（相对传统制造业）。


EDA工具都有一套行之有效地参考flow，每家公司都会开发一些flow和工具，来提高员工的工作效率，标准化开发手段。那么怎样的flow才是一个好的flow呢？大家的意见都是不同的，我只是管中窥豹地讲下我认为的好flow是怎么样子的。
请看图（原创，如需引用请表明出处）：

                               
登录/注册后可看大图

• flow是最外层与用户交互的部分，接受用户的输入，给予用户输出结果
• flow与核心的工具没有关系，flow行驶的是管理和后勤之类的事情，而真正生产线上是生产汽车还是生产iphone，这对于flow来说没有差别
• flow中应该要包含项目管理和时间控制等等子模块，这些子模块本身可能也是一个比较复杂的过程
• 确定执行具体功能脚本的机制，尽可能降低维护成本

对于Tcl来做flow controller，以下两种方式的调用子功能的方法做个比较:
— proc 实现子功能

• 作用域不明确，需要不断切换，EDA工具的所有配置都是在global domain里的，proc封装之后经常会发生作用域不明确，给开发带来额外的负担
• 方便管理，责任明确
• 更新维护方便
• 复用性强

— eval 运行子功能模块

• 运行排错滞后，不能在source的时候就发现一些code上的基本错误
• 所有功能模块都是在global域内执行的，功能模块中使用到的变量的作用域被扩大
• 开发调试上的便利
• 可复用
• 使用wrapper的方式运行具体脚本，便于流程的建立

由于eval的第三条，我采用的是eval来运行具体的功能模块，相当于给具体的脚本加了一层wrapper，可以做到flow与具体功能脚本隔绝开来，能更好地对flow之外的过程进行详细的控制。
对于方便管理和责任明确，维护方便等优点，我自建了一套debug系统，自己建立数据联系，将脚本管理，维护方式，错误报告等统一起来。
而复用这个问题上，eval的确没有proc来得强，也不可能做到封装，而灵活性本来就是eval的优点，这个要有所取舍了。
我编写的这个flower cotrolloer有如下特性：

• 读取excel做为配置文件，实则是转换为ASICII文件后做为flow cotroller的配置文件；
• 每个子功能模块需要的信息都定义在配置文件中，包括维护者，各种特性，有flow cotroller读取并存储在变量里；
• 有自己的message system，定义多种message的级别；
• 输入信息的总体check，有不合理的return并给出解决办法；
• 每个子功能模块有tag机制，方便扩展后续功能；
• 子模块出错，自动发送mail给维护者，抄送当前用户并记录出错时的error message和所有相关变量的值
• 监控子模块的运行时间runtime
• flow run结束有mail提醒，mail中有概要的运行结果信息
• 最终结果以网页的形式发布
• 使用list来代替bool输入
• 适用于ICC/EDI并可以支持其他工具
• 预留了prerun和postrun的接口
• 各种模式切换的接口

这些事主要功能，还有很多贴心的小地方在用户的不断测试中在完善。
分享一个Tcl运行cmd set的wrapper ：整套cmd set包含exeCmdSet, msgCmdSet, cfgCmdSet三个命令和一个全局数组变量varCmdSet。

• 可接受数据输入
• 计算runtime
• mute消息
• 自定义array

?Download execmdset.proc

1. proc exeCmdSet {args} {
   
2. 
   
3.   global varCmdSet ;
   
4.   my_parse_proc_arguments -args $args alist ;
   
5.   ...
   
6. }
   
7. my_define_proc_arguments exeCmdSet -info "Evaluate tasks defined in -array, default is strCmdSet" \
   
8.   -define_args {
   
9.     {task     "Name of tasks" tasks list required}
   
10.     {-nomsg   "Boolean to control the stdout msg" "" boolean optional}
    
11.     {-array   "Array to exec" array string optional}
    
12.     {-runtime "Calculate the runtime" "" boolean optional}
    
13.     {-data    "Data store in varCmdSet" data list optional}
    
14.   }
    

复制代码

sjtusonic

写得好！

icfans3

回复 1# xoit


    你好，这个flow controller有哪些相关资料哈 以前没接触过类似的？？？

wjchuan

厉害，结构很清晰啊

梦想的东南

说的真心很好

icfbicfb

基本上和synopsis的lynx类似吧，

我觉得主要是tcl和perl的结合， eda工具里面都是tcl，包括复杂的eval，expect等，
图形化主要靠tk， 用户interface方面可以多靠perl扩展处理比较方便，
尤其是对文本，regex的处理

永不止步wl

能回答下我这个脚本是什么意思吗？set tmpfile tmpfile[pid] [expr int (rand()*10000)]谢谢啦

xoit

回复 7# 永不止步wl
set tmpfile tmpfile[pid] [expr int (rand()*10000)]

这个语句是不是有点问题，或者少了点什么连接的字符。

首先tcl会解析命令，pid和expr会被return出值，pid是当前tcl程序的一个process id，是一个比较唯一的值，防止文件冲突。
expr那句生成一个0~10000的随机整数。

连起来就是给tmpfile赋值，值和pid和随机数有关，但这个运行应该有错，set <var name> <value> 其中value只能是单值，多值要写成list形式。

xoit

回复 3# icfans3

最近在完善博文，时隔一年才来回复，这个flow controller是自己根据实际情况开发的，使用tcl语言。
和ICC/EDI/Olympus联系很紧密。

可参考我的blog， http://qfshare.com/?s=%E6%80%8E%E4%B9%88%E5%86%99%E5%87%BA%E5%A5%BD%E8%84%9A%E6%9C%AC

永不止步wl

回复 8# xoit
哦，谢谢你啦，会不会是数组呢？