代码大全2（3）

一下子把第三章也看完了，只觉得经典就是经典啊，虽然软件工程课上也是讲过的，但那时没想这么多呀，，没有实际的工作经验，总觉得软件就是写代码，，总想着教人写代码才是软件，但是后来去实习了才知道软件远远不止这些，，后来看了些书……

第三章：三思而后行：前期准备（Measure Twice，Cut Once：Upstream Prerequisites）

这一章就是在说构建前的准备工作，并且这准备工作是非常重要的！确实，整个开发过程中的每一步都是很重要的！

前期准备包括三件事：问题定义、需求分析、系统架构。

前期准备的重要性：项目前期准备工作可以决定这个项目的成败！说到这里就想到了我们公司目前三部正在做的一个系统，赶着要上线了可是还有很多的问题，听说不知被客户骂了多少次，同事好几天都没见他回来了，说是在客户那边附近宾馆住下连夜加班做了。我虽然不太清楚具体情况，但我总觉得是需求没做好……

“准备工作的中心目标就是降低风险，一个好的项目规划者能够尽可能早的将主要的风险清除掉。”

前期准备不足的原因：

1. 前期准备人员能力不够
2. 程序员不能够抵抗“尽快开始编码”的欲望，当时的我不就是这样的么？
3. 管理者不明白前期准备工作的重要性，要知道“软件开发不仅仅是写代码”

这让我想起了一件事，初中历史课本上谈到当时建三峡大坝（985项目），说那些专家经过半年的讨论论证才同意这个方案，当时我是把那些人骂了个够，我想不就是建个大坝嘛，需要半年的讨论吗？这些人办事效率就是低！可见我当时不明白需求调研的重要性。。。就算是现在的很多事我也不一定明白，那结果必然就如同当时初中生的我了……可见换位思考的重要性，很多我们不理解的事我们也不要立马去反对，而是应该思考、理解、包容。就算我们想要反对，那也应该先把问题弄清楚了，从理性的角度来反驳，而不是毫无意义的喷口水，这就是所谓的“没有调查就没有发言权”吧。从这些事中就可看出一个人的风度和气质、性格等……朋友相交就是平时的这些小事在影响着彼此的关系，所谓合得来合不来就是看彼此是否有共同的……

呃…扯远了

技术雇员的一部分工作就是培训周围的非技术员工，讲解开发过程。应对“尚未觉悟的管理者和老板”。

从多个方面来说：

1. 诉诸逻辑：大项目有大计划，小项目有小计划，制定计划是必须的，不然走错了进了死胡同；
2. 诉诸类比：软件开发就像建房子，建房子前先要准备好设计图（要包含所有信息），不然就会发生推到重建的事情，又记起一件事，大学时，一条新修的公路刚建好一两个月，其中很大一段又围起来挖了来修排水工程，，我当时就在想这些人干什么吃的，难道新建马路时没想到要建下水管道的吗？不仅多花了钱，还封路带来了不方便。由此可见一个好的城市管理者是多么重要！！一个好的领导是多么重要啊！！呵呵~刚才还说不理解就不要喷别人，实在没忍住！！
3. 诉诸数据：告诉老板如果不做好需求分析，后期出问题了修复的费用与发现的时间的关系，告诉他，越晚发现问题，改动费用越高。引用两幅本书的图片来说明

最好采用迭代开发，，说了那么多迭代，就像使用“隐喻”这个词一样，总是让人心里有阴影，虽然都在那么说，但是就是不给个准备通俗易懂的说法，我理解迭代就是：不断重复循环。循环的过程中一步步的改善，做的更好。

拿到项目了，不要一头就往下做，最后做完了给客户一看，“No，这不是我想要的",   你就等着哭吧~应该做一点就给他看一下，确认完后再继续，其间有问题的立即改，，，这也是所谓的技巧，领导安排了任务，做的时候要随时汇报并确认，不能等做完了，领导说做错了，不断汇报会让他又准备接受最后的结果，即使没完成或者失败了。

正式开始本章的三个问题：

一、问题定义

产品设想、设想陈述、任务描述、产品定义……都一个意思，这里就叫问题定义好了。

“问题定义”只说要做什么，不涉及任何可能的解决方案，问题定义因该用客户的语言来书写，从客户的角度来描述问题，不要一开始就想着编程，因为有可能客户所说的问题不需要用代码来解决，而我们却把它想多了。

二、需求分析

需求开发、需求描述、需求定义、软件需求、规格书、功能规格书……也都一个意思。就是说这个项目要有什么样的功能。

需求绝壁是会变的，程序员最想要的就是《最终需求——永远不变版本》，但这是不可能的，所以一开始就要和客户沟通好，充分详细的描述他们的需求。如果需求要变怎么办：

1. 确保每一个人都知道需求变更的代价！！！！！！！一定要让每一个人知道！客户随时会想到一个新功能，然后让你去改，作者称之为“新功能中毒症患者”，如何应对：对他说：“嗯，这主意不错，但是它不是需求文档里的东西，我会整理出一份修订过的进度表和成本估算表，然后你再决定是否修改，可以过一阵子再说”。呵呵，只要跟他说新需求会加长时间和费用就可以了。其实没有什么不可以的，无非就是加钱嘛，只要给的多就可以改，重新来过都可以，关键是钱要给到位！
2. 建立一套变更控制流程，就是所谓的需求池，有需求变更，可以！扔到需求池中吧，按顺序来一个一个的改！
3. 使用能适应变更的开法方法：演进交付：分阶段交付。
4. 放弃这个项目：实在是更改太变态、太多的话，，要不是没办法了谁会这么做呢！实在是天愤人怨啊。
5. 考虑商业价值：很有特色的功能要是不能带来价值，就得考虑是否应该现实了。

三、系统架构

高层设计、顶层设计、系统架构……同义。

架构的典型组成：

1. 程序组织：首先义慨括的形式对有关系统做一个综述，就是说这是用来干嘛的，然后定义程序的主要构造块（模块），模块有的简单有的复杂，有的只是一个类，有的需要多个类组成一个子系统，都是用来实现各自的功能，比如显示界面、与用户交互、访问数据、封装业务规则……每条功能需求都应该至少有一个模块来实现它，构造快的设计原则：各自负责一个区域的事情，对其他构造快的情况知道的越少越好，对自己要实现的功能越精越好，将涉及的信息局限于各个构造快之内。明确定义每个构造快的通信规则（输入、输出、数据格式……）
2. 主要的类：描述那些主要的类的责任，类之间的交互。如果系统很大，还应该描述如何将这些类组织成一个子系统。80/20法则：对于构成系统80%的行为的20%的类进行描述。
3. 数据设计：主要文件和数据表结构，数据应该只由一个子系统或类来访问。
4. 业务规则：描述业务规则对系统设计的影响。
5. 用户界面设计：这应该在需求分析阶段就详细说明，如果没有，就应该在架构时定义web页面格式、GUI等主要元素。
6. 资源管理：例如数据库连接、线程、进程……
7. 安全性：处理缓冲区、内存、处理用户输入的数据、cookies、配置文件、加密规则等……
8. 性能：时间复杂度、空间复杂度、速度、内存
9. 可扩展性：用户数量、服务器数量、网络节点数量、数据库……等的增长
10. 互用性：与其他软件或硬件交互
11. 国际化/本地化：Internationalization、Localization，编码、字符资源（不要硬编码）
12. 输入输出：
13. 错误处理：约定好规则，比如是由某个（组）类专门来检查数据还是各个类负责自己的数据有效性 
14. 容错性：发生错误时怎么办？
15. 架构是否可行？
16. 过度工程：不要死板硬套，大项目有大架构，小项目要灵活变通，要全局考虑问题，只有符合国情的才是好的，要走有中国特色的社会主义
17. “买”还是“造”：有些控件或功能是自己编写还是买，考虑时间、人力、客户需求等的成本
18. 复用：对已存在的软件加工，使构造快各自独立就是为了能复用吧，不然每次都写新的程序也太麻烦了，构造快负责的业务单一就能很方便的抽取出来用到其他软件中来
19. 架构的总体质量：《人月神话》，架构与编程语言无关，不用过度描述，也不要描述太少。架构要指明风险区，并说明为什么和已经采取了哪些方案以使风险最小化。架构要从多个视角描述，类似房屋的不同设计图：正视图、平面图、结构图、水电管道图等
20. 架构要让人容易理解！！！

书上说了架构的很多，但是目前最能让我考虑到的恐怕只有前面几条了：模块、类、数据结构。

前期准备时间：20%~30%

一旦开始，再改，成本巨大！早确定、少改动。宁愿多花时间来确认需求！！！