作者：王波
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Java架构师指南试读：
前言
互联网的发展带动了各行各业信息化的趋势，一大批高新企业如雨后春笋般出现在大众的视野中。于是，不同类型的软件项目应运而生。在这些琳琅满目的项目中，有企业管理、电商平台、财务报表、金融银行、医疗器械、智慧城市和大数据分析等类型。项目的层出不穷带来了巨大的利润，让高新企业不断地成长起来，与此同时，也带来了很多相关的就业岗位。
当然，要顺利地完成这些项目，就需要大量的软件工程师。这种硬性的需求又养活了一大批培训机构，从事软件行业的人员当初是凤毛麟角，现在依然是供不应求。那么，如何提高软件工程师的开发技能就成了一个无法回避的问题。诚然，公司可以不定期进行培训，提高开发人员的技能水平，但从更普遍、更直接的意义上来说，提高技能水平的最佳方式还是系统地阅读相关书籍。
回到正题，项目从设计到完成的每一个环节，都需要精确地把控，如果这方面做不好，会让项目陷入困境，得不偿失！同时，在开发语言的选择上，也需要相当慎重。例如，大家熟悉的Java语言，它最大的优点就是跨平台运行。如果使用Java语言开发项目，程序员关注的无非是在某个系统环境下完成代码的编写和调试，至于最终需要用在哪里，没有必要过多地关心，因为无论是在Windows系统还是在Linux系统，Java程序都可以顺利地部署，流畅地运行。Java跨平台的优点得到了很多公司的青睐，他们纷纷把自己公司的核心编程语言确定为Java。这样的情况愈演愈烈，以至于Java语言在J2EE方向的发展非常迅速，成为企业级开发的首选。Java与众多优质的第三方框架搭配起来使用，更是让项目的开发进入了一个非常高效、便捷、可复用的时代。举个经典的例子，大家熟知的SSH框架技术集合，就是使用Java语言开发，再把Struts、Spring、Hibernate三者结合起来，组成的一套成熟的开发框架。这套框架曾经风靡全球，引起了业界学习的浪潮，促使很多公司前赴后继。不过，在2005年6月的JavaOne大会上，Sun公司发布标准版Java SE 6的时候，顺带将J2EE改成了Java EE，但因为历史原因，J2EE的提法仍然经常存在。
如果说Java语言的跨平台特性是很受欢迎的，那么Java语言的安全性也是非常让人放心的，这主要得益于Java语言中设计的沙箱安全模型。Java代码的执行全部在类装载器、类文件检验器、Java虚拟机内置的安全特性、安全管理器这4个组件的安全策略下完成，极大地保障了程序运行的安全。另外，Java语言还提供了AWT和Swing方面的开发，这两者都是基于图形化用户界面的，也就是业界常说的GUI层面的开发。但是，Java语言在GUI领域的优势并不那么明显，更多的开发人员仍然选择C++，绕过虚拟机直接与操作系统交互。而与此同时，Java在企业级方面的优势却越来越大，以至于出现了一枝独秀的局面。
计算机语言从机器语言、汇编语言发展到现在的高级语言，这个过程中诞生了很多种语言。有些语言已经逐步退出历史舞台，有些语言仍然在小众化的范围内存在。而Java语言，经历了二十多年的发展，仍然保持着旺盛的生命力，在编程语言排行榜中高居不下，Java程序员的数量也与日俱增，这种现象主要是由Java自身的优势决定的。作为开发人员，需要关注的并不是底层的核心，更多的是Java带给我们的简单、直观、易于使用的平台。因此，程序员不用关心虚拟机复杂的结构和每一步的运行情况，只需要关注项目业务的代码即可。这种易于接受的情形，让更多人把开发当成了一种乐趣。
最近，在业内流行起来的全栈工程师的定位更像是高级程序员，而架构师则需要站在更高的层面思考问题。作为Java架构师，不但要懂得前端插件化的开发理念，为项目选择合适的前端插件，还需要精通后端开发，为项目选择合适的框架，这样才能高效地完成任务。否则，极有可能出现事倍功半的情况。如果说需要弥补架构缺陷，最乐观的情况是通过加班实现，最糟糕的情况是直接导致项目失败。因为项目经理可能并不会深入了解具体的代码，他通常会参考架构师的意见，所以架构师的意见就显得极为重要。因此，本书在讲解架构师必备的知识技能的同时，也会穿插项目管理的知识。
Java技术发展迅速，本书旨在结合最近几年流行的技术，带领读者见证从项目启动到收尾的全过程，力求在短时间内让读者掌握Java架构师必备的知识技能，并且能在日后的工作中做到游刃有余，既可以在掌握扎实的基础知识后，熟练地搭建框架，又可以为项目经理提供专业的参考意见。内容特色
市场上的技术图书琳琅满目，令人难以选择。但是，这些书中讲解程序员进阶到架构师的过程的书却很少，这不得不说是一件令人遗憾的事情。本书的出现将会带给读者全新的认知，帮助读者在短时间内掌握架构师必备的知识，缩短从程序员到架构师的进阶时间，早日达到架构师的高度。
另外，本书专注于Java企业级开发，从最基本的企业管理系统开始，到颇具特色的电商系统都有涉及，还附带了诸如报表系统、员工信息系统、代码扫描平台的开发等，基本上包含了业界常用的项目类型。书中的项目都是基于BS架构的，与Java程序员的技术成长趋势完全匹配。读者可以通过阅读本书，并结合提供的源码进行练习，以做到融会贯通。
本书结合实际、深入浅出，以项目为驱动，阐述了我多年来在Java Web方面的开发经验。同时，本书通俗易懂。虽然没有把Java中特别浅显的内容用独立的章节来讲解，但这些内容都会在本书的代码中出现，读者可以结合程序自行理解，或者通过阅读注释学习，都可以很容易地理解它们的意思。综合来看，本书不但适合刚步入职场的新手，还适合有一定工作经验的开发人员，因为书中的每份代码都会有详细的注释和代码解析，方便不同技术层次的读者领会代码的含义。本书通过讲解企业管理系统的开发过程，让读者全面掌握Java EE的精粹内容，之后再通过其他几章的讲解，让读者学习到电商系统、报表系统、员工信息系统、代码扫描平台的开发，不断地拓展Java架构师技能的广度和深度。结构与组织
本书的核心内容是讲解Java架构师必备的知识和技能。● 第1章讲述编程基础，通过搭建简单的环境，开发第一个程序。● 第2章从项目管理方面介绍需求调研的整个过程以及项目文档的
撰写方法，让读者初步了解项目的启动、规划、执行、监控和收
尾五大过程组。● 第3章到第9章讲述企业管理系统的具体开发过程，重点讲述
Servlet、SSH、Spring MVC等框架，并且加入了近年来流行的
Redis、EhCache、MongoDB等新知识。● 第10章详细讲解电商系统的开发，项目本身比较简单，最大的
亮点是集成了支付接口，以帮助读者应对近些年来不同公司对程
序员提出的需要有支付经验的痛点，帮Java架构师丰富知识，提
高技能。未来做支付是必备的经验，但很多公司的项目并没有提
供这样的机会。● 第11章提出产品思维的概念，以此作为架构师的必备常识，旨
在帮助架构师理解和建立产品思维，以方便在项目开发的同时设
计出良好的产品雏形。与此同时，在管理系统中集成了
Bootstrap和ECharts报表，以实例证明产品化的可行方案。● 第 12 章讲的是项目运维，包含 Java架构师需要具备的项目运维
知识。另外，本章开发了SonarQube代码扫描平台并且初步配置
了Jenkins持续集成，阐述了项目数据的迁移方案，讲述了ETL工
具的使用。目标读者
本书特别适合Java Web领域的开发人员以及刚步入职场的新手。本书通过讲述Java架构师必备的知识技能，让广大读者在原有知识的基础上更上一个台阶，争取早日实现架构师的梦想。
对于架构师的定义，每个人的看法都不尽相同，我结合自己多年的工作经验，也只是大致定义了一个范围，希望可以帮助到别人。读者可以结合自己的实际情况，通过阅读本书，不断地扩展和充实这种范围，以达到自己理想中的境界。“不想当将军的士兵，不是好士兵。”在软件行业中，也似乎有这样一句话：“不想当架构师的程序员，不是好程序员。”虽然这看似是一种调侃，但从学习的角度来说，成为架构师，显然是一个好的目标！人只有在心里有了目标，才会变得更加幸福。
如果你不希望一直停留在Java的初级阶段，想在未来成为架构师，那么本书非常适合用来全面提高自己的开发水平。如果你想转项目经理，那么本书同样适合你，因为书中的每个项目都是完整的迭代过程。
本书以项目为驱动，是非常科学的学习方法。读者需要自行下载源码，自己搭建环境，对照章节中讲解的过程，逐步深入地学习Java技术。一个项目的代码量多得超乎想象，如果读者从第一行代码开始就要逐个阅读和编写，那么等学习完这个项目可能就需要一年的时间。因此，本书合理地安排了章节，科学地封装了技术知识，让读者在轻松的氛围下对照源码即可完成技术水平的提升，这不得不说是一个创新！相信大家在阅读本书后，都能够学习到“干货”，极大地提高自己的Java水平，达到架构师的高度。致谢
本书得以顺利出版，离不开我自己多年来的努力。正是因为我有作为Java架构师的觉悟，才让自己在平时从未停下脚步，并且积极学习。不论是在工作中还是在业余生活中，我都会认真总结、分析近年来Java技术领域的知识。所谓学习的诀窍，对每个人都是一样的，就是不停耕耘、努力奋进，在这个过程中，我们总会收获良多。另外，还要感谢家人、朋友对我的帮助，感谢人民邮电出版社和杨海玲编辑对我的信任和支持。
由于水平有限，书中难免有不足之处，恳请专家和读者批评指正。欢迎读者通过电子邮件（453621515@qq.com）与我交流。资源与支持
本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关资源和后续服务。配套资源
本书提供如下资源：● 本书源代码；● 书中彩图文件。
要获得以上配套资源，请在异步社区本书页面中点击，跳转到下载界面，按提示进行操作即可。注意：为保证购书读者的权益，该操作会给出相关提示，要求输入提取码进行验证。提交勘误
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，点击“提交勘误”，输入勘误信息，点击“提交”按钮即可。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。与我们联系
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线提交投稿（直接访问www.epubit.com/selfpublish/submission即可）。
如果您是学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。关于异步社区和异步图书“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近30年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。异步社区微信服务号第1章 编程基础
程序员到架构师的进阶之路是非常艰辛和漫长的，不但需要掌握很多高级的知识技能，还需要有过硬的基础知识。本章主要介绍Java程序员走向架构师的基础知识，还有开发环境的搭建。通过本章的学习，读者可以大致了解程序员的进阶之路，也可更加深刻地认识到程序员的发展方向。1.1 程序员进阶
大学毕业后，初出茅庐的菜鸟经过千辛万苦，总算是找到了人生中的第一份工作。但是，随着工作的开展，菜鸟所面对的问题越来越多。有些人坚持了下来，有些人中途放弃，有些人则在职业生涯中选择了转型。作为一名程序员，不但需要编写大量的代码，还需要对自己的职业生涯做一个规划。结合前辈们所走过的道路，这个职业规划大致是图1-1所示的这个样子。图1-1 程序员职业生涯
一般来说，从初级程序员到高级程序员需要经过5年的磨砺，这个时间段基本上是业界的共识了。而且，在众多招聘信息中也可以发现程序员的起点都是需要两年工作经验的。也许，有些天赋异禀的程序员可能经过3年的刻苦学习也能达到高级阶段，但是，他们的知识技能往往并不全面，可能只是在某些方面比较熟悉罢了。到了高级程序员的阶段，可供选择的方案就比较多了，大概有图1-2所示的这3个走向。图1-2 程序员发展方向
如果高级程序员再向上进阶的话，会面临3个选择。第一种方案是成为项目经理，负责管理加上部分开发。因为高级程序员对公司的项目是非常了解的，对公司目前的开发过程也驾轻就熟。如果本人有这方面的意愿，很容易胜任项目经理这个角色。而且，公司通常会从内部选择项目经理，空降项目经理的方式并不是常态，归其原因就是难以熟悉项目架构。
第二种方案是高级程序员可能更喜欢专著于技术，不喜欢出差和撰写大量的项目文档。在这种情况下，他可以成为一名架构师，专门负责维护公司的项目、产品方面的架构工作。如果公司有一定的规模，他可能会成为研发平台的负责人。当然，这种情况的前提是该程序员没有跳槽。
第三种方案是高级程序员可能经历了若干年的开发后，对写代码已经深恶痛绝，丝毫感受不到任何快乐了，但他对公司的项目和产品又非常熟悉，也有深厚的研发积累。在这种情况下，他可以彻底转型成为一名产品经理，纯粹负责公司产品的规划、设计、包装，甚至肩负一定的市场职责。当然，成为产品经理的前提是公司的项目已经产品化或者正在产品化之中。所谓的产品经理，通常就是向技术部提出一个原型设计：“看吧，这就是我想要的东西，至于怎么实现，你们看着办！”如果他懂代码还好说，但如果不懂代码，可能会让程序员陷入抓狂状态！
到了高级程序员的阶段，很多人就开始思考：究竟是去做项目经理？产品经理？还是继续写代码成为优秀的架构师呢？每个人的想法是不一样的，所作出的选择也是不一样的，这跟自己的能力和性格也有一定的关系。● 项目经理：在大型公司里，主要起协调资源的作用，再往上还有
项目集经理。而在一些中小型公司里，项目经理不但要做好管理，
还要兼备一部分代码的开发工作，但与此同时，也会有5年经验
左右的项目组长，来管理不同的项目组。在软件行业中，经常有
这样一个争论，项目经理到底应该不应该写代码？支持和反对的
人都很多，但作者认为，这也是仁者见仁、智者见智的事情。首
先，项目经理自身也是资源，是资源就有消耗，有些老板可能会
认为：“我花这么多钱，请一个项目经理过来只为了写写文档，
是不是太亏本了？”但到了数万人的大公司，该公司的项目通常
特别多，就需要项目经理非常专注地管理项目，而不是分心去写
代码。这种情况下，老板的思路就会转变，你写什么代码？好好
地管理好公司的项目，不让它出乱子就可以了。● 产品经理：一般则是公司已经将项目过渡到了产品后，才能发挥
更大的作用。如果公司一开始只有项目，则需要大量的时间来积
累，最终实现产品化。在这个过程中，往往不是很需要专职的产
品经理，可能项目中的每个人都会对项目献计献策，来使项目更
加通用化。产品经理自身也是需要积累的，如果他成功地设计了
一款App，并且在市场上取得了极大的成功，那么他的职业生涯
可能会因此镀金，这个App将会成为他能力的体现。● 架构师：专注于公司的研发平台，管理框架方面的东西。例如，
写核心代码，并且指导底下的开发人员合理地编码，维护代码库。
在小公司里可能只有一两名架构师，但是在数万人的公司里，架
构师会非常多。在这种情况下，架构师有可能会成为程序员级别
称谓。例如，你在该公司待了8年，虽然你干的活一直是普通研
发，并不负责实际上的架构，但是公司有正常的晋升渠道，你的
级别就会从高级软件工程师上升到软件架构师。这种情况，在外
包公司比较常见。● 全栈工程师：是最近才兴起的一个概念，但全栈工程师说到底还
是程序员，类似于高级开发的角色，只不过是懂的东西比较多，
前端和后端都可以做，技术比较全面。全栈工程师极大地拓展了
自己的开发技能，成为了项目中的骨干成员，类似于技术专家的
角色。一般而言，小公司比较喜欢这样的人，招募一个可以顶3
个。但从学习的角度来说，全栈依然是不错的目标。因为只有成
了全栈工程师，才更能接近架构师。
每种开发语言，都有自己领域的架构师，如C++架构师、PHP架构师，当然也有Java架构师了。架构师需要对公司的整个研发平台了如指掌，清楚平台中细枝末节的东西。他极有可能是陪伴着这个公司成长起来的程序员；也极有可能是在别的公司工作多年后跳槽过来的。前者对公司的项目、产品非常熟悉，甚至自己还动手写过业务层。后者可能只是从大体上了解公司的研发平台，毫不深入，但这并不影响他的发挥，真正的架构师看到代码就有一种亲切感，可以很容易分析出隐藏在代码前后的业务过程。
Java架构师，至少需要在Java领域有5年的开发经验。他需要掌握的内容很多，简单点可以分为前端、后端、数据库、服务器、中间件等。前端插件可以极大地提高开发效率，甚至在不需要美工的情况下做出时尚的界面，类似的插件有AngularJS、Avalon、Bootstrap、ExtJS、jQuery EasyUI、jQuery UI等，这些前端插件也可以称作前端组件或者前端框架，种种叫法也看人的习惯了，没必要吹毛求疵。除了这些前端插件外，还需要掌握JavaScript、HTML等技能。后端需要掌握的技能主要是Java、JVM、Servlet、Struts、Spring、Hibernate、MyBatis等，还有最近流行起来的Spring MVC、Spring Boot等。这些技能和框架只有综合起来使用，并且合理地搭配才能发挥出最好的效果。至于效果能够达到什么程度就需要看架构师的本事了。也许有的架构师可以把这个积木撘得很好，也许有的架构师在搭积木的过程中，这个积木就倒下了。数据库方面需要掌握的内容有Oracle、MySQL、SQL Server，一般常用的数据库大概就是这3个。当然近年来，对于架构师需要掌握的数据库又有所增加，它们主要是代表了NoSQL的MongoDB等区别于传统关系型的数据库。但是，数据库相关的内容有不少，例如，需要熟练掌握SQL的各种语法，还需要掌握数据库性能的调优、备份和恢复。服务器并不是重点，但作为Java架构师，仍然需要有所了解。服务器包括物理服务器、云服务器，还有Web服务器，包括我们在开发中使用的Tomcat。中间件在一些中小型项目中并不怎么常用，如EJB技术、消息中间件ActiveMQ。当然，Web服务器也可以算作中间件，如Tomcat、Weblogic、WebShpere和JBoss等。
只有熟练掌这几个方面的技能后，才能算是一个初级架构师。如果想成为大神级别的架构师，还需要学习更多的知识。Java架构师需要对这些技能非常熟悉，并且能像搭积木一样把他们整合在一起，构建出成熟的、完整的软件开发平台，以供底下的程序员在此基础上进行业务层的开发。但是，随着软件技术日新月异地发展，越来越多的框架进入眼帘，这对于我们来说既是好处又是坏处。好处是我们可以选择更好的、更合适的框架来提高项目的性能，降低开发难度，简化开发流程。坏处是可选择的框架太多，以至于让我们难以选择。所以，本书为大家精心挑选出了一名合格的架构师所必备的专业技能和开发思想，以供大家学习和参考，争取尽早地成为Java架构师。1.2 选择开发工具
孔子曰：“工欲善其事，必先利其器。”这是一个千古不变的哲理，工匠想要使他的工作做好，一定要先让工具锋利，这样才能发挥出最大的效率。这个哲理告诉我们，不管做什么事情，都要选择合适的工具。那么在软件开发的道路上，选择一个合适的开发工具也是极其重要的事情了。Java的开发工具有几种，这里不做太多的赘述，我们只需要对比它们的特点，即可从中选择出一款最适合自己的。
Java中常用的开发工具有NetBeans、JBuilder、Eclipse、MyEclipse、IntelliJ IDEA等。其中，NetBeans是Sun公司开发的，JBuilder是Borland公司开发的，这两个开发工具的功能和界面跟我们常用的Eclipse是没有很大的区别的，之所以在市场占有率方面输给Eclipse，完全是因为细节方面做得不好，还有在用户感知方面不太好。曾经有网友也在社区里面说过这样的问题，我尝试使用过NetBeans或者JBuilder，但总是因为个人习惯的原因没有坚持下来。可能Eclipse是大多数人接触的第一款开发工具吧，这种先入为主的感觉会一直伴随着我们。
Eclipse是完全免费和开源的，它的功能非常强大，开发起来也很顺手。MyEclipse是在Eclipse的基础上加上了自己的插件后的企业级集成开发环境，尤其善于开发Java、Java EE方面的项目。于是，在市场占有率方面Eclipse和MyEclipse非常高，这也在另一方面促进了它们的发展。这两者其实是一个核心，所以选择哪一个都看自己的习惯了。IntelliJ IDEA是Java开发的集成环境，在业界被公认为最好的Java开发工具之一，尤其在代码提示、重构、J2EE支持等方面非常强大。其中有一点对程序员的帮助非常大，就是调试功能，此外在某些细节方面似乎比Eclipse做得更好。而且，IntelliJ IDEA与GIT结合得非常好，而Eclipse与SVN结合得非常好。时间久了，这一开发工具与版本控制工具相结合的特点，也渐渐被程序员们认可，甚至成了项目选择开发工具的一种参考。
举个例子，如果A项目列入了开发计划，为了保持大家代码的一致性，可能项目组内会统一使用开发工具。如何选择呢？如果，这个项目使用SVN来管理代码，那么大家就会优先使用Eclipse；如果使用GIT管理代码，那么大家就会优先使用IntelliJ IDEA。当然，这似乎只是一种约定俗成的参考，并不是硬性要求。
在接下来的学习中，我们以MyEclipse和Eclipse为主来开发项目，并且会讲述SVN和GIT的不同，让大家在以后的工作中更加灵活地搭配开发工具和版本控制工具的组合。至于IntelliJ IDEA，因为它的入手门槛确实有点高，而且一旦选定，后面对于代码的重构会非常麻烦（指Eclipse和IntelliJ IDEA之间），所以本书暂不做相应的讲解。
另外，本书还会使用Eclipse相对较新的版本来做一些练习。其中，MyEclipse的版本是10.7，Eclipse的版本是Kepler，IntelliJ IDEA的版本是2016。SVN和GIT的版本带来的差别并不大，所以并不对版本做具体的规定，MyEclipse10.7的界面如图1-3所示。图1-3 MyEclipse 10.7的界面
Eclipse Kepler的界面如图1-4所示。图1-4 Eclipse Kepler的界面
IntelliJ IDEA 2016的界面如图1-5所示。图1-5 IntelliJ IDEA 2016的界面1.3 安装JDK
JDK是Java开发的核心，包含了Java运行环境、工具、基础类库。如果没有JDK，Java开发是无法进行的，Java项目也无法运行起来。所以要做任何项目的开发，第一件事情就是安装好JDK。接下来，我们才可以做更多的事情。
通常来说，每一个开发工具都会携带JDK，例如，MyEclipse 10.7自带的Sun JDK 1.6.0_13，但是IntelliJ IDEA并没有携带，需要自行配置。鉴于这种情况，我们在安装完开发工具后紧接着就应该安装合适的JDK。使用MyEclipse 10.7自带的JDK也可以完成日常的开发，但这款JDK没有进行环境变量的设置，可能在后续的开发中会有影响，而且这款JDK是混杂在MyEclipse 10.7的安装目录下的，给人的直观感觉不太好。为此，我们需要单独安装一款JDK，而说到安装JDK，就不免要选择合适的版本。目前，JDK版本已经到了8，但是因为历史原因，使用JDK 8来开发项目的公司并不多，第一个吃螃蟹的人会有惊喜也有潜在的风险。使用JDK7也是个不错的选择，但是因为本书中所涉及的项目众多，为了项目的稳定性，还有学习的顺序性，我们仍然使用久经历史验证的JDK 1.6版本，也可以称作JDK 6，对于这个名称不用纠结，是因为历史原因造成的。JDK 1.6以上的版本才正式改变了叫法，如JDK 7，也有开发人员习惯叫它JDK 1.7。读者可以在JDK 1.6版本下熟练掌握本书的内容后，自行更用更高级的版本来测试程序的运行性能和代码编译方面的不同。因为本书的主旨是讲述常规的技术，所以对于JDK的新特性并没有过多讲解。
首先，需要在Oracle官方网站下载JDK 6。因为Oracle官网经常更新，具体的地址也会经常改变，很难有一个确切的下载地址。但是，在Oracle官网可以找到Downloads的菜单，基本上Oracle公司所有的产品都可以在这里找到。另一种方法是可以在其他的网站下载JDK 6，例如，国内的一些网站，下载起来速度也相对比较快，Oracle官网下载JDK如图1-6所示。图1-6 Oracle官网下载JDK
下载完JDK6之后，最好将它安装在非系统盘里。接着，需要对刚才安装好的JDK进行环境变量的设置，以方便我们在DOS系统下使用JDK命令。例如，最常用的编译命令javac，显示JDK版本的命令java -version，这些命令的使用都依赖于环境变量的配置。如果没有配置，是不会生效的。
首先，打开Windows的环境变量界面，新建系统变量JAVA_HOME和CLASSPATH。编辑JAVA_HOME变量，在变量值里输入JDK6的安装地址，如D:\Program Files\Java\jdk1.6.0_43，点击“确定”保存。接着，编辑CLASSPATH变量，在变量值里输入%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.jar，点击确定保存。最后，选择系统变量名为Path的环境变量，在原有变量值的基础上追加%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin，点击“确定”保存，添加环境变量的界面如图1-7所示。图1-7 Windows环境变量设置界面
为了验证Java环境变量是否设置成功，可以运行CMD程序，打开Windows的命令行模式，输入java -version命令，如果环境变量设置成功，会在下面输出当前的JDK版本号以及JDK位数，正确的输出结果如图1-8所示。图1-8 命令行模式下输出JDK版本
配置好了环境变量，还需要在MyEclipse 10.7中配置JDK，使其可以在开发工具中使用。打开MyEclipse 10.7，在Preferences菜单中的Java选项下找到Installed JREs选项，就可以看到当前工作空间中的JDK设置，MyEclipse 10.7默认自带一个JDK6，如图1-9所示。图1-9 MyEclipse10.7自带的JDK6
点击Add按钮，在弹出的Add JRE对话框中选择Standard VM点击Next按钮进入下一步，在弹出的对话框中点击Directory按钮，选择JDK6的安装目录，点击确定。对话框会自动识别出JDK的相关信息，并且在JRE system libraries列表框中显示出来，如图1-10所示。图1-10 MyEclipse 10.7中设置JDK6
点击Finish按钮完成设置。这时，MyEclipse 10.7会自动回到Installed JREs对话框中，刚才的列表中会多出一栏我们刚刚设置好的JDK选项，在勾选框中选择它点击OK。至此，MyEclipse10.7下的JDK设置就成功了，在以后的开发工作中，我们全依赖这个JDK提供的基础JAR包来开发和运行项目。1.4 安装Tomcat服务器
安装好了JDK，我们就可以在MyEclipse 10.7中进行一系列代码编写工作了。例如，可以在开发工具中写一些类，做一些练习。普通的包含main函数的Java类，我们可以通过Run As菜单下的Java Application命令来运行，输出程序结果。例如，可以在MyEclipse 10.7下新建一个Java Web工程practise。具体的过程如下，选择File菜单下的New选项，在弹出的右侧菜单中选择Web Project，在对话框的Project Name文本框中输入practise，将J2EE Specification Level选项设置为Java EE 6.0，和安装的JDK保持一致，点击Finish按钮，practise项目就建立好了。
选中practise项目的src目录，右键选择新建Package，在对话框的Name文本框中输入com.manage.practise，点击Finish，就可以给这个项目建立一个空包。接下来，就可以在这个空包里新建类。选中Java包，右键选择New菜单下的Class，在弹出的对话框中在Name处输入类名Test，并且勾选public static void main(String[] args)，点击Finish。这样，在practise包下的第一个类Test就建立成功了。打开Test类，在main函数中输入第一行Java语句System. out.println("Hello World");，使用Java Application来运行。此时，控制台会在空白区域输出Hello World。理论上来说，我们的第一个Java程序就这样诞生了，尽管这个程序非常简单！
如果只是在MyEclipse 10.7下安装了JDK，这款开发工具能做的事情无非是编写类，利用Java Application来运行，并且进行程序的测试。在这种情况下，我们的代码中所设定的数值均是由自己输入的参数；然后再根据程序中的处理逻辑，做一些简单的运算；最后，输出正确的结果。可是，程序开发远远不是这么简单的事情，我们需要做的是开发一个具有交互能力的项目，而不仅仅是写一段简单的程序。要达成这个目标，我们就必须在MyEclipse 10.7安装Web服务器来运行项目。在这里，我们选择使用Tomcat服务器，这是因为Tomcat服务器具有简单、易用的优点。
首先，打开Apache的官方网站，在下载Tomcat 6.0的页面找到对应的软件，在Core列表中选择64-bit Windows zip的版本，将Tomcat 6.0保存到本地，并且解压缩到本地的非系统盘内，如E盘的根目录。下载Tomcat 6.0如图1-11所示。图1-11 下载Tomcat 6.0
打开MyEclipse 10.7的Preferences对话框，在MyEclipse的列表中选择Servers，这时，会出现一个列表，列出MyEclipse 10.7支持的服务器。选择Tomcat，再选择Tomcat 6.x。这时，对话框右侧会出现Tomcat 6.x的配置项，选择Enable，启用Tomcat 6.x。点击Tomcat home directory对应的Browse按钮，在弹出的磁盘目录列表中选择Tomcat 6.0所在的位置，MyEclipse 10.7会自动补齐其他的两处空白，点击OK按钮，Tomcat 6.0服务器就配置好了。
我们通过工具栏运行Tomcat 6.0，启动成功后，点击工具栏的Open MyEclipse Web Browser功能的图标，在地址栏中输入http://localhost:8080/，就可以看到Tomcat 6.0运行成功的画面。接下来，就可以通过在Tomcat服务器里部署Web项目来进行正式地编码工作了，运行界面如图1-12所示。图1-12 Tomcat 6.0运行成功1.5 Hello World程序
完成了前面几节的配置，MyEclipse 10.7 的开发环境已经正式配置成功了。这时，我们可以在MyEclipse10.7下完成第一个Hello World程序来结束本章的学习。
在MyEclipse 10.7的界面中，我们可以看到Package Explorer视图下有一个Java Web项目practise，这个项目是之前创建好的，并且在包里建立了一个Test类。我们通过运行该类，可以在控制台里输出了Hello World，说明这个类没有问题。但是，这种简单的编码没有交互性，是不能满足项目的需求的。如果要开发一个项目，必须让其在Tomcat服务器里运行，才能起到交互的作用。那么我们可以把practise项目部署到Tomcat服务器里试试效果。
选中practise项目，右键弹出功能菜单选择MyEclipse，在弹出的右侧菜单中选择Add and Remove Project Deployments功能，在弹出的对话框中可以看到Deployments列表中为空，说明Tomcat服务器里并没有部署任何项目。这时，我们点击Add按钮，在Server下拉框中选择Tomcat 6.x，点击Finish，把practise项目正式部署到Tomcat服务器中。部署好的practise项目如图1-13所示。图1-13 部署好的practise项目
这时，我们启动Tomcat服务器就会自动加载部署到服务器里的practise项目。通过控制台，可以看到服务器的启动日志，如果没有报错的话，说明practise项目没有编译错误，那么Tomcat服务器启动成功。打开IE浏览器，在地址栏中输入http://localhost:8080进行访问，可以看到程序运行成功，但显示的仍然是Tomcat服务器的默认页面，这是因为我们没有输入项目名称。
打开practise项目的WebRoot文件夹下的index.jsp文件，把title标签里的内容修改成First Page，把body标签里的内容修改成Hello World，保存index.jsp文件。再次打开IE浏览器，访问http://localhost: 8080/practise，可以看到页面上已经发生了变化，如图1-14所示。图1-14 practise项目运行1.6 小结
本章我们全面阐述了程序员的职业发展规划，从而为广大读者提供一个晋级的参考。从程序员到项目经理、产品经理、架构师的过程至少需要5年。这5年是一个学习期，5年后就可以进行转型了。所以，建议大家在工作的前5年不要频繁跳槽，还是需要系统地掌握知识技能，积累经验才是硬道理。频繁跳槽不但让自己的知识会出现断层，也可能影响到自己在HR心中的形象。
接着介绍了Java开发中常用的工具，并且做了简单的对比，相信读者可以根据自己的喜好选择其中的一款。因为本书主要采用MyEclipse 10.7作为开发工具，所以读者最好先使用这款开发工具，其他的工具会在后面的章节中介绍。等对这些工具驾轻就熟的时候，再随意切换。每个开发工具都有自己的优缺点，但不要人云亦云，选择自己最习惯用的才是最好的。最后介绍了安装JDK、Tomcat服务器的过程，并且开发了第一个Hello World程序。如果读者已经牢牢掌握了本章的内容，这就是万里长征迈出了坚实的第一步，相信在以后的学习当中大家的收获会更多。第2章 需求调研
也许有人会有这样的疑问，需求调研是项目经理的事情，为什么需要架构师来参与呢？这种说法虽有一定的道理但也不完全正确。因为在不同规模的企业中，架构师和高级开发人员都是有可能去客户现场调研的。通常，他们会跟项目经理一起过去，针对客户的需求，从专业的技术方面提出建设性的意见。另外，如果去客户现场调研的是纯管理的项目经理，他可能会把业务方面阐述得非常清楚，但如果对方提出技术问题的话，项目经理也许会被当场问住。这种情况下，就需要有一个架构师或者高级开发人员在场，及时地从技术的角度来分析问题给出答案，这在需求调研方面起到了一个互补的作用。2.1 搭建关系
A 公司开发了一套企业管理系统，已经基本上趋于成熟，可以进行大规模销售了。于是，A 公司开发了一个官方网站，将这款产品挂在了网上，希望以此开拓互联网市场。通过网络卖出了几套产品之后，A 公司接到了一个客户的电话，希望他们对这款企业管理系统进行定制化开发。如果这次开发顺利的话，后续还会有其他方面的合作。
公司高层对此十分重视，如果能把这个大客户的项目做好，对于公司的发展将会非常有益。于是，A 公司派出了销售经理带着几个人的团队，亲自飞往客户现场沟通需求、搭建关系。因为企业管理系统的功能比较简单，前去出差的售前工程师的经验也比较丰富，所以此次出差并没有技术人员参与。销售团队在客户现场与客户进行了多次沟通，并且主动请客户吃饭，参加各类活动联络感情，增进彼此之间的关系。
果然，功夫不负有心人！在一种融洽和谐的关系之中，双方对企业管理系统的项目达成了很多共识。B 公司的规模很大，他们急需一款企业管理系统来对公司的资源进行实时查看。例如，销售部需要查看一些市场信息，若干员工的业绩等；人事部需要通过查看最近几个月离职的员工情况来做一些统计等。总之，不同部门都有这方面的需求。但是，A 公司的企业管理系统只能满足他们的部分需求，涉及具体部门的报表展现还需要进行定制化开发，从 B 公司的数据库里读取信息。因为A 公司的企业管理系统跟B 公司的需求有很大的匹配度，B 公司根据市场价格、人力成本等多方面考虑之后，才决定委托A 公司进行定制化开发，这无疑是一件对于双方都有好处的事情。A 公司有这样的产品，而B 公司有这样的需求，两者碰在一起，才能产生经济价值。针对 B 公司提出的增加定制化报表的需求，A 公司售前工程师对此进行了专业的回答，当场承诺可以满足这方面的需求，且技术难度不大。于是，没过多久A 公司的销售团队就带着丰硕的成功回来了。2.2 正式立项
B 公司的领导在会议上进行了多方面的讨论，充分审阅了各部门汇总的“企业管理系统采购需求”，研究了采购部门提供的“可行性研究报告”，又综合分析了市场，参考了 A 公司提供的相关文档，认真评估了采购预算。最终，仍然觉得该项目不需要招标，直接让A 公司开发是最好的选择。当然，B 公司能够如此爽快地立项成功，也与A 公司的销售在前期的努力是分不开的。正是因为销售巧妙地拓展了关系，并且售前工程师以丰富的专业知识打动了客户，拍胸脯保证了该项目的可行性，才让该项目在会议上如此顺利地立项，并且是以直接采购的形式。
当听到这个振奋人心的消息之后，A 公司的员工欢呼雀跃。与此同时，A 公司派出客户经理又一次飞往客户现场，与B 公司的采购部门主管签订了正式的采购合同，并且规定了开发细则。其实，对于立项来说是有两层含义的，B 公司采购管理系统有一个立项过程；同样的，A 公司如果有一套自己的规章制度的话，也需要走一个立项流程。比较典型的做法是，A 公司的项目经理可以在公司的网站中提出立项申请的工作流，由上级领导逐级审批，最终立项申请获得通过。当然，这只是一种可供参考的做法。2.3 需求调研
合同签订后，B 公司积极履行合同，在规定的时间内为A 公司支付了项目的预付款。A 公司整合了技术部的资源，正式成立了“企业管理系统定制化开发项目组”，并且制定了“项目章程”。该项目组由一名项目经理、一名架构师、两名高级研发人员、一名初级研发人员组成。本来，该项目组并不需要架构师参与，但考虑到平台的扩展性，最终决定还是要有一名架构师参与其中。
因为B 公司的企业管理系统属于定制化开发，要在A 公司原有产品的基础上加入很多新的需求，所以在正式进行开发之前必须要去客户现场调研。为此，A 公司成立了需求调研组，由项目经理亲自带队，带着架构师和一名高级研发成员过去，为了方便和干系人联系，调研组又加入了一名之前去过客户现场的销售人员。
B 公司对企业管理系统的定制化开发非常重视，在进行正式调研之前，B 公司副总将各部门领导和A 公司调研组召集在一起，专门开了一个调研启动会，号召B 公司各部门积极配合A 公司调研小组的工作，并且规定了各部门的相关责任人，争取这个项目能够圆满取得成功。B 公司调研小组感谢了这位副总，并且主动请副总吃饭，席间大家对这个项目进行了多方面的讨论。回到宾馆，B 公司调研小组都觉得这个项目开展得非常顺利，这一切不但归功于自己的产品，还要感谢销售人员前期的铺垫。正是这种铺垫，为两个公司之间搭起了桥梁，营造了很融洽的合作关系。
调研的第一天，项目经理进行了干系人的优先级排序。首先，他们决定去拜访人事部的主管，针对企业管理系统的组织架构方面的需求做一个详细的沟通。人事部主管查看了调研小组制作的项目原型，认为项目经理阐述的功能已经符合了人事部的需求。于是，双方对此达成了一致，人事部主管签署了需求确认书。
调研的第二天，项目经理决定带队去销售部，针对业务部门关注的报表功能进行详细地询问、记录，力争做到没有疏忽和遗漏。销售部主管拿来了一堆指标文件，对调研小组说，“我们现在给领导汇报工作的时候，都拿着这些纸质的文件，总觉得不是很方便。因为领导现在提出了新的要求，他想实时地、动态地查看最新的销售业绩，这无疑给了我们部门很大的压力。还好现在要上这个企业管理系统了，只要你们将领导要看的这些报表，从我们的机房数据库里提取出来，展示在系统中就起到了很大的作用。领导不用经常让我们去打印文件了，我们也不用再过多的关注这些事情，能更加专注于市场营销方面了。”听了这个无纸化办公的理念，项目经理从内心里庆幸，还好我们在这方面有了足够的积累。虽然，这方面的报表并没有做很多，但至少是做了几个演示（demo），开发起来难度不大。于是，项目经理自信地承诺了这个功能可以实现。接着，调研小组去了其他的部门，对其他部门的需求进行了沟通。当客户表现出对技术方面的担忧之时，架构师就积极地站出来，用专业的知识来回答客户的问题，打消了客户的顾虑。因此，整个调研过程也一帆风顺。
调研的第三天，项目经理带队去了B公司的运维部。因为这个项目是需要部署在B公司的机房的。所以很有必要对B公司的部署环境做一个充分的了解。经过了一段时间的沟通，B公司运维部的主管表示，“我们这里有Windows服务器，也有Linux服务器，具体的部署看你们的项目情况了，我们不做硬性要求，只要你们的项目稳定即可。”听到这样的回答后，项目经理总算是完全放心了。这个项目，不是棘手的那种，做起来应该会很顺利。回到宾馆，项目经理组织调研小组，进行了一个简单的头脑风暴，确定了此次出差调研没有遗留的问题后就决定了返程。
需求确认书：在进行需求调研的过程中，很有必要对客户所提出的需求做一个梳理，并且以文档的形式输出。然后，项目经理需要拿着这份需求确认书，找相关的客户进行反复地确认，最终在达成一致的情况下签署需求确认书。需求确认书在项目的整个过程中是至关重要的，因为，不管客户说过什么，只要没有正式书面的文档，客户就很有可能说自己忘记了，或者反复地进行需求变更。这种情况，会让项目陷入被动之中，为项目埋下隐患。也许最后按照客户原来的意思把需求都实现了，但客户予以否认，说这不是我想要的东西，此时就需要拿出需求确认书与之过目。2.4 输出文档
调研结束后，项目经理并没有急着组织开发，而是静下心来思考了整个调研过程。他认为，客户规定的开发周期是半年，这个时间对于当前的人力、成本来说都是可控的范围。所以，不必为工期过多地担心，而是要在前期做好足够的准备工作。目前，项目的启动过程组的内容已经完成，接下来就是要处理好规划过程组的事情，才可以进入软件的开发阶段。
于是，项目经理布置了任务，让此次参与调研的同事们撰写出差总结，并且决定输出用户需求说明书、概要设计说明书、干系人登记册、项目管理计划。这些文档主要是项目经理撰写，但涉及技术方面的问题时，项目经理仍然需要参考开发人员的建议。因为文档太多，项目经理也可以请开发人员负责一部分文档的输出。国内的软件项目，大多都因为成本或者是企业文化方面的原因，在撰写项目文档方面做得良莠不齐。大多数中小型公司甚至没有很好的文档计划，他们接到项目就会迅速地步入开发阶段（执行过程组），这看似可以节省成本，但实际上会为项目埋下很多隐患，到头来导致频繁地返工，或与客户在需求方面的问题争论不休，最坏的结果就是项目迅速开发、迅速结束。反之，如果从项目开始阶段就注重文档方面的输出，为撰写文档留出一定的时间（把这部分时间当作项目成本），这样整个项目计划会有条不紊地进行，就算项目出现了问题，也可以很快地找到补救的方法。
项目管理专业人士资格认证（Project Management Professional，PMP）中有一个经典的理论是项目的渐进明细。把这个理论扩展一下，就是说项目中充满了渐进明细的内容，不论是整个项目还是项目的组成部分，如项目管理计划、项目范围、项目目标等。同样的，项目经理只有与干系人进行持续地、有效地沟通，再加深自己对项目的理解，这种渐进明细才可以达到。否则，什么内容都停留在项目的初期调研阶段的话，将发生不可预料的风险。这时候，输出文档就是一个很好的选择了，它可以保证调研的内容得到二次的梳理，让项目成员明确需求，还可以在项目组成员的讨论中产生渐进明细的效果。因为，项目的需求、可交付成果都是暂时不可见的，没有人能精确地预料它的结果（除非对某种项目特别熟悉，形成了某种模式）。在这种眼前一摸黑的情况下，输出文档可以产生渐进明细的效果，大家群策群力也可以完善风险登记册的内容，对风险的发生概率、影响、级别、应对策略、预防措施等进行讨论。另外，完善的项目文档最终会转变为组织过程资产，由项目管理部（Project Management Office，PMO）进行统一管理，也是对公司的未来发展大有裨益。
这时，我可以举几个典型的例子，应用场景是项目经理水平靠谱，在与客户进行着有效地持续地沟通。注意，与干系人的沟通会贯穿整个项目开发的完整过程，不要以为拿到了用户需求确认书就可以万事大吉了，需求总是需要反复解读和确认的。
第一个场景是客户总是想变更需求，这种变更可能是好的也可能是坏的。如果没有完整的项目文档，不论是客户还是项目组，都很难对这个需求进行变更。因为在这种情况下，客户和项目组都没有可供参考的文档，无法合理估计成本和风险，这就不能按照正确的流程处理变更。如果项目经理凭借自身经验认为可以接受变更，那么因为经验不足导致的不利结果就会由公司承担；如果项目经理以成本或者风险为由拒绝变更，客户可能会让项目经理拿出相应的数据，这时文档的价值就显得极为重要。从记录变更请求、分析影响、提交CCB进行审批、批准或者拒绝，到通知干系人，这个完整的过程都离不开项目文档的参考。
第二个场景是项目的风险应对，包括来自整个项目中各个方面的风险。项目的风险管理包括了规划风险管理、识别风险、实施定性风险分析、实施定量风险分析、规划风险应对、控制风险。虽然，PMP对风险提出的这几个过程看似比较繁杂，但放到具体的项目中还是很简单的。因为，对项目风险的管理可以总结成一句话，“对项目的风险进行有效性管理。”不过，要做到这句话就需要有选择地实施那几个过程，但实施这几个过程就需要参考项目中产生的所有与之相关的文档。例如，常见的项目管理计划、项目章程、干系人登记册、风险管理计划、成本管理计划、进度管理计划、质量管理计划等，只有参考这些文档，才能通过分析技术、专家判断、会议、文档审查、假设分析、SWOT分析、风险分类、风险审计等工具与技术，继续输出和完善我们认为极有价值的文档，如风险管理计划、风险登记册、工作绩效信息等。这些文档凝结了项目组成员的智慧，可以有效地应对项目风险，保障项目的安全进行。
第三个场景是PMO对项目的帮助。首先，明确两个概念，组织过程资产和事业环境因素。
试读结束[说明：试读内容隐藏了图片]