减轻前端框架锁定的恐惧

Question

我的团队即将建立一个新的用户界面。该团队拥有一系列客户端和服务器端技术的技能。一半的团队支持ASP.NET MVC，一半的团队支持JavaScript SPA。这两种技术都适用于我们的业务需求。

争论的焦点似乎是如何在SPA框架动荡中生存下来。例如，每个人都觉得微软10年后会支持ASP.NET，但我们对像React这样的框架并不那么确定。

人们似乎已经通过使用行业标准、接口和依赖项注入来解决服务器端组件的这个问题。但是，对于前端框架，似乎没有同等的选项。

我们怎样才能消除对框架锁定的恐惧？

Answer 1

不要被锁在

里

作为建议，这是没有帮助的(我知道)，但这不是重点。

把它作为你团队中的一个目标，以避免供应商锁定。全队都是工程师，他们会找到出路的。

剪切层

代码有不同级别的搅动，每一个搅动率都是一个剪切层。

如果你真的相信这个框架在3年内不会出现，那就把它当作任何剪切级别上的代码来对待吧。包含它，以便它可以被替换(剪短)以后。

本质上，将框架+最小数量的胶水代码作为实际程序的插件。如果框架变得不受支持，您只需替换该框架并将其形状设置为相同的插件接口即可。

任何你想活得更久的东西，都是在较低的剪切水平上。做这项工作，把它移到一个较低的剪切水平。

将资产外部化.

将您的资产保持在给定框架的控制之外。将每一项资产视为在几个没有给定框架的项目中使用。

• 保持您的图形以无处不在的格式，目前: JPEG，PNG
• 将CSS样式保持在框架外部。
• 将业务逻辑与框架分开。通过强大的插件样式接口向业务逻辑提供框架--如果您绝对必须的话，并且只在必要的范围内提供。
• 使用单独的框架编写行为相同的第二个应用程序
• 将所有测试保持在框架的外部。一个独立的JavaScript测试库，用于单元测试和浏览器驱动的集成测试。
• 确保API遵循给定的交互标准，即SOAP、REST、特定的HTTP/2消息流。更好的是，如果有其他工具/框架可以无缝地使用该工具/框架。还要确保独立的API级测试，由JavaScript以外的其他东西驱动。

避免特性

每个功能都是一段延迟的工作。

确保你知道你在拖延什么，以及它是否值得。

三项缓减战略：

1. 看看其他的服务，他们是否支持一个足够相似的功能，你可以提升和移动。
2. 确定你是否可以自己直接提供。有些功能很难独立实现，如果你不得不改变，你能自己提供吗？
3. 不同的功能能提供同样的商业利益吗？说到生物识别，基于短信的双因素能不能令人满意？

对这些策略的支持越多，采纳某一特性就越安全。

反对越多，就越应该避免这些特性，至少如果你想避免锁定。