• 2012-12-19

    平台的绑架

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/226077776.html

    每每接触一个新项目,无论是咨询还是交付,我总是希望带来一些不一样的东西,其中就包括一些软件或平台的更新。比如:

    • 作为一个忠实的IntelliJ IDEA的粉丝,我总有一种把项目从Eclipse拯救出来的心。
    • 作为一个新时代自动化构建的粉丝,ANT和Maven让我回归旧石器时代。
    • 作为一个简化开发的粉丝,一见到EJB,我就想退避三舍。
    • 作为一个轻量级部署的粉丝,每每听到WebLogic或Websphere的名字,我就头皮发麻。

    我的心是好的,但现实总是那么残酷,有各种各样的理由把平台的威力发挥至极致,以致于我们只能一动不动:

    • 我们用到XX公司的框架,在Eclipse很容易配置,而且配置完了,可以部署到XX平台上,很方便。
    • Gradle,没听说过,我们现在的东西已经能够编译打包,这不就是自动化工具该做的吗?
    • 我也知道EJB代码不太好,但这是遗留代码,不好改。
    • 我们用到WebLogic/Websphere的XX强大特性。

    出现这样的结果,我们已经被平台绑架了。所谓被平台绑架,指的是,你只能使用某个特定平台的东西。这样的结果就是,在技术更新时,我们就只能停滞不前。

    在这个技术发展飞快的年代,新技术层出不穷,用不了多长时间,我们现在所谓的一些时髦技术已经成了地摊货,再过一段时间,就会过时了。或许你会说,我们没有必要跟得那么紧吧。我认同你的观点,但是,如果你成为一个有多年经验的老程序员,你会发现,时间是把杀猪刀。

    我脑海中依然记得初学EJB时的情景,现在EJB已经完全成了过街老鼠,时间仅仅过去了十年。如果我的故事还不算老,最近还听了一个我的客户给我讲的一个故事。多年之前,他们从某大公司那买了大型机,在上面开发用COBOL开发他们的MessageBroker,为此,他们投入很大,招了不少懂上面开发的“专家”,后来,大公司不再支持这个机器了,这个世界上,也只有他们有这些“专家”,当然,也只有他们需要这些“专家”。现在,在不断纠结很多年之后,他们终于下定决心,剔除这个大型机,彻底地。

    好吧,我是一个老程序员了,可以讲一些老程序员的故事了。有了教训,当然,还应该有一些可以分享的经验。

    最重要的是,尽量不要依赖于任何特定的平台。

    • 使用IDE,即便用到它的一些特定功能,也要知道其背后的原理,像部署之类的事情一定要有自动化脚本,养成没有IDE这事也能做的习惯。请记住,IDE是我们的工具。工具,我们当然要挑最好用的。
    • 多了解开发新闻,抱着开发心态了解最新的发展,用一些小例子尝试新工具。这样,才不会受限于某个特定工具。对于构建工具这一点而言,请理解《软件开发地基》,剩下的,无非是用哪个工具实现而言。
    • 尽可能让自己的代码与特定的框架隔离开,即便是要依赖也应该只有那一点的调用。这样,如果要替换,我们的核心业务逻辑都是独立的。
    • 部署方面,尽量使用标准的东西,减少对特定平台的依赖,保证我们的部署包是可移植的。如果万不得已一定要依赖,一定要把这部分代码/配置从物理上与我们领域代码/配置隔离开来。更换部署的时候,我们只要把特定的部分删掉就好了。

    是的,我们可以有一万个理由说,现在这样也挺好。但我们是程序员,我们不该让自己的生活再美好一些吗?在开发方面,我这些年不断追求的,无它,只是想让开发效率再高一些。别让平台绑架了我们。

    分享到:

    历史上的今天:

    引用地址:

    评论

  • 你好,我看了你写的这个很惊讶

    “作为一个新时代自动化构建的粉丝,ANT和Maven让我回归旧石器时代。”
    实话说,我还因为会点儿ANT粘粘自喜过,Maven还没没列入计划。你说的“自动化构建”是用什么技术,什么工具呢?请指教。多谢。
    回复greatgarlic说:
    没什么,只是视野不同而已,所以,学习不能停。去年写过一篇《选择,构建工具》可以参考。现在我的个人倾向里,Java世界构建的首选是gradle,次选是buildr。新写的blog算是回答你了。
    2012-12-19 10:00:35