timystruct 前世今生（2）

有很多朋友都很纳闷，现在都什么时候了，你还需要考虑计算机资源吗？而且现在的资源都很便宜。如果从眼前的经济实用性角度看待问题，这个我也认同。但从技术发展的长远角度来看，节约资源，提高效率，永远是作为技术人员所追求的。这就是为什么我们仍然在看到不断有新的语言出现，比如 RUST 。而为什么 Spring 框架里搞 Bean 的生命周期概念，目的不也是在节约内存资源吗？关于这个话题，我们后面还可以继续探讨，就不在这里过多强调了。

其实模块化带来的好处很多，尤其是处在微服务时代。在一个项目起步的时候，我们很难知道一个项目是否就应该采用微服务架构。大多数人都是跟风，做到后面发现实现这些需求根本不应该搞微服务。想切回单体架构又特别麻烦。而且还是一个系统改造工程。那如果一个框架能在单体架构与微服务架构之间切换，那不是很棒的一件事吗？你可能会想了解 tinystruct 是如何实现的，我用简单的比喻形容它：一个项目像一根电缆，而服务或功能则是电缆里的每一根导线。这就是 tinystruct 的设计理念之一。这世界上没有一样复杂的事物是不可能被拆分成一个特定规模的小的单元。

作为一个能运行在低端设备上的框架，除了模块化以外，就是外部依赖。如果要实现一个功能，却依赖很多，必然导致资源不可控。毕竟有些依赖会耗费很多资源，而有一些依赖一时半会，你想去掉并不是那么容易。所以，你可能会注意到 tinystruct 框架里，并没有使用一些常用的库，比如 Jackson ，也没有像 fastjson 里搞一堆的将 JSON 硬生生地映射为某个 Java 对象。在我的设计哲学里，我更喜欢简单，职责单一，这才是减少 bug 的关键。

当我们有时候接到一个任务，需要写一个工具，而这个工具可能仅仅就是处理一个小需求，比如从处理一些 excel 文件数据。很多朋友用惯了 Springboot 就自然的建了一个 Springboot 项目。然后，又接到一个爬虫需求，又去建了一个 Springboot 项目。不过，有些比较资深的程序员就会想，我为什么要用这么大的一个框架，去完成这么小的任务呢？如果你去找个替代品，貌似在 Java 世界里，找不到几个可以拿来用的。那就自己从零到一写一个纯 Java 的工具吧。写到一半你会发现你要写很多东西，比如访问数据库，比如 JSON 格式的转换，处理 HTML 的库等等。于是搞不下去了。甚至很多人忘了在没有 Spring 框架下如何去写 Java 了。从这种现象中，我们可以发现一些问题。首先就是习惯了杀鸡用牛刀；其次，淡化了 Java 原有的运行模式；最后，感觉这个 Java 世界只有 Spring boot 再没有别的，完全失去了程序员该有的创新意识。甚至很多人都觉得换个工作可能只能跑快递了。我想对 Java 程序员说的是，框架是被你使用的，你可以根据需要选择它，而不能让框架把自己绑架了。

不过，我要强调的是，本人无意去撼动一个被众人推崇的框架，只是认为 tinystruct 或许是一个补充，或者可以满足一部分小众需求。或者只要能帮我自己解决一点问题就好。我本身也不是靠这个吃饭的。只是分享一下我个人的一种解决问题的方式而已。你是否感兴趣，我丝毫不在意。我也不建议你放弃你的吃饭的家伙来选择一个你觉得可能对你是无聊的东西。

（未完待续）

tinystruct 前世今生（ 1 ）： https://v2ex.com/t/1158684?p=1#reply7