程序员修炼之道 从小工到专家读书笔记

  前段时间抽空阅读了程序员修炼之道的第一章。从书中充满哲学的小故事,以及作者的领悟,受到了许多的启发。所以对这本书的兴趣便更加浓烈,静下心来仔细阅读。这两周,认真的阅读了此书的第二章:注重实效的途径。在软件开发的各个层面中,有多的提示和诀窍。有些想法已经几乎成为公理,另一些过程大家都在使用。可是没有人将这些系统的总结。而这一章,作者便将这些想法和过程集中在一起。下面是我阅读这一章的一些读书笔记

  头两节:“重复的危害”,“正交性”关系十分紧切。“重复的危害”提醒我们不要再系统各处对知识进行重复。“正交性”提醒我们不要把任何一项知识分散在多个系统组件中。

  重复性的危害:

          DRY原则:系统中的每一项指示都必须具有单一,无歧义,权威的表示。这个原则让我们对于软件开发更易于理解和维护。这是         注重实效的程序员的工具箱里最重要的工具之一。

          重复大体可以分为下列几种: 强加的重复、无意的重复、无耐性的重复、开发者之间的重复。强加的重复可以通过编写代码生成器,针对文本生成不同语言平台的代码。 尽量让低级的知识放在代码中,将注释保留      给其他高级的说明。建立文档到代码的生成机和语言问题解决。无意地重复原因来自信息结构的不规范。无耐性的重复究其原因就是一个字 懒。开发者之间的重复可以通过高层设计避免。

  正交性:两条直线相交成直角,两条直线互不相依,沿着某条直线移动,投影到另一直线上的位置不变。在计算机中,这个术语用来表示某种不相依赖性或是解耦性。如果两个或多个事物中的一个发生变化,不会影响其他食物,这些事物就是正交的

          正交性可以提高效率,降低风险

  下一节可撤销性 :不存在最终决策。为了达到可撤销性,需要灵活的架构,使用项CORBA技术能够讲项目某些部分与语言分割开

  接下来的两节也是相关的,“曳光弹”中讨论了一种开发方式,能让我们同时搜集需求、测试设计、并实现代码。“原型与便笺”告诉我们在曳光弹开发不适用的情况下,怎样使用原型来测试架构、算法、接口以及各种想法。

     曳光弹:先动手,然后观察各种反馈,立即改进。曳光弹方法适用于新的项目。注重实效的程序员往往更喜欢使用曳光弹。曳光开发与项目永不会结束的理念是一致的:总有改动需要完成,总有功能需要增加  这是一个渐进的过程。

     曳光代码方法有许多优点:用户能够及早看到能工作的东西、开发者构建了一个他们能在其中工作的结构、你有了一个集成平台、你有了可用于演示的东西、你将更能够感觉到工作进展。但是曳代码不能百分之百确定该去往何处的情形下使用这项技术。

    原型与便笺:原型制作与完全的制作对比成本低很多,举例轿车制作商可以为某种新车设计不同的原型,目的是测试轿车的具体方面-空气动力学,结构特征等。同样道理,软件产品也可以使用原型制作,利用不同材料制作原型,可以是白板上的图形、绘图工具绘制的产品图等等。但是,如果发现自己处于不能放弃细节的环境中,需要问自己是否采用该方法而转而使用曳光弹方法。

应制作原型的事物:

  • 架构
  • 已有系统的新功能
  • 外部数据的结构或内容
  • 第三方工具或组件
  • 性能问题
  • 用户界面设计
    原型制作中可忽略的细节:
    • 正确性:虚设数据
    • 完整性:提高有意义的事物
    • 健壮性:错误检查
    • 风格

制作架构原型:

  • 主要组件的责任是否得到良好定义?是否适当?
  • 主要组件间协作是否得到良好的定义
  • 耦合是否得以最小化
  • 你能否确定重复的潜在来源
  • 接口的定义和各项约束是否可接
  • 受每个模块再执行中能否访问其所需的数据?是否在需要时进行访问

   领域语言中作者给了一些关于计算机语言的适度的建议

   估算:学习估算,并将此技能发展到你对事物的数量级直觉的程度,你就能展现出一种魔法般的能力,确认他们的可行性。在进行估算的过程中,将会加深对程序所处的世界的理解。所有的估算都以问题的模型为基础,任何估算练习的第一步都是建立对提问内容的理解。理解提问的内容、建立系统的模型、把模型分解为组件、给每个参数指定值、计算答案、追踪自己的估算能力、估算项目进度,便是估算的大体步骤。

以上便是这几周阅读的笔记与感受,接下来的阅读相信作者能给我带来更多的启发与感悟。

原文地址:https://www.cnblogs.com/wendi/p/11771727.html