架构师(2022年8月)

架构师(2022年8月)

发布于:2022 年 8 月 8 日 08:00
本期内容推荐:搞不定移动端性能,全球爆火的 Notion 从 Hybrid 转向了 Native ;下一代负载均衡的思考与实践;Rust for Linux 要来了,这对我们意味着什么
下载此书

卷首语:前端团队做技术决策的五条原则

作者|宝玉


编辑|辛晓亮


今年上半年我曾经做过一个关于如何做架构设计的分享,其中有个很重要的话题是“如何更好地做技术决策“,针对我们的前端团队,我整理了 5 条做技术决策的原则。


原则 0:遵守公认的好的设计原则

  • DRY - Don’t Repeat Yourself(不要重复自己)

  • KISS - Keep It Simple,Silly(让设计尽可能的简单)

  • YAGNI - You aren’t gonna need it(只做刚刚好的设计,不要过度设计)

  • 其他


原则 1:找出最本源的需求,而不应该局限于当前的技术实现和资源

很多时候我们很容易被表面需求所误导,就像乔布斯的名言:“如果亨利福特在发明汽车之前去做市场调查,他得到的答案一定是大家想要一辆更快的马车”,如果我们在做设计和技术决策的时候,没有找出用户的真实需求,就会很容易在错误的方向上狂奔,做很多无用功。


要找出本源的需求,就需要多问为什么,多和干系人沟通,少考虑技术细节,少被现有的技术所误导或局限。


案例:设计部门希望设计系统支持 Angular

我们设计部门最近希望我们的设计系统提供 Angular 版本,因为当前只支持 React 版本。


从这个需求来看,表面上是要我们开发 Angular 版本,如果仔细追问他们到底为什么需要 Angular 版本,是因为有一个团队还在用 Angular。他们希望这个团队能使用我们的设计系统,但是对方表示用不了。


其实本源的需求是希望有更多的团队使用我们的设计系统,而不是要单纯支持 Angualr。


那要满足团队的这个需求,是不是非要做一个 Angular 版本不可呢?当然不需要。如果我提供一个类似于 BootStrap 的 HTML 和 CSS 版本,他们一样能用起来,而这么做成本不高,并且其他的团队也可以用。


(更多案例可参考下图)



原则 2:聚焦于 “收益”、“成本”和“风险”三者之间的平衡,而不是技术本身

每一次技术决策,其实本质上就是一次取舍(Trade-Offs)。


每一次取舍(Trade-Offs),本质上就是在“收益”、“成本”和“风险”三者之间的平衡。



既然每一个决策都涉及到收益成本风险,那么就不能只看收益而无视成本和风险。就像前一个案例中提到的,设计部门考虑的是 Angular 版本带来的收益,但是他们却忽略了打造一套 Angular 版本的设计系统所需要的成本,以及可能带来的巨大风险。



所以在做技术决策的时候,理性考虑一下决策背后的收益、成本和风险的关系是很必要的,而不是仅靠喜好或者直觉来做决策。


原则 3:选择某个技术背后的生态系统而不是某个技术

这条原则特别适用于前端领域,在前端,各种新技术、框架、工具层出不穷,如果总是追新,或者被某个软文吸引轻易选择了某个技术,往往最终会带来巨大的成本。


案例:我们为什么从 Preact 迁移到 React

在早些年的时候,我们前端选择了 Preact 作为 UI 渲染技术,这有早年 React License 的原因,也有 Preact 体积更小、性能更好的原因。


然而在这几年的使用过程中,发现很多不足的地方,核心原因其实都是生态不够好。


比如说 Preact 调试很麻烦,它不像 React 有一个强大的 DevTools;比如说我们遇到过 Preact 在服务端渲染的内存泄漏问题,如果像我们这样大规模访问量的用户多一点,可能早就有人踩过坑了,不需要我们去花很长时间定位并最终去解决这个问题;再比如最近我们在集成 Nextjs,Nextjs 是完全为 React 设计的,对 Preact 兼容性并不好。


这样的案例还很多(如下图),所以选择技术,它背后的生态和社区活跃度很重要。



原则 4:不仅要考虑如何构建,还要考虑如何维护

这是一个常见的问题,很多人只管搭建新项目的时候爽,而不管后续维护是不是困难,用了一堆自己喜欢的新技术,最后难以维护。下一个人接手了,搞不好会推翻重写一遍,这样的循环一次又一次。



这样的错误我也常犯,比如 2 年前 React Hooks 刚出的时候,我就迫不及待用它来替代 Redux。结果上线后发现不好维护,有 Bug 也不好定位,不像以前 Redux,数据流特别清晰,借助工具非常方便重现和定位问题,最终上线没多久就改回去了。


所以现在在做技术决策的时候,我们很注意的一个问题就是将来的维护会不会很麻烦。包括我在做代码审查的时候,有时候看到一些功能能运行得很好的 PR、但是代码写得比较难懂的,或者说没有遵守最佳实践的,但只要会给未来的维护带来麻烦的,我都会毫不犹豫要求重写,尽可能避免增加日后的维护成本。


最后简单总结一下上面就是我们现在实践的五个技术决策原则:


  • 原则 0:遵守公认的好的设计原则;

  • 原则 1:找出最本源的需求,而不应该局限于当前的技术实现和资源;

  • 原则 2:聚焦于 “收益”、“成本”和“风险”三者之间的平衡,而不是技术本身;

  • 原则 3:选择某个技术背后的生态系统而不是某个技术;

  • 原则 4:不仅要考虑如何构建,还要考虑如何维护。


这些原则绝大部分时候都可以很好地帮助我们做出正确的决策,避免踩坑。我也会一直在反思曾经做过的决策,对于不太好的决策,会反过来考虑是否要修订这些原则,最终通过不断完善决策原则,帮助我和团队更好地做出技术决策。


作者简介


宝玉,前微软 Asp.Net 最有价值专家,互联网科技博主。


目录

热点 | Hot


搞不定移动端性能,全球爆火的 Notion 从 Hybrid 转向了 Native


放弃 GitHub,现在正是时候?


这群 WebAssembly 大佬创业失败了:有时从 JS 迁移到 Wasm 并不值当?


理论派|Theory


详解“洋葱架构”


下一代负载均衡的思考与实践


推荐文章 | Article


编程不适合 12 小时工作制,“我有灵感才工作” | 专访《Java 编程思想》作者 Bruce Eckel


多领域试水,WebAssembly 距离大规模应用还有多远?(最后一段的会议广告和图片删去)


观点 | Opinion


Rust for Linux 要来了,这对我们意味着什么


评论

发布
暂无评论