程序员修炼之道 从小工到专家读书笔记
前段时间抽空阅读了程序员修炼之道的第一章。从书中充满哲学的小故事,以及作者的领悟,受到了许多的启发。所以对这本书的兴趣便更加浓烈,静下心来仔细阅读。这两周,认真的阅读了此书的第二章:注重实效的途径。在软件开发的各个层面中,有多的提示和诀窍。有些想法已经几乎成为公理,另一些过程大家都在使用。可是没有人将这些系统的总结。而这一章,作者便将这些想法和过程集中在一起。下面是我阅读这一章的一些读书笔记
头两节:“重复的危害”,“正交性”关系十分紧切。“重复的危害”提醒我们不要再系统各处对知识进行重复。“正交性”提醒我们不要把任何一项知识分散在多个系统组件中。
重复性的危害:
DRY原则:系统中的每一项指示都必须具有单一,无歧义,权威的表示。这个原则让我们对于软件开发更易于理解和维护。这是 注重实效的程序员的工具箱里最重要的工具之一。
重复大体可以分为下列几种: 强加的重复、无意的重复、无耐性的重复、开发者之间的重复。强加的重复可以通过编写代码生成器,针对文本生成不同语言平台的代码。 尽量让低级的知识放在代码中,将注释保留 给其他高级的说明。建立文档到代码的生成机和语言问题解决。无意地重复原因来自信息结构的不规范。无耐性的重复究其原因就是一个字 懒。开发者之间的重复可以通过高层设计避免。
正交性:两条直线相交成直角,两条直线互不相依,沿着某条直线移动,投影到另一直线上的位置不变。在计算机中,这个术语用来表示某种不相依赖性或是解耦性。如果两个或多个事物中的一个发生变化,不会影响其他食物,这些事物就是正交的
正交性可以提高效率,降低风险
下一节可撤销性 :不存在最终决策。为了达到可撤销性,需要灵活的架构,使用项CORBA技术能够讲项目某些部分与语言分割开
接下来的两节也是相关的,“曳光弹”中讨论了一种开发方式,能让我们同时搜集需求、测试设计、并实现代码。“原型与便笺”告诉我们在曳光弹开发不适用的情况下,怎样使用原型来测试架构、算法、接口以及各种想法。
曳光弹:先动手,然后观察各种反馈,立即改进。曳光弹方法适用于新的项目。注重实效的程序员往往更喜欢使用曳光弹。曳光开发与项目永不会结束的理念是一致的:总有改动需要完成,总有功能需要增加 这是一个渐进的过程。
曳光代码方法有许多优点:用户能够及早看到能工作的东西、开发者构建了一个他们能在其中工作的结构、你有了一个集成平台、你有了可用于演示的东西、你将更能够感觉到工作进展。但是曳代码不能百分之百确定该去往何处的情形下使用这项技术。
原型与便笺:原型制作与完全的制作对比成本低很多,举例轿车制作商可以为某种新车设计不同的原型,目的是测试轿车的具体方面-空气动力学,结构特征等。同样道理,软件产品也可以使用原型制作,利用不同材料制作原型,可以是白板上的图形、绘图工具绘制的产品图等等。但是,如果发现自己处于不能放弃细节的环境中,需要问自己是否采用该方法而转而使用曳光弹方法。
应制作原型的事物:
- 架构
- 已有系统的新功能
- 外部数据的结构或内容
- 第三方工具或组件
- 性能问题
- 用户界面设计
原型制作中可忽略的细节:- 正确性:虚设数据
- 完整性:提高有意义的事物
- 健壮性:错误检查
- 风格
制作架构原型:
- 主要组件的责任是否得到良好定义?是否适当?
- 主要组件间协作是否得到良好的定义
- 耦合是否得以最小化
- 你能否确定重复的潜在来源
- 接口的定义和各项约束是否可接
- 受每个模块再执行中能否访问其所需的数据?是否在需要时进行访问
领域语言中作者给了一些关于计算机语言的适度的建议
估算:学习估算,并将此技能发展到你对事物的数量级直觉的程度,你就能展现出一种魔法般的能力,确认他们的可行性。在进行估算的过程中,将会加深对程序所处的世界的理解。所有的估算都以问题的模型为基础,任何估算练习的第一步都是建立对提问内容的理解。理解提问的内容、建立系统的模型、把模型分解为组件、给每个参数指定值、计算答案、追踪自己的估算能力、估算项目进度,便是估算的大体步骤。
以上便是这几周阅读的笔记与感受,接下来的阅读相信作者能给我带来更多的启发与感悟。