登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

秒大刀 博客

好好学习 天天向上

 
 
 

日志

 
 
 
 

读《代码大全2》第1部分 打好基础  

2009-10-26 21:51:34|  分类: 读书 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

全部书摘参见 读《代码大全2》


第1部分 打好基础
译序
  应该首先为人编写代码,其次才是为机器
第1章 欢迎进入软件构建的世界
  提高关键的质量和开发者的生产效率都是很重要的
  构建活动会占到整个软件开发时间的30%~80%,占整个项目成本的65%左右
  不同程序员的生产率差异可达10到30倍
  软件构建是软件开发的核心活动,构建活动是每个项目中唯一一项不可少的工作
  软件构建的主要活动包括:详细设计、编码、调试、集成、开发者测试(包括单元测试和集成测试)
第2章 用隐喻来更充分的理解软件开发
  重要的研发成果常常产自类比
  模型的威力就在于其生动性,让你能够把握整个概念
  数据处理正在从“以计算机为中心”的观点向“以数据库为核心”的观点转变
  算法直接给你解决问题的指导,而启发式方法则告诉你该如何发现这些指导信息,或者至少到那里去寻找他们
  三分之二的项目在首次发布之后还有90%的工作量要做
  精心计划并不意味着事无巨细的计划或者过度的计划
  隐喻是启示而不是算法,因此往往有一点随意
  隐喻把软件开发过程与其他你熟悉的活动联系在一起,帮助你更好的理解
  有些隐喻比其他隐喻更贴切
  通过把软件的构建过程必做是房屋的建设过程,我们可以发现,仔细的准备是必要的,而大型项目和小型项目之间也是有差异的。
  通过把软件开发中的实践比作是智慧工具箱中的工具,我们又发现,每位程序员都有许多工具,但并不存在任何一个能适用于所有工作的工具,因地制宜的选择正确工具是成为能有效编程的程序员的关键
  不同的隐喻彼此并不排斥,应该使用某种对你最有益处的隐喻组合
第3章 三思而后行:前期准备
  软件开发中最常见的项目风险是糟糕的需求分析和糟糕的项目计划
  人生苦短,当有大量更好的选择摆在你面前的时候,在一个荒蛮的软件企业中工作是不明智的。
  尽早把哪些是最关键的需求要素和架构要素确定下来
  选择序列式开发的理由:
       需求相当稳定
       设计直截了当,而且理解透彻
       开发团队对于这一领域十分熟悉
       项目的风险很小
       “长期可预测性”很重要
       后期改变需求、设计和编码的代价很可能较昂贵
  选择迭代开发的理由:
       需求并没有被理解透彻,或者出于其他理由你认为它是不稳定的
       开发团队对于这一领域不熟悉
       项目包含许多风险
       “长期可预测性”不重要
       后期改变需求、设计和编码的代价很可能较低
  在射击之前,确信你瞄准了正确的目标
  一般项目在开发过程中需求会有25%的变化,需求变更导致的返工占总返工量的75%~85%
需求核对表:
  针对功能需求:
       是否详细定义了系统的全部输入,包括其他源、精度、取值范围、出现频率等
       是否定义了系统的全部输出,包括目的地、精度、取值范围、出现频率、格式等
       是否详细定义了所有输出格式,web页面、报表等
       是否详细定义了所有硬件和软件的外部接口
       是否详细定义了全部外部通信接口,包括握手协议,纠错协议、通信协议等
       是否列出了用户想要做的全部事情
       是否详细定义了每个任务所用的数据,以及每个任务得到的数据
  针对非功能需求(质量需求):
       是否为全部必要的操作,从用户的视角,详细描述了期望响应时间
       是否详细描述了其他与计时有关的考虑,例如处理时间、数据传输率、系统吞吐量等
       是否详细定义了安全级别
       是否详细定义了可靠性,包括软件失灵的后果、发生故障时需要保护的至关重要的信息、错误检测与恢复的策略等
       是否定义了机器内存和剩余磁盘空间的最小值
       是否定义了系统的可维护性,包括适应特定功能的变更、操作环境的变更、与其他软件接口变更的能力
       是否包含对“成功”的定义?“失败”的定义呢?
  需求的质量:
       需求是用用户的语言书写的吗?用户也这么认为吗?
       每条需求都不与其他需求冲突吗?
       是否详细定义了相互竞争的特性之间的权衡——例如健壮性与正确性之间的权衡
       是否避免在需求中规定设计(方案)
       需求是否的详细程度上保持相当一致的水平,有哪些需求应该更详细的描述吗?有些需求应该更粗略的描述吗?
       需求是否够清晰,即使转交给一个独立的小组去构建,他们也能理解吗?开发者也这么认为吗?
       每个条款都与待解决的问题及其解决方案相关吗?能从每个条款上溯到它在问题域中对应的根源吗?
       是否每条需求都是可测试的,是否可能进行独立的测试,以检验满不满足各项需求
       是否详细描述了所有可能的对需求的改动,包括各项改动的可能性
  需求的完备性:
       对于在开发开始之前无法获得的信息,是否详细描述了问题不完全的区域
       需求的完备度是否达到这种程度:如果产品满足需求,哪么它就是可接受的
       你对全部需求都感到很舒服吗?你是否已经去掉了那些不可能实现的需求——那些只是为了安抚客户和老板的东西
架构的典型组成部分:
       程序组织
       主要的类
       数据设计
       业务规则
       用户界面设计
       资源管理
       安全性
       性能
       可伸缩性
       互用性
       国际化/本地化
       输入输出
       错误处理
       容错性
       架构的可行性
       过度工程
       关于“买”还是“造”的决策
       关于复用的决策
       变更策略
       架构的总体质量
架构核对表:
  针对架构的主题
       程序的整体组织结构是否清晰?是否包含一个良好的架构全局观(包括理由)?
       是否明确的定义了主要的构造块?(包括每个构造块的职责范围以及与其他构造块的接口)
       是否明确涵盖了“需求”中列出的所有功能(每个功能对应的构造块也不太多也不太少)?
       是否描述并论证了那些最关键的类
       是否描述并论证了数据设计?
       是否详细定义了数据库的组织结构和内容
       是否指出了所用的关键业务规则,并描述其对系统的影响
       是否描述了用户界面设计的策略
       是否将用户界面模块化,使界面的变更不会影响程序的其余部分
       是否描述并论证了处理IO的策略
       是否估算了稀缺资源(如线程、数据库连接、句柄、网络带宽等)的使用量,是否描述并论证了组员管理的策略?
       是否描述了架构的安全需求
       架构是否为每个类,每个子系统,或每个功能域提出空间与时间预算
       架构是否描述了如何达到可伸缩性
       架构是否关注户操作性
       是否描述了国际化/本地化策略
       是否提供了一套内聚的错误处理策略
       是否规定了容错的办法(如果需要)?
       是否证实了系统各个部分的技术可行性
       是否详细描述了过度工程的方法
       是否描述了必要的“买vs.造”的策略
       架构是否描述了如何加工被复用的代码,使之符合其他架构目标
       是否将架构设计得能够适应很可能出现的变更
  架构的总体质量:
       架构是否解决了全部需求
       有没有哪个部分是“过度架构”或“欠架构”,是否明确宣布了在这方面的预期指标
       整个架构是否在概念上协调一致
       顶层设计是否独立于用作实现它的机器和语言
       是否明确了所有主要决策的动机
       你,作为一名实现该系统的程序员,是否对整个架构感觉良好?
       一般来说,一个运作良好的项目会在需求、架构以及其他前期计划方面投入10%~20%的工作量和20%~30%的时间
前期准备核对表:
       你是否辨明了自己所从事的软件类型,并对所用的开发方法做出了相应的剪裁
       你是否充分明确的定义了需求,而且需求足够稳定,能开始构建了?
       你是否明确的定义了架构以便开始构建
       是否已经指出项目中独有的风险,以避免构建活动面临不必要的风险
       构建活动的准备工作的根本目标在于降低风险,要明确你的准备活动在降低风险,而非增加风险
       如果你想开发高质量的软件,软件开发过程中必须由始至终关注质量。在项目初期关注质量,对产品质量的正面影响要比在项目末期关注质量的影响大
       程序员的一部分工作是教育老板和合作者,告诉他们软件开发过程,包括在编码之前进行充分准备的重要性
       你所从事的软件项目的类型对构建活动的前期准备工作有重大影响——许多项目应该是高度迭代的,某些应该是序列式的
       没有明确的问题定义,那么你可能在构建期间解决错误的问题
       如果没有做完良好的需求分析工作,你可能没能察觉待解决问题的重要细节。如果需求变更发生在构建之后的阶段,其代价是“在项目早起更改需求”的20至100倍。因此在开始编程之前,你要确认“需求”已经到位了
       如果没做完良好的架构设计,你可能会在建构期间用错误的方法解决正确的问题。架构变更的代价随着“为错误的架构编写的代码数量”增加而增加,因此,也要确认“架构”已经到位了
       理解项目的前期准备所采用的方法,并相应的选择构建方法

第4章 关键的构建决策
  每种编程语言都有其优点和弱点,要明确知道你所使用语言的有点和弱点
  在开始编程约定。“改变代码使之符合这些约定”是近乎不可能的
  “构建的实践方法”的种类比任何单个项目能用到的要多。有意识的选择最适合你的项目的实践方法
问问你自己,你所采用的编程实践是对你所采用编程语言的正确响应,还是受它的控制,请记住“深入一种语言去编程”不要仅“在一种语言上编程”
  你在技术浪潮中的位置决定了哪些方法是有效的——甚至是可能用到的。确定你在技术浪潮中的位置,并相应调整计划和预期目标

  评论这张
 
阅读(1265)| 评论(0)

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018