程序员修炼之道

第4章 注重实效的偏执 　　这一章讨论了一个现实的问题，那就是一个程序员不可能写出完美的代码。就像我们平常的作业一样，很少能完美符合要求，总会或多或少存在一些不合理之处，这些不合理让我们程序成为了不完美的，但要去修正往往需要很大的精力。真正懂得实效的程序员会利用这种情况。 　　我们注重实效的话，往往就好在编码的时候进行预防工作，标记上容易出错的代码，而书本中的程序员甚至连自己都不会信任，防范会更加紧密。而能做到防范性的就是按照合约设计。 　　合约规定了我们的权利与责任，此外也规定了不遵守的后果，遵照合约进行开发双方都能受益。就像书中提到的DBC协议，为的是确保程序正确性，也就是在使用程序之前要用文档记录要做事情的程序。软件系统中每一个函数和方法都是做某种事情，再开始做之前，合约会寻杂找对应的条件，包括了 前条件 和 后条件， 也就是需求和结束，这样便完成了一个合约。 　　说实话我实在不能明白这些的意义，可能在未来就会运用的上吧。 来源： https://www.cnblogs.com/limitCM/p/11070550.html

程序员修炼之道读后感5 最近有阅读了《程序员修炼之道》这本书的第八章，使我收获颇丰。 第八章是注重实效的项目，主要讨论的是能使项目成功或失败的几个关键因素。主要是组织和管理团队、工作流程自动化、项目测试、编写文档和是使投资人高兴的诀窍等几个方面。 首先我明白了要修正那些容易的小漏洞，不然这些小漏洞一旦过多，大漏洞就比较难处理了。然后就是每个人都要注意环境的变化，比如说需求的变化以及其他硬件软件环境的变化。我 还明白了开发团队中要有交流，不然团队协作性就不好，无法发挥团队的力量，比如说文档不一致。我知道了团队中要有分工，这样工作起来才能更高效。我还学习到了正交性，项目中 各个活动要有正交性，不然一个活动出错，所有活动都会受到影响，要围绕功能、而不是工作职务进行组织。我还明白了要是用一些强大的工具实现自动化，这样可以降低工作量。一切 可以用自动化实现尽量都用自动化，比如说项目编译、生成代码、回归测试。我明白了要实现这样的自动化，就必须构建自动化，要注意最终构建，要学会自动化管理，比如说网站生成、 批准流程等。我学到了我们要学会自制能够帮助我们的工具。再来说说测试吧，要经常测试、早测试、自动测试，不能温和的测试你的程序，测试的目的不是为了通过，而是要找出隐藏的 问题，所以要测试程序的极限以发现可能存在的问题，要注意资源的使用、性能测试和可用性测试。我还学习到了一些测试的方法，比说测试数据

　　本书第八章为注重实效的项目。 　　在“注重实效的团伙”部分，首先讲了团队作为一个整体，不应该容忍破窗户。其次是团队作为实体需要与外界明晰的交流。给出了提示60，“围绕功能，而不是工作职务进行组织”。确保一致的和准确的一种很好的方式是使团队所做的每件事情自动化。 　　在“无处不在的自动化”部分，给出了提示61，“不要使用手工流程”。在项目编译时，使用makefile有若干好处。项目构建包括以下几个步骤：1、从仓库中签出源码2、从头开始构建项目3、创建可分发映像4、运行规定的测试。对于大多数项目，这一层面的构建是在每天夜间自动运行的。 　　在“无情的测试”部分，给出了提示62，“早测试，常测试，自动测试”。提示63，“要到通过全部测试，编码才算完成”。项目范围测试的三个主要方面是：测试什么（单元测试，集成测试，验证和校验，资源耗尽、错误及恢复，性能测试，可用性测试），怎样测试(回归测试，测试数据，演练GUI系统，对测试进行测试，彻底测试），以及何时测试。给出了提示64，“通过蓄意破坏测试你的测试”。提示65，“测试状态覆盖，而不是代码覆盖”。提示66，“一个bug只抓一次”。 　　在“全都是写”部分，提到注重实效的程序员会把文档当作整个开发过程的完整组成部分加以接受。给出了提示67，“把英语当作又一种编程语言”。提示68，“把文档建在里面，不要拴在外面”。 　　在“极大的期望”部分

第六章：当你编码时 这一章的内容和我们现在经常做的事情息息相关，需要好好理解理解。 注重实效的程序员批判地思考所有代码，包括我们自己的。我们不断地在我们的程序和设计中看到改进的余地。在“重构”中，我们将讨论一- 些即使我们还处在项目中期，也能帮助我们修正现有代码的技术。 只要你在制作代码，你就应当记住，有一天你必须对 其进行测试。这样你将增加它实际通过测试的可能性。 怎样深思熟虑地编程 我们想要让编写代码所花的时间更少，想要尽可能在开发周期的早期抓住并修正错误，想要在一开始就少制造错误。如果我们能深思熟虑地编程，那对我们会有所帮助: ●总是意识到你在做什么。Fred让事情慢慢失去了控制，直到最后被煮熟，就像“石头汤与煮青蛙”里的青蛙一样。 ●不要盲 目地编程。试图构建你不完全理解的应用，或是使用你不熟悉的技术，就是 希望自己被巧合误导。 ● 按照计划行事,不管计划是在你的头脑中,在鸡尾酒餐巾的背面. 还是在某个CASE工具生成的墙那么大的输出结果上。 ●依靠可靠的事物。不要依靠巧合或假定。如果你无法说出各种特定情形的区别,就假定是最坏的。 ●为你的假定建立文档。 “按合约编程" 有助于澄清你头脑中的假定，并且有助于把它们传达给别人。 ●不要 只是测试你的代码，还要测试你的假定。不要猜测;要实际尝试它。编写断言测试你的假定。如果你的断言是对的，你就改善了代码中的文档

内容目录： 提供多种选择，不要找接口 不要容忍破窗户 投资知识资产 多交流，会交流 DRY -不要重复你自己 维持正交性 可撤销，可更换 无处不在的自动化 不要靠巧合编程 测试的重要性 新方法和新工具 附：思维导图笔记 提供多种选择，不要找接口 出了问题后，要提出各种解决方案的选择，而不是找借口；不要说事情做不到，要说明接下来做什么来挽回局面； 不要容忍破窗户 我们看到过整洁、运行良好的系统，一旦窗户开始破裂，就相当迅速的恶化； 不要留着破窗户不修；发现一个bug就修复一个，如果没有足够的时间进行恰当的修理，就用木板先订起来；或许你可以先把代码注释起来，或是显示“未实现”的消息；采取某种行动防止进一步的损坏，并说明情形在你的控制之下； 投资知识资产 我们喜欢把程序员所知道的关于计算机技术和经验视为他们的知识资产； 你的资产是有时效的资产，会随着新技术、语言和环境的出现而变得过时； 管理知识资产与管理金融资产非常类似： 严肃的投资者定期投资-作为习惯 多元化是长期成功的关键 管理风险；聪明的投资者在保守的投资和高风险的投资之间平衡他们的资产； 应周期性的重新评估和平衡资产 投资建议： 每年至少学习一种新语言； 每季度至少阅读一本技术书籍； 也要阅读非技术书籍； 多交流，会交流 与他人交流时，你需要了解你的听众： 你想他们学到什么？ 他们对你讲的什么感兴趣？ 他们有多富有的经验？

译 序 本书原名“The Pragmatic Programmer”，也就是“注重实效的程序员”。正如书名所示，本书将围绕“注重实效”讲述关于编程的各种话题：个人责任、曳光弹开发、调试策略、元程序设计、按合约设计（Design By Contract）、重构、无情的测试，等等。看到本书的目录，你也许会奇怪，300多页的篇幅，怎么能涵盖如此多内容？但本书的两位作者Andy Hunt和Dave Thomas的确做到了，他们知道抵达编程的各种维度的途径，并找到了一种言简意赅的方式讲述这些途径；与此同时，在书中还提供了大量资源，可以帮助你找到各种更深入讨论这些话题的读物。本书的各个小节既独立又相关，你可以从头开始阅读，也可以随手翻开任何一页开始阅读——Dave Thomas就将本书视为一本“洗手间读物”。如果你是编程初学者，你可以从本书中了解到各种编程技术和方法，根据书中的指引拓展你的编程生涯；如果你是富有经验的程序员，同样可以从本书中获益：如果一本书能够全面、明晰地总结你从实践中获得的各种认识、总结你从其他书里散乱地读到的技术和方法，这本书就一定不是无益的。 除了是程序员，Andy Hunt还是一位木匠和音乐家，而Dave Thomas则喜欢驾驶单引擎飞机。尽管作者未曾明言，在本书的许多地方，你都将看到与这样的背景相关的叙述。我想，对于两位作者而言，编程就和木匠活、和音乐创作

　　本书第四章为注重实效的偏执。 　　给出了提示30，你不可能写出完美的软件。 　　在“按合约设计”部分，给出了提示31，通过合约进行设计。如果语言不在代码中支持DBC，也可以把合约作为注释放在代码中。通过早崩溃，在问题现场找到和诊断问题要容易的多。 　　在“死程序不说谎”部分，给出了提示32，早崩溃。当你的代码发现，某件被认为不可能发生的事情已经发生时，你的程序就不再有存活能力，从此时开始，他所做的任何事情都会变得可疑，所以要尽快终止他，死程序带来的危害通常比有疾患的程序要小的多。 　　在“断言式编程”部分，给出了提示33，如果它不可能发生，用断言确保它不会发生。 　　在“何时使用异常”部分，关于异常的问题之一是知道何时使用他们。异常很少应作为程序的正常流程的一部分使用，异常应保留给意外事件。给出了提示34，将异常用于异常的问题。 　　在“怎样配平资源”部分，给出了提示35，要有始有终。他意味着，分配某项资源的例程或对象应该负责解除该资源的分配。对于需要不止一个资源的例程，可以对资源分配的基本模式进行扩展，给出了两个建议，1、已与资源分配次序相反的次序解除资源分配 2、在代码的不同地方分配同一组资源时，总是以相同的次序分配他们，这将降低发生死锁的可能性。 来源： https://www.cnblogs.com/songxinai/p/11865798.html

41 注重实效的团队 不留破窗户 不做温水青蛙，时刻注意到外部的变化如需求、商业政策等 不要重复自己 正交性：围绕功能而不是工作职务进行组织 42 无处不在的自动化 不要手工 自动化： 测试 构建 生成代码 批准流程 来源： https://www.cnblogs.com/xiangyu721/p/11963898.html

22 死程序不说谎 早崩溃。不要破坏（trash），写入错误的数据 23 断言式编程 如果它不可能发生，用断言确保它不会发生。 断言时不要有副作用 24 何时使用异常 理解需求，异常是留给意外事件的 25 怎样配平资源 要有始有终：分配资源，使用它，释放它 嵌套的分配（一次性不只一个资源） · 以与资源分配的次序相反解除资源的分配，如果一个资源含有对另一个资源的引用，就不会造成资源被遗弃 · 在代码不同的地方分配同一组资源，总是以相同的次序分配他们，这将降低死锁的可能性。 26 解耦与得墨忒耳法则 遵循得墨忒耳法则虽然可以减少模块之间的依赖，但是会带来很多委托方法出现，不仅增加无关的代码，还影响代码的执行速度，所以需要根据不同的场景折衷，违反规范来赢取性能的改进。 27 元程序设计 元数据 · 元数据（metadata）:描述应用的配置选项：调协参数、用户偏好 · 元数据严格意义上是数据的数据，宽泛意义上是对任何对应用进行描述的数据。（除了偏好外，还有资源等） · 元数据是在运行时被访问和使用，而不是在编译时。 把抽象放在代码，把细节放在元程序 28 时间耦合 一开始编程都是按照时间的顺序去进行。但是一旦需要并发时，就出现了麻烦。 利用UML的活动图，分析工作流。 29 它只是视图 我们基于分而治之的理念将程序分成若干个模块，但是怎么管理组织不同模块（类）之间依赖确实一个难题。

编码不是机械工作。如果要让所得的程序享有长久的、无误和富有生产力的 “一生”，就必须对这些决策进行仔细的思考。不主动思考他们的代码的开发者是在靠巧合编程——代码也许能正常工作，但却没有特别的理由说明他们为何能工作。有时候尽管我们的代码能够快速运行，我们偶尔也会开发一些算法，可能会让最快的处理器陷入困境。我们要学会一些估算代码的速度的方法，发现这些潜在问题。大多数并非微不足道的算法都要处理某种可变的输入。通常，这些输入的规模会影响算法：输入越多，运行时间就越长，或者使用的内存就越多。 Don’t Use Wizard Code You Don,t Understand. 不要使用你不理解的向导代码。向导生成的代码变成了 Joe 的应用的完整组成部分。向导代码并没有被分解出来，放在整洁的接口后面——它一行一行地与 Joe 编写的功能交织在一起。最后，它不再是向导的代码，而变成 Joe 的代码。没有人应该制作他们不完全理解的代码。 完美，不是在没有什么需要时增加，而是在没有什么需要去掉时达到的。需求很少存在于表面上，通常，他们深深的埋藏在层层假定、误解和政治手段的下面。需求是对需要完成的某件事的陈述。 编写程序规范就是把需求归约到程序员能够接管的程度的过程。这是一个交流活动，旨在解释并澄清系统的需求，比如消除主要的歧义。除了与最初实现的开发者交谈以外