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

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

《程序员修炼之道阅读笔记.docx》由会员分享，可在线阅读，更多相关《程序员修炼之道阅读笔记.docx（11页珍藏版）》请在冰豆网上搜索。

程序员修炼之道阅读笔记

第一章注重实效的哲学

1、注重实效的程序员的特征：

是他们处理问题、寻求解决方案时的态度、风格、哲学。

∙设法把问题放在更大的语境中，设法注意更大的图景

∙对所做的每件事情负责

∙接受变化，拥抱变化

∙理解工作的语境

∙广泛的知识和经验基础

∙交流

1、我的源码让猫给吃了

∙在所有弱点中，最大的弱点就是害怕暴露弱点。

∙为自己的行为负责

∙对我们的无知和错误，应该诚实、坦率

∙预期到超过自己能力范围的风险，可以不必承担，若没有预期到已经发生，则必须承担

∙提供各种选择，不要找蹩脚的接口（ProvideOptions,Don'tMakeLameExcuses.）

∙任何谈话可以先预演一遍，预知一下结果

∙不要说做不到，要想有什么解决方案

2、软件的熵

∙熵：

来自物理学的概念，指某个系统中的“无序”的总量

∙促生软件腐烂的一个重要因素：

开发项目时的心理（文化）

∙不要容忍破窗户（Don'tLiveWithBrokenWindows）

3、石头汤与煮青蛙

∙当遇到请求许可“拖延和漠然”，设计出可以合理要求的东西

∙做变化的催化剂（BeaCatalystforChange）

∙记住大图景（RemembertheBigPicture）

∙留心大图景，持续不断地观察周围发生的事情，而不只是你自己在做的事情

∙当你设法催生变化时，你能否确定是在做石头汤还是青蛙汤？

决策是主观还是客观的？

4、足够好的软件

∙欲求更好，常把好事变糟（李尔王）

∙影响我们控制质量的因素：

时间、技术、急躁

∙缺乏职业素养的做法：

1）无视用户的需求，一味的给程序增加新特性，或一次一次的润饰代码

2）许诺不可能兑现的时间标度（timescale）

3）为赶上最后期限而消减基本的工程内容

∙制作系统的范围和质量应该作为系统需求的一部分规定下来

∙使质量称为需求问题（MakeQualityaRequirementsIssue）

∙给用户的东西，要及早让他们使用，他们的反馈常常会吧你引向更好的最终解决方案

∙如果不懂得何时止步，绘画会迷失在绘制中（不要因为过度修饰和过于求精而毁损完好的程序）

5、你的知识资产

∙知识上的投资总能得到最好的回报（本杰明。

富兰克林）

∙知识和经验是有时效的资产（expiringasset）

∙定期为你的知识资产投资（InvestRegularlyinYourKnowledgePorfolio）

∙目标（持续投入）：

1）每年至少学习一种新语言（拓宽思维）

2）每季度阅读一本技术书籍（拓宽范围）

3）也要阅读非技术书籍（了解人）

4）上课

5）参加本地用户组织

6）实验不同的环境

7）跟上潮流（了解新技术）

8）上网

∙批判的思考你读到的和听到的（让你能理解负责的答案）

6、交流

∙我相信，被打量比被忽略要好

∙讲清楚自己想要说的内容（可以写出大纲、撰写文档）

∙了解你的听众（了解他们需要什么）

∙选择时机

∙选择风格（让你的风格适合你的听众）

∙让文档美观（你的主意很重要，让他们以美观的方式传递到你的听众）

∙让听众参与

∙做倾听者

∙回复他人

∙你说什么和你怎么说同样重要

∙电子邮件交流：

1）发送前进行校对

2）检查拼写

3）让格式保持简单

4）让在你知道对方能够阅读rick-text或HTML格式的邮件的情况下使用这些格式，纯文本是通用的

5）设法让引文减少至最少

第二章注重实效的途径

7、重复的危害

∙可靠的开发软件、并让我们的开发更易于理解和维护的唯一途径，是尊徐我们称之为DRY的原则：

系统中的每一项知识都必须具有单一、无歧义、权威的表示。

∙DRY-Don'tRepeatYourself.<不要重复你自己>

∙在两个或更多地方表达同一事物时，若果你改变其中一处，你必须记得改变其他各处

∙重复范畴：

1）强加的重复：

开发者觉得他们无可选择------环境似乎要求重复

2）无意的重复：

开发者没有意识到他们在重复信息

∙开发过程中，会因为性能原因而选择违反DRY原则，这经常会发生在需要缓存数据，以避免重复昂贵的操作。

诀窍是：

使影响局部化。

3）无耐性的重复：

开发者偷懒，他们重复，因为似乎那样更容易

∙时间压力：

驱使最优秀的人走捷径的力量

∙一种最容易检测和处理的重复形式，此时需要你接受训练，并愿意为避免以后的痛苦而预先花一些时间

4）开发者之间的重复：

同一团队（或不同团队）的几个人重复了同样的信息

∙最难检测和处理的重复

∙处理此问题的最佳方式：

鼓励开发者相互进行主动的交流（论坛，交流组）

∙MakeItEasytoReuse（让复用变得容易）

8、正交性

∙如果两条直线相交成直角，他们就是正交，比如坐标轴。

用向量的术语说，这两条直线互不影响。

沿着某一条直线移动，你投影到另一条直线的位置不变。

∙非正交系统的改变与控制更复杂

∙EliminateEffectsBetweenUnrelatedThings（消除无关事物之间的影响）

∙我们要设计自足的组件：

独立，具有单一、良好的定义的目的和Constantine，称之为内聚（cohesion）

∙正交系统的优点：

1）提高生产效率

∙改动得以局部化，开发时间和测试时间降低

∙正交的途径还能够促进复用

∙若果对正交的组件进行组合，生产率会有相当微妙的提高

2）降低风险

∙正交的途径能降低任何开发中固有的风险

∙有问题的代码区域被隔离开

∙使系统更健壮

∙正交系统很可能得到更好的测试

∙不会与特定的供应商、产品、平台紧绑在一起

∙在工作中应用正交原则的几种方式：

1）项目团队

2）设计

3）工具箱与库（EJB，面向方面编程AOP）

4）编码

∙让你的代码保持解耦

∙避免使用全局数据

∙避免编写相似的函数

5）测试

6）文档：

坐标轴是内容合表现形式

9、可撤销性

∙如果某个想法是你唯一的想法，在没有什么比这更危险的事情了。

∙ThereareNoFinalDecisions<不存在最终决策>

∙每当有两种可能结果的牙合反应发生时，宇宙就会被克隆。

在其中一个宇宙中个，事件发生，另一个宇宙中，事件不发生。

薛定谔的猫：

在一个封闭的盒子中有一只猫，还有一个放射性粒子，这个粒子有50%的机会裂变成两个粒子，若果发生裂变，则猫被杀死；如果没有，则猫没有事。

那么，猫是死是活？

根据薛定谔的理论，答案是”都是“。

只有打开盒子时，你才知道你在哪一个宇宙里。

10、曳光弹

∙UseTracerBulletstoFindtheTarget.<用曳光弹找到目标>

∙曳光代码方法的优点：

1）用户能够及早看到能工作的东西

2）开发者构建了一个他们能在其中工作的结构

3）你有了一个集成平台

4）你有了可用于演示的东西

5）你将更能够感受到工作的进展

11、原型与便笺

∙PrototypetoLearn<为了学习而制作模型>

∙在构建原型时，可以忽略的细节：

1）正确性

2）完整性

3）健壮性

4）风格

12、领域语言

∙语言的界限就是一个人的世界的界限

∙计算机语言会影响你思考问题的方式，以及你看待交流的方式

∙ProgramClosetotheProblemdomain<靠近问题领域编程>

13、估算

∙在进行估算的过程中，你将会加深对你的程序所处的世界的理解

∙通过学习估算，并将此技能发展到你对食物的数量级有直觉的程度，你就能展现出一种魔法般的能力，确定他们的可行性

∙EstimatetoAvoidSurprises<估算，已避免发生意外>

∙进行估算时，要注意解答问题的语境（精确/大概）

1）多准确才足够准确

2）估算来自哪里：

已问题模型为基础

3）理解提问内容

4）建立系统的模型

5）把模型分解为组件

6）给每个参数指定值

7）计算答案

8）追踪你的估算能力

9）在被要求进行估算时说什么

第三章基本工具

∙工具放大你的才干。

工具越好，你越是能更好的掌握他们的用户，你的生产力就越高

∙让需要驱动你的采购

14、纯文本的威力

∙KeepKnowledgeinPlainText<用纯文本保存知识>

∙缺点：

1）与压缩的二进制格式相比，存储纯文本所需空间更多

2）要解释及处理纯文本文件，计算上的代价可能更昂贵

∙优点：

1）保证不过时

2）杠杆作用

3）更易于测试

∙Unix哲学：

提供”锋利“的小工具，其中每一样都意在把一件事情做好（面向行的纯文本文件）

15、shell游戏

∙UserthePowerofCommandShells<利用命令shell的力量>

16、强力编辑

∙编辑器的特性：

1）可配置

2）可扩展

3）可编程

17、源码控制

∙进步远非由变化组成，而是取决于好记星。

不能记住过去的人，被判重复过去。

∙AlwaysUseSourceCodeControl。

<总是使用源码控制>

18、调试

∙调试的心理学

FixtheProblem,NottheBlame<要修正问题，而不是发出指责>

∙调试的思维方式

最容易欺骗的人是一个人自己

∙橡皮鸭：

找到问题的原因的一种非常简单、却又特别有用的技术，是向别人解释他

∙Don'tAssuemeit-ProveIt.<不要假定，要证明>

第四章注重实效的偏执

∙YouCan'tWritePerfectSoftware<你不可能写出完美的软件>

∙当每个人都确实要对你不利时，偏执就是一个好主意

21、按合约设计

∙没有什么比常识和坦率更让人感到惊讶

∙按合约设计：

一种简单而强大的技术，他关注的是用文档记载（并约定）软件模块的权利与责任，以确保程序正确性

∙DesignwithContracts<通过合约进行设计>

∙断言不能沿着集成层次向下遗传

∙出错时要偏向消费者，这是我们对行为的保证

22、死程序不说谎

∙CrashEarly<早崩溃>

23、断言式编程

∙在自责中有一种满足感。

当我们责备自己时，会觉得再没有人有权责备我们。

∙这绝不会发生。

。

。

我们不要这样自我欺骗，特别是在编码时

∙IfItCan'tHappen,UseAssertionstoEnsureThatItWon't.<如果他不可能发生，用断言确保他不会发生>

24、何时使用异常

∙UseExceptionforExceptionalProblems<将异常用于异常的问题>

25、怎样配平资源

∙FinishWhatYouStart<要有始有终>

第五章弯曲，或折断

∙保持灵活的一种好办法是少写代码

26、解耦与得墨忒耳法则

∙好篱笆促成好邻居

∙函数的得墨忒耳法则视图使任何给定程序中的模块之间的耦合减至最少

27、元程序设计

∙再多的天才也无法胜过对细节的专注

∙我们可以让我们的代码变得高度可配置和”软和“------也就是容易适应变化

∙Configure,Don'tIntegrate<要配置，不要集成>

∙PutAbstractionsinCode,DetailsinMetadata<将抽象放进代码，细节放进元数据>

∙不要让你的项目（或你的职业生涯）走上渡渡鸟的道路（毛里求斯岛上的渡渡鸟不能适应人类和他们的家畜的出现，很久就灭绝了。

这是人类记载的第一起物种灭绝）

28、时间耦合

∙时间是软件架构的一个常常被忽视的方面。

时间有两个方面对我们很重要：

并发（事情在同一时间发生）和次序（事情在时间中的相对位置）

∙我们需要容许并发，并考虑解除任何时间或次序上的依赖

∙AnalyzeWorkflowtoImproveConcurrency<分析工作流，以改善并发性>

∙AlwaysDesignforConcurrency<总是为并发进行设计>

29、它只是视图

∙那人依然只听到，他想要听到的东西，而不顾其他。

啦-----啦-----啦

∙不要把程序写成一个大块，应该”分而治之“，吧程序划分成模块

∙模块的一个好定义就是，他具有单一的、定义良好的责任

∙让视图与模型分离

30、黑板

∙黑板系统让我们完全解除了我们的对象之间的耦合，并提供了一个”论坛“，知识消费者和生产者可以在哪里匿名、异步地交换数据，还能减少我们必须编写的代码的数量

∙可以用黑板协调完全不同的事实和因素，同时又使个参与方保持独立、甚至隔离。

第六章当你编码时

靠巧合编程

∙应该避免靠巧合编程-----依靠运气和偶然的成功-----而要深思熟虑的编程

∙Don'tProgrambyCoincidence<不要靠巧合编程>

∙怎样深思熟虑的编程：

1）总是意识到你在做什么

2）不要盲目的编程

3）按照计划行事

4）依靠可靠的事物

5）为你的假定建立文档

6）不要只是测试你的代码，还要测试你的假定

7）为你的工作划分优先级。

把时间花在重要的方面。

32、算法速率

∙EstimatetheOrderofYourAlgorithms<估算你的算法的阶>

∙TestYourEstimates<测试你的估算>

33、重构

∙周遭所见，皆是变异与衰败

∙代码需要演化：

他不是静态的事物

∙不要对改动犹豫不决

∙代码若具有如下特征，则应该考虑重构：

1）重复

2）非正交的设计

3）过时的知识

4）性能

∙RefactorEarly,RefactorOften<早重构，常重构>

∙就其核心而言，重构就是重新设计

∙怎样进行利大于弊的重构：

1）不要试图在重构的同时增加功能

2）在开始重构之前，确保你拥有良好的测试。

（尽可能经常运行这些测试，如果你的改动破坏了任何东西，你很快可以知道）

34、易于测试的代码

∙单元测试

∙TestYourSoftware,orYourUsersWill<测试你的软件，否则你的用户就得测试>

35、邪恶的向导

∙Don'tUseWizardCodeYouDon'tUnderstand<不要使用你不理解的向导代码>

第七章在项目开始之前

36、需求只坑

∙完美，不是在没有什么需要增加，而是在没有什么需要去掉时达到的

∙Don'tGatherRequirements-DigforThem<不要搜集需求-挖掘他们>

∙WorkWithaUsertoThinkLikeaUser<与用户一同工作，以像用户一样思考>

∙Abstractionslivelongerthandetails<抽象比细节活的更长久>

∙Useaprojectglossary<使用项目词汇表>

37、解开不可能解开的谜题

∙解开谜题的关键：

确定加给你各种约束，并确定你确实拥有自由度

∙Don'tthinkoutsidethebox-findthebox<不要在盒子外思考-要找到盒子>

∙我们可以先确定最为严格的约束，然后再在其中考虑其余约束

∙很多时候，对需求的重新诠释能让整个问题全部消失------就像戈尔迪斯结

38、等你准备好

∙有时犹豫的人会得以保全

∙Listentonaggingdoubts-startwhenyou'reready<倾听反复出现的疑虑------等你准备好再开始>

39、规范陷阱

∙编写程序规范就是吧需求规约到程序员能够接管的程度的过程

∙somethingsarebetterdonethandescribed<对有些事情，”做“胜于”描述“>

40、圆圈与箭头

∙结构化程序设计------拥有长久的生命

第八章注重实效的项目

41、注重实效的团队

∙有了注重实效的开发者，让他们工作在能够发挥自身能力的环境中，他们很快就会发展并提炼他们自己的、有效的团队动力机制

42、无处不在的自动化

∙软件开发人员常常会使用最糟糕的工具来完成工作

43、无情的测试

∙Testearly,testoften,testautomatically<早测试，常测试，自动测试>

∙Codingain'tdone,tillalltestsrun<要到通过全部测试，编码才算完成>

∙Usesaboteurstotestyourtesting<通过”蓄意破坏“测试你的测试>

∙Teststatecoverage,notecodecoverage<测试状态覆盖，而不是代码覆盖>

∙Findbugsonce<一个bug只抓一次>

44、全部都是写

∙好记性不如烂笔头

∙Treatenglishasjustanotherprogramminglanguage<吧英语当做又一种编程语言>

∙Builddocumentationin,don'tboltiton<吧文档建在里面，不要拴在外面>

45、极大的期望

∙Gentlyexceedyourusers'expectations<温和的超出用户的期望>

46、傲慢与偏见

∙Signyourwork<在你的作品上签名>