Hanami 与自己的思考

起因

前段时间看到一篇 My thoughts on Hanami，也看了 This was originally posted as a comment on Reddit, 对其中的一些观点深表赞同。

As dev, the more you learn, the better is for you as a job candidate. Even if the job is a Rails one. Learning Hanami, dry-rb, ROM, TRB expands your Ruby knowledge. It also happens that features or ideas that are introduced first in these frameworks then they appear in Rails.

As employee, you can experiment with these frameworks for minor side projects if you want just evaluate them.

As employer, you may want to: 1. diversify your tech stack as investment diversification 2. expose your employees to different techs to improve their skills.

It's really a win-win situation for everyone involved.

在很久以前就听说过 Hanami，当时粗看了一下，的确是精简，和我自己造的轮子也颇有几番相似，当时就没有细入研究。随着后来团队人员增多，就碰到了一个问题，RoR 的同学觉得我造的轮子多少有些别扭。

这是引起思考的一个点。遂记录下来。

轮子轮子

我的这个轮子呢，主要是利用 Rack + Grape + ActiveReocrd/Sequel 组成的，其中一些启动逻辑，如环境变量都是自己组装和管理的。去年 2017 年也慢慢从 AR 切换到 sequel 作为 ORM。让习惯了 Rails 的一些同学感觉很不适应。

我一直以为 Ruby 圈里的一个怪象就是什么问题都用一种解决方案来解决。的确，Rails 像瑞士军刀一样可以解决多种问题，但是与此同时这也限制了程序员的思维，与隔壁 Python 家产生了鲜明的对比。我只能说各有利弊。

最近一段时间利用 Hanami 这个框架写了一个 API Service，有了一些经验，也记录下来。

Hanami 的核心架构思想

  1. The Clean Architecture

    Hanami 在他的文档首页也写明了自己设计架构，主要是利用 The Clean Architecture 来做的。

    这是著名软件大师Bob大叔提出的一种架构，也是当前各种语言开发架构。干净架构提出了一种单向依赖关系，从而从逻辑上形成一种向上的抽象系统。

    上图中同心圆代表各种不同领域的软件。一般来说，越深入代表你的软件层次越高。外圆是战术实现机制，内圆是战略核心策略。在外面圈中使用的数据格式不应被内圈中使用，特别是如果这些数据格式是由外面一圈的框架生成的。我们不希望任何外圆的东西会影响内圈层。

    在图的右下方是我们如何越过圆边界的例子。它显示控制器和界面之间是如何和用例进行通信的。注意控制流程。它开始于控制器，通过用例，然后在界面处执行。还要注意源代码的依赖关系。他们中的每一个点都是指向内部用例。我们通常使用依赖注入来实现这种依赖。

    这些架构产生的系统特点是：

    • 独立的框架。这样的架构并不依赖于应用软件的具体库包，这样可以将框架作为工具，而不必将你的系统都胡乱混合在一起。
    • 可测试。业务规则能够在没有UI和数据库或Web服务器的情况下被测试。
    • UI的独立性。 UI改变变得容易，不必改变系统的其余部分，一个Web UI能被一个控制台或专门的图形UI替代, 这些读不必更改业务核心规则。
    • 数据库的独立性。 你能够在Oracle或SQL Server Mongo, BigTable, CouchDB,或之间切换, . 你的业务规则不会和数据库绑定
    • 独立的外部代理，其实你的业务规则可以对其外面的技术世界毫无所知，比如是否使用了MVC或DCI都可以不关心

  2. Monolith First

我的理解很简单，就是先做出东西来，再一点点拆分，毕竟都是有成本的。面向业务，让技术服务于商业。

  1. 与 DDD 切合

    Hanami 中的 Domain 和 Repository 的概念也是有的，这个 DDD 中的概念一一对应。

Hanami 与我的轮子对比

  1. 解决了 initializers 功能

    我在造轮子的时候一直想要做的一件事情就是模仿 Rails 做一个 initializers，不过现在挺好的。可以直接用了。用了之后效果也不错。

  2. 同样使用 dotenv 形式的环境变量

总结

其实想要表的思想很简单，我们应该多去学习新的东西，这也是自我知识体系的完善过程。也是因为这些原因，我也是长期处在创业公司，可以面对更多的技术问题以及新的事物。不过最近的一个决策是想往 T 型深度发展，有幸拿到一个符合目标的 offer，这一块正是我欠缺的，有机会去弥补也是很好的。