分类 技术 中的文章

『每个架构师都应该研究下康威定律』

InfoQ 中国在 2016 年,发表过一篇文章,杨波的《每个架构师都应该研究下康威定律》。这篇文章对当时的我,触动是非常深刻的。一些说不清道不明的经验,被别人用浅显易懂的道理,讲得一清二楚。 康威定律是很早就听说过的,后来陆续又有一些接触,每次时隔一段时间再做了解,就会有非常深的触动。我理解,原因无他,因为它聚焦在组织架构和系统设计的关系上,而这两者,一个是架构师目标,一个是架构师的手段/工具。文中用很简短的一句话,讲清楚了这中间的关系。 系统架构的目标是解决利益相关者的关注点。 这句话简直太重要,太精妙了。 1. 架构师的目标,是各个利益相关者的关注点 很多人对架构师的误解,都以为是架构师是技术执行,是 top-level coder,对 coding 的结果负责。这就犯了以表象取人的问题。为什么?我后面再提。 架构师首先应该关注的,是项目中,各个角色,各个利益相关者,他们的利益诉求,他们在项目中的焦点。根据这些焦点,得到一个权衡的方案,并取得最大限度的支持。 2. 架构是权衡的艺术 权衡的英文表述比较准确一些。trade-off 。利益交易和平衡。 权衡的方法是博弈,无论是纳什均衡还是帕累托最优,权衡目标是达成一个相对稳定的博弈结果。这个结果,就是架构的目标需求。 所以你看,脱离实际场景谈『架构』,本来就是虚空的。 3. 架构首先是业务架构,其次才是技术架构 道理很简单,业务架构往往涉及最直接的利益分配,从市场到产品到后勤保障,通常都对业务指标虎视眈眈。产品技术指标他们并不关心。 从工作流程上来讲,业务架构决定产品设计,产品设计决定技术设计。说业务架构是技术架构的前置步骤,一点不为过。 唯一的例外,可能就是大厂里面做平台产品研发的案例了。从无到有形成一个平台,比如阿里 IaaS 云。商业模式不清晰,业务架构反而受制于技术架构。不过这种机会今后出现的可能性,越来越小。 4. 技术架构是工具/手段 确定了各个 stakeholder 的 key points,剩下就是怎么做的事情了。技术手段、技术架构,不过是实现平衡的工具而已。通过技术架构,将权衡的方案,表达出来,这是一个称职的架构师,秀于外的工作。 我个人对架构师的定义是,以权衡项目中各个利益相关方的利益关注点为目标,以技术设计为工具和手段,以持续的产品技术服务为交付物的产品研发决策者。 所以回过头去看,架构师的工作中,技术架构的部分,优先级排不到前列,称得上是最基础、最『本分』的技能。技术好,技术设计灵活,不是一名架构师值得炫耀的资本。架构师值得炫耀的,是他能够在复杂纷扰的环境中,仍然可以理出线头,正确判断形势,做出合理的架构设计。 比方说,一名做 ToB 业务的 SaaS 平台架构师,既往工作中,以项目经理/甲方的利益诉求为主,以己方销售的利益诉求为辅,养成了习惯。一个需求做不做,怎么做,第一问己方销售/甲方,其次问项目经理,总可以得到答案。有一天,他去到一家做 toC 产品的公司任架构师,他面临的 stakeholders 发生了翻天覆地的变化,『甲方』成了成千上万的个体,怎么去问每个个体,他们的 key points 是什么?所以这位架构师的转变是,以直接上级的利益诉求为主,以产品经理的利益诉求为辅。那么,这个架构师,很明显就犯了最低级的失职。即便他的技术实力再强,首先目标就错了,谈何取得胜利? 雷军讲的,以战术上的勤奋,掩盖战略上的懒惰,大概也是说这个意思。 啰嗦一句。无论是 toC 产品还是 toB 产品,架构师首先应该予以重视的 stakeholder,都应该是财务上销项对应的一方。也就是为公司提供入账的一方。有人可能会觉得奇怪,toC 产品不应该是用户为首要的 stakeholder 吗?真不一定。如果是付费用户,那么他们是公司账上销项对应的一方,他们算首要的 stackholder。如果用户是免费使用公司服务,那么应该把他们看做产品/服务的一部分,把他们看做产品/服务的资源,而不是 stackholder。既然是资源,能为己所用就可以;既然是产品的一部分,只要产品不散就可以。不需要过多考虑免费用户的诉求和偏好。 有些免费产品讲情怀,前提是他们活着不成问题。没干爹可抱的企业,先把自己的财务账算清楚,努力维持公司现金流为正,先有资本活下去,才是正道。别人在山顶为踏足云顶做赋,那是情怀,你在山底谈云,那是浮云。 5. 架构不止『偏技术』,不是每一名架构师都需要『偏管理』的搭档 架构师的责任,是交付能够让至少大多数 stakeholder 满意的架构方案,并且落地执行,交付一个 predictable 的结果。……

阅读全文

hexo 又报 package 的依赖问题了

因为 hexo 的 package 的依赖问题,特别是对彼此版本的依赖问题,折腾过两三次,一直没有特别好的解决办法。 node 本质上仍然是脚本语言,不像编译型语言,实在不行,还可以把 package 一个一个打成 binary,逐个消除 package 的依赖问题。node 做不到。当两个以上的 package 声明的依赖相互冲突时,这个项目基本上也就废了。没法儿正常使用了。 有人会问,怎么可能出现这样的情况?开发者发现不了吗? 开发者可能还真发现不了。首先,开发者的环境是既有的,是缓慢生长起来的,不是什么问题都能发现的。其次,CI 也不一定能发现问题。有些基础的 package 为了自身兼容性,对不同 node 环境做了兼容处理,在不同版本的 node 下,逻辑代码不同。再次,npm 的 peerDependencies 对 package 之间的依赖关系进行了解耦,有些依赖关系非强制,实际上是允许了冲突的存在。最后,node 的环境隔离方案,类似 pyenv 这样的,也有,非主流,而且治标不治本,仍然解决不了 package 之间的冲突。 之前我遇到的问题是 peerDependencies 导致的。今天遇到的问题,则是对 node 版本的声明导致的。 error nunjucks@3.1.3: The engine “node” is incompatible with this module. Expected version “>= 6.9.0 <= 11.0.0-0”. Got “12.4.0” error Found incompatible module 我的 node 是通过 HomeBrew 安装的,latest,当前版本 *v12.4.0*。 对 node 一直有一点担心,然后这种担心在 2016 年左右,逐渐成了现实。那就是 npm 对 package 的依赖管理策略。越松散,越自由,就越极客,越小众;越独裁,越限制,就越方便,越大众。npm 很明显走前者的路线,而且偏向极端。我知道稍微有点能力的公司,用 RN/Vue/Angular…… 都是自己搭 package server,自己造 package。包括一些基础的 package。没别的,就为一条,质量可控。……

阅读全文