从后端到前端的转变:如何选择框架?( 三 )


文章插图
 
 
甚至“bootstrap”这个词也成了使用有限资源的代名词 。在“good-fast-cheap”的模式中 , 你选择了 fast 和 cheap——无论这些决定是否是有意识的 。换句话说 , 你选择投资一个充满技术债务的产品 。
不相信我说的?考虑一下未来你的造型开始变得过时的情况 。新的竞争带来了更吸引人的用户体验 , 是时候升级你的游戏了 , 否则你将地位不保 。

从后端到前端的转变:如何选择框架?

文章插图
 
 
你开始进行品牌重塑 , 调整 Bootstrap 无穷无尽的变量列表 。经过一阵的折腾 , 却发现你所希望的改变只有在让轮换所有开发人员之后才能保持一致 。
此外 , 你真正想要的深度定制涉及构建复杂的 CSS 特性 , 以覆盖 Bootstrap 对选择器的自由使用 。
你想要修改布局 , 但发现每个组件都使用 col 类进行硬编码 。可悲的是 , 每个元素都在以不同的屏幕分辨率争夺空间 。一个变更需要其他五个甚至更多的地方也做出修改 。
这并没有那么糟糕 , 除非做出每个变更都需要深入到不可读的结构、样式和行为代码中 , 这些代码都在 render 函数中 , 而这些函数要在每个组件文件的末尾才能找到……
几个月后 , 在喝了 10 磅咖啡之后 , 你为再次加入竞争做好了准备(但其实那不是真的)……
如果你的目标是短期收购 , 你可能会不在乎 。但请记住 , 技术的灵活性和敏捷性就是力量 。如果产品的长期愿景是一台缓慢倾斜的机器 , 你可能会发现自己在谈判桌上处于下风 。
问题的影响
在飙升的劳动力成本、诉讼风险、错失的商业机会、有限的客户获取以及无法迅速掌控局面之间 , 看似微不足道甚至明智的技术决策突然之间对现实世界的商业产生了影响 。
对于正在处理某些类型应用程序的一些企业来说 , 我所讨论的一切都在完全掌控之中 。然而 , 其他致力于其他类型应用程序的企业可能会盲目陷入长期的承诺和高维护的噩梦之中 。
请记住 , 与开发相比 , 软件将在维护中度过大部分时间 。通过快速搜索 , 我找到了以下有关维护成本分配的经验法则:
  • 年度维护 = 初始支出的 15-20%;
  • 终身维护 = 总支出的 40-80%(平均 60%) 。
以下是一个 10 年期的成本投入情况 , 初始投入 100 美元 , 年度维护费用为 20%:
从后端到前端的转变:如何选择框架?

文章插图
 
 
如你所见 , 维护成本仅用了 5 年就超过了开发阶段 。在第 7 到第 8 年间超过了 60%的总成本阈值 。
当然 , 这只是一种简化的成本示例 。最有可能的情况是 , 在应用程序的整个生命周期中 , 项目越大 , 维护起来就越困难 。从长远来看 , 短期目标可能导致长期后果 , 这种后果只会随着时间的推移而复杂化 。
我也想知道如何将这些不可维护的项目排除在这些规则之外 , 因为维护成本变得如此之高 , 以至于项目直接以失败告终 , 并被抛弃……
根本原因我相信 , 从服务器端到客户端应用程序的重大转变 , 将大量有才华的开发人员从后端拉到了前端 。由于优势和劣势的不同 , 这些程序员开始改变前端的开发方式 。
当然 , 这只是一个假设 , 但我认为下面这个图表有助于解释我们正处在一个恶性循环之中:
从后端到前端的转变:如何选择框架?

文章插图
 
 
你可能已经注意到图中使用了引号 , 这是有原因的 。“Highly skilled”只是相对于其他开发人员引入前端工具能力而言的 , “Complexity”是相对于被解决的问题而言的 , “Low skilled”是相对于目前在生产环境中使用的工具的复杂性而言的 。
我们可以合理地假设“Highly skilled”开发人员正在引入工具来弥补他们在前端方面的不足 , 而不是增强整个组织的能力 。例如 , 从使用 CSS 框架中获益最多的人是维护 CSS 能力最差的人 。


推荐阅读