##前期准备
##三思而后行
###1. 前期准备的重要性
- 测试是不可能检测出诸如”制造了一个错误的产品”,或者”使用错误的方法制造正确的产品”之类
的缺陷的。这样的缺陷必须在测试之前解决更确切的说是在构建活动之前。 你可能会认为,所有的专业程序员都知道准备工作的重要性,并且在跃入构建活动之前会检查确认
所有先决条件都已经满足了,很不幸,这不是事实。- 然而那最近实现的一个模块来说: 这确实不是事实，由于诸多因素,比如个人经验和能力限制。
看不到构建之前的设计缺陷，导致构建过程中问题不断,构建活动推翻了前期的架构设计。
应为架构中预期的先决条件，在构建中才发现,这实现起来代价很大。
(服务器-负载均衡实现,就犯了这样的错误,先决条件没有确认,在构建构成中发现实现代价过大) - 做前期准备的活动的开发人员并不具备完成这一任务的专业技能。项目规划,创作引入注入的商业案例
分析出全面而准确的需求,创建高质量的架构等活动都需要一定的技能,这些技能不能轻而易举的获得
的,但是绝大多数的开发人员都没有结构果针对这一些活动的训练。当开发人员不知道如何进行这些前期
工作的时候,建议”做更多的前期工作”就完全没有用。如果不能首先把这项工作做好,那么做再多也没有意义。 - 有一些程序员确实知道如何进行前期工作,但是他们并没有做,因为他们不能抵抗”尽快开始编码”的欲望
- 程序员不做准备工作的最后一个原因,管理者们对那些”花时间进行构建活动的前期准备的程序员”的冷漠已经到了
人神共愤的程度。 - 如果遇到那种命令你立即写代码的管理者.
- 第一种简单的说遵命(这没什么可怕的,老手当然知道他在说什么)这种回答很糟糕,你可以有几种跟好的替代方案
首先,你可以断然拒绝以这种无效的命令,加入你和老板的关系不错,而且你银行卡的钱数也支持你这么做的话,
祝你好运。 - 第二个不太靠的住的方案是假装在写代码,而事实上不是,在你的桌角上放一份旧的程序代码清单,然后投入需求
和架构当中去,同时不用理会老板同不同意,你将能更快的完成项目,并得到更高的质量。有些人会觉得这种方法不
合乎情理,但是从你老板的角度看,无知是福。 - 第三种方法是,你可以教育你的老板,告诉他技术项目的微妙之处,这是一个好办法,因为它能增加世界上脱盲老板的
人数。 - 最后一个方案是, 你可以另外找一份工作,虽然经济景气程度时高时低,但是优秀的程序员永远是紧缺的.人生苦短,当有
大量更好的选择摆在你面前的时候,在一个荒蛮的软件企业中工作是不明智的。
- 第一种简单的说遵命(这没什么可怕的,老手当然知道他在说什么)这种回答很糟糕,你可以有几种跟好的替代方案
- 然而那最近实现的一个模块来说: 这确实不是事实，由于诸多因素,比如个人经验和能力限制。
###然而,为什么抄书呢?
###2. 辨明你所从事的软件的类型
- 商业系统
- 使命攸关的系统
- 性命攸关的嵌入式系统
###3. 问题定义的先决条件
在开始构建之前,首先要满足的一项先决条件是,对这个系统要解决的问题做一个清楚的陈述.
这有时称为”产品设想”,设想陈述,任务陈述,产品定义,问题定义.问题定义,只定义了问题是什么,而不涉及任何可能的解决方案,听起来应该像是一个问题.
好的问题定义看上去像是这样:我们跟不上Gigatron的订单了
一个糟糕的问题定义可能是这样: 我们需要优化数据自动采集系统,使之跟上Gigatron的订单
###4. 需求的先决条件
- 需求分析是对所定义的问题的深入调查
- “需求”详细描述软件系统应该做什么,这是达成解决方案的第一步。
- 为什么需要明确的需求 Why Have Official Requirements
明确的需求有助于确保是用户(而不是程序员)驾驭系统的功能,如果需求明确,那么用户可以自行评审,
并进行核准。否则,程序员就常常会在编码期间自行决定需求,明确的需求免得你去猜测用户想要的是什么。
明确额的需求还有助于避免争论。 - 如果没有好的需求,你可能对问题有总体的把握,但却没有击中问题的特定方面。
- 稳定的需求是软件开发的圣杯。这表示”一旦客户接受了一份需求文档,就再也不做更改”是一个美好的愿景。
开发工程能够帮助客户更好的理解自己的需求,这是需求变更的主要来源,计划严格按照需求行事,实际上就是计划不对客户的需求做出回应。 - 在构建期间处理需求变更
- 确保每一个人都知道需求变更的代价
- 建立一套变更控制程序
- 使用能适应变更的开发方法
- 放弃这个项目
- 注意项目的商业案例
###5. 架构的先决条件
- 软件架构(software architecture)是软件设计的高层部分,是用于支撑更细节的设计的框架。
- 架构的质量决定了系统的”概念完整性”,后者继而决定了系统的最终质量.
- 架构为程序员提供指引,它将工作分为几个部分,使多个开发团队可以独立工作.
- 好的架构是构建活动变得更加容易,糟糕的架构则使构建活动几乎寸步难行。
- ####架构的典型组成部分
- 程序组织 Program Organization
- 系统架构首先一概括的形式对有关系统做一个综述。
- 在架构中,你应该能发现对那些曾经考虑过的最终组织结构的替代方案的记述,找到之所以选用
最终的组织结构,而不用其他替代方案的理由。 - 架构应该定义程序的主要构造块(building blocks)。根据程序规模不同,各个构造块可能是单个类,也可能是由
单个类组成的一个子系统。每个构造块无论是一个类还是一个协同工作的类和子程序,它们共同实现一种高层功能,
诸如与用户交互,显示Web页面,解释命令,封装业务规则,访问数据,等等~~~ - 应该明确定义个个构造块的责任。每个构造块应该负责一个区域的事情,并对其他构造块负责的区域知道的越少越好。
- 应该明确定义各个构造块的通信规则
- 主要的类 Major Classes
架构应该详细定义所用的主要的类 - 数据设计 Data Design
架构应该描述所用到的主要文件和数据表的设计
数据通常只应该由一个子系统或一个类直接访问
架构应该详细定义所有数据库的高层组织结构和内容。 - 业务规则 Business Rules
- 用户界面设计 User Interface Design
用户界面常常在需求阶段进行详细说明。如果没有就应该在软件架构中进行详细说明
架构应该模块化,以便替换为新用户界面时不影响业务规则和程序的输出部分 - 资源管理 Resource Management
- 安全性 Security
架构应该描述实现设计层面和代码层面的安全性的方法。 - 性能 Performance
- 可伸缩性 Scalability
是指系统增长满足未来需求的能力 - 互用性 Interoperability
- 国际化/本地化 Internationalization/Localization
- 输入输出 Input/Output
- 错误处理 Error Processing
错误处理已被证实为现代计算机科学中最棘手的问题之一。 - 容错性 Fault Tolerance
- 架构的可行性 Architectural Feasibility
架构应该论证系统的技术可行性,任何方面不可行都会导致项目无法实施 - 过度工程 Overengineering
- 关于”买”还是”造”的决策
- 关于复用的决策
- 变更策略
- 架构总体质量
- 程序组织 Program Organization
###6. 花费在前期准备上的时间长度
引用书籍:
###1. CODE COMPLETE 代码大全