Code Complete总结(一)

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/Rookie_cong/article/details/81605666

Code Complete

本书是一本比较老的书,但是对于现今的编码来讲,任是一本经典的书籍,对提高我们的编程风格和提升编码思想仍有很大的指导意义。

第一章 欢迎进入软件创建世界

  • 1.什么是软件构建:
    主要指编码、调试过程、详细设计和测试。

    计算机软件开发的主要方面(没看明白,还是记下来方便以后看):

    • 问题定义
    • 需求分析
    • 实现计划
    • 总体设计
    • 详细设计
    • 创建即实现
    • 系统集成
    • 单元测试
    • 系统测试
    • 校正性的维护
    • 功能强化
  • 2.软件创建的重要性
    论述了软件创建在开发中很重要,应该把主要精力放在创建活动中。

第二章 利用隐喻对编程进行更深刻的理解

  • 1.隐喻的重要性
    论述了通过隐喻在科学上取得的一些成就。。。
  • 2.如何使用软件隐喻
    好的软件隐喻会给你启发。
    使用软件隐喻帮助你在编程过程中的内在理解。
  • 3.通常的软件隐喻
    • 软件书写(Writing Code)
      作者认为这种隐喻不适合现在的软件构建,现在的系统开发的投资相当于建一栋办公楼。并且这种比喻向写信一样,写了就不管也不能 修改。
    • 软件播种
      作者也认为这种比喻十分拙劣,这种比喻的弱点是对于软件开发失去了直接的控制,并且就像是只给系统计划施肥,让代码自由生长,这显然是不合适的。
    • 软件珍珠培植法
      这个隐喻强调了积累的重要性,每次都想系统加一点东西,最终完成它。
    • 建造软件
      建造房子,首先的设计很重要,然后再试选好房址、打地基、建造房屋框架等等。作者认为这和软件创建基本差不多。建造房子材料成本更贵,建造软件劳动成本更贵。
    • 智能工具箱
      作者认为开发人员在十几年的积累中,有了很多的工具和开发技巧。但要明确,有些方法在某些场合有用,有些却是不适合。
    • 复合隐喻
      作者认为隐喻更像是一种启发而不是公式,只要你愿意,你可以用多种隐喻组合,关键是他能够激发你的思想。

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

  • 1.准备不足的原因
    忠告:
    • 阅读工作的内容提示,或许会发现一些没想到的问题。
    • 注意自己的问题。
  • 2.问题定义先决条件
    问题定义只描述要解决的问题是什么,不涉及解决方法。通俗地说,它应该是一个简短的说明。
  • 3.需求分析先决条件
    明确的需求很重要。
    稳定需求对软件开发很重要。
    在创建阶段要做好需求的变化。
  • 4.结构涉及先决条件
    如果要进行结构变动,越早越好。
    要考虑的要素:
    • 程序的组织形式:找出最终组织形式的集中方案,并且应该知道为什么选中了现在的组织形式。
    • 变动策略:变动是不可避免的(创建软件是逐渐学习的过程),因此在设计中应该考虑到某些变动。
    • 能购买的尽量不建造
    • 主要的数据结构:数据结构对系统维护有举足轻重的影响。
    • 关键算法:在选择算法时要给定选择该算法的原因。
    • 主要对象:在面向对象的系统中,应该规定每一个对象的责任并指出对象之间是如何相互作用的。
    • 通用功能:用户界面、输入/输出、内存管理和字符串存储。
    • 错误处理:如果可以纠正错误,程序尝试从错误状态下恢复。
    • 坚固性:裕度设计(大于需求定义的规定)、断言、容错性和性能。
    • 通用的结构设计质量准则:一个好的结构设计,应该是被看到时是为他的解决方案的自然和简单而感到折服,而不会把问题和答案生拼硬凑一起的感觉。
  • 5.选择编程语言先决条件:对于不同的工作,不同的语言的表现差异很大。
  • 6.编程约定:高质量的软件中,结构设计的概念完整性与较低层次之间的密切联系。
  • 7.应花在先决条件上的时间:大概在20~30%(不包括详细设计)。
  • 8.改变先决条件以适应你的项目

第四章 建立子程序的步骤

  • 1.建立程序步骤概述:设计程序、检查设计、子程序编码、检查代码。
  • 2.程序设计语言(PDL):一种详细设计的工具。
  • 3.设计子程序:分析好程序的功能(输入、输出、是否是交互式、要处理的信息、影响的全局变量等等)
    • 给子程序命名:动词、做什么的、是什么、需要什么条件等等。
    • 考虑效率:模块化和性能。(优化的主要受益主要来自高层设计,而不是个别子程序)
    • 研究算法和数据结构
    • 编写PDL
    • 编写工作应该从抽象到具体
    • 考虑数据
    • 检查PDL
    • 逐步细化
  • 4.子程序编码:把原来的抽象说明用程序语言实现。
    • 书写子程序说明(先写上和编程风格一样的注释,再一步转化成代码???)
    • 非正式地检查代码:想一下有什么因素可能跑坏目前的块
    • 进行收尾工作:检查子程序的接口、检查通用设计质量(子程序只完成一项任务并且完成得很好)、检查子程序的数据、检查子程序的控制结构(循环、嵌套等)、检查子程序设计、检查子程序的文档。
  • 5.检查子程序
    • 在心里对子程序进行查错处理
    • 编译子程序(到这一步才编译不容易混乱)
    • 使用计算机来检查子程序错误
    • 消除子程序中的错误

第五章 高质量子程序特点

  • 1.生成子程序的原因:
    • 降低复杂性(避免代码重复)
    • 限制了改动带来的影响
    • 隐含顺序
    • 改进性能(改进一个地方,几个地方受益)
    • 进行集中控制
    • 隐含数据结构(使得在不改变绝大多数程序的条件下,改变数据结构成为可能)
    • 隐含全局变量(不必改变程序就改变数据结构)
    • 隐含指针操作(指针操作可读性差)
    • 提高代码的可读性
    • 提高代码的可移植性
    • 分隔负责操作
  • 2.子程序名称恰当
    • 用动词
    • 对于函数名字,可以使用返回值的描述(Cos()、PrinterReady()、CurrentPenColor())
    • 避免无异议或者模棱两可的动词
    • 描述子程序所做的一切
    • 名字长度要符合需要(9~15)
    • 建立用于通用操作的协定
  • 3.强内聚性:每个子程序只需要做好一项工作,而不必考虑其他任务。
    • 功能内聚性:在功能上只做好一项工作。
    • 顺序内聚性:子程序内包含需要按特定顺序进行、逐步分享数据而不形成一个完整功能的操作。(把操作分隔开,没有产生独立的功能)。难命名,通常意味着你要重新组织和设计子程序,以使它是功能内聚性的。
    • 通讯内聚性:GetNameAndChangePhoneNumber(),其中的Name和PhoneNumber是放在同一用户记录的,就是通讯内聚性。
    • 临时内聚性:因为同时执行才被放在同一个子程序里,用子程序去调用其他专门功能的子程序。
      注:到此为止的内聚性都在接受范围,但最可取的是功能内聚,一下是不可取的。
    • 过程内聚性:和顺序内聚不同的是,过程内聚性操作的是不同的数据。
    • 逻辑内聚性:操作由传递进来的控制标志所选择。
    • 偶然内聚性:同一个子程序之间没有任何联系。
  • 4.松散耦合性:任何一个子程序很容易被其他子程序调用(尽量避免它对其他子程序有依赖性)。
    • 简单数据耦合:两个子程序之间传递的数据是非结构化的,并且全部都是通过参数表进行的,这个最好。
    • 数据结构耦合:两个子程序之间传递的数据是结构化的,并且是通过参数表实现传递的。
    • 控制耦合:一个子程序通过传入另一个子程序的数据通知它该做什么。这种不好,它要指导另一个子程序里干了什么。
    • 全局数据耦合:两个子程序使用同一个全局数据,就是全局数据耦合(公共耦合或全局耦合)。这种作者不太认同,他觉得这么做子程序之间的联系不密切又不可见。
    • 不合理耦合:一个子程序使用另外一个子程序中的代码,改变了其中的局部变量。
  • 5.子程序长度:不要超过200行
  • 6.防错性编程:即使一个程序被传入坏数据,也不会受到伤害。
    • 断言
    • 输入垃圾不要输出也是垃圾
    • 异常情况处理
    • 预计改动
    • 计划去掉调试帮助
    • 检查函数返回值
    • 在最终软件中保留一些防错性编程(保留查找重要错误和延缓终止的代码
    • 去掉无关紧要和引起程序终止的代码)
  • 7.子程序参数:
    • 确保实际参数和形式参数匹配(养成检查参数表中的参数变量类型和类型匹配)
    • 几个子程序使用了相似的参数,应按照不变的顺序排列这些参数
    • 使用所有参数
    • 把状态和“错误”变量防止最后
    • 不要把子程序中的参数当做工作变量
    • 说明参数的接口假设
    • 应该把一个子程序的参数个数限制在7个左右
    • 仅传递子程序需要的那部分结构化变量

第六章 模块化设计

  • 1.内聚性与耦合性
  • 2.信息隐蔽
  • 3.建立模块的理由(模块不支持继承性)
    • 用户接口
    • 对硬件有以来的区域
    • 输入和输出
    • 操作系统依赖部分
    • 数据管理
    • 真实目标与抽象数据类型
    • 可再使用的代码
    • 可能发生变动的相互联系的操作
    • 相互联系的操作(相互联系的子程序和数据放在一起有更强的组织原则)

没有更多推荐了,返回首页