读书笔记 - 程序员修炼之道

2013-07-21 19:31

注重实效的程序员有哪些特征

  • 早期的采纳者/快速的改编者
  • 好奇
  • 批判的思考着
  • 有现实感
  • 多才多艺

70个提示

提示1

关心你的技艺 Care About Your Craft 如果你不在乎能否漂亮的开发软件,你又为何要耗费生命去开发软件呢

提示2

思考!你的工作 Think! About Your Work 关掉自动驾驶仪,接管操作。不断的批评和评估你的工作

提示3

提供各种选择,不要找蹩脚的借口 Provide Options, Don't Make Lame Excuses 要提供各种选择,而不是找借口。不要说事情做不到,说明能够做什么

提示4

不要容忍破窗户 Don't Live with Broken Windows 当你看到糟糕的设计,错误的决策和糟糕的代码时,修正它们

提示5

做变化的催化剂 Be a Catalyst for Change 你不能强迫别人改变,相反,要向他们展示未来可能会怎样,并帮助他们参与对未来的创造

提示6

记住大图景 Remember the Big Picture 不要太过于专注于细节,以致忘了查看你周围正在发生什么

提示7

使质量成为需求问题 Make Quality a Requirements Issue 让你的用户参与确定项目真正的质量需求

提示8

定期为你的知识资产投资 Invest Regularly in Your Knowledge Portfolio 让学习成为习惯

提示9

批判地分析你读到的和听到的 Critically Analyze What You Read and Hear 不要被供应商,媒体炒作或教条左右。要依据你自己的看法和你的项目的情况去对信息进行分析

提示10

你说什么和你怎么说同样重要 It‘s Both What You Say and the Way You Say It 如果你不能有效地向他人传达你的了不起的想法,这些想法就毫无用处

提示11

不要重复你自己 DRY Don't Repeat Yourself 系统中的每一项只是都必须具有单一、无歧义、权威的表示

提示12

让复用变得容易 Make It Easy to Reuse 如果复用很容易,人们就会去复用。创造一个支持复用的环境

提示13

消除无关事物之间的影响 Eliminate Effects Between Unrelated Things 设计自足、独立、并具有单一、良好定义的目的的组件

提示14

不存在最终决策 There Are No Final Decisions 没有决策是浇筑在石头上的,相反,要把每项决策都视为是写在沙滩上的,并为变化做好计划

提示15

用曳光弹找到目标 Use Tracer Bullets to Find the Target 曳光弹能通过试验各种事物并检查它们离目标多远来让你追踪目标

提示16

为了学习而制作模型 Prototype to Learn 原型制作是一种学习经验,其价值并不在于所产生的代码,而是所学到的经验教训

提示17

靠近问题领域编程 Program Close to the Problem domain 用你的用户的语言进行设计和编码

提示18

估算,以避免发生意外 Estimate to Avoid Surprises 在着手之前先进行估算,你将提前发现潜在的问题

提示19

通过代码对进度表进行迭代 Iterate the Schedule with the Code 用你在进行实现时获得的经验提炼项目的时间标度

提示20

用纯文本保存知识 Keep Knowledge in Plain Text 纯文本永不过时,它能够帮助你有效利用你的工作,并简化调试和测试

提示21

使用Shell的力量 Use the Power of Command Shell 当图形界面无能为力时使用shell

提示22

用好一种编辑器 Use a Single Editor Well 编辑器应该是你手的延伸,确保你的编辑器是可配置、可扩展和可编程的

提示23

总是使用源码控制 Always Use Source Code Control

提示24

要修正问题,而不是发出指责 Fix the Problem, Not the Blame bug是你的过错还是别人的过错,并不是很有关系,它仍然是你的问题,它仍然需要修正

提示25

不要恐慌 Don't Panic When Debuging 做一次深呼吸,思考什么可能是bug的原因

提示26

Select 没有问题 Select Isn't Problem 在OS或编译器或者是第三方产品或库中很少发现bug,bug很可能在应用中

提示27

不要假定,要证明 Don't Assume It, Prove It

提示28

学习一种文本操纵语言 Learn a Text Manuipulation Language 你用每天的很大一部分时间处理文本,为什么不让计算机替你完成部分工作呢

提示29

编写能写代码的代码 Write Code that Writes Code 代码生成器能提高你的生产率,并有助于避免重复

提示30

你不可能写出完美的软件 You Can't Write Perfect Software 软件不可能完美,保护你的代码和用户,使他们免于能够预见的错误

提示31

通过合约进行设计 Design with Contracts 使用合约建立文档,并检验代码所做的事情正好是它声明要做的

提示32

早崩溃 Crash Early 死程序造成的危害要比有问题的程序要小得多

提示33

用断言避免不可能发生的事情 Use Assertions to Prevent the Impossible 断言验证你的各种假定。在一个不确定的世界里,用断言保护你的代码

提示34

将异常用于异常的问题 Use Exception for Exceptional Problems 异常可能会遭受可读性和可维护性问题的折磨

提示35

要有始有终 Finish What You Start 只要可能,分配某资源的例程或对象也应该负责解除其分配

提示36

使模块之间的耦合减少至最少 Minimize Coupling Between Modules 通过编写羞怯的代码并应用德墨忒尔法则来避免耦合

提示37

要配置不要集成 Configure, Don't Integrate 要将应用的各种技术选择实现为配置选项,而不是通过集成或工程方法实现

提示38

将抽象放进代码,细节放进元数据 Put Abstractions in Code, Details in Metadata 为一般情况编程,将细节放在被编译的代码库之外

提示39

分析工作流,以改善并发性 Analyze Workflow to Improve Concurrency 利用你的用户的工作流中的并发性

提示40

用服务进行设计 Design Using Services 根据服务-独立的、在良好定义、一致的接口之后的并发对象-进行设计

提示41

总是为并发进行设计 Always Design for Concurrency 容许并发,你将会设计出更整洁、具有更少假定的接口

提示42

使视图与模型分离 Separate Views from Models 要根据模型和视图设计你的应用,从而以低廉的代码获取灵活性

提示43

用黑板协调工作流 Use Blackboards to Coordinate Workflow 用黑板协调完全不同的事实和因素,同时又使各参与方保持独立和隔离

提示44

不要靠巧合编程 Don't Program by Coincidence 只依靠可靠的事物,注意偶发的复杂性,不要把幸运的巧合和有目的的计划混为一谈

提示45

估算你的算法的复杂度 Estimate the Order of Your Algorithms 在你编写代码之前,先大致估算事情需要多长时间

提示46

测试你的估算 Test Your Estimate 对算法的数学分析并不会告诉你每一件事情,在你的代码的目标环境中测定它的速度

提示47

早重构,常重构 Refactor Early, Refactor Often 对代码重写,重做,重新架构,要铲除问题的根源

提示48

为测试而设计 Design to Test 在你还没有编写代码时就开始思考测试问题

提示49

测试你的软件,否则你的用户就得测试 Test Your Software, or Your Users Will 无情地测试,不要让你的用户为你查找bug

提示50

不要使用你不理解的向导代码 Don't Use Wizard Code You Don't understand 向导可以生成大量代码,在你把它们合并进你的项目之前,确保你理解全部这些代码

提示51

不要搜集它们 - 挖掘他们 Don't Gather Requirements - Dig for Them 需求很少存在于表面,它们深深的埋藏在层层假定,误解和政治手段下面

提示52

与用户一同工作,像用户一样思考 Work with a User to Think Like a User 要了解系统实际上将如何被使用,这是最好的方法

提示53

抽象比细节获得更长久 Abstractions Live Longer than Details 投资于抽象,而不是细节,抽象能在来自不同的实现和新技术的变化的攻击之下生存下去

提示54

使用项目词汇表 User a Project Glossary 创建并维护项目中使用的专有术语和词汇的单一信息源

提示55

不要在盒子外面思考 - 要找到盒子 Don't Think Outside the Box - Find the Box

提示56

等你准备好再开始 Start When You're Ready 你的一生都在积累经验,不要忽视反复出现的疑虑

提示57

对有些事情做胜于描述 Some Things Are Better Done than Described 不要掉进规范的螺旋 - 在某个时刻,你需要开始编码

提示58

不要做形式方法的奴隶 Don't Be a Slave to Formal Methods 如果你没有把某项技术放进里的开发实践和能力的语境中,不要盲目的采用它

提示59

昂贵的工具不一定能制作出更好的设计 Costly Tools Don't Produce Better Designs 小心供应商的炒作,行业教条,以及价格标签的诱惑,要根据工具的价值判断它们

提示60

围绕功能组织团队 Organize Teams Around Functionality 不要把设计师与程序员分开,也不要把测试员和数据建模员分开,按照构建代码的方式构建团队

提示61

不要使用手工流程 Don't Use Manual Procedures 使用shell脚本或批处理

提示62

早测试,常测试,自动测试 Test Early, Test Often, Test Automatically 每次构件运行的测试有效的多

提示63

要通过全部测试,编码才算完成 Coding Ain't Done Til All the Tests Run yes。。

提示64

通过蓄意破坏测试你的测试 Use Saboteurs to Test Your Testing 与单独的软件副本上故意引入bug,以检测测试是否抓住它们

提示65

测试状态覆盖,而不是代码覆盖 Test State Coverage, Not Code Coverage 确定并测试重要的程序状态,只是测试代码是不够的

提示66

一个bug只抓一次 Find Bugs Once 一旦测试员找到一个bug,这应该是测试员最后一次找到它,此后自动测试应该对其进行检查

提示67

英语就是一种编程语言 English is Just a Programming Language 像你编写代码一样编写文档,遵守DRY原则,使用元数据,MVC,自动生成等

提示68

把文档建在里面,不要栓在外面 Build Documentation In, Don't Bolt It On 与代码分离的文档不太可能被修正和更新

提示69

温和地超出用户的期望 Gently Exceed Your User's Expectations 要理解你的用户的期望,然后给他们的东西要多那么一点点

提示70

在你的作品上签名 Sign Your Work 签个名吗。。

检查清单

管理你的知识资产

  • 定期投资
  • 多元化
  • 管理风险
  • 低买高卖
  • 重新评估和平衡

管理你的知识资产 - 目标

  • 每年至少学习一种新语言
  • 每季度阅读一本技术书籍
  • 也要阅读非技术书籍
  • 上课
  • 参加本地用户组织
  • 实验不同的环境
  • 跟上潮流
  • 上网。。

了解听众

  • 你想让他们学到什么
  • 他们对你讲的什么感兴趣
  • 他们有多富有经验
  • 他们想要多少细节
  • 你想要让谁拥有这些信息
  • 你如何促使他们听你说话

重复是怎样发生的

  • 强加的重复
  • 无意的重复
  • 无耐性的重复
  • 开发者之间的重复

怎样维持正交性

  • 设计独立、良好定义的组件
  • 使你的代码保持解耦
  • 避免使用全局数据
  • 重构相似的函数

应制作原型的事物

  • 架构
  • 已有系统中的新功能
  • 外部数据的结构或内容
  • 第三方工具或组件
  • 性能问题
  • 用户界面设计

架构问题

  • 责任是否得到了良好定义
  • 写作是否得到了良好定义
  • 耦合是否得以最小化
  • 你能否确定潜在的重复
  • 接口定义和各项约束是否可接受
  • 模块能否在需要时访问所需数据

函数的得墨特尔法则

某个对象只调用以下情景的方法:

  • 它自身
  • 传入的任何对象
  • 它创建的对象
  • 组件对象

怎样深思熟虑的编程

  • 总是意识到你在做什么
  • 不要盲目的编程
  • 按照计划行事
  • 依靠可靠的事物
  • 为你的假定建立文档
  • 不要只测试你的代码,还要测试你的假定
  • 为你的工作划分优先级
  • 不要做历史的奴隶

何时进行重构

  • 你发现了对DRY原则的违反
  • 你发现事物可以更为正交
  • 你的知识扩展了
  • 需求演变了
  • 你需要改善性能

遇到不可能解决的问题时?

  • 有更容易的方法吗
  • 我是在解决正确的问题吗
  • 这件事情为什么是一个问题
  • 是什么使它如此难以解决
  • 它必须以这种方式完成吗
  • 它真的必须完成吗

测试的各个方面

  • 单元测试
  • 集成测试
  • 验证和校验
  • 资源耗尽、错误和恢复
  • 性能测试
  • 可用性测试
  • 对测试自身进行测试

目录

第1章 注重实效的哲学

  • 处理问题,寻求解决方案时的态度,风格,哲学。
  • 注重实效的编程源于注重实效的思考的哲学。

1 我的源码让猫给吃了

2 软件的熵

3 石头汤和煮青蛙

4 足够好的软件

5 你的知识资产

6 交流

第2章 注重实效的途径

7 重复的危害

8 正交性

9 可撤销性

10 曳光弹

11 原型与便签

12 领域语言

13 估算

第3章 基本工具

14 纯文本的威力

15 shell游戏

16 强力编辑

17 源码控制

18 调试

19 文本模拟

20 代码生成器

第4章注重实效的偏执

21 按合约设计

22 死程序不说谎

23 断言式编程

24 合适使用异常

25 怎样配平资源

第5章 弯曲或折断

26 解耦与得墨忒儿法则

27 元程序设计

28 时间耦合

29 它只是视图

30 黑板

第6章 当你编码时

31 靠巧合编程

32 算法速率

33 重构

34 易于测试的代码

35 邪恶的向导

第7章 在项目开始之前

36 需求之坑

37 解开不可能解开的谜题

38 等你准备好

39 规范陷阱

40 圆圈与箭头

第8章 注重实效的项目

41 注重实效的团队

42 无处不在的自动化

43 无情的测试

44 全都是写

45 极大的期望

46 傲慢与偏见