你我的生活周遭已处处可见java;到火星上走走、eBay大采购、网络银行转帐、拿着健保卡到医院看病、无聊时把玩手机上的java游戏…。
在生活中，你通常只知道「喔!原来这网站是用Java写的」、「喔!原来这是手机的Java Game」。若自技术层次拆解，Java Technology可简单区分为Java 程序语言(language)与java 平台(platform)。
Java 程序语言所指是撰写程序所需的语法与词汇，像学习中、英文，有一套基本的单字与语法，只要利用单字组出符合语法的句子，这就是java程序的基础。
至于Java 平台，如大家熟知的，java共分三大平台：J2ME、J2SE和J2EE，分别专精于嵌入式行动平台、标准平台和企业应用平台，除了共同的类别函式库(API)之外，每个平台也有其特定的API，供程序设计师们开发使用。
随着开发工具陆续推出，降低了Java开发技术门坎，要写出正确无误的Java程序不是太难的事情，但论及系统性的java软件开发，那可就不是一件轻松事。
开发大型项目有三项非常重要的因素，将会影响整个项目的进度与质量，分别是人(people)、流程(process)与技术(technology)。
这三个要素是环环相扣的，任何一项要素的成败都会影响另外两个要素，而每个要素也都足以影响一个项目的成败。
如何取得这三者的平衡，并将每个要素充份的发挥，取决于管理者的经验，与相关开发人员的素质，这不是一项简单容易的任务，但有好的方法可以完成。
java弹性多选择资源丰富任君挑选
「技术」应该是最容易掌握的部份，因为你选择了Java。如前所述，全世界已有许多Java资源可以选择。某些人可能会认为java技术门坎高，考虑训练成本而决定导入较为简易的程序语言，如VB.Net，或是不敢转换到java平台。
事实上，真正困难的不是java程序语言或是API的使用，而是整个对象导向程序设计的概念。C#也标榜与Java有着类似的对象导向架构，除执行平台不同、API的名称不同，本质与java可以算是孪生兄妹，怎么没听有人抱怨C#很难学?
既然java、.Net门坎是一样的，那该如何选择?答案是，你喜欢谁就选谁。只是当你决定投靠其中一个阵营时，不妨想想一件事：「在这个平台上，我是不是有选择的空间与自由?」
java是一开放的技术、平台，可执行于各类作业平台，还有各式各样的开发工具、API套件与执行环境，包括商业、免费、开放源码等丰富资源任君挑选。
流程关乎项目预算与时间控制
「程序」指的是软件开发流程或是项目流程，定义流程的目的是要掌控所有的情况。项目的最大敌人是时间及预算，这两者都是有限的，如何在有限预算内准时完成项目，可说是一项艺术。
幸运的是，时间和预算都是可控制的，并不是指我们可以控制时间快慢或长短，而是如何明确知道哪一个时间点，需要何种产出物，而我们有多少的预算可以完成。为有效控制，我们需要一个标准的流程，只要照着规矩走，一切都好办。
RUP(Rational Unified Process)就是一种业界常用的不成文规矩，在多数软件项目中几乎都会使用的一项语言、方法与工具。 RUP的精神在于反复(ITerative)与渐近的(incremental)。
在渐进式的开发过程中，透过不断的提炼(refine)，可趁早发现问题且找出解决方法，也确保每一工作项目的进度。不过，在架构(ArchITecture)方面，RUP确实着墨较少，而架构优劣也是足以影响软件系统成败的关键因素。
QoS(Quality of Service)或是SLR(Service Level Requirement)，我想是每个系统最基本的要求，它包含可用性(Availability)、可管理(Manageability)、可信赖(Reliability)、可扩充(ScalabilITy)和安全性(SecurITy)等条件。
当系统架构进行规划时，就应同步考虑这几项条件。举例而言，先前某家外商银行因系统设计不良而导致外人可轻易猜出参数设定的方式，直接入侵系统窃取消费者隐私数据;也有某家电信业者为没考虑系统的负载量，而导致在耶诞、跨年等重要节日时，涌入大量简讯的尖峰时期造成服务塞车、系统当机。
在电视新闻中，我们常常可见类似的新闻报导，而背后隐藏的意义是，「当初没做好系统架构规划」，看得不够远、想得不够深，等系统开发到一半，或是系统上线后才发现问题，此时再东补西补，为时已晚。
虽说不同的程序技术皆有其满足QoS的方法，相较之下，java对上述五大项功能的支持应该算是最为丰富。如在J2EE的设计模式(Design Pattern)中，几乎都是为解决此几项问题而设计，之后再配合程序语言本身的强固性，开发而成的企业级应用系统，我想应可满足客户对于QoS的严格要求。
话说回头，企业一旦使用java开发一套系统，就一定会是百分百稳定且满足QoS吗?我想，设计模式跟程序语言无关，将J2EE 设计模式作为C#实作的架构，也未尝不可，只要能建构出相同安全稳定的环境执行该系统，都是可行的。就像会说国语，未必可写出漂亮的文章一样，训练、经验再加上一点天份才是最重要的。
专业技术认证可供参考
「人」是项目中最难预料与掌控的一项要素。人可分成两部份，一是客户，二是研发人员。客户是最难掌握的，不同的客户有不同的个性，没有任何人能教导你，如何应付不同的客户，除了靠运气，还要靠经验。
暂不谈客户，先看研发人员这部分。我想，要满足技术与流程两项因素，关键都是人。如何选择对且合适的技术，要有专业人才;如何有效管理流程?如何规划满足AMRSS五项需求的系统架构?这都是需要有经验的管理人才及架构师(archITect)。当然，能不能写出漂亮且可完善运作的程序代码，也是需要有一定水平的研发人员。
开发程序人员的水平是较容易被认证。java有几项专业认证，如SCJP、SCJD、SCWCD，都可用以鉴定开发人员基本的功力。另有SCEA、 SCBCD等认证可评鉴程序架构人员的素质。除专业训练之外，经验也是一位优秀的架构师所应具备的条件，而程序部份其实也有认证，如PMP。
也许你会觉得java很八股，写程序为什么需要一大堆文件、设计模式、程序与方法论(methodology)，边写边设计，且战且走不行吗?对于小型系统，或是没有营运压力系统而言，是可以的。如果是人力不足、预算有限、结案期限已在眼前，当然也该直接动工。
但依我接触过案子经验的深刻体验，宁愿花费较长时间与心力，在项目初期就先详细规划，才可节省后期开发的时间，系统上线后也更容易维护与扩充。虽然耕耘过程会较辛苦，但所得好处也会是倍增的。 |
