面试时发现的一些软件问题
这段时间参加了一些前端面试，也看到了一些软件问题，主要体现在以下几个方面：
- 第三方件管理。
- 污染全局变量，修改原生对象。
- 使用设计模式去Hack有问题的代码。
- 组件化开发，并没有做到单一职责原则。
1. 第三方件管理
第三方件管理的原则是：不阻碍第三方件自由升级。第三方有时也有安全漏洞，升级是经常的事情。
我们的实施过程一般是这样的：
- 不把第三方件的源码上库，可以避免自己人修改其源码。
- 只有在构建时引用以发布的软件包。
- 只在第三方件上做扩展，不修改或覆盖原有功能。
2. 全局变量与原生对象
任何计算机语言中，我们最怕全局变量污染。原则是：尽量不暴露全局变量，单例模式时也只暴露方法。如果全局变量污染，可能造成多个模块问题不断。
在前端领域，原生对象是可以修改的。但是，如果修改原生对象，不敢保证与以后的标准是否有冲突，也把功能代码隐藏太深了。
我们一般要这么做：
- 尽量使用ES6 export/import或依赖倒置。
- 一个软件包(模块)只导出一个全局变量，且需要统一的命名规范，避免冲突。优先遵守“重用的颗粒就是发布颗粒”原则。
- 不要修改原生对象，而是提供单独的工具函数。
- 统一polyfill，不要散落到多个模块中完成。
3. 不要使用设计模式去Hack
有些模块把window下的全局对象修改了，会造成部分模块的不兼容，然后，部分同学就使用ES6 Proxy去规避问题。
在我看来，这并不是一个正确的处理方法，理由有：
- 有问题的代码并未得到修正，以后类似的问题仍会再犯。
- ES6 Proxy与Reflect并不高效，平常代码中能不用就不用。
遇到这种问题时，我们应该参考“全局变量与原生对象”中的做法去修正有问题的代码。
- ES6 Proxy正确使用场景：在对象创建框架中，需要完成Logging、约束或副作用时。
- 23种设计模式是为了让软件满足5大设计原则，不是为了Hack问题代码。
4. 做到真正的单一职责原则
目前，在前端领域稍微有点规模的团队都应该是组件化开发这种模式了。但是，并不是每个团队都能做到软件质量越来越高、开发效率越来越高。造成这样的原因有：
- 软件的规模越来越大。功能越来越复杂，对用户体验要求也越来越高，包含效果、性能等。
- 软件设计能力未跟上软件的规模。
下面只讲我听到的问题：按照功能划分组件，把数据请求等都塞到这个组件中，在复用时出现问题。造成这样问题的主要原因是在这个组件中一次完成的内容太多了，也没有划分复用与非复用的边界。主要违法的设计原则是“单一职责原则”。
在实施单一职责原则的过程中，有以下方法可以参考：
- 文件的代码行数限制在300~350行。据我的经验，组件化开发时90%的文件都可以满足该目标，大部分文件都在200行左右，极少数达到500行。超过350行时我们就应该考虑“组合模式”或其它模式了。
- 函数长度限制50行。要写好代码，一个函数最好不要超过30行。
- 目录文件限制30~50个。一个目录中的文件(夹)个数，应该有一个合理的限制，避免包含过多的内容。Components中一般有几十个文件夹，但是组件或组合组件中一般只有几个文件(夹)。
- 边界划分：业务核心层、复用层、响应变化层，可以参考Clean Architecture。业务核心层，一般放与数据相关的；复用层，主要放视图组件，也是稳定层，提升开发效率；响应变化层，一般放容器组件、组合组件等最外层的内容，可以快速响应需求变化。