《代码大全》笔记

举报
云端小宅女 发表于 2021/07/26 15:36:33 2021/07/26
【摘要】 (01)程序员处于软件开发食物链的最后一环。结构设计吃掉需求分析;详细设计者以结构设计者为食,而他自己又成为编码者的食物。(02)问题定义只描述要解决的问题是什么,根本不涉及解决方法。它应该是一个简短的说明,听起来像一个问题。比如“我们无法跟上指令系统”听起来像一个问题,也是一个好的问题定义。而“我们需要优化数据入口系统以便跟上指令系统”则是一个糟糕的问题定义,它听起来不像是个问题而更像是个...

(01)程序员处于软件开发食物链的最后一环。结构设计吃掉需求分析;详细设计者以结构设计者为食,而他自己又成为编码者的食物。

(02)问题定义只描述要解决的问题是什么,根本不涉及解决方法。它应该是一个简短的说明,听起来像一个问题。
比如“我们无法跟上指令系统”听起来像一个问题,也是一个好的问题定义。而“我们需要优化数据入口系统以便跟上指令系统”则是一个糟糕的问题定义,它听起来不像是个问题而更像是个解决方案。

(03)需求详细描述了一个软件系统需要解决的问题,这是找到问题答案的第一步。这项活动也被称作“需求分析”“需求定义”等。

(04)明确的需求可以保证是由用户而不是程序员决定系统的功能。如果需求是很清楚的,那么用户可以对其进行评定,并确认自己是否同意。如果需求不很清楚,那么程序员在编程过程中就不得不自己决定系统功能,明确的需求防止对用户需求进行猜测。

(05)用户对自己想要的东西,也是随着项目的进行而越来越清楚的,这也是需求变动的主要原因。 一个从不变更需求的计划,事实上是一个对用户的需求不予理睬的计划

(06)软件结构设计是较高级意义上的软件设计,它是支持详细设计的框架。结构也被称为“系统结构”、“设计”、“高水平设计”或者“顶层设计”。一般说来,结构体系往往在一个被称为“结构定义”或者“顶层设计”的单一文件中进行描述。

(07)过程内聚性(不可取)。当子程序中的操作是按某一特定顺序进行的,就是过程内聚性。与顺序内聚性不同,过程内聚性中的顺序操作使用的并不是相同数据。比如,如果用户想按一定的顺序打印报告,而所拥有的子程序是用于打印销售收入、开支、雇员电话表的。那给这个子程序命名是非常困难的,而模棱两可的名字往往代表着某种警告。

(08)逻辑内聚性(不可取)。当一个子程序中同时含有几个操作,而其中一个操作又被传进来的控制标志所选择时,就产生了逻辑内聚性。之所以称之为逻辑内聚性,是因为这些操作仅仅是因为控制流,或者说“逻辑”的原因才联系到一起的,它们都被包括在一个很大的 if 或者 case 语句中, 它们之间并没有任何其它逻辑上的联系。 类似的子程序有 ComputeAll(),EditAll(),PrintAll()等等。但是,如果一个逻辑内聚性的子程序代码都是一系列 if 和 case 语句,并且调用其它子程序, 那么这是允许的。在这种情况下,如果程序的唯一功能是调度命令,而它本身并不进行任何处理,那么这可以说是一个不错的设计。对这种子程序的专业叫法是“事物处理中心”,事物处理中心往往被用作基础环境下的事件处理,比如,Apple Macintosh 和 Microsoft Windows。

(09)功能内聚性(可取)。比如计算雇员年龄并给出生日的子程序就是功能内聚性的,因为它只完 成一项工作,而且完成得很好。

(10)顺序内聚性(可取)。假设有一个按给出的生日计算雇员年龄、退休时间的子程序,如果它是利用所计算的年龄来确定雇员将要退休的时间,那么它就具有顺序内聚性。而如果它是分别计算年龄和退休时间的,但使用相同生日数据,那它就只具有通讯内聚性(可取)。

(11)过程内聚性(可取)。假设有一个子程序,它产生读取雇员的名字,然后是地址,最后是它的电话号码。这种顺序之所以重要,仅仅是因为它符合用户的需求,用户希望按这种顺序进行屏幕输入。另外一个子程序将读取关于雇员的其它信息。这个子程序是过程内聚性,因为是由一个特定顺序而不是其它任何原因,把这些操作组合在一起的。


(12)“软件设计”一词的意思是指,把一个计算机程序的定义转变成可以运行程序的设计方法。 设计是联系要求定义和编码与调试的活动的桥梁。 它是一个启发的过程而不是一个确定的过程,需要创造性和深刻的理解力。设计活动的绝大部分活动都是针对当前某特定项目进行的。

(13)设计的层次------层次 1:划分成子系统;层次 2:划分成模块;层次 3:划分成子程序;层次 4:子程序内部的设计

(14) 从事结构化设计的人与从事面向对象设计的人会发现他们进行交流非常困难,原因是他们没有意识到是在不同层次上讨论设计的,因此主题也是不同的。从事结构化设计的Tom 说:“我想这个系统应该分解成 50 个子程序。 “面向对象设计的 Joh 则说:“我认为系统应划分成7个对 象”。如果你仔细观察,可能会发现这7个对象中可能共含有50 个子程序,而Tom的子程序或许可以分成7组。

(15)进行有效设计的关键是要认识到它是个启发的过程。设计中,总是吃一堑,长一智的。往返设计的概念事实上解释了设计是个启发过程这一事实,因为你要把任何设计方法都只当成一种工具。一种工具只对一种工作或者一种工作的某一部分才有效,其余的工具适合其它的工作,没有一种工具是万能的。因此,你往往要同时使用几种工具。

(16)图示法是另一种有力的启发工具。一幅图抵得上一千个单词。你往往不愿用那一千个单词而宁愿用一幅图,因为图形提供了比文字更高的抽象水平,有时或许你想在细节上处理某一问题,但是,更常见的是在总体上处理问题。

(17)往返设计的一个附加的启发能力是你在设计的头几次循环中,可以暂时对没有解决的细节问题弃之不管,你不必一次就对一切都做出决定,应记住还有一个问题有待做出决定,但同时要意识到,你目前还没有充分的信息来解决这个问题。为什么在设计工作最后10%的部分苦苦挣扎呢?往往在下一循环中它们会自然获得解决。为什么非要在经验和信息都不足的情况下草率决定呢?你完全可以在以后等经验和信息丰富时做出正确决定。有些人对一次设计没能彻底解决问题会感到很不舒服,但与其很不成熟地勉强解决问题,不如把问题暂放一个,待到信息足够丰富时,再解决它。

(18)最重要的设计原则之一是不要死抱着一种方法不放

(19)在给变量命名时,考虑的问题是变量名称是否完全而又准确地描述了变量所代表的实体。 一个有效的方法是用自然语言(如英语)将变量所代表的实体描述出来。往往这一描述本身便是最好的名称,因其不含缩写它很容易读懂,又由于它是对实体的全面描述。因此不会与其它实体相混淆,而且因为它与概念相近,所以也很容易记。

(20)一个好记的名字通常是面向问题而不是解决问题的。一个恰当的名字往往说明是“什么” 而不是“怎样”

(21)应恰当使用反义词。使用关于反义词的命名约定可以帮助保持连续性,同时也可以提高可读性。像 first/last 这样一组反义词是很容易理解的,但 first/end 就有些让人摸不着头脑了,以下是一些比较容易理解的反义词。

add/remove begin/end create/destroy insert/delete first/last get/release increment/decrement put/get up/down lock/unlock min/max next/previous old/new open/close show/hide source/destination source/target start/stop

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。