本文探讨了尊重与个人成长的关系，指出优秀的人懂得尊重。在软件开发中，架构设计的重要性被强调，尤其是其对效率的影响。作者提出，好的架构能缩短交付周期，但评估架构好坏的标准在于能否控制复杂性和提高效率。微服务作为解决系统增长压力的手段，其目标是持续交付而非快速交付。此外，文章提倡柔性设计和领域建模来应对业务复杂性，并分享了对工作挑战和个人成长的感悟。
大家好，这里记录，我每周碰到的，看到的，或想到的，引起触动，或感动的，事物的思考，不见得都对，但开始思考总是好的。
这周有看到什么让你“醍醐灌顶”的语句吗
我以为别人尊重我，是因为我很优秀，慢慢的我明白了，别人尊重我，是因为别人很优秀！优秀的人更懂得尊重别人，对人恭敬其实是在庄严自己。
中国人的性情是总喜欢调和折中的，譬如你说，这屋子太暗，须在这里开一个窗，大家一定不允许的。但如果你主张拆 掉屋顶他们就来调和，愿意开窗了。——鲁迅《无声的中国》
把简单的设计做复杂简单，把复杂的设计做简单复杂。
咋看架构的好
近几个月以来，我一直在不断的探索或者叫摸索，也尝试一些方法，甚至是“手段”，努力的来衡量或者是评判一个架构的好坏，我们也制定了一些指标，这里有过程指标和结果指标。
如果让你说一个架构的坏处，你可能能罗列一大堆，耦合、系统之间没有调用没有预警，没有容错等等，但是，如果让你说出一个架构的好，然后又是为什么好，恐怕就不是那么容易的事情了。
不过，这一切都要围绕一个词：效率。
软件开发的目的是持续地缩短交付周期来产生积极的商业价值。
好的架构肯定能提高效率，也就能缩短软件的交付周期，但架构的作用边界到底在哪里。有一天我的一位同事转给我一篇文章，一口气看完以后，才发现这是晓岩老师的写的，大家可以读一读https://mp.weixin.qq.com/s/tU86DhSPLRA3kFlA7_oJ3g
下面这张图，是我参照了上述文章的内容，结合我们当前实际的运行流程做了一些改变。
那么，纯技术的作用范围，是在编码、测试、上线这三个阶段，这点是很好理解的，比如你不用spring框架，你要手写很多东西，你不用CI/CD上线部署就很痛苦。
那么编码以前的流程，越往前受技术的管控越小，甚至技术的手，已经莫及。有人说，你这个是瀑布呀，其实哪怕你再敏捷，要把一个需求实现， 脑子里想的和实际发生的都会经历这么一个阶段，只是需求的粒度小了，或者是这期间的步骤有可能会跳过几个，比如没有PRD，你也能开发，没有概要设计你也能开发。
那编码之前的，技术人应该如何影响呢，毕竟从需求被提出那一刻就开始被期望了。这里面有流程及过程机制，也有复盘机制，我还是觉得重要的一点，要有补位意识，这也是我们内部一直强调的，要做懂业务的架构师。
好，那好像还是没有说到，如何来从效率的角度来衡量或者是量化一个架构的好，这些呢，我在内部已逐步开始试点，待有阶段效果后，再来跟大家沟通。
接下来，看下复杂性的问题。
控制复杂性
很多应用程序最主要的复杂性并不在技术上，比如有很多程序员乐于学习并实践各种基础技术，IOC、DI，还有一些中间件技术，乐此不彼，学习这些技术当然无可厚非。
但有时候就是很残酷，这些基础技术再好也对提高我们软件的开发效率无济于事，因为，就如开头说的复杂性不在技术上，而是来自领域本身，来自用户的活动或业务。
我们编写一段代码，甚或一个应用来满足实际的生产需求，那么最大的阻碍之一可能就是这个需求对应的业务的复杂性。
而我们开发的软件却又是无法回避这种复杂性的，因为毕竟我们是要通过软件来帮助我们的业务实现自动化，或者是提高企业的自动化程度。
所以，在这样的情况下，我们就只能控制复杂性而不是回避。
那么如何控制复杂性呢，最为关键的一点就是要建立一个好的领域模型，而且这个模型不仅仅是停留在领域的表面，应该是要透过表象去抓住领域的实质结构，从而为我们的软开开发人员提供支持。
“不抽象看不到事务的本质，不具体看不到事物的长相”这句话是本周一次会议上我老板说的，突然想起来，用到这里还挺合适，这里的抽象便是我们所说的建立一个模型。
如何建模，又如何落地呢，就是采用柔性设计。
软件设计的最终目的是为我们的用户服务，但首先它必须要为开发人员服务。
为了使项目能够随着开发工作的进行加速前进，而不会由于它自己的老化停滞不前，设计必须要让研发人员乐于使用，而且易于做出修改。这就是柔性设计（supple desig）。
关于这方面更详细的内容，建议大家读一读《领域驱动设计：软件核心复杂性应对之道》这本书的第10章的内容。
软件系统的增长压力
微服务风格的架构，对于如今的研发人员早已不模式，甚至都可以说已经穿插到了研发人员的日常工作中去了，但回头想一想，当初为什么要搞成微服务的呢。
你在网上搜一搜估计能搜到很多内容，比如拆分微服务的四个时机，拆分微服务的六大规范等等。
正如那句“走出太远而忘记了为什么出发”，微服务实践越来越多，服务数量越来越多，也会让人们暂时遗忘掉了拆分微服务的意义。
不过，本周在《微服务实战》这本书中看到下面这张图，我还是觉得描述的很是恰到好处，软件系统增长的压力。
选自《微服务实战》1.13章节中的列表
书中的这个列表分别从系统的规模承载能力，新功能的数量和旧有功能相结合的难易程度，项目团队日渐发展的规模，长期的技术债务等方面阐述了我们为什么要进行微服务。
微服务目标的核心侧重点，注意，我这里说的是侧重点，是持续交付，而不是快速交付。这点听起来似乎有些矛盾，品一品还是有区别的，持续是有节奏的交付，当然微服务可能会比单体时代能够较快的交付，但微服务的侧重关注点是持续交付。
对于我所描述的持续交付这层含义，大家只要想一想，或者搜一搜，微服务的产生和发展曲线，跟devops、敏捷是一起发展的，就能够体会到了，因为devops和敏捷都是用来保障持续交付的，一个是从工具上，一个是从组织上，而微服务刚好是从架构上。
软件开发的目标就是持续地缩短交付周期来产生积极的商业价值。
本周朋友圈精彩截图，也是别人转发的，现分享给大家
什么才叫吃苦
图自网络
结合我自己的情况谈一下我对这段描述的感觉。我当时写书，写专栏感同身受；当时带领一个团队做开放平台，深有体会；现在尝试解释200多人团队的研发效能问题，又深陷破境。
我还是觉得这些都能走出来，把自己想到的，干到，想不到的，找人沟通一起想到，再干到，做到这些，如果结果还不好，那死也死个明白，不就是这样么。
这是你的人生目标？
图自网络
其它文章：
扫一扫
207
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
