出版社: 电子工业出版社
出品方: 博文视点
副标题: 从小工到专家
原作名: The Pragmatic Programmer: From Journeyman to Master
译者: 马维达
出版年: 2011-1
页数: 272
定价: 55.00元
装帧: 平装
丛书: 传世经典书丛
ISBN: 9787121123368
内容简介 · · · · · ·
《程序员修炼之道:从小工到专家》内容简介:《程序员修炼之道》由一系列独立的部分组成,涵盖的主题从个人责任、职业发展,知道用于使代码保持灵活、并且易于改编和复用的各种架构技术,利用许多富有娱乐性的奇闻轶事、有思想性的例子及有趣的类比,全面阐释了软件开发的许多不同方面的最佳实践和重大陷阱。无论你是初学者,是有经验的程序员,还是软件项目经理,《程序员修炼之道:从小工到专家》都适合你阅读。
作者简介 · · · · · ·
Andrew Hunt是世界知名的软件技术专家。他从事软件开发和咨询多年,涉及电信、银行、金融服务、公共服务、医学成像等各种领域。以本获得世界级声誉后,他与David Thomas合作开办了一家专业的软件咨询和出版机构The Pragrammers,并撰写或组织出版了Programming Ruby和Agile Web Development With Rails 等名著,直接推动了RUBY和ROR的兴起,Andrew Hunt与合作人的PRACTICES OF AN AGILE David一书(中文版即将由人民邮电出版社出版),延续了本书的风格,同样也已成为经典。
Dave Thomas 喜欢驾驶单引擎飞机飞行,并通过这样的方式为他的习惯付账:为各种难题寻找优雅的解决方案,提供诸多领域里的咨询服务——航空、银行、金融服务、服务、电信、交通运...
Andrew Hunt是世界知名的软件技术专家。他从事软件开发和咨询多年,涉及电信、银行、金融服务、公共服务、医学成像等各种领域。以本获得世界级声誉后,他与David Thomas合作开办了一家专业的软件咨询和出版机构The Pragrammers,并撰写或组织出版了Programming Ruby和Agile Web Development With Rails 等名著,直接推动了RUBY和ROR的兴起,Andrew Hunt与合作人的PRACTICES OF AN AGILE David一书(中文版即将由人民邮电出版社出版),延续了本书的风格,同样也已成为经典。
Dave Thomas 喜欢驾驶单引擎飞机飞行,并通过这样的方式为他的习惯付账:为各种难题寻找优雅的解决方案,提供诸多领域里的咨询服务——航空、银行、金融服务、服务、电信、交通运输及Internet。
马维达,《C++网络编程(卷2)》与,《ACE自适配通信环境技术文档》的译者
目录 · · · · · ·
序
第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 傲慢与偏见
附录A 资源
专业协会
建设藏书库
Internet资源
参考文献
附录B 练习解答
索引
注重实效的程序员之快速参考指南
· · · · · · (收起)
丛书信息
喜欢读"程序员修炼之道"的人也喜欢的电子书 · · · · · ·
喜欢读"程序员修炼之道"的人也喜欢 · · · · · ·
程序员修炼之道的话题 · · · · · · ( 全部 条 )



程序员修炼之道的书评 · · · · · · ( 全部 121 条 )




程序员基本素质的培养


态度、观念、习惯,程序员的养成
> 更多书评121篇
-
青釉花圃 (我爱重光)
DRY---Don't Repeat Yourself 不要重复你自己;让复用变得容易 代码的重复,往往是由于经受不住诱惑而直接拷贝。抽取是一个好办法,抽取与重构应该自主的进行。结合上一章, 想清楚哪些以后可以重复使用,或者在工作完成之后对代码进行重构抽取出可以重复利用的部分。当然,这些都需要一定的功力。做好设计。 开发者的重复往往是由于相互之间缺乏沟通,但目前来看貌似在项目管理软件下,这种情况发生的比较少,往往在共同修改某...2018-12-01 19:33 1人喜欢
DRY---Don't Repeat Yourself 不要重复你自己;让复用变得容易
代码的重复,往往是由于经受不住诱惑而直接拷贝。抽取是一个好办法,抽取与重构应该自主的进行。结合上一章, 想清楚哪些以后可以重复使用,或者在工作完成之后对代码进行重构抽取出可以重复利用的部分。当然,这些都需要一定的功力。做好设计。
开发者的重复往往是由于相互之间缺乏沟通,但目前来看貌似在项目管理软件下,这种情况发生的比较少,往往在共同修改某些小功能上容易发生。
消除无关事物之间的影响
其实主要说的就是减少模块之间的耦合性。包括在设计的时候,选择技术的时候。目前各种框架的使用很好的减少了前台与后端之间的耦合性,但在工作中仍旧会发现某些代码之间嵌套的很死,耦合性很差。注意保持解耦,减少全局变量,并写好相关文档。
另外在做习题的时候发现面向对象由于多态,继承等不同于面向过程语言的一些特性,似乎更容易发生耦合现象。这个tip还需要在以后工作中持续思考。
不存在最终决策
这个tip是个启发。没有最终决策不等同于可以随意改变最初的需求文档。需求一旦定死即可不更改,但实现的方式可以是多种多样,在实现过程中寻求最优,或者最便利(有时往往不是最优)的解决方案,应该在项目开发生命周期中持续进行。这应该就是同事说的“工作方法”。当然其中也应该包括程序员的自尊心,即便是做统计数据用in也不要图方便用union all(笑)。
用光弹找到目标
这里说说的应该是前期的一些实验代码,实验后有可能废弃,也可能融合在项目中保存生命力。一些小的实验代码往往可以寻求问题的解决之道,这里不要怕浪费时间,但相反也不要进入拿起来就做的状态,防止陷入做了那么多才发现自己做错了的状态。
为了学习而制作原型
这里并没有什么体会。不知道在原有项目基础上进行重新架构的项目算不算。记下来以后再看。
靠近问题领域编程
这里仍没有体会
估算,以避免发生意外
这里给出一种估算的简单方式。建模,分割作为组件,给各个参数指定值,计算,验证。我认为这里是提出了一种估算项目进度的训练方式。
在被要求进行估算时说什么:我等会儿回答你
。。。。
回应 2018-12-01 19:33 -
青釉花圃 (我爱重光)
对于我们的缺点---还有我们的无知和我们的错误---我们必须诚实。 正确认识已经发生的错误,对自己的职业生涯负责。对于已经发生的错误,重要的是如何处理来挽回局面,这样也可以赢得别人的帮助。 不要容忍破窗户 这点在接手项目的时候最为明显。往往好的项目让人不忍心去破坏其中完美的逻辑和美好的语言。一旦自己开始利用混乱的逻辑和糟糕的代码,往后的编码质量往往直线下滑。 做变化的催化剂;记住大图景 拖延,规范,要时刻...2018-12-01 19:14 1人喜欢
对于我们的缺点---还有我们的无知和我们的错误---我们必须诚实。
正确认识已经发生的错误,对自己的职业生涯负责。对于已经发生的错误,重要的是如何处理来挽回局面,这样也可以赢得别人的帮助。
不要容忍破窗户
这点在接手项目的时候最为明显。往往好的项目让人不忍心去破坏其中完美的逻辑和美好的语言。一旦自己开始利用混乱的逻辑和糟糕的代码,往后的编码质量往往直线下滑。
做变化的催化剂;记住大图景
拖延,规范,要时刻提醒。设计出合理的东西,然后拿出他,这就是石头。
使质量成为需求问题
质量一般都是隐含的需求。但也不要过分追求质量而停止脚步。停滞的结果往往就是自己都失去耐心。
定期为你的知识资产投资
没啥说的,多看书,视野要广。视野要广。视野要广。多学习。
你说什么和你怎么说同样重要
多问,多说。态度很重要。
回应 2018-12-01 19:14 -
36° (仰望星空 脚踏实地)
即使有火在咆哮(最后期限、发布日期、会展演示等等),你也不会想成为第一个弄脏东西的人。 每个人都会护卫他们自己的资源。有时候,这叫做“启动杂役”。人们发现,参与正在发生的成功更容易,让他们瞥见未来,你就能让他们聚集在你周围。 不仅是推动新项目,任何说服别人和你一起做事的时候,都是这样。 留心大图景。要持续不断地观察周围发生的事情,而不只是你自己在做的事情。 就像金融投资一样,你必须顶起为你...2013-08-14 08:30
即使有火在咆哮(最后期限、发布日期、会展演示等等),你也不会想成为第一个弄脏东西的人。
不仅是推动新项目,任何说服别人和你一起做事的时候,都是这样。每个人都会护卫他们自己的资源。有时候,这叫做“启动杂役”。人们发现,参与正在发生的成功更容易,让他们瞥见未来,你就能让他们聚集在你周围。
留心大图景。要持续不断地观察周围发生的事情,而不只是你自己在做的事情。
习惯自身和总量一样重要!就像金融投资一样,你必须顶起为你的知识资产投资。即使投资量很小,习惯自身也和总量一样重要。
是否在某个项目中使用这些技术,或者是否把他们放入你的简历,这并不重要。学习的过程将扩展你的思维,使你向着新的可能性和新的做事方式扩展。
设法把你学到的东西应用到你当前的项目中。即使你的项目没有使用该技术,你或许也能借鉴一些想法。
只有当你是在传达消息时,你才是在交流。为此,你需要了解你的听众的需要、兴趣、能力。
有点项目leader的感觉。Wisdom 诗:通过针对不同的人进行适当的修正,你将让他们都为你的项目感到兴奋。
What do you want them to learn? What is their interest in what you've got to say? How sophisticated are they? How much detail do they want? Whom do you want to own the information? How can you motivate them to listen to you?
如果你想要大家听你说话,你必须使用一种方法:听他们说话。
再怎么强调这句话的重要性也不多余。你说什么和你怎么说同样重要。
回应 2013-08-14 08:30
-
RobinLiu (你要带我去哪里?)
关心你的技艺 思考你的工作 不要依靠自动驾驶仪,不间断的思考,实时地批判你的工作。 在一个项目的总体结构中,总有个性和技艺的位置。一百年之后,我们的工程看起来或许已很古老,就像是中世纪的大教堂建造者所使用的技术在今天的土木工程师看来很古老一样,但我们的技艺却仍将受到尊重。 在所有的弱点中,最大的弱点就是害怕暴露弱点。 提供各种选择,不要找蹩脚的借口。不要说事情做不到,要说明能够做什么来挽回局...2012-11-04 15:16
关心你的技艺思考你的工作不要依靠自动驾驶仪,不间断的思考,实时地批判你的工作。在一个项目的总体结构中,总有个性和技艺的位置。一百年之后,我们的工程看起来或许已很古老,就像是中世纪的大教堂建造者所使用的技术在今天的土木工程师看来很古老一样,但我们的技艺却仍将受到尊重。在所有的弱点中,最大的弱点就是害怕暴露弱点。提供各种选择,不要找蹩脚的借口。不要说事情做不到,要说明能够做什么来挽回局面。不要害怕提出要求,也不要害怕承认你需要帮助一扇破窗户,只要有那么一段时间不修理,就会渐渐给建筑的居民带来一种废弃感。于是又一扇窗户破了,人们开始乱扔垃圾。出现了乱涂乱画。严重的结构损坏开始了。不要容忍破窗户但更重要的是,士兵充当催化剂,把村民团结起来,和他们一起做到了他们自己本来做不到的事情——项目协作的成果。每个人最后都是赢家。做变化的催化剂。知识上的投资,总能得到最好的回报。1. 严肃的投资者定期投资——作为习惯。2. 多元化是长期成功的关键——你知道的不同的事情越多,你就越有价值。3. 管理风险4. 低买高卖。在新兴的技术流行之前学习它可能和找到被低估的股票一样困难,但所得到的就和那样的股票带来的收益一样。5.重新评估和平衡最重要的是定期为你的知识资产投资。你说什么和你怎么说同样重要。第二章 注重实效的途径不要重复你自己(DRY)系统中的每一项知识都必须具有单一、无歧义、权威的表示。代码中的文档:把注释保留给其他的高级说明,否则,我们就是在重复知识。用头文件记载接口问题,用实现文件记载代码的使用者无需了解的实际细节。无耐性的重复:如果你觉得受到诱惑,想一想古老的格言:”欲速则不达“正交性:不相依赖性或者是解耦性消除无关事物之间的影响可撤销性没有什么永远不变——而如果你严重依赖某一事实,你几乎可以确定它将会发生变化。通过DRY原则、解耦以及元数据的使用在黑暗中发光的代码——快速清晰的获取用户需求。在背要求进行估算时说什么——”我等会告诉你“。第三章 基本工具 * 用纯文本保存知识 * 利用shell 的力量find . -name '*.c' -newer Makefile -printfind . -name '*.jave' -mtime +7 -print * 使用单一的编辑器选一种强大的编辑器,然后学好他调试心理学要修正问题,而不是发出指责不要恐慌代码生成器编写能够编写代码的代码第四章 注重实效的偏执你不可能写出完美的软件俺合约进行设计——用文档记载并约定软件模块的权利与责任,以确保程序的正确性。早崩溃,要崩溃,不要破坏断言式编程:如果它不可能发生,用断言确保它不会发生异常留给意外事件,“如果我移走所有的异常处理,这些代码是否仍能正常运行?” 如果答案是否,那么异常也许就用到了非异常的情形中。错误处理器是另外一种选择怎样配平资源:分配某项资源的例程或对象应该负责解除该资源的分配。以与资源分配次序相反的次序解除资源的分配在不同的地方分配同一套资源时总是使用相同的顺序分配他们,以减少死锁的可能性。第五章 弯曲,或折断解耦与得墨忒耳法则编写遵守得墨忒耳法则的“羞怯”的代码函数的得墨忒耳法则:某个对象的任何方法都应该只调用属于以下情形的方法:1. 他自身的方法2. 传入该方法的任何参数;3. 它创建的任何对象;4. 任何直接持有的组件对象缩小调用类中的响应集的规模元程序设计要配置,不要集成元数据:关于数据的数据,如调谐参数,用户偏好,安装目录等。元数据在运行时而不是编译时被访问和使用将抽象放进代码,将细节放进元数据。以声明的方式思考(规定要做什么,而不是怎么做):为一般情况编写程序,把具体情况放在别处——在编译的代码库之外。时间耦合:分析工作流,以改善并发性为并发进行设计用黑板协调工作流第六章 当你编码时靠巧合编程:1. 实现的偶然;2. 语境的偶然;——你的模块必须依赖GUI?是否依靠说英语的用户?你还依靠别的什么没保证的东西?3. 隐含的假定;怎样深思熟虑的编程:1. 总是意识到你在做什么2. 不要盲目的编程;3. 按照计划行事;4. 依靠可靠的事物;5. 为你的假定建立文档;6. 不要只是测试你的代码,还要测试你的假定;7. 为你的工作划分优先级8. 不要做历史的奴隶最好的算法并非总是最好的重构:1. 重复2. 非正交的设计;3. 过时的知识;4. 性能早重构,常重构1. 不要在重构的时候加入新的功能;2. 在开始重构之前,确保你拥有良好的测试。3. 采取短小、深思熟虑的步骤:如果使你的步骤保持短小,并在每个步骤之后进行测试,你将能够避免长时间的调试。确保对模块做出的剧烈改动,会破坏构建。易于测试的代码:为测试而设计。第七章 在项目开始之前你是否曾经有过你的项目注定要失败的感觉,甚至是在项目开始之前?有时它也许会这样,除非你先建立某些基本准则。不要搜集需求——挖掘他们找出用户维护要做特定事情的原因,而不是他们目前做这件事情的方式。用文档记载需求背后的原因将在每天进行实现决策时给你的团队带来无价的信息。与用户一同工作,以像用户一样思考。倾听反复出现的疑虑,等你准备好再开始。你可能无法准确地指出问题所在,但给它时间,你的疑虑很可能就会结晶成某种更坚实的东西,某种你可以处理的东西。对于某些事情,“做”胜于“描述“注重实效的程序员批评的看待科学方法,并从各种方法学中提取精华,融合成每个月都在变得更好的一套工作习惯。这至关重要。你应该不断努力提炼和改善你的开发过程。绝不要把方法学的呆板限制当作你的世界的边界。第八章 注重实效的项目不要留破窗户煮青蛙交流不要重复你自己正交性无处不在的自动化文明通过增加我们不加思索就能完成的重要的操作的数目而取得进步。一切都要自动化。在现实中,项目的成功是由它在多大程度上满足了用户的期望来衡量的。温和的超出用户的期望。交流期望额外的一公里。注重实效的程序员不会逃避责任。相反,我们乐于接受挑战,乐于使我们的专业知识广为人知。如果我们在负责一项设计,或是一段代码,我们是在做可以引以为豪的工作。Sign Your Work在你的作品上签名。过去时代的手艺人为能在他们的作品上签名而自豪,你也应该如此。回应 2012-11-04 15:16 -
大句哥哥 (make pie, or invent universe)
絮絮叨叨了n篇序和一坨该死的废话后终于进入了作者写的正题。开篇第一章 俨然有种歪叔在面前吐槽的错觉。中午吃饭时讨论的基本和书中一致。 本书开篇讨论的是「责任」。**a pragmatic programmer**应当对自己的职业生涯负责,不惧怕承认无知或错误。 歪叔中午也提到了「对于没有权限的事,有权**不**去为之负责,权限越大责任也越大」,书中的言辞是不可能做到的事或风险太大的事。这基于自己的道德准则和判断来做决定,也就是常... (3回应)2013-03-05 22:51
絮絮叨叨了n篇序和一坨该死的废话后终于进入了作者写的正题。开篇第一章 俨然有种歪叔在面前吐槽的错觉。中午吃饭时讨论的基本和书中一致。本书开篇讨论的是「责任」。**a pragmatic programmer**应当对自己的职业生涯负责,不惧怕承认无知或错误。歪叔中午也提到了「对于没有权限的事,有权**不**去为之负责,权限越大责任也越大」,书中的言辞是不可能做到的事或风险太大的事。这基于自己的道德准则和判断来做决定,也就是常说的三观。现在的软件系统愈来愈大,必须分析风险**是否超出了控制**,然后负担起自己控制得了的那部分责任。说起来 sunyi一直奉行什么权限都别给我加的行事准则 就是三观很正的表现。在**确实**同意为某个结果负责的情况下,犯错误/判断失误/造坑/没节操代码,应该诚实的承认它,并设法给出选择,**不要pass 不要ignore**,本小节在责任之后的话题是「Provide Options,Don't Make Lame Execuses」。踩坑,可以获得「直接经验」,多看博客/书/交流获得「间接经验」,这些经验为的就是再次遇到坑时可以bypass,或者说知道对应的解决方案/方案选择。建议预演一遍说出借口后怎么圆都圆不上的尴尬场面吧(当然 三观不正的人可能想象不出来),不要说事情做不到,而要说明做什么能挽回局面。不要害怕提出要求,也不要害怕承认需要帮助(啊 啊 有些事认为很需要 但是别人认为优先级还不够高而延迟了提供帮助 但这种情况似乎又是*职权之外*的suck thing了 隐约觉得本章最后所说的猫要承受指责大概说的就是这情况) 嗯 长得虽萌,但也要练起一条毒舌出来。必须得承认 这两天 我做了一个糟糕透顶的设计 要做有节操的一线基层码农 就要optimize it。3回应 2013-03-05 22:51 -
《程序员修炼之道》笔记 ========= ###1. 注重实效的哲学 A Pragmatic Philosophy - 负起责任,不要找借口。Provide options, dont make lame excuses. - 不要容忍破窗,一扇破窗足以使软件开始腐烂。Dont live with broken windows. - 在人人自危不团结时,拿出自己能做的最好的东西,做变化的催化剂,聚结起团队。Be a catalyst for change. - 投资知识财产,评估管理风险。新语言、书籍、组织、网络。批判地学习。Cri...
2013-10-05 10:20
《程序员修炼之道》笔记=========###1. 注重实效的哲学 A Pragmatic Philosophy- 负起责任,不要找借口。Provide options, dont make lame excuses.- 不要容忍破窗,一扇破窗足以使软件开始腐烂。Dont live with broken windows.- 在人人自危不团结时,拿出自己能做的最好的东西,做变化的催化剂,聚结起团队。Be a catalyst for change.- 投资知识财产,评估管理风险。新语言、书籍、组织、网络。批判地学习。Critically analyze what you read and hear.- 交流 * 写出大纲,理清想要说什么 * 了解听众 (WISDOM) - what: 想让他们学到什么 - interest: 他们对你讲的什么感兴趣 - sophisticated: 他们有多富有经验 - detai: 他们想要多少细节 - own: 你想要让谁拥有这些信息 - motivate: 如何促使他们听你说话 * 选择适合的时机,风格 * 让听众参与,倾听反馈,回复他人。###2. 注重实效的途径 A Pragmatic Approach- 重复的危害 * DRY - dont repeat yourself. Make it easy to reuse. - imposed duplication 强加的重复 >编写简单的过滤器, 代码生成器 - inadvertent duplication 无意识的重复 - impatient duplication 缺乏耐性的重复(偷懒) - interdeveloper duplication 开发者间的重复。- 正交性(两条直线相交成直角,不相互依赖) * 消除无关事物之间的影响。Eliminate effects between unrelated things. - 提高生产力 * 改动得以局部化,缩短开发测试时间 * 促进复用 - 降低风险 * 代码隔离。某个模块的问题不会扩散到系统的其余部分。 * 更易测试。 * 编码 - 保持解耦 - 避免使用全局数据 - 避免编写相似的函数- 可撤销性 * 灵活的架构。不存在最终决策 there are no final decisions.- 曳光弹 > 构建未接触过的新项目,使用不熟悉的算法、技术、语言、库,面对着大量未知的事物。传统使用繁重的工程方法,制作大量分档,确定所有未知的因素,限定环境。 * 在黑暗中发光的代码。 Use tracer bullets to find the target >> 曳光代码并非用过就仍的代码:编写它是为了保留它,包含错误检查、结构、文档。只不过功能不全而已。 - 让用户及早看到能跑起来的东西 - 开发者能构建一个他们能在其中工作的结构 - 有了一个集成平台。 - 能感觉到工作进展 * 曳光代码 vs 原型制作 > 原型是对概念进行试验,试验完成后代码即抛弃。所以一般选用更高级的语言,不考虑正确性、完整性、健壮性。- 领域语言 * 实现小型语言 - 定义语法(BNF表示法),转换为解析器生成器(parser generator)<yacc(c,cpp), javaCC(java) - 扩展现有语言。- 估算 > Estimate to avoid surprises * 需要多准确 > 选择单位。1-15天,3-8周,2-6个月。 * 估算 - 理解提问内容,把握问题域的范围 - 建立系统模型 - 把模型分解为组件,组件的参数,影响整个模型 - 给每个参数指定值。对那些影响较大的参数,估值应尽量正确。 - 计算答案 - 追踪你的估算能力 * 估算项目进度 - 检查需求 - 分析风险 - 设计、实现、集成 - 向用户确认### 3.基本工具 The basic tools- 纯文本 > 用纯文本保存知识,keep knowledge in plain text * 缺点:需要更多控件,计算处理时间更长 > 用户密码进行加密,不让改变参数值时,增加参数值的MD5作为校验和 * 文本的威力 - 保证不过时(相对二进制文件,更已读) - 杠杆作用 (更有益于版本控制,部署等。。) - 更易于测试- Shell游戏 * Use the power of command shells. > GUI的好处是what you see is what you get, 缺点时what you see is all you get. - find . -name '*.c' -newer Makefile -print - zip archive.zip *.h *.c - find . -name '*.java' -mtime +7 -print - find . -name '*.java' -mtime +7 print | xargs grep 'java.awt' - grep '^import' *.java | sed -e's/.import *// ' -e's/;.*$//' | sort -u >list > windows下可用cygwin. <perl power tools>- 编辑器 Use a single editor well. > 精通一种编辑器,用于所有编辑任务:代码、文档、备忘录、系统管理。 * 编辑器特性 - 可配置 - 可扩展 - 可编程,执行复杂、多步骤的操作。通过宏或内建脚本进行编程。 - 语法突显 - 自动完成 - 自动缩进 - 初始代码或文档样板 - 与帮助系统挂接 - 类IDE特性(编译、调试等) * 编辑器 - The Emacs Editor - The XEmacs Editor - The Vim Editor - The elvis Editor - Emacs Viper Mode- 源码控制 Always use source code control.- 调试 * Fix the problem, not the blame. * Donot panic. * Donot assume it, prove it. * 调试检查列表 - 正在报告的问题是底层bug的直接结果,还是只是症状 - bug真的在编译器里?在OS里?或者是在你的代码里? - 如果你向你同事详细解释这个问题,你会说什么? - 如果可以代码通过了单元测试,测试是否足够完整? - 造成这个bug的条件是否存在于系统中的其他地方?- 文本操纵 > unix开发者喜欢使用shell,用awk、sed一类的工具增强,偏爱结构化工具的喜欢python, * 数据库schema维护 >> 一组Perl脚本读取含有数据库schema定义的纯文本文件,根据他声称 - 用于创建数据库的SQL语句 - 用于填充数据词典的flat数据文件 - 用于访问数据库的c代码库 - 用于检查数据库完整性的脚本 - 含有schema描述及框图的网页 - schema的xml版本 * Java属性访问,用脚本修改源文件,做适当标记。 * 测试数据生成。将散布在不同文件、不同格式的大量数据汇合,转为适于放入数据库的格式 * 写书。提取树种的代码片段 * C与Object Pascal的接口 * 生成web文档- 代码生成器 * 被动代码生成器 - 创建新的源文件。模板、源码控制指示、版权说明,标准注释块 - 在编程语言之间进行一次性转换 - 生成查找表及其它在运行时计算很昂贵的资源 * 主动代码生成器 > 遵循DRY原则的必需品。需要根据定义文件生成代码### 4. 注重实效的偏执 Pragmatic paranoia.you canot write perfect software.- 按照合约设计(DBC) > precondition前条件,postcondition后条件,class invariant类不变项 * 断言。c/c++中可以参考Nana,在运行时监控断言- 死程序不说谎 Crash early * 要崩溃,不要破坏trash- 断言式编程 > 如果他不可能发生,用断言确保它不会发生 If it canot happen, use a assertions to ensure that it wonot.- 何时使用异常 Use exceptions for exceptional problems. > 什么是异常: 异常应保留给意外事件,不作为程序正常流程的一部分。- 怎样配平资源 > 管理内存、事物、线程、文件、定时器。 Finish what you start### 5. 弯曲,或折断 Bend, or break.- 解耦与德墨忒尔法则 > minimize coupling between modules.- 元程序设计 Configure, donot integrate.算法、数据库产品、中间件技术和用户界面风格,应该作为配置选项,而不是通过集成或工程实现。 元数据即关于数据的数据。如数据库schema,schema含有按照名称、存储长度及其它属性、对字段进行描述的数据。 '元数据驱动应用'。Put abstractions in code, details in metadata. 把抽象放进代码,细节放进元数据。- 时间耦合 不只考虑线性 分析工作流,以改善并发性。analyze workflow to improve concurrency. Design Using Services. 用服务进行设计。 Always design for concurrency. 总是为并发进行设计。- 它只是视图 * 发布/订阅协议 > 如果对publisher生成的特定事件感兴趣,只需要登记自己。publisher追踪所有感兴趣的subscriber对象,当publisher生成又去的事件时,将依次调用每个subscriber,通知他们事件已经发生。 * Model-View-Controller. separate views from models. - 模型。 表示目标对象的抽象数据模型。 - 视图。 订阅模型中的变化和来自控制器的逻辑事件 - 控制器。 既向模型、也向视图发布事件。- 黑板 用黑板来梳理工作流, Use blackboards to coordinate workflow. 黑板方法的一些关键特征: * 侦探查看黑板,不需要知道其他侦探存在,从中了解新的信息,加上他们的发现; * 侦探可能接受过不同的训练,具有不同程度的教育背景和专业经验,甚至不在一个辖区工作。他们的共同点是渴望破案; * 在破案过程中,不同侦探可能会来来去去,工作班次也可能不同 * 对放在黑板上的内容没有什么限制,可以是图片、判断、物证等等。 >图像处理:简单的并行进程间工作负载调度,共享的工作队列也许就很足够了。如果涉及反馈,如模块图像的处理结果对其他块有影响,可以考虑黑板系统。 >机构日程安排: > 网络监控工具:收到用户发来的问题报告和自动报告统计信息,把他们公布在黑板上。人或软件代理可以分析黑板,诊断网络故障。### 6. 当你编码时 When you are coding.- 不要靠巧合编程 Donot program by coincidence. * 意识到自己在做什么 * 不要盲目,理解应用,谨慎使用不熟悉的技术。 * 按照计划行事 * 依靠可靠的事物,不要依靠巧合和假定。 * 为你的假定建立文档 * 不要只是测试你的代码,还有测试你的假定。 * 为你的工作划分优先级。 * 不要做历史的奴隶。如果不再适用,所有的代码都可以被替换。- 算法速率 * O()表示法 > O()表示法,把O视为“阶为……”(on the order of),表示对度量的事物的值设置了上限。 * O(1) 常量型,访问数组元素 * O(lg(n)) 对数型,二分查找 * O(n) 线性型,顺序查找 * O(nlg(n)) 比线性差,但不会差太多,快速排序、堆排序的平均时间 * O(n2) 平方律型,选择和插入排序 * O(n3) 立方型, 2n x n矩阵相乘 * O(Cn) 指数型,旅行商问题,集合划分 * 常识估算 - 简单循环,O(n) - 嵌套循环, O(m*n) - 二分法, O(lg(n)) - 分而治之,O(nlg(n)) - 组合,可能失控,常用启发式方法(heuristics)减少时间 * 估算 > 使用code profiler进行精确估算- 重构 > 不要在重构的同时增加功能 > 在开始重构前,保证拥有良好的测试。 > 才去短小、深思熟虑的步骤。- 易于测试的代码 * 测试装备(test harness) 应具有的功能: - 用以指定设置与情理(setup and cleanup)的标准途径 - 用以选择个别或所有可用测试的方法 - 分析输出是否是预期结果的手段 - 标准化的故障报告形式 * 构建测试窗口 部署后的软件包含跟踪消息的日志文件,可用在运行时显示状态信息,通过“热键”开启,最终用户不知。- 邪恶的向导 不要使用不理解的IDE向导代码,Dont use wizard code you dont understand.### 7. 在项目开始之前 Before the project.### 8. 注重实效的项目 Pragmatic projects.- 无处不在的自动化 * 项目编译 makefile, 脚本化、自动化。生成代码,自动运行回归测试。用一条命令完成签出、构建、测试和发布。 * 构建自动化 1. 从仓库中签出代码 2. 从头开始构建项目,典型情况下从顶层的makefile开始。每次构建都会标注版本号或日期戳。 3. 创建可分发映像。确定文件所有权和权限,严格按照发运时所需的格式,产生所有的例子、文档、README文件。 4. 运行规定的测试化。- 无情的测试 Test early, test ofen, test automatically. Coding ainot done till all the tests run. 1. 测试什么 * 单元测试 * 集成测试 * 验证和校验 * 资源耗尽、错误及恢复(内存、磁盘、CPU带宽、挂钟时间、磁盘带宽、网络带宽、调色板、视频分辨率) * 性能测试 * 可用性测试 2. 怎样测试 * 回归测试,确保新代码没有破坏旧代码 * 测试数据。大样本、边界数据、展现特定的统计属性的数据。 * 演练GUI系统 * 对测试进行测试。通过“蓄意破坏”测试你的测试。Use saboteurs to test your testing. * 彻底测试。测试状态覆盖,而不是代码覆盖。Test state coverage, not code coverage. 3. 何时测试 频繁进行测试,不要等到最后。 如果bug绕过了现有的测试网,你需要增加新的测试。Find bugs once.- 全都是写 把代码与文档紧密的结合在一起。Build documentation in, dont bolt it on. Treat english as just another programming language. * 注释 > 注释应用于讨论为何要做某事、它的目的和目标。DRY回应 2013-10-05 10:20
-
颦儿 (偷来梨蕊三分白,借得梅花一缕魂)
-
青釉花圃 (我爱重光)
DRY---Don't Repeat Yourself 不要重复你自己;让复用变得容易 代码的重复,往往是由于经受不住诱惑而直接拷贝。抽取是一个好办法,抽取与重构应该自主的进行。结合上一章, 想清楚哪些以后可以重复使用,或者在工作完成之后对代码进行重构抽取出可以重复利用的部分。当然,这些都需要一定的功力。做好设计。 开发者的重复往往是由于相互之间缺乏沟通,但目前来看貌似在项目管理软件下,这种情况发生的比较少,往往在共同修改某...2018-12-01 19:33 1人喜欢
DRY---Don't Repeat Yourself 不要重复你自己;让复用变得容易
代码的重复,往往是由于经受不住诱惑而直接拷贝。抽取是一个好办法,抽取与重构应该自主的进行。结合上一章, 想清楚哪些以后可以重复使用,或者在工作完成之后对代码进行重构抽取出可以重复利用的部分。当然,这些都需要一定的功力。做好设计。
开发者的重复往往是由于相互之间缺乏沟通,但目前来看貌似在项目管理软件下,这种情况发生的比较少,往往在共同修改某些小功能上容易发生。
消除无关事物之间的影响
其实主要说的就是减少模块之间的耦合性。包括在设计的时候,选择技术的时候。目前各种框架的使用很好的减少了前台与后端之间的耦合性,但在工作中仍旧会发现某些代码之间嵌套的很死,耦合性很差。注意保持解耦,减少全局变量,并写好相关文档。
另外在做习题的时候发现面向对象由于多态,继承等不同于面向过程语言的一些特性,似乎更容易发生耦合现象。这个tip还需要在以后工作中持续思考。
不存在最终决策
这个tip是个启发。没有最终决策不等同于可以随意改变最初的需求文档。需求一旦定死即可不更改,但实现的方式可以是多种多样,在实现过程中寻求最优,或者最便利(有时往往不是最优)的解决方案,应该在项目开发生命周期中持续进行。这应该就是同事说的“工作方法”。当然其中也应该包括程序员的自尊心,即便是做统计数据用in也不要图方便用union all(笑)。
用光弹找到目标
这里说说的应该是前期的一些实验代码,实验后有可能废弃,也可能融合在项目中保存生命力。一些小的实验代码往往可以寻求问题的解决之道,这里不要怕浪费时间,但相反也不要进入拿起来就做的状态,防止陷入做了那么多才发现自己做错了的状态。
为了学习而制作原型
这里并没有什么体会。不知道在原有项目基础上进行重新架构的项目算不算。记下来以后再看。
靠近问题领域编程
这里仍没有体会
估算,以避免发生意外
这里给出一种估算的简单方式。建模,分割作为组件,给各个参数指定值,计算,验证。我认为这里是提出了一种估算项目进度的训练方式。
在被要求进行估算时说什么:我等会儿回答你
。。。。
回应 2018-12-01 19:33 -
青釉花圃 (我爱重光)
对于我们的缺点---还有我们的无知和我们的错误---我们必须诚实。 正确认识已经发生的错误,对自己的职业生涯负责。对于已经发生的错误,重要的是如何处理来挽回局面,这样也可以赢得别人的帮助。 不要容忍破窗户 这点在接手项目的时候最为明显。往往好的项目让人不忍心去破坏其中完美的逻辑和美好的语言。一旦自己开始利用混乱的逻辑和糟糕的代码,往后的编码质量往往直线下滑。 做变化的催化剂;记住大图景 拖延,规范,要时刻...2018-12-01 19:14 1人喜欢
对于我们的缺点---还有我们的无知和我们的错误---我们必须诚实。
正确认识已经发生的错误,对自己的职业生涯负责。对于已经发生的错误,重要的是如何处理来挽回局面,这样也可以赢得别人的帮助。
不要容忍破窗户
这点在接手项目的时候最为明显。往往好的项目让人不忍心去破坏其中完美的逻辑和美好的语言。一旦自己开始利用混乱的逻辑和糟糕的代码,往后的编码质量往往直线下滑。
做变化的催化剂;记住大图景
拖延,规范,要时刻提醒。设计出合理的东西,然后拿出他,这就是石头。
使质量成为需求问题
质量一般都是隐含的需求。但也不要过分追求质量而停止脚步。停滞的结果往往就是自己都失去耐心。
定期为你的知识资产投资
没啥说的,多看书,视野要广。视野要广。视野要广。多学习。
你说什么和你怎么说同样重要
多问,多说。态度很重要。
回应 2018-12-01 19:14
在哪儿买这本书 · · · · · ·
在哪儿借这本书 · · · · · ·
这本书的其他版本 · · · · · · ( 全部6 )
- Addison-Wesley Professional版 1999-10-30 / 329人读过 / 有售
- 电子工业出版社版 2005-1 / 2568人读过
- 中国电力出版社版 2003-8-1 / 96人读过
- 人民邮电出版社版 2007-12 / 66人读过
以下豆列推荐 · · · · · · ( 全部 )
- 开智正典:心智升级百本经典导读 (开智学堂)
- 改变自己▶编程 (Chain)
- 全世界程序员都说好的图书 (欧阳)
- 闲着没事读读书(四) (鹿小羽)
- 交互设计师养成书单 (LimboMinaïs)
谁读这本书?
二手市场
订阅关于程序员修炼之道的评论:
feed: rss 2.0
0 有用 机动美少年憂鬱 2018-12-13
我对翻译很失望
0 有用 板子 2012-06-26
翻了一遍,水平不够,暂未吸收太多,明年再翻,看是否能有更多收获
0 有用 一只黑眼睛看着大千世界 2011-07-26
程序员之道
0 有用 舀点米 2013-06-02
I was look it. It's awesome. It has a lot of suggestion. I'll get them.
0 有用 蝉 2013-11-07
:TP311.11/0225-1
0 有用 simpleapples 2019-02-18
继代码大全之后第二本让我醍醐灌顶的书,没有把程序员个人的极客精神推崇至极,也没有把软件工程领域的各种教条奉为金科玉律,可以说是实实在在的 pragmatic,并且通俗幽默易读,不可多得的好书。
0 有用 阿毛 2019-02-08
对java工程师很有用,可惜我是python,不过还是有参考意义
0 有用 悠游的叶 2019-02-09
很经典的一本书,合约设计,正交性,拽光弹,原型,领域语言,断言式编程,黑板,metadata,学到了很多,准备后续再看一遍
0 有用 dawin 2019-02-03
一些经验,一种意识,对日常工作有非常大的帮助,从需求分析到团队交流,总结了很多经验,看完有种茅塞顿开的感觉,推荐那些团队协作的初级程序员看,多看几遍
0 有用 thanq 2019-02-02
几个小时看完 部分习题很有意思