Clean Architecture

• 悠然生活

  2021-11-08
  如果想设计一个便于推进各项工作的系统，其策略就是要在设计中尽可能长时间地保留尽可能多的可选项
• 悠然生活

  2021-11-08
  软件架构这项工作的实质就是规划如何将系统切分成组件，并安排好组件之间的排列关系，以及组件之间互相通信的方式
• 悠然生活

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

  2021-10-27
  一个架构设计良好的应用程序应该将状态修改的部分和不需要修改状态的部分隔离成单独的组件，然后用合适的机制来保护可变量。
• 悠然生活

  2021-10-27
  面向对象编程就是以多态为手段对源代码中的依赖关系进行控制的能力
• 悠然生活

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

  2021-10-26
  这就是科学理论和科学定律的特点：它们可以被证伪，但是没有办法被证明
• 悠然生活

  2021-10-25
  研发团队必须从公司长远利益出发与其他部门抗争
• 悠然生活

  2021-10-25
  好的系统架构设计应该尽可能做到与“形状”无关
• 悠然生活

  2021-10-25
  对机器上那些很难改变的工作行为，我们通常称之为硬件（hardware）
• 阿树

  2021-03-13
  按照这些架构设计出来的系统，通常都具有以下特点。独立于框架：这些系统的架构并不依赖某个功能丰富的框架之中的某个函数框架可以被当成工具来使用，但不需要让系统来适应框架。可被测试：这些系统的业务逻辑可以脱离U、数据库、Web服务以及其他的外部元素来进行测试。独立于U：这些系统的U变更起来很容易，不需要修改其他的系统部分例如，我们可以在不修改业务逻辑的前提下将一个系统的UI由Web界面替换成命令行界面。独立于数据库：我们可以轻易将这些系统使用的 Oracle、 SQL Server替换成 Mongo、 Big Table、 COUCHDB之类的数据库。因为业务逻辑与数据库之间已经完成了解耦。独立于任何外部机构：这些系统的业务逻辑并不需要知道任何其他外部接口的存在。
• 阿树

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

  2021-03-06
  正如我们之前所说，架构师们所追求的目标是最大限度地降低构建和维护一个系统所需的人力资源。那么我们就需要了解一个系统最消耗人力资源的是什么？答案是系统中存在的耦合一一尤其是那些过早做出的、不成熟的决策所导致的耦合。那么，怎样的决策会被认为是过早且不成熟的呢？答案是那些决策与系统的业务需求（也就是用例）无关。这部分决策包括我们要采用的框架、数据库、Web服务器、工具库、依赖注入等。在一个设计良好的系统架构中，这些细节性的决策都应该是辅助性的，可以被推迟的。一个设计良好的系统架构不应该依赖于这些细节，而应该尽可能地推迟这些细节性的决策，并致力于将这种推迟所产生的影响降到最低。
• 阿树

  2021-03-06
  首先，软件架构师自身需要是程序员，并且必须一直坚持做一线程序员，绝对不要听从那些说应该让软件架构师从代码中解放出来以专心解决高阶问题的伪建议。不是这样的！软件架构师其实应该是能力最强的一群程序员，他们通常会在自身承接编程任务的同时，逐渐引导整个团队向一个能够最大化生产力的系统设计方向前进。也许软件架构师生产的代码量不是最多的，但是他们必须不停地承接编程任务。如果不亲身承受因系统设计而带来的麻烦，就体会不到设计不佳所带来的痛苦，接着就会逐渐迷失正确的设计方向。
• 阿树

  2021-03-06
  根据上述讨论，我们可以得出一个无法逃避的结论：组件结构图是不可能自上而下被设计出来的。它必须随着软件系统的变化而变化和扩张，而不可能在系统构建的最初就被完美设计出来。
• 阿树

  2021-02-28
  这就是科学理论和科学定律的特点：它们可以被证伪，但是没有办法被证明。但是我们仍然每天都在依赖这些定律生活。开车的时候，我们就等于是在用性命担保F=ma是对世界运转方式的一个可靠的描述。每当我们迈出一步的时候，就等于在亲身证明F=Gm1m2/r2是正确的。科学方法论不需要证明某条结论是正确的，只需要想办法证明它是错误的。如果某个结论经过一定的努力无法证伪，我们则认为它在当下是足够正确的。当然，不是所有的结论都可以被证明或者证伪的。举一个最简单的不可证明的例子：“这句话是假的”，非真也非伪。最终，我们可以说数学是要将可证明的结论证明，而与之相反，科学研究则是要将可证明的结论证伪。
• 阿树

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

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

  2019-08-15
  《架构整洁之道》孙宇聪译，软件架构参考书籍。第一章软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。软件开发的核心特点:要想跑得快，先要跑得稳。过度自信只会使得重构设计陷入和原项目一样的困局中。研发团队最好的选择是清晰地认识并避开工程师们过度自信的特点，开始认真地对待自己的代码架构，对其质量负责。要想提高自己软件架构的质量，就需要先知道什么是优秀的软件架构。而为了在系统构建过程中采用好的设计和架构以便减少构建成本，提高生产力，又需要先了解系统架构的各种属性与成本和生产力的关系。第二章软件系统两个价值维度-----行为价值和架构价值。软件架构师这一职责本身就应该更关注系统的整体结构，而不是具体的功能和系统行为的实现。软件架构师必须创建出一个可以让功能实现起来更容易、修改起来更简单、扩展起来更轻松的软件架构。第四章在架构设计领域，功能性降解拆分仍然是最佳实践之一。第十五章软件架构师自身需要是程序员，并且必须一起坚持做一线程序员，绝对不要听从那些说应该让软件架构师从代码中解放出来以专心解决高阶问题的伪建议。如果不亲身承受因系统设计而带来的麻烦，就体会不到设计不佳所带来的痛苦，接着就会逐渐迷失正确的设计方向。软件架构这项工作的实质就是规划如何将系统切分成组件，并安排好组件之间的排列关系，以及组件之间互相通信的方式。软件架构的终极目标就是最大化程序员的生产力，同时最小化系统的总运营成本。在真正制作出来一个可复用框架之前，是不知道怎么制作一个可复用框架的。想要制作一个可复用的框架，必须要和几个复用该框架的应用一直开发。
• 阿树

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