Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

简化工作流

  前段时间改了一坨旧程序,槽点简直多得吐不完。太细的坑我也不想纠结,但确实有个值得一提的坑。这些坑不仅是旧程序上存在,新程序中大家也在默默地挖着。程序的维护成本与其工作流的复杂程度是成正比的,就算逻辑是正确的也不应该把工作流复杂化。
  这段描述可能有点太虚了吧?那我就举个现实点的例子。前段时间改的那坨程序,逻辑上本身是完全没问题的,而且也非常注重分层设计。但它的层级分得有点丧心病狂了,多到每次改一个地方需要同时打开一大堆文件去找那些层的对应关系。经常是把我的 vim 标签页占掉一屏以上,有时我的脑子都要堆栈溢出了都没找到 API 在哪里调用。或者就算找到了,那也是耗费了大量时间的事,甚至有时找到后都已经忘了为什么要找它了。
  确实有时候由于页面上的奇葩需求会分出很奇怪的层叠关系来。但即便如此,我们也应该把层之间的接口差异降到最低。比如 API 返回一个枚举类型,那么如果没有特殊需求,这个枚举类型就应该一路保持自己的取值范围到 view 层,无论中间嵌了多少层。
  再举个例子吧。如果后端提供了一套 API,并且有完整的文档。这时前端应该如何使用这套 API 才能让工作流最简化呢?我不反对把 API 在前端封装一层,但如果这一层封装出来的东西与后端的 API 文档完全关联不上,那么即便这一层封装提供了更完整的文档也只会让工作流变复杂。为什么呢?也许这一层的开发者想着后续的层不会直接与后端 API 交互,所有请求都经过这一层。虽然这个逻辑是对的,但这个想法显然太理想化了。程序永远需要 Debug,不会因为多了一层封装就万无一失。我就经常从前端 Debug 到数据库,甚至 Debug 到 CMS 才找出问题所在。这样的封装只会让其它层的开发者要多读一份文档而已。所以我觉得这种情况的最佳封装方案应该是直接使用后端提供的 API 文档来封装,让后续层的开发者只要看后端这一份文档就可以完成所有流程。
  「简单」这个词其实是个很主观的概念,也许这样的东西我觉得是「简化」了,但确实有人觉得是「复杂化」了。所以如果真觉得无法接受我的观点也可以无视掉,我只是觉得把事件浪费在读各种奇怪的文档上有点划不来而已。
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^