相关语录

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

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

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

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

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

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

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

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

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

软件架构师可以根据相关函数被修改的原因、修改的方式及修改的时间来进行分组隔离，并将这些相互隔离的函数分组整理成组件结构，使得高阶组件不会因低阶组件被修改而收到影响