#engineering heuristics

rss · Sean Goedecke · 11月6日 00:00 「背景」 作者把数据库中的行或记录重新定义为“全局变量”：程序任何部分都能读写它们，因此也会带来隐式传数和跨模块耦合这两类全局变量的典型问题。然而，工程界一边告诫避免全局变量，一边又让许多优雅系统依赖数据库，这种表面矛盾正是文章要解释的。 「方案」 作者逐一检验了五种解释。第一，数据库应用也许本来就比较混乱；他认为这有一定道理，但不足以解释全部现象，因为数据库应用仍会刻意避免普通全局变量。第二，ACID 事务能缓解问题；他不接受，因为全局变量的根本问题在于其存在本身，而不是能否同步，否则加一把互斥锁就该让全局变量变得可接受。第三，数据库操作更显式，查询需要连接对象和函数调用，扫描代码时更容易定位，这确实减轻了隐式耦合。第四，数据库只能存数据、灵活性更低；他认为这只在弱类型语言中较有说服力，无法解释类型化语言里的情况。第五，开发者熟悉数据库的使用规范，比如读取时检查列类型，也不会拿它做循环计数器之类的琐事。作者最终认为第三和第五条最有说服力：数据库更好，部分是因为使用方式更显式、用途更受限，而这些原因是偶然形成的，并非数据库固有；若给全局变量建立类似约定，理论上也可能达到相近效果。 「启示」 作者并不建议改用全局变量，而是指出“避免全局变量”和“用数据库保存状态”这两条常见教条并不完全一致。他的更大结论是：软件设计知识仍多是一堆松散的经验法则，因此对那些只诉诸“最佳实践”、讲不出具体理由的工程师，应保持怀疑。 标签: databases, global variables, software design, coupling, engineering heuristics