一下子把第三章也看完了,只觉得经典就是经典啊,虽然软件工程课上也是讲过的,但那时没想这么多呀,,没有实际的工作经验,总觉得软件就是写代码,,总想着教人写代码才是软件,但是后来去实习了才知道软件远远不止这些,,后来看了些书……
第三章:三思而后行:前期准备(Measure Twice,Cut Once:Upstream Prerequisites)
这一章就是在说构建前的准备工作,并且这准备工作是非常重要的!确实,整个开发过程中的每一步都是很重要的!
前期准备包括三件事:问题定义、需求分析、系统架构。
前期准备的重要性:项目前期准备工作可以决定这个项目的成败!说到这里就想到了我们公司目前三部正在做的一个系统,赶着要上线了可是还有很多的问题,听说不知被客户骂了多少次,同事好几天都没见他回来了,说是在客户那边附近宾馆住下连夜加班做了。我虽然不太清楚具体情况,但我总觉得是需求没做好……
“准备工作的中心目标就是降低风险,一个好的项目规划者能够尽可能早的将主要的风险清除掉。”
前期准备不足的原因:
- 前期准备人员能力不够
- 程序员不能够抵抗“尽快开始编码”的欲望,当时的我不就是这样的么?
- 管理者不明白前期准备工作的重要性,要知道“软件开发不仅仅是写代码”
这让我想起了一件事,初中历史课本上谈到当时建三峡大坝(985项目),说那些专家经过半年的讨论论证才同意这个方案,当时我是把那些人骂了个够,我想不就是建个大坝嘛,需要半年的讨论吗?这些人办事效率就是低!可见我当时不明白需求调研的重要性。。。就算是现在的很多事我也不一定明白,那结果必然就如同当时初中生的我了……可见换位思考的重要性,很多我们不理解的事我们也不要立马去反对,而是应该思考、理解、包容。就算我们想要反对,那也应该先把问题弄清楚了,从理性的角度来反驳,而不是毫无意义的喷口水,这就是所谓的“没有调查就没有发言权”吧。从这些事中就可看出一个人的风度和气质、性格等……朋友相交就是平时的这些小事在影响着彼此的关系,所谓合得来合不来就是看彼此是否有共同的……
呃…扯远了
技术雇员的一部分工作就是培训周围的非技术员工,讲解开发过程。应对“尚未觉悟的管理者和老板”。
从多个方面来说:
- 诉诸逻辑:大项目有大计划,小项目有小计划,制定计划是必须的,不然走错了进了死胡同;
- 诉诸类比:软件开发就像建房子,建房子前先要准备好设计图(要包含所有信息),不然就会发生推到重建的事情,又记起一件事,大学时,一条新修的公路刚建好一两个月,其中很大一段又围起来挖了来修排水工程,,我当时就在想这些人干什么吃的,难道新建马路时没想到要建下水管道的吗?不仅多花了钱,还封路带来了不方便。由此可见一个好的城市管理者是多么重要!!一个好的领导是多么重要啊!!呵呵~刚才还说不理解就不要喷别人,实在没忍住!!
- 诉诸数据:告诉老板如果不做好需求分析,后期出问题了修复的费用与发现的时间的关系,告诉他,越晚发现问题,改动费用越高。引用两幅本书的图片来说明
最好采用迭代开发,,说了那么多迭代,就像使用“隐喻”这个词一样,总是让人心里有阴影,虽然都在那么说,但是就是不给个准备通俗易懂的说法,我理解迭代就是:不断重复循环。循环的过程中一步步的改善,做的更好。
拿到项目了,不要一头就往下做,最后做完了给客户一看,“No,这不是我想要的",
你就等着哭吧~应该做一点就给他看一下,确认完后再继续,其间有问题的立即改,,,这也是所谓的技巧,领导安排了任务,做的时候要随时汇报并确认,不能等做完了,领导说做错了,不断汇报会让他又准备接受最后的结果,即使没完成或者失败了。
![发火](http://static.blog.csdn.net/xheditor/xheditor_emot/default/angry.gif)
正式开始本章的三个问题:
一、问题定义
产品设想、设想陈述、任务描述、产品定义……都一个意思,这里就叫问题定义好了。
“问题定义”只说要做什么,不涉及任何可能的解决方案,问题定义因该用客户的语言来书写,从客户的角度来描述问题,不要一开始就想着编程,因为有可能客户所说的问题不需要用代码来解决,而我们却把它想多了。
二、需求分析
需求开发、需求描述、需求定义、软件需求、规格书、功能规格书……也都一个意思。就是说这个项目要有什么样的功能。
需求绝壁是会变的,程序员最想要的就是《最终需求——永远不变版本》,但这是不可能的,所以一开始就要和客户沟通好,充分详细的描述他们的需求。如果需求要变怎么办:
- 确保每一个人都知道需求变更的代价!!!!!!!一定要让每一个人知道!客户随时会想到一个新功能,然后让你去改,作者称之为“新功能中毒症患者”,如何应对:对他说:“嗯,这主意不错,但是它不是需求文档里的东西,我会整理出一份修订过的进度表和成本估算表,然后你再决定是否修改,可以过一阵子再说”。呵呵,只要跟他说新需求会加长时间和费用就可以了。其实没有什么不可以的,无非就是加钱嘛,只要给的多就可以改,重新来过都可以,关键是钱要给到位!
- 建立一套变更控制流程,就是所谓的需求池,有需求变更,可以!扔到需求池中吧,按顺序来一个一个的改!
- 使用能适应变更的开法方法:演进交付:分阶段交付。
- 放弃这个项目:实在是更改太变态、太多的话,,要不是没办法了谁会这么做呢!实在是天愤人怨啊。
- 考虑商业价值:很有特色的功能要是不能带来价值,就得考虑是否应该现实了。
三、系统架构
高层设计、顶层设计、系统架构……同义。
架构的典型组成:
- 程序组织:首先义慨括的形式对有关系统做一个综述,就是说这是用来干嘛的,然后定义程序的主要构造块(模块),模块有的简单有的复杂,有的只是一个类,有的需要多个类组成一个子系统,都是用来实现各自的功能,比如显示界面、与用户交互、访问数据、封装业务规则……每条功能需求都应该至少有一个模块来实现它,构造快的设计原则:各自负责一个区域的事情,对其他构造快的情况知道的越少越好,对自己要实现的功能越精越好,将涉及的信息局限于各个构造快之内。明确定义每个构造快的通信规则(输入、输出、数据格式……)
- 主要的类:描述那些主要的类的责任,类之间的交互。如果系统很大,还应该描述如何将这些类组织成一个子系统。80/20法则:对于构成系统80%的行为的20%的类进行描述。
- 数据设计:主要文件和数据表结构,数据应该只由一个子系统或类来访问。
- 业务规则:描述业务规则对系统设计的影响。
- 用户界面设计:这应该在需求分析阶段就详细说明,如果没有,就应该在架构时定义web页面格式、GUI等主要元素。
- 资源管理:例如数据库连接、线程、进程……
- 安全性:处理缓冲区、内存、处理用户输入的数据、cookies、配置文件、加密规则等……
- 性能:时间复杂度、空间复杂度、速度、内存
- 可扩展性:用户数量、服务器数量、网络节点数量、数据库……等的增长
- 互用性:与其他软件或硬件交互
- 国际化/本地化:Internationalization、Localization,编码、字符资源(不要硬编码)
- 输入输出:
- 错误处理:约定好规则,比如是由某个(组)类专门来检查数据还是各个类负责自己的数据有效性
- 容错性:发生错误时怎么办?
- 架构是否可行?
- 过度工程:不要死板硬套,大项目有大架构,小项目要灵活变通,要全局考虑问题,只有符合国情的才是好的,要走有中国特色的社会主义
- “买”还是“造”:有些控件或功能是自己编写还是买,考虑时间、人力、客户需求等的成本
- 复用:对已存在的软件加工,使构造快各自独立就是为了能复用吧,不然每次都写新的程序也太麻烦了,构造快负责的业务单一就能很方便的抽取出来用到其他软件中来
- 架构的总体质量:《人月神话》,架构与编程语言无关,不用过度描述,也不要描述太少。架构要指明风险区,并说明为什么和已经采取了哪些方案以使风险最小化。架构要从多个视角描述,类似房屋的不同设计图:正视图、平面图、结构图、水电管道图等
- 架构要让人容易理解!!!
书上说了架构的很多,但是目前最能让我考虑到的恐怕只有前面几条了:模块、类、数据结构。
前期准备时间:20%~30%
一旦开始,再改,成本巨大!早确定、少改动。宁愿多花时间来确认需求!!!