Java程序员的错
Java程序员是有问题的。我使用Java编程已经有10多年的历史。同时,我还有过大量的使用其它语言开发的经历,比如C#, C, C++, Python, Lua, Objective-C等等,我认为这些经历在对我认识Java程序员的问题上起到了巨大的帮助。很多人说Java是一种很糟糕的编程语言。我不同意。Java语言有它自己的缺点,但我想,很多时候,当你看到Java在有些地方让人很多人不爽时,那本质上不是Java语言的问题,而是它被错误的使用。
这些年来,在我见过的各种Java代码中,我发现这最大的问题是,写代码的人痴迷于把自己当作架构师。他们很喜欢这样,在我阅读他们的代码时,经常会发现这些代码与其说是去真正的解决一个问题,事实上更像是为了解决一个问题而规划的一个蓝图模板。这两者之间并不是细微的差别。你会看到继承很深的抽象层和成堆臃肿的样板式的代码。由面向对象而诞生的子类超生现象无以复加。你根本无法一眼看明白、理解这些代码是干什么的——你需要一层层深入 挖掘,你需要理解它的整套滥用的术语和折磨人的词汇(“AbstractAdapterFactory”),你必须要把自己当成系统的一部分。我已经记不起来上一次看到一个不是这种情况的Java项目是什么时候了。
导致在Java王国里代码最终总会变成这样的原因有很多。Java语言自身要承担一定责任。Java平台的API就是上面说的这些问题的典范,于是,善良的程序员们沿袭标准类库里体现出来的编码规范和风格,将之当作通用的好的编程原则,一下子就误入迷途。Java语言还会对程序员强迫施加一种上层的形式主义和啰嗦,以至于最后你不得不习惯了这样的风格,当看到其它语言的简洁语法时,反而感觉就像它们都是没穿衣服的裸体——这就是“斯德哥尔摩综合症”(译注:来源于1973年发生于此地的一次银行抢劫案中,一个人质浪漫地被她的劫持者吸引住了)。
面向对象的流行部分原因也是这种心理作用造成的。有越来越多的程序员开始退后一步用整体的眼光认识Java,他们发现,作为一种编程模式,面向对象真的是相当的糟糕。然而,Java是最大限度的根植于面向对象模式,如果没有面向对象,Java寸步难行。即使是今天,你仍然能看到大学里的编程课程严重的偏向面向对象,大量的使用Java授课,相比起10年前、5年前要普遍的多。
虽然Java语言非常的流行,在企业软件开发里被普遍的采用,但这一点都无助于Java编程质量的提高。我坦白的说,你在各种企业产品里看到的大量的Java代码都是由非常低质量的程序员写出来的。
非常糟糕的是,这些问题并不是只体现在代码上,而是在整个Java生态系统上也是如此。不论是你使用的Java单元测试工具、依赖关系管理工具,还是模拟框架,即使是很小的Java程序,你也逃离不了它周边庞大的系统。Java程序员无能为力——让他们开发一个小功能,你必然会看到一个继承15层的类工厂(factory)的出现。
今天,我在学习Gradle框架,很显然是因为最近它在Android开发社群里很火。Gradle来自于Java世界,所以它继承了上面我说的所有的Java所具有的问题。正像Tim Bray 最近在《泄了气的老程序员》中抱怨的:
“我的浏览器打开的是Gradle文档的一页:第50章.依赖关系管理。它有63个小章节,划归在10个一级章节下,这是第50章,文档一共有65章(包括五节附录)。”
Android——如果说除了那些开发企业软件的人,还有人会在意Java,那一定是因为它——它沿袭Java的老路,走的更远。你会习以为常的发现,在读一页Android API文档时,你根本不知道它究竟是在说什么。当然,最终你会弄明白,你需要绕道弄清楚其它17个类才行。什么?这让你吃不消?你显然不具备学习Java系统API的百折不挠的精神。你会变成一个Loser。
谷歌公司里开发Android的工程师忙于构筑伟大的系统框架,没有时间解决真正的问题。
我是一个Android程序员,我讨厌Java。它让我很受伤。
你也许感兴趣的:
- 【外评】不要把 Rust 写成 Java
- “甲骨文牌”Java正在死亡
- 您现在可以像运行 Python 一样运行 Java
- 从 Java 8 迁移到 Java 17 (二):Java 中值得注意的 API 变化
- 从 Java 8 迁移到 Java 17:新功能大汇总
- Oracle 再夺 Java 命?大公司用 Java 要小心了!
- 【程序员搞笑图片】java haters
- Java 22 新功能特性及示例
- Java 22 中最令人兴奋的 3 个功能
- 【译文】Java 21 – Kotlin 是否正在消亡?
既然是翻译作品,就请标明原著的网址,谢谢