《程序员修炼之道-从小工到专家》

一.注重实效的哲学 1. 我的源码让猫给吃了 Provide Options,Don't Make Lame Excuess 提供各种选择，不要找蹩脚的借口

2017-12-15
IT人文

思维导图版

一.注重实效的哲学

  1. 我的源码让猫给吃了
    1. Provide Options,Don’t Make Lame Excuess 提供各种选择，不要找蹩脚的借口
  2. 软件的熵
    1. Don’t Live with Broken WIndows 不要容忍破窗户
    2. 不要容忍低劣的设计，错误的决策，或是糟糕的代码,如果没有足够的时间可以把出现的问题添加注释
  3. 石头汤和煮青蛙
    1. Be a Catalyst for Change 做变化的催化剂
    2. 设计出你可以合理要求的东西，好好开发它，一旦完成，就拿给大家看，让大家大吃一惊 让他们瞥见未来，你就能让他们聚集在你周围
    3. Remember the Big Picture 记住大图景
    4. 要持续不断地观察周围发生的事情，而不只是你自己在做的事情
  4. 足够好的软件
    1. 让你的用户参与权衡
    2. Make Quality a Requirements Issue 使质量成为需求问题
    3. 制作的系统的范围和质量应该作为系统需求的一部分规定下来
    4. 知道何时止步
    5. 不要因为过度修饰和过于求精而损毁完好的程序
  5. 你的知识产权
    1. Invest Regularly in Your Konwledge Portfolio 定期为你的知识资产投资
    2. 定期投资
    3. 每季度读一本技术书籍
    4. 多元化
    5. 阅读非技术书籍
    6. 重新评估和平衡
    7. Critically Analyze What You Read and Hear 批判地分析你读到的和听到的
  6. 交流
    1. It’s Both What You Say and the Way You Say It 你说什么和你怎么说同样重要
    2. 了解听众，选择时机，选择合适的交流风格，做倾听者，懂得如何回复他人

二.注重实效的途径

  1. 重复的危害
    1. Don’t Repeat Yourself 不要重复你自己
    2. 强加的重复
    3. 开发者觉得他们无可选择-环境似乎要求重复
      1. 包括代码的注释，代码文档
    4. 无意的重复
    5. 开发者没有意识到他们在重复信息
    6. 无耐性的重复
    7. 开发者偷懒，因为那样似乎更容易
      1. 欲速则不达
    8. 开发者之间的重复
    9. 统一团队（或不同团队）的几个人重复了同样的信息
      1. 鼓励开发者相互进行主动的交流阅读对方的源码和文档
    10. Make It Easy to Reuse 让复用变得容易
  2. 正交性
    1. Eliminate Effect Between Unrelated Things 消除无关事物之间的影响
    2. 高内聚低耦合
    3. 让你的代码保持解耦
    4. 避免使用全局数据
    5. 避免编写相似的函数
  3. 可撤销性
    1. 变动不一定会严苛，但随着时间的流逝，随着项目取得进展，当每一项关键决策的做出，选择的余地会越来越小
    2. There Are No Final Decisions 不存在最终决策
    3. 事物总会随着时间发生改变
  4. 4.曳光弹
    1. Use Tracer Bullet to Find the Target 用曳光弹找到目标
    2. 传统：面对从未构建过的项目时，面对着大量未知的事物，经典的做法是把系统定死（制作大量文档，逐一列出各项需求等）但低效
    3. 曳光代码：新项目创建时搭建框架代码，逐渐为框架添加功能正是这样一个过程
    4. 曳光开发VS原型模式
    5. 原型中的代码是用过就扔的，寻求以最快的速度展示产品，甚至会采用更高级的语言
    6. 曳光代码虽然简约，但却是完成的，它拥有完整的错误检查与异常处理，只不过是功能不全而已
  5. 原型与便笺
    1. Prototype to Learn 为了学习而制作原型
  6. 领域语言
    1. Program Close to the Problem domain 靠近问题领域编程
  7. 估算
    1. Estimate to Avoid Surprise 估算，以避免发生意外
    2. 检测需求
    3. 分析风险
    4. 设计，实现，集成
    5. 向用户确认
    6. Iterate the Schedule with the Code 通过代码对进度表进行迭代

三.基本工具

  1. 纯文本的威力
  2. shell游戏
  3. 强力编辑
  4. 源码控制
  5. 调试
  6. 文本操纵
  7. 代码生成器

四.注重实效的偏执

  1. 按合约设计
    1. Design with Contracts 通过合约进行设计
    2. 客户与供应商必须就权利与责任达成共识
  2. 死程序不说谎
    1. Crash Early 早崩溃
    2. 想要确保找出bug的过程中，不会造成任何破坏，所以我们设法经常检查各种事项，并在程序出问题时终止程序
  3. 断言式编程
    1. If It Can’t Happen，Use Assertions to Ensure That It Won’t 如果它不可能发生，用断言确保它不会发生
    2. 断言是一种调试设施
    3. 沿途检查的轻松方法——编写主动校验你的假定代码
  4. 何时使用异常
    1. Use Exceptions for Exceptional Problems 将异常用于异常的问题
  5. 怎样配平资源
    1. Finish What Your Start 要有始有终
    2. 当你无法配平资源时，为内存分配设立一个语义不变项

五.弯曲，或者折断

六.当你编码时

  1. 避免靠巧合编程

    1. Don’t Program by Coincidence 不要靠巧合编程
    2. 总是意识到你在做什么
    3. 不要盲目编程
    4. 按照计划行事
    5. 依靠可靠事物，不要依赖巧合和假定
    6. 为你的假定建立文档，有助于澄清头脑中的假定，并且利于把他们传达给别人
    7. 不要只是测试你的代码，还要测试你的假定
    8. 为你的工作划分优先级，把时间花在重要的方面
    9. 不要做历史的奴隶，不要让已有的代码支配将来的代码

  2. 算法速率

    1. Estimate the Order of Your Algorithms 估算你的算法的阶
    2. 估算算法使用的资源——时间，处理器，内存等
    3. 可以使用常识估算许多基本算法的阶
    4. 简单循环
    5. 嵌套循环
    6. 二分法
    7. 分而治之
    8. 组合
    9. Test Your Estimates 测试你的估算
    10. 即考虑理论问题，又考虑实践问题
  3. 重构
    1. Refactor Early，Refactor Often 早重构，常重构
    2. 重写，重做和重新架构代码合起来称为重构
    3. 需要代码重构的特征
    4. 重复
    5. 非正交的设计
    6. 过时的知识
    7. 性能
    8. 使用设计模式
    9. 不要试图在重构的同时增加功能
    10. 在开始重构之前，确保你拥有良好的测试。尽可能经常运行这些测试，如果你的改动破坏了任何东西，就能很快的发现
  4. 易于测试的代码
    1. Design to Test 为测试而设计
    2. 编写单元测试
    3. Test Your Software，or Your Users Will 测试你的软件，否则你的用户就得测试
  5. 邪恶的向导
    1. Don’t Use Wizard Code You Don’t Understand 不要使用你不理解的向导代码
    2. 如果你使用向导，却不理解它制作出的所有代码，你就无法控制你自己的应用

七.在项目开始之前

  1. 1.需求之坑
    1. Don’t Gather Requirement —— Dig for Them 不要收集需求——挖掘它们
    2. 学会挖掘需求
    3. 需求不是架构，需求不是设计，也不是用户界面。需求是需要
    4. 建立需求文档
    5. UML用例图
    6. Work with a User to Think Like a User 与用户一起工作，以像用户一样思考
    7. 能更深入的知道客户的需求是什么
    8. Abstractions Live Longer than Details 抽象比细节活的更久
    9. 制作需求文档不需要太过具体，好的需求文档会保持抽象
    10. Use a Project Glossary 使用项目词汇表
    11. 确保一致性
  2. 解开不可能解开的谜题
    1. Don’t Think Outside the Box——Find the Box 不要在盒子外面思考——要找到盒子
    2. 换个角度思考问题，或许会发现有更简单的解决办法
  3. 等你准备好
    1. Listen to Nagging Doubts——Start When You Ready 倾听反复出现的疑虑——等你准备好再开始
    2. 等待也是一种开始，只要判断好这不是拖延即可
  4. 规范陷阱
    1. 编写程序规范就是把需求归约到程序员能够接管的程度的过程，旨在解释并澄清系统的需求，消除主要的歧义
    2. Some Things Are Better Done than Described 对有些事情“做”胜于“描述”
    3. 不要编写过于详细的规范，可以让编码人员更好的发挥技巧。没有人为制造的限制，健康的开发过程鼓励把来自实现和测试的意见反馈到规范中
    4. 搜集需求，编写规范，开始编码所有这些步骤都不是孤立进行的规范和实现不过是同一过程——设计捕捉和编撰需求——的不同方面
  5. 圆圈与箭头
    1. Don’t Be a Slave to Formal Methods 不要做形式方法的奴隶
    2. 大多数形式方法结合图和某些说明文字来捕捉需求
    3. 形式方法似乎鼓励专门化
    4. 我们喜欢编写有适应能力的动态系统
    5. Expensive Tools Do Not Produce Better Designs 昂贵的工具不一定能制作出更好的设计

八.注重实效的项目

总结

  1. 完美，不是在没有什么需要增加，而是在没有什么需要去掉时达到
  2. 许多项目的失败都被归咎于项目范围的增大——也称为特性膨胀，蔓延特性论，或是需求蔓延
    1. 追踪需求
  3. 编程是一种技艺，一种需要用心学习的技艺
  4. 有事犹豫的人会得以保全
  5. 注重实效的程序员应该不断学习
  6. 当水平不够的时候，永远不能认识到那些朴素道理的重要