Web 技术研究所

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

项目解耦,将「一坨」化作「一坨坨」

  无论是何种项目何种语言编写,当业务复杂时或者经历过多次大规模修改后,无论先前规划得多好,最终都会变成一坨。解决这个问题是无法通过某个架构来实现的,只有不断地重构才能确保项目不变成一坨。而让项目重构的成本降到最低的办法,唯有将项目拆成多个。
  以前开发项目的时候都比较随便,把所有业务都放在同一个项目中实现。当项目越来越复杂后就经常会出现牵一发而动全身的问题。虽然有专业的测试,但要把整个项目的全流程完整地跑下来,那不是短时间可以完成的(所有 UI 测试框架都是不靠谱的)。所以当一个项目越来越大时不仅开发成本变高,测试成本也会变高,而且也更容易出错。
  同一个项目中的业务有一个特点,那就是可以共享代码共享逻辑。虽然可以减少代码冗余,但它是出错的罪魁祸首。代码复用是项目开发中最容易出错的地方,有时候一个类的定义根本不知道被哪些业务复用了,负责任的开发者会在删除前做一次全局搜索,确保没人用了才会删除掉;而有些开发者觉得这个东西是自己写的,自己知道在哪里使用,删除使用部分后就直接把定义也给删除了,根本不考虑其他开发者也可能使用。有时候就算全局搜索也很难确保引用被替换干净,因为有些开发者可能不直接使用名称来访问,而是通过字符串拼接属性(强烈建议项目中不要出现这种代码)。
  为了防止定义被删除后出错,大家可能都会避免删除。于是僵尸代码越来越多,很多定义即便没人使用也没人敢删除。如果只是因为代码冗余,那根本不是什么大不了的事。问题的关键在于僵尸代码占用了大量优秀命名,导致后来的代码只能用一些奇奇怪怪的命名。最后新参与项目的开发者根本看不懂原来的代码是在干什么,于是项目就变成一坨。
  避免不必要的代码共享是解决以上问题的唯一出路。而「避免代码共享」这件事如果只是一纸约定肯定会有一堆开发者把它无视掉,人类是不可信的。唯有将项目拆成多个,物理上隔离代码才能避免一些熊孩子强迫性的代码共享。
  不过共享代码始终是存在的,在同一个业务中确实有些逻辑是强耦合的,它们必须共享。或者可能是产品经理挖了一个坑,搞出一堆奇奇怪怪的逻辑,导致某些业务上的代码非共享不可。但无论如何,只要我们把项目尽量拆碎,最糟糕的情况也只是个别子项目变成一坨坨。而且这些一坨坨的子项目由于本身并不大,即便重构也不会耗费太大的开发成本。
  将「一坨」化作「一坨坨」才是科学的可持续发展!
网名:
50.16.97.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^