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

秒大刀 博客

好好学习 天天向上

 
 
 

日志

 
 
 
 

读《代码大全2》第6部分 系统考虑  

2009-12-28 21:02:48|  分类: 读书 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

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


第6部分 系统考虑

第27章 程序规模对构建的影响
  1. 改善交流效率的常用方法是采用正式的文档
  2. 对于小项目,影响生产率的最大因素莫过于单个程序员的技巧。随着项目规模和团队规模的增大,组织方式对生产率的影响也将随之增大。
  3. 开发软件产品的成本大约是开发“软件程序”的3倍。开发一组能够结合起来工作的程序的软件系统的成本是简单程序开发成本的3倍。开发系统产品的成本是简单程序的9倍。
  4. 建造摩天大楼的方法和搭狗窝的方法是不一样的。
  5. 对于大项目来说,如果不有意识的去选择方法论,就将无法完成任务。
  6. Key Points:
    1. 随着项目规模的扩大,交流需要加以支持。大多数方法论的关键点都在于减少交流中的问题,而一项方法论的存亡关键也应取决于它能否促进交流。
    2. 在其他条件都相等的时候,大项目的生产率会低于小项目。
    3. 在其他条件都相等的时候,大下次昂木的每千行代码错误率会高于小项目。
    4. 在小项目里的一些看起来“理应如此”的活动在大项目中必须仔细的计划。随着项目规模扩大,构建活动的主导地位逐渐降低。
    5. 放大轻量级的方法论要好于缩小重量级的方法论。最有效的办法是使用“适量级”方法论。

第28章 管理构建
  1. 质量目标和项目规模都会显著影响这个软件项目的管理方式。
  2. 项目中编程标准的制定,应该由一位受人尊敬的架构师来做,而不应该是管理者。在软件项目中,“专家层”起的作用至少与“管理层”相同。
  3. 强调代码是共有财产
  4. 需求变更和设计变更
    1. 开发过程中,你一定会有很多关于如何改善系统的想法。如果每产生一个想法就实施相应的变更,你会发现自己走上了软件开发的treadmill——虽然系统在发生变化,但却没有向着“完成”的方向迈进。
    2. 遵循某种系统化的变更控制手续。当你面临很多变更需求时,系统化的变更控制手续犹如天赐之物。通过建立一套系统化的手续,你就能将变更放在“在对系统整体最为有利”的环境下进行考虑。
    3. 成组的处理变更请求。人们倾向于一有想法就去实现那些较容易的变更,因此类变更消耗了资源,会导致更好的变更因资源不足而被丢弃。应该记下所有的想法和建议,不管它实现起来有多容易。把它记录下来,直到你有时间去处理它们。到那时,把所有变更当做一个整体来看待,从中选出最有益的一些变更来加以实施。
    4. 评估每项变更的成本。评估变更成本时要仔细考虑所有环节的代价,而不仅仅是编码。
    5. 提防大量的变更请求。变更请求数量太大是一个很关键的警报信号,这表明需求、架构或者上层设计做得不够好,从而无法有效的支持构建活动。
    6. 成立变更控制委员会或者类似机构。变更控制委员会是一项“设定需求变更的优先级”和“控制需求变更”的最佳实践。
    7. 警惕官僚主义,但也不要因为害怕官僚主义而排斥有效的变更控制。缺乏规范的变更控制是当今软件业面临的主要管理难题之一。不要去考虑“未做跟踪但却同意执行的变更”。但变更控制有滋生官僚主义的倾向。变更控制的实质就是确定什么最重要,所以不要因为害怕官僚主义就不去享受变更控制的诸多益处。
  5. 要定期对项目做重新评估。项目越接近完成,评估的准确度应该越高。
  6. 如果你落后了改怎么办?
    1. 项目通常会超出原定完成时间的100%
    2. 希望自己能赶上。当项目落后于进度安排时,人们通常的反应是对此抱有乐观态度。事实上,越接近项目后期,延误和超值现象就越严重,项目并不能在后期把时间补回来,而是会越落越后。
    3. 扩充团队。Fred Brooks定律:往一个已经落后的软件项目里加人手只会使得它更加落后。发现进度落后时扩充团队无异于火上浇油。一位妇女可以怀胎十月诞下一子,并不意味着10位妇女能只用一个月时间生下一个孩子。更多的工人在工作并不一定意味着能做更多的工作。当一个项目中的任务是不可分割的、不能各个击破,那么增加人手是无济于事的;但如果项目中的任务是可以分割的,那么就可以把任务进一步细分,然后分给不同的人来做,甚至可以分配给项目后期才加入进来的人。
    4. 缩减项目范围。最初做版本计划的时候,要把产品的功能划分成“必须有”、“有了更好”和“可选择”三类。当资源不足时可以针对不同的类型采取不同的策略,或者实现功能的粗略版本。
  7. 度量
    1. 任何一种项目特征都是可以用某种方法来度量的,而且总会比根本不度量好得多。度量结果也许不会完全精确,度量也许很难做,而且也许需要持续的改善结果,但是它能使你对软件开发过程进行控制,而如果不度量就根本不可能控制。
    2. 留心度量的副作用。度量乎会对动机产生影响。人们会对那些被度量的事物更加用心,他们认为度量的目标是在评价他们。要谨慎的选择哪些环节需要被度量。人们会倾向于集中做哪些被度量的工作,而忽视未被度量的工作。
    3. 反对度量就是认为最好不要去了解项目中到底在发生什么
  8. 如果你为了聘请到10%最优秀的程序员而需要多支付报酬,那么就请欣然接受这一现实。你会因为所雇用的程序员的高品质和高生产力而迅速得到回报,而且这么做还有一个剩余效应,那就是你的组织中其他程序员的品质和生产力不会下降,因为好的程序员倾向于聚到一起。
  9. 当试图要求统一某些编程实践时,可能会遇到敏感的程序员信仰问题,这些信仰涉及程序员自己的个人风格,为避免激怒你的程序员:
    1. 要清楚的知道你是在处理一个敏感的问题。在全心全意投入之前要先试探程序员对有关敏感问题的看法。
    2. 对这些领域要使用“建议”或者“指导原则”。避免指定僵硬的“规则”或者“标准”。
    3. 避免流露明显的意图通过一些技巧来避免针对敏感问题直接对话
    4. 让程序员们制定他们自己的标准。不要给你的程序员们设立标准,但一定要坚持让他们在“那些对你来说非常重要的领域里”标准化。
    5. 要注意权衡编码风格等的统一和对士气造成的影响。
  10. 宽敞、安静、私密的办公室有利于提高生产力
  11. 管理你的管理者——你需要告诉他应该这样做而不应该那样做。你要表现得使你的管理者认为他仍然在管理你。
  12. Key Points:
    1. 好的编码实践可以通过“贯彻标准”或者“使用更为灵活的方法”来达到
    2. 配置管理,如果应用得当,会使程序员的工作变得更加轻松。特别包括变更控制。
    3. 好的软件评估是一项重大挑战。成功的关键包括采用多种方法、随着项目的开展而修缮评估结果,以及很好的利用数据来创建评估等。
    4. 度量是构建管理成功的关键。你可以采取措施度量项目的任何方面,而这要比根本不度量好得多。准确的度量是制定准确的进度表、质量控制和改进开发过程的关键。
    5. 程序员和管理人员都是人,在把他们当人看的时候工作的最好。

第29章 集成
  1. 集成——将一些独立的软件组件组合为一个完整系统。
  2. 华盛顿大学的露天足球场坍塌了,因为它在建造时不能支撑自己的重量。很可能在完工后它会足够览古,但是它的建造顺序是错的——这是一个“集成”错误。
  3. 不适当的过分关注细小的缺陷,会使项目进展瘫痪。
  4. Daily Build and Smoke Test:
    1. 每日构建。构建可以视为项目的脉搏。项目将保证在每次构建时保持同步。
    2. 检查失败的build。好的build:能成功编译、链接,并不包含任何使程序无法启动的bug。
    3. 每天进行冒烟测试。从头到尾的演练整个系统,但不必做到毫无遗漏,但应该能够暴露主要的问题。通过了冒烟测试,就可以认为产品足够稳定,可以接受更加彻底的测试了。
    4. 让冒烟测试与时俱进
    5. 将daily build和冒烟测试自动化。照料并给build喂食是耗时的事。
    6. 成立build小组
    7. 仅当有意义时,才将修订加入build中。但是别等太久才将修订加入进来。
    8. 要求开发人员在把他的代码添加到系统之前,进行冒烟测试
    9. 为即将添加到build的代码准备一块暂存区
    10. 惩罚破坏build的人
    11. 在早上发布build。“在每天快结束时开始冒烟测试,如果发现问题,就在半夜把人召集起来”的做法似乎很有男子气概,但这样的团队过于刻薄,浪费了时间,得不偿失。
    12. 即使有压力,也要进行daily build和冒烟测试
  5. 项目越大,增量继承就越重要。
  6. Key Points:
    1. 构建的先后次序和集成的步骤会影响设计、编码、测试各类的顺序
    2. 一个经过充分思考的集成顺序能减少测试的工作量,并使调试变容易。
    3. 增量集成有若干变型,而且——除非项目是微不足道的——任何一种形式的增量继承都比阶段式集成好。
    4. 针对每个特定的项目,最佳的集成步骤通常自顶向下、自底向上、风险导向及其他集成方法的某种组合。T-型集成和竖直分块集成通常都能工作的很好。
    5. daily build能减少集成的问题,提升开发人员的士气,并提供非常有用的项目管理信息。

第30章 编程工具
  1. 为项目做计划时,就应该花一部分时间来思考需要哪些工具,并为制造这些工具分配时间
  2. 编程——始终需要人来填补真实世界里需要解决的问题和准备用来解决问题的计算机之间的鸿沟。这些人将会被称作程序员,无论他是以汇编语言操控机器的寄存器,还是用VB操控对话框。只要有计算机,就需要能告诉计算机该去做什么的人,这一活动将会被称作编程。
  3. Key Points:
    1. 程序员有时会在长达数年的时间里忽视某些最强大的工具,之后才发现并使用之。
    2. 好的工具能让你的日子过得安逸的多。
    3. 下面这些工具已经可用了:编辑、分析代码质量、重构、版本控制、出错、测试、代码调整。
    4. 你能打造许多自己用的专用工具。
    5. 好的工具能减少软件开发中最单调乏味的工作的量,但它不能消除对“编程”的需要,虽然它会持续的重塑“编程”的含义。

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

历史上的今天

在LOFTER的更多文章

评论

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

页脚

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