wxya（个人网站）《聊聊架构》
前言
一周之前买的这本书，每晚看一点，到今天翻完了。之所以看的这么快（我读书速度挺慢的），是因为书里有很多内容我感觉没必要细看，有些内容是普及概念的，有些内容是离我比较远的。不过，有些内容还是很令我印象深刻的。
（原文链接 juejin.cn/post/685457… ，未经允许禁止转载）
架构和业务
脱离业务的架构，就是耍流氓
什么是架构，什么是架构师？这个词、这个概念，众说纷纭，我们要去没必要非得去讨论出个定义。
不过书中提到一个观点：无论架构和架构师如何定义，它都必须是依赖于业务的，而不是依赖于技术的。我也觉得这一点非常重要。
无论你会多少编程语言，多少流行框架，造过多少轮子，原理源码的了解多深，工程化多熟练…… 只要你不了解这个公司的业务，或者干着和业务无关的工作，你的工作都和架构不沾边。
架构和技术
技术人员对待不同技术是有区别的，对自己喜欢的技术是有感情的，也会有自己不喜欢的技术。所以大家会为了“php 是不是最好的语言”吵群架。而且，技术人员喜欢追求新技术，实际工作开发时恨不得把网上热门的新技术都用个遍，感觉这才能体现出自己的与众不同。
架构师会很冷静、很平等的看待所有技术。他们会深刻思考业务流程，看看哪些技术能满足需求，而且会考虑使用成本、效率、稳定性、未来可扩展性等。而不是考虑这个技术是先进还是落后。总之，所以技术都是平等的，所以技术就是为业务服务的。
“不写代码就没有资格叫架构师” —— 这句话也不完全对。认真观察你会发现，越是级别高的架构师，越关注抽象的业务，就越有可能不是程序员出身。
架构师和 leader
架构师要权责匹配，因为架构的关键并不仅仅在于设计，而在于执行。如果权责不相等，那在实时执行、监控时，就有可能走歪了，或者根本执行不起来。
例如，架构设计时要求项目流程必须有 code review ，如果架构师没有权利要求大家去 code review ，那大家就会敷衍了事，或者干脆不积极参与。
所以，书中所讲的，一个组织真正的架构师就是 leader，而不是具有架构师头衔的人。那些手拿摇扇，指点江山，只出谋划策却没有实际权利的人，不算是架构师。
但是实际情况是，大部分情况下 leader 没有那么多精力去参与设计和执行监控，所以部门才会有一个架构师的职位。这种情况下，我见过比较有效的方式是：leader 在给员工评价绩效时，会非常看重架构师的意见。这样其实架构师就变相的有了点权利。
架构与组织结构
做架构的背景肯定都是业务复杂，参与人员多的情况。人员一多就涉及到人员组织结构，组织结构如果和架构不匹配，就会严重影响项目执行时的沟通。而后可能还有甩锅、打太极、护食分粥等高级动作。
各个公司组织结构的拆分，有两个不同的思路。
- 以不信任软件工程师为基础。传统软件公司、大公司多采用。特点是：文档规范详细，具有较大规模的测试团队，研发流程正规且冗长。职责分工明确，程序员就照着文档写代码即可，写完了就交付测试。
- 以信任软件工程师为基础。现代互联网中下公司多采用，推荐程序员去理解业务，去承担测试。这样文档简单，执行效率高。但是要求团队必须敏捷管理，高效沟通，以及要求程序员要了解业务。
具体的组织结构划分，书中建议：
- 开发团队跟着业务走，和业务要一个大团队，方便沟通。这样，业务团队和开发团队上级是同一个人，他们的目标也就会一致，沟通也就无障碍了。
- 一个软件团队只开发一个软件，不要多个或者交差，否则很容易出现甩锅和扯皮。
架构师的职责
架构师的职责，或者架构的目的 —— 业务增长 。这个我肯定认同，但我要加几个条件：考虑效率、考虑成本、考虑团队稳定性，以及未来的扩展性。
其中最关键的一点 —— 识别关键生命周期（书中的叫法），通俗说就是：抓重点，抓主要矛盾，识别是哪些是核心模块。这一点非常非常重要！各位读者可以想一下，你所做的产品、项目，其核心模块是什么？你所在的公司的业务，其核心模块是什么？
识别除了核心模块，就要重点抓，多花成本做。而其他非核心模块，就可以节省成本，甚至外包出去。例如对于一个产品项目，源码就不是其核心模块，真正核心模块是运营和运维。所以，源码可以开源、甚至外包，但运营流程你必须得保密好。
另外，架构不可一步到位，*不要过度设计。第一，流量达不到时会浪费资源；第二，流量是外部因素，你现在猜不到瓶颈在哪里。
关于单元测试
上文提到架构和组织结构时，提到两个思路，第二个是是“以信任软件工程师为基础”的思路。软件工程师（即程序员）想要得到信任：第一是要了解业务，这无疑是重点；第二是要负责一部分测试流程，就是单元测试。
书中写单元测试的这一章，相比于其他章节，令我看后印象最为深刻。估计是因为我本身就是程序员，对于一些技术内容感兴趣，也看得懂。书中内容较多，我就不一一详细写了，感兴趣的自己去看。
众所周知，单元测试是个好东西，大家都承认，但是实际用起来却发现，并不是好东西就好用。这是为什么呢？
单元测试要测什么？
单元测试要测所有的代码吗？真的要做到所有代码的覆盖率都尽量 100% 吗？—— 书中认为不是这样的。第一，一些平铺直叙的逻辑不用测试，连
if else 都没有的；第二，一些环境工具的使用，不用测试，例如 mysql 是否连接成功。单元测试要测的，是自己写的逻辑单元，一些真正具有判断、循环、甚至递归逻辑的模块。
如果按这个标准，单元测试的范围就一下子减少了，工作也就好执行了。
单元测试要避免环境因素
程序员做的是单元测试，而测试人员做的是集成测试。单元测试测的是逻辑单元，也就一个函数，一个代码片段。集成测试测的是整个系统，要启动系统的各个服务。这俩工作的范围要搞清楚。
但往往有这种情况出现，就是你想做单元测试，却发现整个逻辑单元内部有
request（依赖于 http 请求）。这样你做单元测试时就需要 mock http 环境，只要一 mock ，那麻烦就来了。因为接下来还可能需要 mock 数据库，mock 这个，mock 那个……先不要思考 mock 是不是麻烦，如何简化。先思考一下，mock 是不是应该出现在单元测试中？—— 如果我们 mock 了 http 环境，那它是单元测试，还是集成测试呢？ —— 严格来说它属于集成测试。所以，单元测试尽量不要 mock 任何东西，只测代码逻辑，和其他的无关。
那如何解决上述的问题？很简单，弄一个独立的函数
fn ，把代码逻辑抽离出去，规定输出和输出，把 request 隔离到 fn外面。这样，单元测试只测 fn 就可以了。因为只有 fn 有逻辑，外层涉及 request 的都已变成平铺直叙的代码，不用单元测试了。我们要提倡单元测试
经过以上的认知，如果能充分利用起单元测试，自己的代码自己测，效率肯定高。
但现在为何单元测试盛行不起来了呢，一方面是上述说的使用不当的原因，还有一个原因就是：开发团队和测试团队分离。你看，又扯了组织结构的问题上，这很重要。
试想，一个软件项目，基本都是需求、设计、开发、测试、上线这个几个大步骤。我们程序员处于开发阶段，那有两种选择：第一，今天开发完提测；第二，做单元测试，后天提测；—— 你会选择哪一个？
如果你是开发团队的负责人，你会选择前者。如果你是整个项目的负责人，你会选择后者。但现实情况往往是，让开发负责人选择。
所以，推荐单元测试真的不是技术人员说了算的，还得有项目流程、leader 、组织结构的配合。
最后
书中前言部分写的一句话我特别认同，但上文没地方写，就在这里记录下吧。书中说：现代的计算机和软件方面的教育，基本上都是从科学研究领域脱胎出来的。而这种教育目的，就和日益深入人们生活的软件应用，产生了很大的隔阂。以至于很多计算机和软件专业毕业的大学生，进入企业啥都不会，还得重新学起。—— 这个问题我是感同身受，也希望能早日得到解决，无论以哪种方式。
作者：王福朋链接：https://juejin.cn/post/6854573221400805383来源：稀土掘金著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
Loading...