今天做了一个关于如何做架构设计的分享。非常重要的问题之一是如何做出更好的技术决策。我为我们的前端团队编制了5条技术决策原则。原则1：遵循公认的良好设计原则，例如：DRY-Don'trepeatyourself（不要重复自己）KISS-KeepitSimple,Silly（使设计尽可能简单）YAGNI-你不会needit（做好设计就好，不要过度设计）...其他原则2：找出最原始的需求，不局限于当前的技术实现和资源。很多时候我们很容易被肤浅的要求所误导，就像乔布斯的名言：“如果亨利·福特在发明汽车之前做过市场调查，他得到的答案将是人们想要一辆更快的马车。”需求，很容易走错方向，做很多无用功！找出原始需求，还是要问为什么，多和干系人沟通，少考虑技术细节，少被现有技术误导和限制。案例：设计部门希望设计系统支持Angular我们的设计部门最近希望我们的设计系统提供Angular版本，因为目前只支持React版本。从这个需求来看，表面上是希望我们开发Angular版本。事实上，如果你仔细问他们为什么需要Angular版本，那是因为有一个团队还在使用Angular。他们希望这个团队可以用我们的设计系统，但是他们说不能用。其实最初的需求是让更多的团队使用设计系统，而不是支持Angualr。那么为了满足这个团队的需求，是否有必要做一个Angular版本呢？当然不是，如果我能提供一个类似Bootstrap的HTML和CSS版本，其实都可以用，而且这样做的成本也不高，其他团队也可以用。原则三：关注“收益”、“成本”和“风险”之间的平衡，而不是技术本身。每一个技术决策其实本质上都是一种权衡。每一次权衡（Trade-Offs）），本质上都是“收益”、“成本”和“风险”之间的平衡。由于每项决策都涉及收益、成本和风险，因此不能只看收益而忽视成本和风险。前面案例中提到，设计部门考虑的是Angular版本带来的收益，却忽略了构建Angular版本设计系统的成本和可能存在的巨大风险。因此，在进行技术决策时，需要理性地考虑决策背后的收益、成本和风险之间的关系，而不是仅仅依靠偏好或直觉来进行决策。原则四：选择某项技术背后的生态系统，而不是某项技术。这个原则特别适用于前端领域。在前端，各种新技术、框架、工具层出不穷。如果你总是追新，或者被软文吸引，轻率的选择一项技术，最终会带来巨大的成本。案例：我们为什么从Preact迁移到React早些年，我们选择Preact作为前端的UI渲染技术。这是早年ReactLicense的缘故，也是Preact体积更小性能更好的原因。但是在这些年的使用过程中，还是存在很多不足的地方。核心原因还是生态不够好。比如Preact调试就很麻烦，因为它没有React那样强大的DevTools；比如我们在服务端遇到过Preact渲染的内存泄露问题。如果有更多像我们这样访问量大的用户，可能早就有人踩坑了，我们不需要花很长时间定位并最终解决这个问题；比如我们最近在集成Nextjs，而Nextjs完全是为React设计的，与Preact的兼容不是很好。这样的案例还有很多，所以技术的选择，背后的生态和社区活跃度很重要。原则5：不仅要考虑如何构建，还要考虑如何维护。这是一个常见问题。很多人只关心新建项目，而不管后续维护是否困难。他们用了一堆自己喜欢的新技术，最后难维护。下一个人接手，说不定又会被推翻重写，如此周而复始。我经常犯这样的错误。比如2年前ReactHooks刚出来的时候，我就迫不及待地想用它来代替Redux。上线后发现不好维护，很难定位bug。不像之前的Redux，数据流向非常清晰，借助工具很容易重现和定位问题，最后上线不久就改回来了。所以现在做技术决策的时候，我们关注的一个问题就是以后维护会不会麻烦。包括我在review代码的时候，有时候看到有些功能可以很好的跑PR，但是代码很难看懂，或者没有遵循最佳实践，只要给以后的维护带来麻烦，我就不会犹豫是否要求重写以避免增加未来的维护成本。最后，以上是我们现在正在实践的五个技术决策原则：原则一：遵循公认的好的设计原则原则二：找出最原始的需求，不局限于当前的技术实现和资源“获益”，成本”和“风险”而不是技术本身原则四：选择某项技术背后的生态系统而不是某项技术保持这些原则可以帮助我们在大多数时候做出正确的决策，避免踩坑。但我会一直反思我所做的决定。对于我做出的错误决定，我会反过来考虑是否修改这些原则，通过不断完善决策原则，最终帮助我和团队做出更好的技术决策。决策。
