web开发之用不用框架

最近两个月的参与了公司的一个新项目，在从无到有的过程中不断反思，用模块化方式而不是full-stack框架确实带来一定的好处，但是也伴随着一些坑，这会儿有空总结一下。

回想当年初学web开发，不懂网络和数据库，也太懂操作系统，只是照着人家框架的教程一步一步复制代码，跑出一个博客网站，因为对代码的不理解外加对框架复杂度的恐惧，兴奋之余更多的是失落。这也好理解，人对于未知的不确定性，缺乏掌控进而没有安全感。随着对计算机基础知识的积累，所谓安全感逐渐增强，然后能够更加清晰的理解web开发的各个部分的侧重点和他们之间的关系。web开发中对于后端来讲，就是对每一个请求做出高效、稳定、准确的响应。而整个计算机领域无非就是把现实世界抽象成数据，并提供对其操作的工具，仅此而已。所以对于一般的初创型商业项目直白来讲就是数据库的CURD，需要关注的是业务逻辑，而不是诸如HTTP服务器，大规模数据库等这些问题。那么一般的web开发框架就是帮助我们处理一个HTTP请求的数据并生成响应数据，这里面涉及到的大体可分为路由与参数解析，数据库操作，响应构建模板这三大块。通常来讲数据库操作是逻辑最为复杂的部分，在full-stack框架里面负责这部分的叫ORM，即像操作对象一样操作数据库。这个看起来解放生产力的模块当然也有其坑坑一面，接下来我们可以就ORM结合实战经验来讨论一下。

我们的项目业务逻辑不简单，但有可预见的规模，所以我们没用ORM，而是较为传统地直接将表定义SQL放到项目里，然后手动去数据库执行。这样的好处是我们能针对MySQL进行定义，而坏处是，多人开发需要手动执行修改，没有migration这样的工具，更为严重的是项目上线后，每次修改都得十分小心地去线上数据库执行SQL，稍不留神就会很麻烦（当然也非常锻炼对SQL的熟悉度和心理素质）。而使用ORM则不同，我们看到的是编程语言对数据库的映射，并且每次数据库操作都是执行代码，自带migration工具，无论是合作开发还是线上部署都可以一键执行。但，爱也是束缚，你用了人家的库，就得按照人家的规则办事，灵活性必然受到限制。

除了定义数据库表单，绝大部分是数据库操作代码。用了ORM，就如同对类和对象操作一样方便，无论是可读性还是编码效率都有大大的提高，但问题往往隐藏在过于封装之下，如果不是对ORM有足够的了解，就无法准确地知道，一句ORM语句的背后到底执行了什么SQL。而我们的新项目则是裸写SQL，自然编码效率有所下降，但我们可以非常明确的看到每个SQL的内容，以更精准的把控代码细节。但，可以把控并不代表就一定能把控好，所以测试是保障代码质量的关键环节。

说到测试，主流full-stack框架及其生态环境都提供了较为完善的测试组件，无论是单元测试还是集成测试都能比较理想的到达要求，有些语言如 ruby 写出的rpsec测试代码具有相当的可读性。而对于选择模块化的我们，在工期的压迫下，并没有过多的时间进行测试代码编写，同时也是由于测试的基础设施不完善外加Go语言本身表达力的局限性。除了核心逻辑的测试代码，一些简单数据的测试基本靠手动。这里可以选择用一些脚本语言做集成测试。

full-stack框架还有一个特点就是各有各的一套代码组织模式，比较著名的就是MVC模式，搭配Restful，对于简单的CURD可谓是天生一对，但随着业务逻辑复杂度的增加，完全照搬Restful和死板的MVC模式会让代码变成一个腿细如竿的两百斤大胖子，寸步难行。关于这点，我会另写一篇来讨论代码组织架构。

总结一下，对于一个时间紧张的新项目来讲，full-stack框架是不错的选择，但要对其适用场景和坑做充分调研，并且要克制自己节制使用框架提供的魔法。而对于业务规模稳定且时间宽松的项目来讲，用模块化的方式可以对代码有更强的掌控性，方便日后的优化和持续扩展。