研发团队必须从公司长远利益出发与其他部门抗争

近年来，我开始研究贝克的简单代码规则，差不多也都琢磨透了。简单代码，依其重要顺序：•能通过所有测试；•没有重复代码；•体现系统中的全部设计理念；•包括尽量少的实体，比如类、方法、函数等。在以上诸项中，我最在意代码重复。如果同一段代码反复出现，就表示某种想法未在代码中得到良好的体现。我尽力去找出到底那是什么，然后再尽力更清晰地表达出来。

借用美国童子军一条简单的军规，应用到我们的专业领域：让营地比你来时更干净。如果每次签入时，代码都比签出时干净，那么代码就不会腐坏。

我们都曾经瞟一眼自己亲手造成的混乱，决定弃之不顾，走向新一天。我们都曾经看到自己的烂代码居然能运行，然后断言能运行的烂程序总比没有强。我们都曾经说过有朝一日再回头清理。当然，那些日子里，我们都没听过LawofLeBlanc：Laterequalsnever

这就是科学理论和科学定律的特点：它们可以被证伪，但是没有办法被证明

整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。

好的系统架构设计应该尽可能做到与“形状”无关

我可以列出我留意到的整洁代码的所有特点，但其中有一条是根本性的。整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地。代码作者什么都想到了，如果你企图改进它，总会回到原点，赞叹某人留给你的代码—全心投入的某人留下的代码。

1，并发防御原则（1）单一权责：方法/类/组件应当只有一个修改的理由（2）限制数据作用域（3）使用数据副本避免共享数据（4）线程应尽可能独立2，了解常见的执行模型：生产者-消费者，读者-作者，宴席哲学家3，警惕同步方法之间的依赖4，保持同步区微小5，尽早考虑关闭的代码，注意线程之间的依赖关系6，测试线程代码（1）将伪失败看作可能的线程问题（2）先使非线程代码工作（3）运行多于处理器数量的线程

人渐渐地发现，这个世界上有很多问题就像翘翘板一样，只能要一边，这一边上去了，另边就下来了。就像要么用空间换时间，要么用时间换空间一样，你很难同时满足空间和时间要求的“双利解”；就像CAP的三选二的理论一样，这个世界不存在完美的解方案无论什么方案都有好的一面和不好的一面。而且这些工程师还还渐渐发现，每当引入一个新的技术来解決一个已有的问题时，这个新的技术就会带来更多的问题，问题就像有一个生命体一样，它们会不断地繁殖和进

《架构整洁之道》孙宇聪译，软件架构参考书籍。第一章软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。软件开发的核心特点:要想跑得快，先要跑得稳。过度自信只会使得重构设计陷入和原项目一样的困局中。研发团队最好的选择是清晰地认识并避开工程师们过度自信的特点，开始认真地对待自己的代码架构，对其质量负责。要想提高自己软件架构的质量，就需要先知道什么是优秀的软件架构。而为了在系统构建过程中采用好的

每次签入时，代码都比签出时干净。

一段程序可以由一个测试来证明其错误性，但是却不能被证明是正确的。测试的作用是让我们得出某段程序已经足够实现当前目标这一结论

通过将策略隔离，并让源码中的依赖方向都统一调整为指向高层策略，我们可以大幅度降低系统变更所常来的影响。因为一些针对系统低层组件的緊急小修改几乎不会影响系统中更高级、更重要的组件。

Noisewordsareanothermeaninglessdistinction.ImaginethatyouhaveaProductclass.IfyouhaveanothercalledProductInfoorProductData,youhavemadethenamesdifferentwithoutmakingthemmeananything

这些工程师们普遍用一句话来欺骗自己：“我们可以未来再重构代码，产品上线最重要！”但是结果大家都知道，产品上线以后重构工作就再没人提起了。市场的压力永远也不会消退，作为首先上市的产品，后面有无数的竞争对手追赶，必须要比他们跑得更快才能保持领先。所以，重构的时机永远不会再有了。工程师们忙于完成新功能，新功能做不完，哪有时间重构老的代码？循环往复，系统成了一团乱麻，生产效率持续直线下降直至为零。

软件架构使得目标是创建一种系统形态，该形态会以策略为最基本的元素，并让细节与策略脱离关系，以允许具体决策过程中推车或延迟与细节相关的内容

以及ExtremeProgrammingAdventuresinC#（中译版《C#极限编程探险》）作者

“架构”这个词给人的直观感受就充满了权利与神秘感，因此谈论架构总让人有一种正在进行责任重大的决策或者深度技术分析的感觉

也不必用m_前缀来标明成员变量。应当把类和函数做的足够小，消除对成员前缀的需要。你应该使用某种可以高亮或用颜色标出成员的编辑环境。此外，人们很快学会无视前缀（或后缀），只看到名称中有意义的部分。代码读得越多，眼中就越没有前缀。最终，前缀变作了不入法眼的废料，变作了旧代码的标志物。