程序员修炼之道

按有用程度 按页码先后 最新笔记

• 

  全书

  麦子麦

  不要容忍破窗户（低劣的设计，错误决策或是糟糕的代码）： 一个不修，会越来越多，迅速恶化。 如果没有人处理项目的所有垃圾，找一个大型垃圾桶处理掉。不要遗留下来 当你容忍项目中已存在的垃圾时，会是的自己也不断创造垃圾 当项目中都是漂亮的代码时，你也会想法设法保持优雅 即使暂时无法处理修补垃圾代码，也要把垃圾分离出去，使成为一个独立的附属，随时可以修补和去除 知道何时停止： 不可能存在... (更多)

  不要容忍破窗户（低劣的设计，错误决策或是糟糕的代码）：

  一个不修，会越来越多，迅速恶化。

  如果没有人处理项目的所有垃圾，找一个大型垃圾桶处理掉。不要遗留下来

  当你容忍项目中已存在的垃圾时，会是的自己也不断创造垃圾

  当项目中都是漂亮的代码时，你也会想法设法保持优雅

  即使暂时无法处理修补垃圾代码，也要把垃圾分离出去，使成为一个独立的附属，随时可以修补和去除

  知道何时停止：

  不可能存在完美的代码，完美的功能。

  知道下一步改进所带来的麻烦和改进是否合算

  学习新的知识：

  定期学习：即使学习量很小

  多元化：需要知道目前所用的特定技术的各种特性，掌握的技术越多，就越能更好的调整

  管理风险：不要把所有的技术放在同一个领域

  领先一步：在知识得到大规模肯定和应用之前学习它可能会得到高额回报，而不是总在追随流行的知识，类似于股票

  重新评估和平衡：或许上个月的热门技术已经冰冷，需要重温很久没用的某项知识，

  建议：

  每年至少学习一种新语言

  每季度阅读一本技术书籍

  也要阅读非技术书籍

  上课：培训等

  参加本地用户组织

  实验不同的环境

  跟上潮流

  持续投入：如果熟悉了某种新语言，继续前进

  不要重复你自己：

  软件中的每一项知识都必须单一,无歧义，权威的表示

  使修改时只用修改一处，永远不要期望自己记得与此项关联的其他项，保证只需要修改一处

  正交性：

  系统功能不相互依赖，保持良好的隔离性，使更好的复用，测试，结合

  可撤销性：

  应该允许突然的变动。如数据库系统，商业逻辑

  但随着项目的进展，一个个关键决策的作出，越来越难作出重大改变

  构建原型：

  使用高级的语言实现原型，推迟考虑许多细节，忽略完整性，可以使用虚设的数据，不使用文档和注释

  迅速产生一个演示，方便的进行展示，提供样本以修改，测试

  提供犯错误的机会，可以为不必要的开发做好准备

  在调试时小心“近视”:

  要抵制只修正你看到的症状的急迫愿望：有可能实际的故障就在旁边。

  要小心的改正每个错误，比编码更谨慎的态度去。因为错误的改正bug会导致真正bug更深次的隐藏

  代码生成：

  可用来解决“不要重复你自己”问题，不用复制粘贴代码，而采用一个源文件生成代码的方式来进行，永远保持生成代码

  通过合约进行设计：

  对前条件严格，传递好数据是调用者的责任。而允诺返回的东西要尽可能少。

  早崩溃，对于一个错误的参数，要直接了当的崩溃，明确错误

  软件中不可能发生的事情，也可能发生，要检查，断言：

  一个月少于28天

  c++:a=2;b=3;if(a+b!=5) exit(1);

  内角和不等于180度的三角形

  没有60秒的一分钟

  java：（a+1)<=a

  永远要相信事情有可能发生，不要轻易断言

  要针对不同的问题，采取生成错误信息，或引发异常，或忽略！

  元数据驱动(扩展性)：

  把抽象放进代码，细节放进元数据

  对决定性的配置放在代码外，进行配置

  商业逻辑更应成为元数据

  如采购天数，定期备份等等，这些数据应放在配置文件中，单独列出

  清楚了解什么事物表示为程序的具体代码，什么应表示为外部的元数据

  其实也就是扩展性，应该把经常变动，或者需要变动事物列出，方便用户自主更改

  何时进行重构：

  重复：发现对DRY原则的违反

  非正交的设计

  过时的知识

  性能

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

  2.在开始重构之前，确保拥有良好的测试，这样，如果改动破坏力任何东西，便能很快知道

  3.采取短小，深思熟虑的步骤

  不要使用你不理解的向导代码：

  特别是这些代码与你自己的代码交织一起，你就只能前进，而不知道修改，特别是GUI构建

  形式方法（UML)：

  它们无法表示有适应能力的动态系统

  鼓励专门化，需要专门去学习，把设计数据模型的人跟具体编码人分离

  代码测试：

  编一点，修一点

  sign your work! (收起)

  2011-09-09 15:05:52   回应

  收藏

  推荐
• 

  第28页

  bambreeze (thinking...)

  这里提到了“元数据”和“代码生成器”。这确实是一个好办法，但是不知道难度和复杂度是否很高？我记得以前一个项目，服务器和客户端分别用两种不同的编译器，中间需要一个接口模块来处理调用关系。当时完全是由手工来写代码的，这样每次设计改动都会有很大的重复工作量。曾经尝试过用lex&yacc来解决，但是太复杂，自己的功力又不到，没有成功。现在回想一下，似乎可以用脚本语言，类似Perl/Tcl来解决。 (更多)

  这里提到了“元数据”和“代码生成器”。这确实是一个好办法，但是不知道难度和复杂度是否很高？我记得以前一个项目，服务器和客户端分别用两种不同的编译器，中间需要一个接口模块来处理调用关系。当时完全是由手工来写代码的，这样每次设计改动都会有很大的重复工作量。曾经尝试过用lex&yacc来解决，但是太复杂，自己的功力又不到，没有成功。现在回想一下，似乎可以用脚本语言，类似Perl/Tcl来解决。 (收起)

  2012-02-10 12:34:12   回应

  收藏

  推荐
• 

  第5页

  bambreeze (thinking...)

  “破窗”理论有点意思。在软件开发中，确实如此。如果有谁开始写的代码有点问题，而遗留下来不去修改，那么后面的开发者也基本上不会去改正，而且代码会写的越来越差 (更多)

  “破窗”理论有点意思。在软件开发中，确实如此。如果有谁开始写的代码有点问题，而遗留下来不去修改，那么后面的开发者也基本上不会去改正，而且代码会写的越来越差 (收起)

  2012-02-10 12:14:46   回应

  收藏

  推荐

• 

  第1页

  oo/Apple (德州扑克，十分给力)

  讲的内容有点玄乎，对于初出茅庐的我们来说，没人指导的话很难想明白深层次的东西。这书啊，还是越有经验看着越有味道 (更多)

  讲的内容有点玄乎，对于初出茅庐的我们来说，没人指导的话很难想明白深层次的东西。这书啊，还是越有经验看着越有味道 (收起)

  2011-04-04 23:37:30   回应

  收藏

  推荐
• 

  第1页

  阿来 (天啊 我竟然喜欢歌舞剧!)

  霍炬的序：《程序员升级必备》 当一个程序员水平不够的时候，永远不能认识到那些朴素道理的重要。而当水平达到的时候，这些道理自然会明白。所以一本帮助程序员进阶的书，很容易落到低手觉得是废话，高手也觉得是废话的悲惨境地。 在我心目中，最好的入门书永远是《代码大全》，那也是对我影响最深的一本书。而这本不逊于代码大全的伟大著作。 好书不会因为平台的变化和技术的变迁而消亡，好书只会成为经典。无论是《人月神话... (更多)

  霍炬的序：《程序员升级必备》

  当一个程序员水平不够的时候，永远不能认识到那些朴素道理的重要。而当水平达到的时候，这些道理自然会明白。所以一本帮助程序员进阶的书，很容易落到低手觉得是废话，高手也觉得是废话的悲惨境地。

  在我心目中，最好的入门书永远是《代码大全》，那也是对我影响最深的一本书。而这本不逊于代码大全的伟大著作。 好书不会因为平台的变化和技术的变迁而消亡，好书只会成为经典。无论是《人月神话》还是《代码大全》，都在时间的长河中沉淀下来，传诵至今。这本书也有10年历史了，不过现在翻来看也毫不落伍，甚至感觉穿透了时间，看到了这些年中不少自己犯过的错误，我相信这也是一本经得起时间沉淀的书，只不过需要多点耐心。

  正如本书开头所说：注重时效的程序员应该不断学习。我们都应该不断地学习下去。

  徐宥的序：《程序员心底的小声音》

  在任何行业，适合新手的入门书很多，适合中手的书就很少。原因有两个，一来高手极少愿意耐心指点成长秘诀，即使写了，也是蜻蜓点水，因为这些经验啊，结论啊，都被他们本身提炼成了珠玑，他们觉得最重要的就是那么寥寥几句，说多了都是废话。而读者往往没有类似的经历，看到这些珠玑，也只是觉得把玩颇为有趣而已，极少能有同感。而没有同感，接受起来效果也不好。二来中手水平参差不齐，偏好不一，挑三拣四，自作聪明，所以也不太喜欢读这些书。 但是还是有一些书的，比如《Pragmatic Programmer程序员修炼之道》《The Art of UNIX ProgrammingUNIX编程艺术》《Elements of Progarmming Style 程序风格珠玑》和《The Productive Programmer卓有成效的程序员》。

  能否让正确的原则指导正确的行动本身，其实就是区分是否是高手的一个显著标志。比如KISS，很多人知道，但是能否内化，并用在自己写的程序里，这个可能就是区分中手和高手的标志了。

  如何将原则尽快内化成自己的行动？--- 就是说怎样尽快成为高手？ 第一条路需要有一个高强度的环境，没有高强度复杂的文本处理任务，很难内化正则表达式；没有大型多模块项目，很难内化自动化构建和测试。 第二条路就是有意识的反复强化实践和反复提醒。想要内化这些小声音，还是要靠实践，如果不实践，即使你把这些小声音写在100块钱的高档笔记本上也没有用。不妨一段时间反复练习里面的几个tips，内化后再练习其他的。几个月可能就把所有的tips都实践过了。

  高手可以看这个书，很可能你对其中一些道理的认识比作者还要深刻。那有什么关系呢，能够帮助你提炼更加圆润的珠玑岂不是更好？

  书籍正文的摘录和思考：

  第一章 注重实效的哲学

  注重实效的编程源于注重实效的思考的哲学。

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

  注重实效的程序员对他自己的职业生涯负责，并不害怕承认无知或错误。遇到各种问题，尽量职业地处理他们。这意味着诚实和坦率。负责，并设法给出各种选择，而不是抱怨他人。

  提供各种选择，不要找蹩脚的借口。

  这个就最好懂了。工作过的人都知道，谁也不喜欢满嘴借口的人。犯错不怕，就怕犯了错还不承认，不吸取教训，不想弥补。

  不要容忍破窗户

  一个软件的腐烂可能就是从一个模块腐烂开始的，所以及时修补，省得代码越来越烂。这点驴哥有句话特别好：只要嗅到自己的代码有一点点坏的味道，就要及时修正。 反过来，如果一个项目代码整洁，设计良好，而且很优雅，你就很有可能会格外注意不要去把他弄脏。

  请求原谅，比获取许可更容易。

  有时候你想做一个事情，畏首畏脚到处去争取许可和同意往往得不到许可和帮助。而你先开始做，让别人看到你的成果，或者起码看到你的勇气。再找资源和获得帮助就会容易得多。你需要做变化的催化剂，而不是等着变化。

  也让我想起了google做google books的一个原则：书籍先扫描收录（当然只是有限的页码），如果有作者提出不妥，再删除相应的部分。这样可能要比事先设法联系作者，请求许可要容易得多。如果google采取第二种办法，我甚至怀疑他还能不能做成这件事。

  记住Big Picture

  这个和我在公司的经历差不多，leader总是教育我们要站在更高的层面思考。比如站在组长的层面，站在总监的层面。这样你做的事情才不会在方向上出问题，和上级的沟通也会更加的顺畅。记得翟鸿亮在他的《心路文集》（腾讯内部分享）里画过一张，个人能力和团队贡献度的图。即使你的个人能力箭头再长，和团队的方向不一致，给到团队的分力可能也不够。

  使质量成为需求问题

  人们往往喜欢现在能用的还ok的软件，不喜欢后天才能用的完美的软件。

  知道何时止步

  在某些方面，编程就像绘画。如果你不懂何时止步，所有的辛劳就会遭到破坏。如果你一层又一层，细节复细节的叠加，绘画就迷失在来绘画本身了。

  知识上的投资总能得到最好的回报。

  你的知识经验是你最重要的职业财富。但遗憾的是，知识资产是有实效的。所以你要不停的学习。管理知识资产和管理我们通常意义上的资产有很多相似的地方，比如：

  1、严肃的投资者定期投资---作为习惯。（定期学习）

  2、多元化是长期成功的关键。（拓宽你的知识面，比如多种编程语言，你知道的事情越多，你就越有价值）

  3、聪明的投资者在保守的投资和高风险、高回报的投资之间做出平衡。（不要抱着铁饭碗的死脑筋。不要把你所有的技术鸡蛋放到）

  4、投资者设法低买高卖，以获取最大回报。（在一个知识大多数人接触前熟练掌握，往往可以使自己更吃香）

  5、应周期性的重新评估和平衡资产。（周期性的回顾自己的知识结构，看看哪方面需要重点提高）

  批判地分析你读到的和听到的

  不要人云亦云，要有独立思考的精神和能力。现在这个社会，视图混淆你的视听，扰乱你的步伐的事情太多了。

  在社区提问时，切记提问的技巧。

  关于学习，作者也给出了一些实际行动的建议。

  每一年学习一门新语言。（新工作要求把C++的编程能力提高，或者可以去学一下smalltalk？）

  每一季度读一本技术书籍。（我的技术书籍不是太少了，而是消化得太少了）

  关于交流：你说什么和你怎么说同样重要。

  这个在我的工作中体现得尤为明显，有的时候怎么说比说什么本身还重要... 交流越有效，你就越有影响力，真的这样。

  第二章 注重实效的途径

  上面一章讲得是哲学（就是讲道理），这一张开始讲途径（方法）。这本书的组织方式和我时间管理课程的思路有点像啊。这一章主要讲的是开发过程中要遵循的一些原则。

  系统中的每一项知识，都必须有单一，权威，无歧义的唯一一个解释。这就是DRY原则。

  DRY---- Don't Repeat Yourself.

  两个方面理解：

  1、系统中不要存在自相矛盾的两个地方（比如文档和代码的不一致）

  2、自己不要做重复性的工作

  避免信息的人工多重表示。

  比如过多的注释可能造成你改代码时候不得不也改注释，注释很容易被遗忘而变得自相矛盾。改成由文本或代码生成器来生成会更好。

  而很多的重复也是可以在代码设计阶段解决的。比如一个表示线段的类:

  class Line {

  public:

  Point start;

  Point end;

  double length;

  };

  其中，length显然是可以通过起点和终点坐标计算出来的。那么这里最好可以让他以函数的形式返回。

  class Line {

  public:

  Point start;

  Point end;

  double length() { return start.distanceTo(end);

  };

  而每次这样求length显然很慢。有时候你不得不使用缓存而可能影响DRY原则。那么这么做的诀窍是尽量使得影响局部化。

  比如提供setStart setEnd接口，使得改变start 或者end都有标识，那么只有length()方法检测到起点或者终点有更新后，才更新length。

  这个例子还带出来了像Java C++这样面向对象语言的另一个重要的问题：在可能的情况下，总是使用accessor访问器来读写对象的属性。这样是的未来增加功能（比如缓存）变得容易很多。

  还有很多的重复是程序员偷懒造成的，比如直接拷贝粘贴代码段，而不是将公用的抽取出来做成公共库。比如原来的千年虫问题（程序员偷懒用两个数字代表年份，而不是参数指定）。这个就需要你知道一个道理：现在节省几分钟，可能会导致以后花费数周的时间偿还。

  开发者之间的重复也太常见了。比如公司内可能很多部门在写着差不多的函数库，比如很多部门在搞分布式数据平台... 比如大家都在写着自己的身份证验证合法性代码... 避免这个问题可能需要两个方面都给力一点，一个是要有强有力和方向明确的领导，各个部门或技术团队之间权责清晰。二个是鼓励技术人员之间的相互交流，比如腾讯的KM平台就是一个很好的例子。

  让复用变得容易。

  你要做的就是营造一种环境，在其中找到并复用已有的东西比自己编写要容易。如果不容易，大家就不会去复用。就这么简单。

  正交性。比如MVC可能就比较符合正交性，你动用户界面，不会影响底层数据或者算法。我们就说界面和底层是正交的。比如直升机的控制器就不是正交的。

  所以我们说，尽量降低无关事物之间的影响。

  你的系统都是正交的组件的话，好处非常的多。

  1、可以提高生产率，因为正交的系统往往更好测试，往往相乘后的到的组合功能会最大化。

  2、无疑可以降低变更的风险，正交系统可以得到更好的测试。

  工作中的正交性不只体现在编码上。团队的任务分配如果正交性太差，则很容易出现相互不符合DRY原则和扯皮的情况发生。成员也就会对责任感困惑。（想想自己原来的团队）

  在系统设计上，典型的正交性原则是分层设计、模块化和基于组件。

  在编码上，保持你编写模块的高内聚，低耦合很重要。说白了就是编写羞怯的代码。如果你要改变某个对象的属性，让这个对象自己去完成。

  测试，建议每个模块都拥有自己的、内建在代码中的单元测试，并让这测试作为常规构建过程的一部分自动运行。（想到了make test）

  (收起)

  2011-05-17 21:39:49   回应

  收藏

  推荐
• 

  第1页

  逆游的鱼

  我在读书的时候就听过着本书的大名，现在网上也有这本书的pdf分享版本。一直就觉得计算机方面的书籍太贵了，致使很都先进的知识得不到有效的普及。程序员修炼之道这本书，以程序员职业规划、所需知识等为线索，提到了一些代码优化，整合知识，但是不够全面。更多www.nsdupiwu.com计算机信息。 (更多)

  我在读书的时候就听过着本书的大名，现在网上也有这本书的pdf分享版本。一直就觉得计算机方面的书籍太贵了，致使很都先进的知识得不到有效的普及。程序员修炼之道这本书，以程序员职业规划、所需知识等为线索，提到了一些代码优化，整合知识，但是不够全面。更多www.nsdupiwu.com计算机信息。 (收起)

  2011-06-02 13:55:25   回应

  收藏

  推荐

• 

  第28页

  bambreeze (thinking...)

  这里提到了“元数据”和“代码生成器”。这确实是一个好办法，但是不知道难度和复杂度是否很高？我记得以前一个项目，服务器和客户端分别用两种不同的编译器，中间需要一个接口模块来处理调用关系。当时完全是由手工来写代码的，这样每次设计改动都会有很大的重复工作量。曾经尝试过用lex&yacc来解决，但是太复杂，自己的功力又不到，没有成功。现在回想一下，似乎可以用脚本语言，类似Perl/Tcl来解决。 (更多)

  这里提到了“元数据”和“代码生成器”。这确实是一个好办法，但是不知道难度和复杂度是否很高？我记得以前一个项目，服务器和客户端分别用两种不同的编译器，中间需要一个接口模块来处理调用关系。当时完全是由手工来写代码的，这样每次设计改动都会有很大的重复工作量。曾经尝试过用lex&yacc来解决，但是太复杂，自己的功力又不到，没有成功。现在回想一下，似乎可以用脚本语言，类似Perl/Tcl来解决。 (收起)

  2012-02-10 12:34:12   回应

  收藏

  推荐
• 

  第5页

  bambreeze (thinking...)

  “破窗”理论有点意思。在软件开发中，确实如此。如果有谁开始写的代码有点问题，而遗留下来不去修改，那么后面的开发者也基本上不会去改正，而且代码会写的越来越差 (更多)

  “破窗”理论有点意思。在软件开发中，确实如此。如果有谁开始写的代码有点问题，而遗留下来不去修改，那么后面的开发者也基本上不会去改正，而且代码会写的越来越差 (收起)

  2012-02-10 12:14:46   回应

  收藏

  推荐
• 

  第140页

  cherub

  靠巧合编程 (更多)

  靠巧合编程 (收起)

  2011-11-27 22:15:18   回应

  收藏

  推荐