1.4 起草: 最小的方法
【程序员和作家的比较】
. 相同点
思想使用文本形式表达, 表达的结构能确定产品的成功与否
. 不同点
作家开发一般是独立行为, 涉及到时间限制需要非常经济的使用时间, 抛弃不能带来重要结果的方法
1.4.1 前提
【剧本式设计方法的两个重要前提或者说是某些历史教训和新的需求使然】
. 防护: 和过程语言不同, C++具备很多防护, 程序员可以建立自己的防护以创建的程序破坏它的结构, 无论是在创建期间还是在维护期间
. 辨证: 无论分析的如何透彻, 面对不断发展的事务, 即便在开发后期有些事务的关系还可能没有被发现. 快速分析过程和设计过程实现目标系统的测试是很重要的
【表示方法】
. 语言是表达事物的最佳方法, 鉴于人类自然语言的发展历史, 绝对不要在当前阶段试图使用符号系统表达系统设计, 因为后者在重复性, 扩展性方面是远不及前者的, 很可能增加误导性, 因为它过于明确和限制了.
. 好的描述工具应道建立代码和文档的联系
. 使用熟悉的工具和思维模式非常重要
1.4.2 高概念
【描述和必要性】
. 建立的系统无论如何复杂, 都有一个基本的目的, 它服务于哪个行业和应该满足什么基本需要
. 高概念对于项目定调,非常重要.
. 高概念的描述从一开始无需非常准确
1.4.3 论述( treatment )
. 剧本( 系统描述 )的论述即故事概要, 即高概念的外层
. 计算机系统发展高概念和论述的最好途径就是组成一个小组, 该小组具备一个写能力的辅助工具.
. 在集体讨论中能够提出建立, 辅助工具负责表达各自的思想, 不给出评价, 仅仅是力图保持这些思想的清楚和通畅
* 论述变成了出手对象发现的起点和设计的第一个雏形, 也能够在拥有辅助工具的小组内完成
1.4.4 结构化
对于系统, 结构是关键.
【组织系统】
. 第一层: "高概念", "论述", "对象", "设计"的起始点
. 第二层: 为第一层发现的对象
. 第三层: 增加的对象接口
. 使用描述性语言, 不使用图片, 会议讨论过程不受创作该描述的速度限制
【特征: 发现初始化对象】
. 论述: 名次 + 动词
名词 ==> 类
动词 ==> 类的方法或者系统设计的过程
√这是一个不断反复的过程, 不指望程序一下子完全理解问题
. 如果一个类是从另一个类继承过来, 则其第二层子段应当尽可能靠近地放在其基类的后面, 它的子段名称应当显示这个继承关系
. Occam's Razor方法: 选择一个最简单的进行类构造, 因为向一个类添加元素非常容易, 但是随着时间的推移丢掉元素就困难了
【情节: 初始化系统设计】
. 情节: 系统活动
. 根据小组成员提出的可能的系统活动进行分别记录, 不要求将它们即可建立和系统的联系
. 参与人员面可以很广, 设计人员, 市场人员, 管理人员都可以出席, 目的在于"通讯" -- 对于整个系统的共识, 也可以提高大家的积极性.
. 可以为每一个子情节归纳出基本的条件过渡描述, 将来这些就成为了最初的代码实现目标
1.4.5 开发
从粗设计到编译代码的最初转换, 编译代码可以证明或者反证设计. 这是一个不断反复的过程. 通过对于代码中的结构或者有关文字的改变重新产生文档. 设计文档成为项目进展的报告工具.
【初始翻译】
. 文档第一层, 对象描述
- 根据"对象"产生文件头, 即系统程序头文件, 每一个对象都是通过一些类型实现功能的.
- 将文档分割成为几个部分, 在每一个部分上工作
. 文档第二层, 类型抽象
- 自动产生类声明
- 相应的次层描述获得成员函数和变量声明
. 文档第四层, 情节
- 每一个子情节产生一个独立全局函数, 供入口函数main()使用, 或者是main的一段.
【代码产生】
. 为"对象"段的每一个类产生独立的类声明头文件
. 为每一个子情节产生系统过程声明头文件
. 使用概要标题标记每一个子情节, 类和方法, 诸如: file://#[1]...
. 接口和情节在此时应该是可以编译但是不可连接的, 因为没有代码实现, 仅仅用于语法检查
. 适当补充文档, 如果类或者子情节发现需要变化
1.4.6 重写
【目的】
. 完善程序, 更新文档
【时机】
. 因为软件开发是预约服务, 不可避免地需要进行版本的控制发布
1.4.7 逻辑
【责任】
. 经常性的整理和维护设计文档是项目领导者或管理者的责任
. 项目组或者个人负责对于文档的一小部分的维护( 代码和注释 )
〖个人理解〗
这一小节可以主要提出了两个观点, 语言的作用和剧本方式.
其实自从开始从事编程以来我个人就有一种使用图形或者图片语言的方式表达的倾向, 看来我是错了, 我当初就是因为语言的表意的不明确性而希望使用更加直观和形式化的语言描述系统. 显然我忽略了一点就是人的认识规律和对于事物认知的局限性, 语言的魅力其实就是阅读的因人而异, 不断地认知和修改才是集体认知系统的正确过程, 简单的图示, 往往容易给阅读者一种先入为主和依赖性.
系统设计就是编写剧本, 我以往对于系统设计过于程式化, 其实这也是过程化设计的一个通病, 总是希望在完整了解系统需求以后闭门造车, 显然犯了非辨证的毛病.
