J2EE导论 | 疑惑篇

J2EE是Java程序员从新手进阶的一个必经之路。要体会所谓的工业级代码，就必须要融入和经历更为复杂的开发、部署环境，需要同更多的模块、组件做信息流交换，比较和使用不同的框架，逐一去琢磨和考察它们的必要性及优缺点。

这样一种进阶，注定了其过程必然是痛苦的。这不仅是因为你要掌控和关注的细节、模块一下子陡然攀升，更因为这些增加的细节和模块背后都蕴含着各种复杂的理论知识：网络、web、程序构建。如果再考虑到你要使用的计算机，从一台PC变成多台服务器的交互，而部署环境从一直使用的eclipse自动化，变成多台Linux的部署，各种不适合不理解一下子都全部爆发，实在是巨大的挑战。

还记得当初最开始学习J2EE的时候，没用到一个月时间，就从入门走向了放弃。太多繁杂的部署和配置文件，理论知识又弄得来似是而非，更为要命的是当初根本没有什么软件工程的思想和意识，就简单粗暴地把这些繁琐工作扣上了一个“苦力”的帽子。并且自我安慰道：这么多复杂的零碎，不就是农民工搬砖么，果然是码农，我才不走这样的路。而完全没有意识到，这正是软件工程思想的匮乏所导致的。

正是因为事务性的东西太多，所以你才需要有出色的工程能力，运用你的谋篇布局将复杂的管理任务，通过各种工具、技巧和构架，把它们逐一消磨，从而让所有的细节都在自己的掌控之中，有条不紊地把一项浩繁的工程管理好。

我想，这一思想是一名优秀的软件工程师，也是J2EE入门所必备的 ，那就是控制复杂度是所有工程师最本质的任务。如果出现了细节太过繁杂，让自己深陷其中而无法解脱时，就一定要停下来跳出去思考，自己的整个工作流程应该做怎样的优化和改进，应该如何重构自己的流程和组织，从而把整个团队和工作流程理顺，发挥出他们应有的实力。

也即是，当你面对复杂问题的时候，你不会用消极的放弃或者粗暴的贬低来逃避复杂度失控的现实，而是会更加积极地去寻求改进方案，让自己更有条理更高效地完成任务。

怀揣着这一思想，就可以更为深入地探讨J2EE对新人的挑战和隐藏的深坑。在我看来学习Java，对新手来讲有这么几个坑：

 

1、不关注Java命令的运行

因为Eclipse的大而全，从而完全不会使用java的命令行，更不知道Java参数是些什么鬼。

或许一般的教科书会谈到一点如何通过命令行去运行Java，但紧接着，后面会补充道，有了Eclipse我们就不需要关注这些繁琐的细节。然后把Java命令行的东西永远地抛到脑后。

话是没错，有了Eclipse，谁还会去关注那堆交互极差的命令行？

可正如我在前面所说，当你运行的机器，从个人PC变成了远程端的Linux Server，你还能不关注命令行吗？甚至，让我问一个更为傻气但往往却能戳中新手痛点的一个问题：你使用的Linux Server端，很可能连图形界面都没有，请问如何使用你熟悉而又引以为傲的Eclipse呢？进一步，Eclipse都没有，请问你如何debug呢？又如何加断点，做你习以为常的单步调试，看着一条条的黄色加亮行debug？

从这个角度讲，你或许就能够理解：为什么单步调试并不总是一个好的方法。同样地，为什么你需要学习不同的调试技术，为什么需要学会怎么写log又如何依靠log来做debug。种种这些说法和论调，都会因为你使用工具、计算机的环境的改变而改变。

为什么你以前无法理解这些东西？

因为你以前只会使用一台PC，不会同远程端的Server打交道。更没有什么严肃的工作和需求，逼迫你同Server打交道。即便是在PC上安装了Linux，你或许也会困惑，为什么要用这堆东西呢？都说Linux好，可为什么自己感觉不到呢？原因就在于，Linux的通常使用环境，并不是作为个人PC来用的。它更多的是被当做Server端的操作系统来使用。你连使用场景都弄错了，那又怎么可能理解和体会Linux的好处？

回到我文章开头的那句话，我说“J2EE是Java程序员从新手进阶的一个必经之路”。那么现在，我能更好地给出这个论断的理由：因为有了J2EE相关项目的介入，你终于可以在一个真实需求的情境下，开始逐一发现你使用计算机的不同情况，进而真正去体会不同的论断和说法。例如，这个部分我提到的关于Eclipse的那些问题。

所以，所谓的为什么软件工程师需要实操、需要有真实的工作经验，为什么它们有时候比学校的理论来得重要。这就是因为，“工作”本身会为你提供一个真实的需求，而不是学校书本里自己臆想的一个伪需求，来让你一个个地去体会真实世界中的限制，进而再看到那些曾经在书本上但却不以为意的解决方案或工具时，便会有一种大梦初醒的感觉。

 

2、不知道Java运行的是什么

同样是因为过于依赖大而全的Eclipse，你逐渐会“忘记”，你运行Java的时候，到底在运行什么。或许，你早已在书本上看过，Java源代码需要经过编译变成class字节码，再由JVM把这堆字节码变成所在平台的机器码，进而这堆机械码被加载进内存运行。

可一旦要在Server端部署代码，新手的第一反应很可能就是我上面提到的：我的Eclipse在哪里？没有了Eclipse，我的Java怎么运行？

这其实就是完全没有真正理解上面说的Java运行机制。要运行起来Java，有了JVM、有了class文件就够了啊，你要Eclipse干嘛？

更进一步：OK，就算有class，我不需要通过Eclipse来做编译，可那些jar包的依赖怎么玩儿？每次的jar的依赖都是靠Eclipse来做的连接，没有了它，依赖关系怎么做？

这就又回到了第一部分提到的，根本不懂如何使用Java的命令行，更加不知道Java参数是些神马鬼。更本质来讲，你并不清楚Eclipse为你封装、简化的服务是些什么。你不了解，在Eclipse的背后，到底调动了那些命令来指挥你程序的运行，而这些调动的东西，如果不通过Eclipse又该通过什么方式被实现？

或许你可以辩解道，我曾经的编程工作确实不需要了解这些底层啊，因为了解了也没用，我还是会用Eclipse来简化我的工作。

所以咯，这就是学习J2EE的价值，强迫你弄懂这些细节，并且真的会在Server端的部署和开发中运用到。你不得不关注这些Java的依赖和build，从而更深入地理解Java的运行方式，进而才可以体会到为什么需要所谓的部署工具，从最简单的makefile，到比较流行的Ant、Maven等。

 

3、服务器端的Java入口在那儿

这是另一个有点玄乎的问题，但同样是因为长期在Eclipse环境下做开发导致的。要开发、测试你的程序，那么第一步，你至少要让它运行起来。那么，通常的做法是什么呢？

那当然是在Eclipse中点开某个具有main函数的java文件，然后点击Eclipse的运行按钮。

等到了J2EE的环境下，你会惊讶地发现，你竟然不知道如何将自己写的这堆代码给跑起来。一来当然是因为那个老问题，Server端没有Eclipse，我如何点击运行按钮？

再来，就算我知道可以通过Java命令行来开启一个Java程序的运行，可是，随便拿来一套J2EE的源代码，你竟然找不到一个类是有main函数的！

这可一下子就傻眼了，main函数都没有，你让我如何使用Java命令行把整个代码启动起来？

且等后面再回答这个问题，让我们再提一个有着相同理由的另一个问题。

 

4、数量繁多的配置文件和互补相关的源代码

让J2EE从新手走向放弃的另一大关键，就是“数量繁多的配置文件”和看起来“互不相关的源代码”。随便拿到一个J2EE的项目，就会发现各种xml和独特格式的文件满天飞。而随便找一个java文件读一段，就更加莫名其妙，似乎这个文件就是独立存在的，没有和别的java类的交互，声明自己有哪些变量、提供好自己的setter/getter，然后，就TM没有然后了！或许你以为这只是个特殊的文件，又接连抓过几个java文件来看，发现都是这样的风格。如此种种，当然会把一个newbie逼到抓狂。

你会因为无法把这些配置文件和类文件的功能连起来而抓狂，又同样因为要不断地切入切出各种种类繁多的文件类型而焦躁：搞这么多的文件类型的目的是什么？为什么需要它们、为什么需要这些独立又互不关联的文件？

要理解这个，就必须回到我们最开始说的关于工程师本质目标的思想：控制复杂度。

控制复杂度最基本的技术就是：分而治之，把一个复杂的问题分解为独立的子问题。

这是一个看起来简单，实则深不见底的技术。甚至可以这样夸张地说，所有的工程上控制复杂度的技术，都是对这一条的直接/间接地使用，又或是通过复杂的其它技术的辅助，来实践这一条技术。

将问题分而治之，有很多好处，其重要的就两条：

• 一是把问题分解后，你就可以不必直接面对一个大问题，从而可以更好地通过各个击破的方式将它解决。用最通俗的话来讲，就是饭要一口一口地吃。你不会直接把一大碗饭倒入嘴里，而是各个击破。

• 另一个是，当你把问题分解成独立的子问题后，那么复杂度就从系统性的关联复杂性，转变为了一个个小模块各自的复杂度。因为这个独立性，你才得以获得更好的稳定性。因为，就算是一个模块突然出现了问题，由于它的独立性，便可以只把损失限定在它这个模块里，不会影响到系统别的方面。以这样的方式，实实在在地把问题，限定在了一个更小的范围，从而控制住了复杂度。

那么，配置文件、互不相关的源文件、以及Server端的J2EE代码竟然没有main函数，其实都是一系列关于“设计模块、系统构架”的综合技术对这一思想的体现。它们无疑都是为“分而治之”控制复杂度而服务的。

所以，当你有了这些疑问时，其实是最好的学习设计模式和系统构架的机会。因为你有了一个真实场景，从而会立刻能感受到现实的限制条件对你的逼迫。此时，你将会为这些限制而焦头烂额。如果这时候，你去研究一下业界的成熟解决方案，就会很快发现它们都会和设计模式、系统设计搭上线。进而，你便能够势如破竹地理解清楚这些技术的精髓和存在的意义。

 

5、繁多的理论知识

由于J2EE涉及的环境很多，又是web应用，那么最基本的一点，便是网络、web、Server端的软件、Client端的软件他们之间有什么区别和联系。

还记得我最开始学习J2EE的时候，那简直是胡子眉毛一把抓，且不说把网络和web各种混淆，就连互联网产品和传统IT技术产品的区别都傻傻分不清楚。结果便是，各种概念混用。

而大部分的资料，会一个个地讲解browser的运行方式，讲解HTTP多么高深莫测，又提到Tomcat的Servlet多么本质，又或是Spring框架多么方便和利剑出鞘。可TM从来没有谁把他们串起来，好好地说明他们的职能位置在哪里，在一条生产流水线的位置在哪里。

或许，这是因为这个东西恰好处在一个微妙的尴尬之地：会的人，会觉得这个东西太过简单，拿出讲解或许没啥技术含量，有点不好意思。而不会的人呢，任凭他看多少细节的东西，反正就是不能把各个模块安放在正确的位置，便总是打不通任督二脉，干着急。

我想，我的一个重要任务，便是对这些关联性的东西，做一个细致的宏观review，反正我的脸皮比较厚，不怕diss。

理清楚了这些潜藏在newbie内心模糊的疑问，我们才能在下一篇开始比较系统的自顶向下的技术细节讨论。

不要小看这些问题的梳理。往往，一个newbie从入门走向放弃，就是因为感觉极端模糊，感觉到处都是问题，进而开始展开联想，怀疑是不是自己有问题。而如果能够理清楚自己的问题真正在哪里，就如同分而治之的思想那样，你便能够做到心中有数，只需要把不清晰的技术点，逐一攻破就好了，没什么天塌下来的大事情。

 

 

 

近期回顾

《前端技术的碎碎念》
《放眼望去都是痛》
《网络概念与快递物流》

 

 

如果你喜欢我的文章或分享，请长按下面的二维码关注我的微信公众号，谢谢！

 

   

更多信息交流和观点分享，可加入知识星球：

 

 

VIP赞赏专区：