《代码大全》解读（二）

《代码大全》解读（二）

 

其实今天我是很不爽的，早上跟同事一起到一个省级单位去看某行业软件演示（因众所周知的原因，恕我不能提起相关的信息）。看完演示，我真的是无语了，又是一个“优秀的政府项目”。自从上周看完了头两章，一直没有时间来静下心来看这本书。今天正好抽点时间看看，于是又有了这篇文字。

第三章《软件创建的先决条件》

书的头两章其实是形而上的东西居多，这一章在这本以“务虚”为主的书中算得上是比较“务实”的一章，而且我觉得应该算得上是核心的一章，之所以说它核心是因为在我们现在的工作中，它所讲述的“先决条件”，我们根本没有引起重视，或者当我们尝尽了苦头却不知道做错了什么。

为什么我们不喜欢或者是不习惯做编码前期准备工作（我觉得这样意译更合中国语法逻辑），无非有两种情况：

1、               有些程序员渴望立刻编码，因为写出一行代码，并且正确地运行起来成就感很强。嘿嘿，好象有很多人是有这样的想法的。

2、               管理人员不理解在准备工作上花时间的作用。

作者列出了很多故事以及数据只是告诉我们

1、               让我们自已了解编码准备工作的重要性

2、               让我们的老板了解重要性，或者不理他，还是做我们的准备工作，或者是“优秀的程序员是很少的，可以找到更好的工作，干吗呆在一个不开明的公司做事呢”。

然后作者根据第一章所提出的软件工程创建流程分别阐述以下几项准备工作（跟译文有些差别）

一、准备工作之问题描述：

使用用户的“方言”来描述要解决的问题是什么？而不涉及到具体的解决方案。我之所以用方言二字是因为我觉得其实因为问题的描述更多地是通过用户的行业术语来描述的，它也是能与终端用户进行有效沟通的途径。所以我们的程序员不光要懂程序语言，其实也要基本了解你所服务对象的行业术语。要不然真是鸡同鸭讲。

二、准备工作之需求分析：

（1）             为什么要有正式的需求

（2）             稳定需求的神话

呵呵，经常在CSDN上看到有人发贴，大骂用户变更需求。书里会告诉你：IBM都认为需求一般来说有25%会有变化。

（3）            如何应对需求变化

 具体是如何见书吧

顺便说一说建筑行业的需求变化，在建筑行业里叫“变更”，常常有两种情况引起一种是在原设计时因测量不准，比如地下水位、软地基等等。还有一种是用户在施工期间提出新的变化。第一种主要看当时合同是如何签的，看由谁负责。第二种一般来说一般施工方会给出变更的施工预算，然后提交给用户，用户觉得行就做，要么就会放弃变更的想法。很符合作者提出的“让每个人知道由于变化需求所付出的代价”。不管在什么行业“时间”与“成本”永远是有效的。软件行业也不例外。这一点我也觉得很多程序员做久了，特别要注意，因为我们总是喜欢优化，不断地优化，当然这不是不好，只是在做项目时一定要考虑到项目的进度。

三、准备工作之总体设计（译文为结构设计）

1、          程序的组织形式

    让人能够清楚地了解程序的整个结构。并了解所做的每个模块的作用是什么。就象建筑施工图的第一张总是施工平面图、然后是立面图、剖面图、然后才会是楼层平面图、楼道图、钢筋表、构件图等等。

2、          变动的策略

3、          购买软件

其实作者的意思是利用成熟的软件或是模块。最近CSDN上有一篇贴子是说MS的Enterprise Library 应不应使用的，众说纷纭。我也不再想多说什么，举个很简单的例子。在建筑规范上各地不同，目前在南方大都使用一种规范叫《中南标》，它的设计就某栋建筑来说绝不会是最好的设计，但是为什么它能广泛使用呢？

4、          主要的数据结构以及算法

5、          错误处理

统一的错误处理方式（指面对用户时）

6、          坚固性

就是容错、安全系数（又借用了建筑行业的说法）

 

四、准备工作之编程语言的选择和规范

任何语言都有其优点及缺点，所以我们使用什么语言首要第一条是项目需要什么语言来完成最好？第二是程序员熟悉什么语言。

然后是规范。我并不是很了解其他人在商业开发项目中的编写规范做得如何，但是网上，特别是中国人自已贴的代码，很多真是不敢恭维。这个我也不想多说，大家应该都有体会，特别是你在维护前人的代码时。

 

作者的小结总有点象箴言，摘录两条作为此篇文字的结束。

1、开发高质量的软件，必须从始至终都重视质量。从开始强调质量比在最后强调质量要重要得多，也省钱得多。

2、程序员的重要工作之一是向老板宣传准备工作的重要性。