第一章：追求实效的哲学
第一节：我的源码被猫吃了
在开发过程中，我们经常会遇到一些意想不到的技术问题，导致交付延迟等情况。然而，作为程序员，我们需要诚实和坦率地面对这些问题，并勇于承认自己的错误。我们应该以专业的态度处理这些问题，而不是找借口。
此外，我们要对自己承担的责任负责。如果有些事情超出了我们的控制范围，我们可以提前说明这一点。但是，我们需要对自己应负责的事情负责。如果出现了问题，比如磁盘崩溃而没有备份代码，那么这就是我们的责任。我们不能为错误找借口，而是应该向上级提供可行的解决方案，尽力挽回局面。
第二节：软件的混乱状态
熵是热力学中的概念，指的是系统中的无序程度。在软件工程中也存在类似的熵，即代码的无序状态。随着工程规模的增大，代码的无序状态会变得更加严重。
破窗理论告诉我们，当一个东西本身破旧时，人们不仅不会珍惜，还会进一步破坏。在软件开发中也是如此，如果我们的项目存在很多低劣的设计、错误的决策、糟糕的代码等问题，接手项目的人也会倾向于让它变得更糟糕。相反，如果代码质量良好，我们和接手项目的人都会更加注意保持代码的整洁。因此，我们应该尽早解决项目中存在的问题。
第三节：石头汤和煮青蛙
故事中的士兵们利用石头汤的方法，通过引发村民的好奇心和参与度，最终得到了村民的帮助，大家一起分享了一顿美味的饭菜。这个故事告诉我们，有时候我们需要主动采取行动，而不是等待一切准备好才开始。
在工作中，我们经常会遇到各种阻碍和困难，而请求许可往往会遇到拖延和漠然的态度。在这种情况下，我们不应该等待一切准备就绪，而是应该先行动起来。只要是有益的事情，我们可以先展示一部分结果，然后告诉别人如果有什么改进意见，大家一般都会愿意帮忙。
第四节：足够好的软件
我们应该将质量作为需求问题的一部分。在确定需求时，我们应该考虑到质量这一方面，并与产品或客户商定在规定的时间内可以接受的质量标准。
没有完美的软件，我们应该知道何时停下来。有时候，一个今天很不错的软件可能比明天的完美软件更有价值。我们应该尽早让用户使用软件，他们的反馈通常会帮助我们找到更好的解决方案。
第五节：你的知识资产
知识上的投资总能得到最好的回报。在计算机领域，我们可以将我们了解的技术实现和工作经验视为知识资产，并像管理金融资产一样管理这些知识。
经营知识资产可以从以下几个方面进行：定期投资、多元化、管理风险、低买高卖。定期投资意味着我们需要花时间学习，即使是很小的投资也是很重要的。多元化意味着我们不仅要掌握当前所从事的技术，还要关注技术的发展变化，掌握更多的知识，以便更好地应对变化。管理风险意味着不要把所有的技术都集中在一个地方。低买高卖意味着在新技术流行之前就掌握它，以获得更大的回报。
第六节：有效的交流
在交流中，我们需要明确自己想要表达的核心思想，并围绕这一点展开。了解听众的需求和兴趣，选择适合的风格和方式进行传达。同时，我们还应该注重文档的美观，引导听众参与，并及时回复他人的询问。
第二章：追求实效的途径
第七节：重复的危害
遵循DRY原则是开发可靠且易于理解和维护的软件的唯一途径。DRY是"Don't Repeat Yourself"的缩写。
重复通常有以下几种类型：强制性的重复、无意的重复、无耐心的重复、开发者之间的重复。我们应该尽量避免这些重复，并采取相应的措施来减少重复的发生。
第八节：正交性
正交性是一个从几何学中借鉴而来的概念，指的是某种不相互依赖或解耦的特性。正交性可以提高生产效率，降低代码风险。
在代码设计中应该尽可能考虑正交性
第九节：可撤销性
在设计软件时，我们需要考虑到可能出现的某种错误或需求变更，为此需要构建一个相对灵活的架构，以便于后续的修改和调整。这样的架构具有可撤销性，能够应对未来的变化。
第十节：曳光弹
在黑暗中使用机枪射击时，使用曳光弹可以帮助我们确定目标的位置，而不需要进行复杂的计算。同样地，在软件开发中，我们应该尽早让系统跑起来，然后根据需要逐步完善细节。这样做的好处包括用户能够及早看到可工作的部分、开发者能够构建一个可工作的结构、可以用于演示和感受工作进展。
第十一节：原型与便笺
原型是在忽略细节的情况下，考虑项目流程和主要使用场景的一种方式。通过制作原型，我们可以学习到宝贵的经验教训。制作原型时，我们可以使用便笺或白板，不一定需要编码。制作原型的过程中，我们需要回答一些关键问题，如主要组件的责任是否得到了良好定义、组件间的协作是否得到了良好定义等。
第十二节：领域语言
计算机语言会影响我们思考问题的方式和交流方式。领域语言通常是为了简化流程、配置或控制应用程序而使用的一种语言。DSL（领域特定语言）是一种小型语言，可以扩展自已有语言。在设计DSL时，我们需要权衡可读性和简单性，同时考虑可扩展性和可维护性。
第十三节：估算
通过学习估算并发展到直觉的程度，我们可以确定事物的可行性。估算并非准确度越高越好，而是要在合理的范围内给出一个可行的时间。估算的结果来自于建立系统模型，并根据模型计算出时间。模型应该是动态的，需要不断训练和调整。在被要求进行估算时，我们可以先回答"我等会儿回答你"，然后仔细检查估算的步骤，以得到更好的结果。
通过以上的实效哲学和途径，我们可以更加高效地开发软件，提高质量和效率。同时，我们也需要不断学习和改进，以适应不断变化的技术环境。
标签：代码,需要,读书笔记,重复,小工,程序员,软件,应该,我们 From： https://www.cnblogs.com/newzeon/p/17736952.html