前端架构，你需要知道的东西（1）

本文章主要思想由ThoughtWorks@李光毅授权分享

@李光毅，知乎专栏「前端技术漫游指南」以及图书《高性能响应式Web开发实战》作者。曾就职于爱奇艺、百度、知乎等互联网公司，目前就职于 ThoughtWorks，从事全栈开发相关工作。

1，理论性的讨论前端架构

前端架构满足的是非功能需求，什么是非功能性需求？就是可拓展性，可用性，可靠性，可维护性，可测试性。

一个业务功能需求，可以有多种多样的方法去实现，之所以称满足的是非功能性的是因为它们和我们的业务需求没有任何关系。

可是，运用框架和模式，是能够帮助我们在将来的开发中减少项目的维护成本。这里的成本不仅涵盖新功能的增加，旧功能的迭代，开发过程中的调试、部署，还能够让新加入团队的成员更快的上手融入团队。

实现功能需求不难，如果有几年的工作经验的老生和一个实习生去实现同一个功能，最后的工作成果差别在哪？我相信单单从用户角度上看不大，因为你们都是根据同一份需求文档，同一份界面设计稿，同一份交互方案实现的。真正的区别在于程序的内部你是如何更优雅，更高效和更具前瞻性的解决这个问题的，这些都是非功能需求体现的地方。

如何培养的这样的思维模式：想象你的项目要维护十年之久。在这十年里技术栈可能会发生天翻地覆的变化，可能 React 已经不再是最适合的表现层框架了，已经被XXX框架替代，但是你的业务逻辑依然有效。如何保证业务逻辑与表现层的分离，如何在更换 React 框架为XXX框架的前提下不触碰核心业务逻辑的修改，这一系列文章就是解决该类问题。

2，容易把事情做对

好的系统应该让开发变得容易，使得程序员很容易就能做正确的事情。

“容易把事情做对”对我们的项目非常重要：因为维护项目从来不是一个人而是一个团队的事情。

在一个团队中可能因为水平、经验等各种各样的原因导致不同人对框架理解不同，这种不同反馈在代码中就是大家都变得在用自己的方式，与众不同的方式做同一件事。但另一方面“程序”这种工业级的产品，我们要求的是稳定的输出，长期的可维护性。于是让每个人自己去思考问题，去实现一套自己的解决方案，无论对于效率还是质量而言都是有风险。

code review 的功能之一也是在消除这种变异性。一个好的团队的项目的代码库风格看上去因该是一致的，而不是迥异的。

3，前瞻性的解决问题

当我们希望前瞻性的解决问题时，我们究竟应该看多远？

1. 不要尝试去预测未来；2) 让程序足够灵活能够应对未来的变化即可

“过度设计”的问题在于你认为你预测到了未来，但其实你并没有。你只是在你的视野范围里一厢情愿的相信某件事情可能会发生，但还有千万种可能你没有看到。但现阶段的代码和精力其实无法涵盖这所有的可能性。唯一不变的就是变化本身，你只需要让你的程序有能力应对未来的各种可能性即可。

4，简洁

程序员天生有一种把简单问题搞复杂的能力：

“单用 React 解决问题怎么能体现出我的水平？Redux 全家桶走起”

“我们最好能做一个工具或者平台来解决这个问题，然后把平台推广到整个公司”

“最近 X 技术很火？最好能在项目里用一用，将来好写在我简历上”

在项目和团队的角度上考虑如何满足项目的非功能需求：我们应该尽可能的降低项目维护和学习的门槛，降低它们的风险，而不是反向提高它们。退而求其次的，至少应该把复杂性和风险控制在一定的范围内。

如果你没法保证你的程序满足 SOLID 原则，没有套用各种模式和最佳实践，那么请至少保证系统的简洁和清晰。这依然可以提高代码的可维护性。例如把你的 React 单个组件保持在 300 行以内。

越简洁的代码维护起来就越轻松这一点是毋庸置疑的，你是在一个一千行的面向过程有三层循环的函数内调试 bug 容易还是在一个同样一千行但是拆分为五个每个文件不超过200行的组建代码内调试 bug 容易？这里的简洁是全方位的，小到变量的命名，函数的封装；大到框架的复杂程度，学习曲线