这三个要素是环环相扣 的,任何一项要素的成败都会影响另外两个要素,而每个要素也都足以影响一个项目的成败。如何取得这三者的平衡,并将每个要素充份的发挥,取决于管理者的经验,与相关开发人员的素质,这不是一项简单容易的任务,但有好的方法可以完成。
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 ),边写边设计,且战且走不行吗?对于小型系统,或是没有营运压力系统而言,是可以的。若果是人力不足、预算有限、结案期限已在眼前,当然也该直接动工。
但依我接触过案子经验的深刻体验,宁愿花费较长时间与心力,在项目初期就先详细规划,才可节省后期开发的时间,系统上线后也更容易维护与扩充。虽然耕耘过程会较辛苦,但所得好处也会是倍增的。