FantasticMao 个人博客

如何快速上手一个框架

发表于 2017/09/14,阅读时间 1 分钟

前言

大多时候我们总是为寻求成熟可靠的方案,去选择一个框架,解决现有问题。比如使用 System.out.println() 打印日志很麻烦而且也不规范,于是我们使用 Log4j、Logback 等日志框架;请求的访问量很高,我们则使用 Redis、Memcached 缓存技术(这两个严格意义上不算框架,但情况类似)。

有时候也会觉得现有的代码太烂,或是其它原因,我们选用了新的框架替换之。比如抛弃了频发抛安全漏洞的 Struts,而使用 Spring MVC;抛弃了繁琐流程的 JDBC,而使用 ORM 框架。

开源潮流如火如荼,开源框架多如牛毛。在这个时代,我们应如何快速上手一个框架,这便是我今天要分享的主题 —— 关于使用框架的方法论。

第一阶段

在我认为,适应或者说上手一个框架的第一个阶段是:了解框架背后涉及的专业知识。

使用 JSON 序列化框架,我们就需要知道 JSON 对象的定义和其序列化机制,如此调用 Jackson、Gson、FastJson 等系列框架的 API 才能明白原理。

使用 Web 框架,则需要知道 HTTP 协议,知道 HTTP 报文、Cookie - Session 机制、持久连接机制等等,了解这一系列之后,我们使用 Servlet、Spring MVC、Struts 或者包括其它语言的 Web 框架,才能得心顺手。

同理可得,当使用 Netty 网络编程框架,我们就需要知道必要的更底层的 TCP / IP 等网络知识,虽然我还没接触过。

未了解过框架涉及领域的专业知识,茫然调用框架提供的 API,是一件很冲动和白费力气的事情。

第二阶段

第二个阶段是:开始使用框架,牛刀小试。

这个阶段主要是依靠零碎知识和搜索引擎的帮助,开始使用框架。这期间可能会遇到很多问题,包括对框架概念的不理解、对应用程序抛的异常束手无策等等。在这个阶段,每解决一个问题,都是一次自己能力的小提升。在这个充满挑战的阶段,建议在 IDE 上配置相关 Jar 包的源代码,并在调试程序阶段,通过阅读源代码和注释(开源框架的注释总是很详细的),来理解框架 API 层面提供的功能。这个阶段也可以为后续从点到面地阅读框架源代码做准备。

举个例子,在实践 Spring IoC 模块时候,起初可能会依靠各种比喻和解释来理解「依赖注入」这个概念,并且会生硬地参照着杂七杂八的 Demo,来编写一个 Spring 应用的代码。这便是我所说的使用框架的第二阶段。

第三阶段

第三个阶段是:阅读经典书籍,参阅官方文档。

在对框架的使用流程有所了解之后,这时候就需要开始进行系统的学习了。可以通过阅读一本业界公认的经典书籍,也可以通过阅读开源框架的官方文档,这些都是进阶掌握一个框架的好方法(当然也有其它方法)。在阅读官方文档的时候,会发现自己之前学习的地方有很多纰漏或者不规范的地方,这也是为什么我们需要系统性地学习知识的原因。

大多数官方文档都是英文的,这会让一些同学阅读起来比较费力,包括我也是。但这是不可避免的,自己要尽量去克服这个问题,多花一些时间,多积赞一些词汇量(其实专业词汇也没有几个)。可以随意举例几篇官方文档,我觉得是一个优秀的 Java 开发者应该有阅读过的:《Spring Framework Core Technologies》《MySQL InnoDB Architecture》《Scale with Redis Cluster》《Kafka Design》

第四阶段

第四个阶段是:多敲代码,熟能生巧。

其实这是一个伴随着第二和第三阶段的过程,不过我想强调一点:「温故而知新,可以为师矣」,学习总是一个螺旋向上的过程。在敲过一遍代码、看过一遍书,过了一段时间之后,我们便可能就会忘记之前所看的所学的,因为海量的知识实在是太多了。这时我们需要经常性地、有需求性地回顾相关旧知识。比如看了一遍 MySQL Explain 语句的输出格式之后,可能对其输出的列、输出的列的值含义记不大全,没关系,多看几遍就是了。

每一遍温故,总会有知新,就像重新看一部电影、小说。

第五阶段

第五个阶段是:货比三家,感受框架设计的哲学。

这是最后一个阶段(在我的定义中)。在用过同类的多个框架/库之后,我们便可以对比每个框架的设计和实现,去揣摩这些框架的作者当初编写这个框架的想法,去发现其中的优缺点,取其精华去其糟粕地学习借鉴。经典的例子是 Java 中的几个 ORM 框架:从繁琐的 JDBC 到实用的 MyBatis、Hibernate,再到更优雅的 Spring Data JPA。这些 ORM 框架的更新迭代、优胜劣汰,都体现着一种框架设计哲学的演进。想想人家的代码为什么要这么设计、要这么实现,总是受益良多的。

额外的话

最后想说的是,我们应该拒绝成为一个 API 的工程师 :)