程序员修炼之道-阅读笔记.doc

第一章 注重实效的哲学1、注重实效的程序员的特征：是他们处理问题、寻求解决方案时的态度、风格、哲学。 设法把问题放在更大的语境中，设法注意更大的图景 对所做的每件事情负责 接受变化，拥抱变化 理解工作的语境 广泛的知识和经验基础 交流1、我的源码让猫给吃了 在所有弱点中，最大的弱点就是害怕暴露弱点。 为自己的行为负责 对我们的无知和错误，应该诚实、坦率 预期到超过自己能力范围的风险，可以不必承担，若没有预期到已经发生，则必须承担 提供各种选择，不要找蹩脚的接口（Provide Options, Dont Make Lame Excuses.） 任何谈话可以先预演一遍，预知一下结果 不要说做不到，要想有什么解决方案2、软件的熵 熵：来自物理学的概念，指某个系统中的“无序”的总量 促生软件腐烂的一个重要因素：开发项目时的心理（文化） 不要容忍破窗户（Dont Live With Broken Windows）3、石头汤与煮青蛙 当遇到请求许可“拖延和漠然”，设计出可以合理要求的东西 做变化的催化剂（Be a Catalyst for Change） 记住大图景（Remember the Big Picture） 留心大图景，持续不断地观察周围发生的事情，而不只是你自己在做的事情 当你设法催生变化时，你能否确定是在做石头汤还是青蛙汤？决策是主观还是客观的？4、足够好的软件 欲求更好，常把好事变糟（李尔王） 影响我们控制质量的因素：时间、技术、急躁 缺乏职业素养的做法：1）无视用户的需求，一味的给程序增加新特性，或一次一次的润饰代码2）许诺不可能兑现的时间标度（time scale）3）为赶上最后期限而消减基本的工程内容 制作系统的范围和质量应该作为系统需求的一部分规定下来 使质量称为需求问题（Make Quality a Requirements Issue） 给用户的东西，要及早让他们使用，他们的反馈常常会吧你引向更好的最终解决方案 如果不懂得何时止步，绘画会迷失在绘制中（不要因为过度修饰和过于求精而毁损完好的程序）5、你的知识资产 知识上的投资总能得到最好的回报（本杰明。富兰克林） 知识和经验是有时效的资产（expiring asset） 定期为你的知识资产投资（Invest Regularly in Your Knowledge Porfolio） 目标（持续投入）：1）每年至少学习一种新语言（拓宽思维）2）每季度阅读一本技术书籍（拓宽范围）3）也要阅读非技术书籍（了解人）4）上课5）参加本地用户组织6）实验不同的环境7）跟上潮流（了解新技术）8）上网 批判的思考你读到的和听到的（让你能理解负责的答案）6、交流 我相信，被打量比被忽略要好 讲清楚自己想要说的内容（可以写出大纲、撰写文档） 了解你的听众（了解他们需要什么） 选择时机 选择风格（让你的风格适合你的听众） 让文档美观（你的主意很重要，让他们以美观的方式传递到你的听众） 让听众参与 做倾听者 回复他人 你说什么和你怎么说同样重要 电子邮件交流：1）发送前进行校对2）检查拼写3）让格式保持简单4）让在你知道对方能够阅读rick-text或HTML格式的邮件的情况下使用这些格式，纯文本是通用的5）设法让引文减少至最少第二章 注重实效的途径7、重复的危害 可靠的开发软件、并让我们的开发更易于理解和维护的唯一途径，是尊徐我们称之为DRY的原则：系统中的每一项知识都必须具有单一、无歧义、权威的表示。 DRY - Dont Repeat Yourself. 在两个或更多地方表达同一事物时，若果你改变其中一处，你必须记得改变其他各处 重复范畴：1）强加的重复：开发者觉得他们无可选择-环境似乎要求重复2）无意的重复：开发者没有意识到他们在重复信息 开发过程中，会因为性能原因而选择违反DRY原则，这经常会发生在需要缓存数据，以避免重复昂贵的操作。诀窍是：使影响局部化。3）无耐性的重复：开发者偷懒，他们重复，因为似乎那样更容易 时间压力：驱使最优秀的人走捷径的力量 一种最容易检测和处理的重复形式，此时需要你接受训练，并愿意为避免以后的痛苦而预先花一些时间4）开发者之间的重复：同一团队（或不同团队）的几个人重复了同样的信息 最难检测和处理的重复 处理此问题的最佳方式：鼓励开发者相互进行主动的交流（论坛，交流组） Make It Easy to Reuse(让复用变得容易)8、正交性 如果两条直线相交成直角，他们就是正交，比如坐标轴。用向量的术语说，这两条直线互不影响。沿着某一条直线移动，你投影到另一条直线的位置不变。 非正交系统的改变与控制更复杂 Eliminate Effects Between Unrelated Things (消除无关事物之间的影响) 我们要设计自足的组件：独立，具有单一、良好的定义的目的和Constantine，称之为内聚（cohesion） 正交系统的优点：1）提高生产效率 改动得以局部化，开发时间和测试时间降低 正交的途径还能够促进复用 若果对正交的组件进行组合，生产率会有相当微妙的提高2）降低风险 正交的途径能降低任何开发中固有的风险 有问题的代码区域被隔离开 使系统更健壮 正交系统很可能得到更好的测试 不会与特定的供应商、产品、平台紧绑在一起 在工作中应用正交原则的几种方式：1）项目团队2）设计3）工具箱与库（EJB，面向方面编程AOP）4）编码 让你的代码保持解耦 避免使用全局数据 避免编写相似的函数5）测试6）文档：坐标轴是内容合表现形式9、可撤销性 如果某个想法是你唯一的想法，在没有什么比这更危险的事情了。 There are No Final Decisions 每当有两种可能结果的牙合反应发生时，宇宙就会被克隆。在其中一个宇宙中个，事件发生，另一个宇宙中，事件不发生。薛定谔的猫：在一个封闭的盒子中有一只猫，还有一个放射性粒子，这个粒子有50%的机会裂变成两个粒子，若果发生裂变，则猫被杀死；如果没有，则猫没有事。那么，猫是死是活？根据薛定谔的理论，答案是”都是“。只有打开盒子时，你才知道你在哪一个宇宙里。10、曳光弹 Use Tracer Bullets to Find the Target. 曳光代码方法的优点：1）用户能够及早看到能工作的东西2）开发者构建了一个他们能在其中工作的结构3）你有了一个集成平台4）你有了可用于演示的东西5）你将更能够感受到工作的进展11、原型与便笺 Prototype to Learn 在构建原型时，可以忽略的细节：1）正确性2）完整性3）健壮性4）风格12、领域语言 语言的界限就是一个人的世界的界限 计算机语言会影响你思考问题的方式，以及你看待交流的方式 Program Close to the Problem domain 13、估算 在进行估算的过程中，你将会加深对你的程序所处的世界的理解 通过学习估算，并将此技能发展到你对食物的数量级有直觉的程度，你就能展现出一种魔法般的能力，确定他们的可行性 Estimate to Avoid Surprises 进行估算时，要注意解答问题的语境（精确/大概）1）多准确才足够准确2）估算来自哪里：已问题模型为基础3）理解提问内容4）建立系统的模型5）把模型分解为组件6）给每个参数指定值7）计算答案8）追踪你的估算能力9）在被要求进行估算时说什么第三章 基本工具 工具放大你的才干。工具越好，你越是能更好的掌握他们的用户，你的生产力就越高 让需要驱动你的采购14、纯文本的威力 Keep Knowledge in Plain Text 缺点：1）与压缩的二进制格式相比，存储纯文本所需空间更多2）要解释及处理纯文本文件，计算上的代价可能更昂贵 优点：1）保证不过时2）杠杆作用3）更易于测试 Unix哲学：提供”锋利“的小工具，其中每一样都意在把一件事情做好（面向行的纯文本文件）15、shell游戏 User the Power of Command Shells16、强力编辑 编辑器的特性：1）可配置2）可扩展3）可编程17、源码控制 进步远非由变化组成，而是取决于好记星。不能记住过去的人，被判重复过去。 Always Use Source Code Control。18、调试 调试的心理学Fix the Problem, Not the Blame 调试的思维方式最容易欺骗的人是一个人自己 橡皮鸭：找到问题的原因的一种非常简单、却又特别有用的技术，是向别人解释他 Dont Assueme it - Prove It.第四章 注重实效的偏执 You Cant Write Perfect Software 当每个人都确实要对你不利时，偏执就是一个好主意21、按合约设计 没有什么比常识和坦率更让人感到惊讶 按合约设计：一种简单而强大的技术，他关注的是用文档记载（并约定）软件模块的权利与责任，以确保程序正确性 Design with Contracts 断言不能沿着集成层次向下遗传 出错时要偏向消费者，这是我们对行为的保证22、死程序不说谎 Crash Early23、断言式编程 在自责中有一种满足感。当我们责备自己时，会觉得再没有人有权责备我们。 这绝不会发生。我们不要这样自我欺骗，特别是在编码时 If It Cant Happen, Use Assertions to Ensure That It Wont.24、何时使用异常 Use Exception for Exceptional Problems25、怎样配平资源 Finish What You Start 第五章 弯曲，或折断 保持灵活的一种好办法是少写代码26、解耦与得墨忒耳法则 好篱笆促成好邻居 函数的得墨忒耳法则视图使任何给定程序中的模块之间的耦合减至最少27、元程序设计 再多的天才也无法胜过对细节的专注 我们可以让我们的代码变得高度可配置和”软和“-也就是容易适应变化 Configure, Dont Integrate Put Abstractions in Code, Details in Metadata 不要让你的项目（或你的职业生涯）走上渡渡鸟的道路（毛里求斯岛上的渡渡鸟不能适应人类和他们的家畜的出现，很久就灭绝了。这是人类记载的第一起物种灭绝）28、时间耦合 时间是软件架构的一个常常被忽视的方面。时间有两个方面对我们很重要：并发（事情在同一时间发生）和次序（事情在时间中的相对位置） 我们需要容许并发，并考虑解除任何时间或次序上的依赖 Analyze Workflow to Improve Concurrency Always Design for Concurrency29、它只是视图 那人依然只听到，他想要听到的东西，而不顾其他。啦-啦-啦 不要把程序写成一个大块，应该”分而治之“，吧程序划分成模块 模块的一个好定义就是，他具有单一的、定义良好的责任 让视图与模型分离30、黑板 黑板系统让我们完全解除了我们的对象之间的耦合，并提供了一个”论坛“，知识消费者和生产者可以在哪里匿名、异步地交换数据，还能减少我们必须编写的代码的数量 可以用黑板协调完全不同的事实和因素，同时又使个参与方保持独立、甚至隔离。第六章 当你编码时靠巧合编程 应该避免靠巧合编程-依靠运气和偶然的成功-而要深思熟虑的编程 Dont Program by Coincidence 怎样深思熟虑的编程：1）总是意识到你在做什么2）不要盲目的编程3）按照计划行事4）依靠可靠的事物5）为你的假定建立文档6）不要只是测试你的代码，还要测试你的假定7）为你的工作划分优先级。把时间花在重要的方面。32、算法速率 Estimate the Order of Your Algorithms Test Your Estimates33、重构 周遭所见，皆是变异与衰败 代码需要演化：他不是静态的事物 不要对改动犹豫不决 代码若具有如下特征，则应该考虑重构：1）重复2）非正交的设计3）过时的知识4）性能 Refactor Early, Refactor Often 就其核心而言，重构就是重新设计 怎样进行利大于弊的重构：1）不要试图在重构的同时增加功能2）在开始重构之前，确保你拥有良好的测试。（尽可能经常运行这些测试，如果你的改动破坏了任何东西，你很快可以知道）34、易于测试的代码 单元测试 Test Your Software, or Your Users Will35、邪恶的向导 Dont Use Wizard Code You Dont Understand 第七章 在项目开始之前36、需求只坑 完美，不是在没有什么需要增加，而是在没有什么需要去掉时达到的 Dont Gather Requirements - Dig for Them Work With a User to Think Like a User Abstractions live longer than details Use a project glossary 37、解开不可能解开的谜题 解开谜题的关键：确定加给你各种约束，并确定你确实拥有自由度 Dont think outside the box - find the box 我们可以先确定最为严格的约束，然后再在其中考虑其余约束 很多时候，对需求的重新诠释能让整个问题全部消失-就像戈尔迪斯结38、等你准备好 有时犹豫的人会得以保全 Listen