「架构」一词意味着什么呢？这个看似学术的名词，其实在我们的日常生活中也常会听到的，例如，文章架构、组织架构、发展架构，它在形容事物的一种风格、组织方式或着决策方向。在这里我们要谈的是软件架构，顾名思义它也是指软件的一种风格、组织方式或着决策方向，不过这样的解释可能不好理解，毕竟软件本身是一个复杂的创意。软件架构的重要，就如同每个人的体质，从身体的最深处，一层一层的影响到外表的美丽。

软件架构杂乱，项目失败风险高
我曾经历过一个经典且传统的软件项目，那是一个旅游网站，旅客可以在网站上透过聪明的航程规画精灵实时地比较机票的价格，然后直接订机票并且在线付款，流程中几乎不用和旅行社的票务人员交涉，除此之外，在那个网站上也可以查到各式旅行信息。

和大部份的软件项目一样，在这个案子里有一位野心勃勃的老板，另外，我们有一些极热心但是拥有模拟脑（完全不懂计算机）的旅游专家──就是票务小姐及票务经理，然后我们需要和信用卡系统及一个世界级，但是稳定度及整合接口是古迹级的票务系统介接，最后还有一群从没搭过飞机，但视加班为进补的程序开发人员，我们要做的系统包含了旅客会直接使用的订票网、票务小姐管理票务的后台系统、跨平台介接的实时订票系统及在线付款系统等等。

这个项目包含了许多不同的「角色」及「需求」。角色有旅客、老板、票务人员及软件开发人员等等。他们都有各自己的需求，例如，旅客希望票价便宜并且系统使用安全、方便及稳定、老板希望以最少的成本及时间就能上线、票务小姐希望系统能减轻她们后台票务的工作量、营销业务希望什么功能都有、开发人员希望系统设计弹性或者使用熟悉的技术来开发。

于是乎，开发人员为了符合大家的需求或者某个特殊活动的需要，开始了一夜夜悲壮的软件开发战役。而在系统尚未稳定之时，没想到老板竟想要复制「成功」经验，开始建立两岸三地的作战堡垒，因此系统也由小恐龙渐渐地变成了究极大怪兽。

「使用接口风格不一致、订票系统容易断线、订票响应速度太慢……」，一连串的问题陆续出现，然而最终没有人真正了解问题的来源或者可以解释细节。这个没有人能控制的大怪兽终于带来了最后的审判日──失败的软件项目。这个项目失败的原因很复杂，包括了使用者接受度、商业模式（Business Model）、政治因素、项目管理控制等等，当然有很大的一部分原因是：它拥有一个杂乱的软件架构及一个无法控制的系统。

软件系统的最高指导原则
所谓的软件架构，简单的来说，就是定义一个软件系统未来发展的「最高指导原则」，就像宪法一样，在未来的发展中不可抵触，例如，系统该分成哪些模块、要用哪些技术、组件间的沟通接口是什么、组件间的互动行为要用哪些Pattern。

这些最高的原则当然是由各种需求或者开发团队的能力分组所引导出来的，例如，分成三层，并分给三个不同能力的小组来完成，或者使用讯息中介软件介接外部系统，缩短使用者的等待时间并增加系统的稳定度及可靠度等等。这些最高指导原则订定了整个软件系统发展的大方向，也等于限制住系统技术发展的最大范围，进而防止系统开发走向错误的方向，并且让开发人员有一个技术的依归，可以踏实地完成系统开发。当然，宪法是可以修的，只不过必须经过正式的修宪会议而已，软件架构也是一样，不然在偏离架构范畴下所开发出来的软件，最后还是很可能会误入歧途而失败。

在《Software Architecture in Practice》一书中，作者Bass、 Clements、Kazman对于软件架构以比较学术的方式来解释：「软件架构是一种系统的结构，「包含」并「定义」了许多软件组件及其间的组织方式和互动行为」。换句话来说，软件架构有许多软件组件、一个以上的结构以及它们之间的各种关系。除此之外，架构还包含了非功能面的条件，像是QoS （Quality of Service）或是SLR（Service Level Requirement），它包含可用性（Availability）、可信赖（Reliability）、可扩充（Scalability）和安全性（Security）等等。
上述这个定义也暗示着任何一个软件系统都有软件架构，只不过和系统本身的好坏无关。对于一个软件系统来说，架构并没有绝对的好与坏，只有适不适合而已。例如，一个时间紧迫并且规模小的网站系统，就没有必要一定要用MVC的架构来开发，它也可以很简单的利用Layer的观念并且配合资料封装技术来实作。建立软件架构的关键在于能够提供软件系统未来实用而稳固的发展基础，这是很重要的一点，因此架构不应由错误尝试中得到，它应该是经过认真的设计及规划出来的，而架构文件则是架构设计后所该留下的重要结果，也是未来开发的依据。清楚的架构设计有利于开发过程的「沟通」、系统的「演化」以及未来产品线开发的「再利用」。

平衡软件项目元素，建立扎实软件架构
通常一个软件系统，打从娘胎开始就会不断地受到各种需求的影响，但同时满足所有的需求是不容易的，因为有许多的需求是相互抵触或者是有隐含的意义。软件的「开发过程」就是在协调及满足这些需求，而过程中，如果没有好好地规画软件设计的发展策略，软件系统很容易会变成多头马车，进而演变出迭床架屋的架构，充满随时倒塌的危险。

架构师的责任就在于利用自己的经验来「平衡」项目相关人员需求、开发团队技术能力、技术环境及成本等元素，进而建立出扎实的软件架构。虽然我们都知道软件的本质是「恒变的需求」，但是在我们拥抱改变的信念下，还是不可能从咖啡机中煮出红酒来的。
「软件架构」就像是一个人的体质，它会影响软件系统未来的生老病死，因此在开发软件系统前，请先好好的调理它。

一个好的软件系统，除了必须符合使用者的需求之外，应该可以容易地再利用、维护及扩充。要达成这个目标，需要多少的设计思维及创意呢？若是符合这个目标的系统，一定充满软件美学的精神。软件设计其实是一种艺术，它不仅需要灵活的设计思维及技巧，还需要平衡项目的资源及使用者的期望，因此不管从工程面来看，还是从管理面来看，都是一种艺术。而要秉持软件美学精神来开发软件系统，其最深层的根基则必须要以「Pattern」来支撑。

相信有许多软件开发人员会觉得：Pattern和自己开发的程序代码好像是两回事一样，不知如何理解及使用，更不会了解它和软件架构、开发流程，乃至于整个开发项目的关系。美丽，应该从头开始，开发一个好的软件系统也是一样，就让我们从敷Pattern面膜开始。

我们先想象一个情境，假设你是一家比萨餐厅的大厨，现在有两位客人向你点餐，第一个人说：「我要一份虾仁搭配菠萝、洋葱的比萨，虾仁要多一点，再加上一份洒上墨西哥辣椒、洋葱、美式腊肠、意大利肉肠的比萨，不要太辣，外加一份法国香蒜面包及2瓶350毫升的百事可乐」。第二个人则说：「鲜虾菠萝及哈辣墨西哥比萨各一份，外加一份香蒜面包及2瓶小瓶的百事」。

如果你是大厨，你会比较希望听到哪一种点餐方式？除此，这两个人的点餐方式有什么差别呢？其中最大的差别就在于第二个人使用了大家都了解的餐点名称，大大地简化了点餐所使用的语句，而且所表达的意思和第一个人所要的差不多。如此身为大厨的你不仅容易理解顾客所点的餐点，也容易记忆他要的东西，并且节省了彼此沟通的时间。相较之下，你听到第一种点餐方式是不是很想把他轰出餐厅呢？

Pattern的沟通力量
我们再来看看对象导向的程序设计。一个设计老手一定熟悉许多对象导向的基本原理及设计原则，当他在解决一些设计问题时，会很自然地运用这些技巧及经验，设计出解决各式难题的蓝图。

假设你就是这位设计老手，而你刚好要跟伙伴说明这个绝妙的设计。你可能会说：「我先建立一个super abstract class及两个继承于它的sub-class，并在其中一个sub-class中建立一个往super abstract class方向的association以便形成container功能，这样就可以先完成一个递归的类别结构，然后在那container class实作一个final的method，用来固定的呼叫super abstract class所定义的抽象方法，这样在未来继承于此container class的类别阶层的所有对象，都可以动态地被加入到执行时期对象模型的递归结构，透过分别修饰原有功能来增加新功能」，不知道说到这里，有几个人听得懂的呢？

或许你可以用更简洁的方式来表达，你可以说：「在这个部份的设计，我要建立一个Decorator Pattern」。一句再简单不过的话，就足以表达上述那段又臭又长的演讲，甚至所传达的意思还更为清楚。这就是「共享词汇」的力量，也是「沟通」的力量。

在前一篇「感受美丽的元素，设计思维」中有提到，大部分的软件开发都是团队合作，要让大家了解自己伟大的设计，光用言语及UML来表达可能不够，还必须注意传达设计思维的问题。由于每一个Pattern的设计都是基于对象导向精神及原则，在应用上来看，它们保证了软件某个程度的弹性及稳定，除此之外，「沟通」则是另一项非常重要但却比较少人体认到的功用。从Pattern的定义来看：「一种在某个特定情境下，为了解决某种问题的解决方案。」因此，还要再加上某个特定「名称」，才能算是个Pattern，才能和别人沟通。

3类常见的Pattern
Pattern有很多种类，只要符合定义的都可以称做Pattern，但我们先把Pattern简单的分为三种常见的种类，分别是「Architectural Pattern」、「Platform Pattern」及「Design Pattern」，代表三种不同层次的应用，因为每个层次都有各自不同的问题。

Architectural Pattern针对的是软件架构，如Pipes、Broker、MVC等等。

Platform Pattern针对的是某个特定的发展平台，例如J2EE Pattern。

而Design Pattern就是大家比较耳熟能详的，例如四人帮（Gang of Four，简称GoF，这四个人分别是Gamma、Johnson、Helm、Vlissides）的圣经级著作《Design Patterns: Elements of Reusable Object-Oriented Software》一书中，所探讨的是针对一般化的问题，而不是特定领域的问题。每个领域的Pattern几乎都可以看到Design Pattern的影子，因为它提供了最基础而稳固的设计元素。

看到这里也许有人会说，有那么多开放原始码软件可用，为何还要用Pattern呢？这其实也是个事实，我们常常寻找好用的开放原始码 Framework作为开发系统的骨干，例如，Struts、Spring、Hibernate等等，通常我们只要加上一些客户需求的程序代码，拼凑一番，就可以上线了，似乎用不上Pattern。但是，除了要注意开放原始码的授权种类之外，还要注意那些Framework，是否有助于我们让自己的程序代码容易地维护、再利用及扩充？是否有助于我们去「沟通」？再者，这些著名的Framework都是使用Pattern来设计的最佳范例，因此理解 Pattern对于了解Framework的精髓，及如何整合入自己的系统，有很大的帮助，才不会误解Framework的整合方法而张冠李戴，这就是使用Pattern的最好时机及理由。

必学23个Design Pattern
初学Pattern的人一定会觉得Design Pattern很难放到自己的设计上，这个因扰大部分来自于所学的Design Pattern太少，只学习了几个Pattern就急于使用，就很容易会为了使用Pattern而强用Pattern，反而是化简为繁。因此，首先要尽量让自己对于Pattern有多一点的理解。我认为GoF所归纳出来的23个Pattern，是你该理解的最基本数量，这么说并不代表在设计软件中就应该全数用上，重点是当你理解那23个Pattern后，对对象导向会更有感觉，所累积的原力会让你较容易地「感觉」出，应该使用哪些Pattern。其实在做程序代码的Refactorying时，是最好的练习时机，因为你可以从现有程序代码，慢慢修改到某个Pattern的形式，要记住的是，Pattern只是心法，如何变化出招式是靠你的美感，实际的设计是没有必要和Pattern所定义的形式完全相同的。

世界上大大小小的事件、每个人的想法、做法，只要不是具象的事物，就都是抽象的，而软件设计的思维亦是如此。

在软件设计的领域中，对象导向的设计方式是个抽象的分析思考法，很适合在虚拟世界里面表达出真实世界的需求。虽然对象导向的技术已经行之有年了，但是真正了解其观念，并且能将其思维放到实际设计与实作上的人并不多，可能是因为受到现实环境的影响。

以Java来说，笔者就看过许多使用Java写出C程序风格的例子，以应用面来看，这样实在谈不上有设计思维，只能说是透过程序撰写一行行地列出工作而已。然而也许是因为这样的观念不清，导致利用Java开发的系统效率不张或者幽灵问题不断，而让人误解Java系统的好坏。

对象导向的关键哲理－抽象
对象导向是一种很有趣的分析「哲学」，它试图从人们对真实世界的看法及感受来解释属于虚拟世界的软件。从分析问题领域，进而转成相对应的程序代码，都是在模拟真实世界里的自然过程。

真实世界的事物是瞬息万变的，而软件开发也是如此，唯一不变的，就是恒变的需求。因而，「抽象」则是描述「瞬息万变」的一个重要并且安全的方法。

抽象的观念也是大部分的人在学习或运用对象导向观念时，比较容易遇到的瓶颈。所谓的抽象，简单来说，就是「萃取」出的概念，而且和实作无关，因为真实问题背后所隐含的意义，往往无法从直接的实作中得知。抽象的焦点是事物的本质特性，不同的观点可以对同一事物抽离出不同的元素来，若是将抽象结果对映到真实世界中，有可能是一个具体的东西，也可能是一个看不见的概念。

抽象有助概念与实作的再利用
想象一个简单的例子，在人声鼎沸的世贸计算机展里，你能够抽象出什么呢？是某计算机公司的摊位、辣妹跳舞、某个品牌的计算机，还是拆解成摊位、辣妹、表演、消费者、产品、销售、交易？若是后者，那么将这些元素套用到家具展上，其实也没问题。因此，抽象有助于「概念的再利用」，同样也有助于「实作的再利用」及稳定。

如果我们要设计一个展览馆的软件平台，起码，当计算机展要改成家具展时，只要重新实作产品内容，不用重新设计整个平台，因为交易模式及展埸运作模式都是类似的。

大家在此应先建立一个观念，对象导向的分析方法是由特殊到一般，由实体到抽象。抽象的观念还可以在经过一般化（generalization）或者特殊化（specialization）的分析后，衍生出阶层的结构，这一层一层的抽象结构，可以像一层一层的防火墙一样，挡住一级一级需求变异的风浪。

以黑客任务说明对象导向
对对象导向技术有初步认识人都会读到不少技术名词，例如接口（Interface）、讯息（Message）、类别（Class）、抽象（Abstraction）、具象（Concrete）或者Pattern、IoC（Inversion of Control）、Dependency Injection、MVC（Model View Controller）等等，这些名词都和对象导向的设计思维习习相关。我很喜欢的一部电影──黑客任务（Matrix），可以套用来说明这些名词的观念及对象导向设计的思维。

在黑客任务的电影情节里，人类被所谓的「母体」控制在一个虚拟的计算机世界里，在那个虚拟世界里面的所有事物，例如行道树、食物、味觉，甚至物理或化学反应，不管是看得到、感觉得到还是所谓的自然定律，都是计算机程序所创造出来的，而真实的人类却浑然不知地被「饲养」在一座座充满连接管线的生态槽里。

看完电影后我不禁思考：如果我是那母体（Matrix）的架构师（architect），该怎么设计那套系统？

我大概会利用复合技术（composition）的方法，再配合连结器（adapter）机制和真实世界生态槽里收集人体各项模拟讯号的生物接口连接，再转化成数字讯号，然后将人类的类别（class）具现（instantiate）到数字世界里时，利用dependency injection的方式，将经转化的数字讯号注入人类实例（instance），并和那里的所有事物建立对象关系，然后人类就可以在那个世界里生活着。

这么酷的想象，透过对象导向的技术来形容似乎就不难理解，它可以容易地传递设计的思维。然而，光是了解对象导向的原理，还不足以让你变成一位好的设计师，好的设计作品应该是容易地再利用、扩充及维护的，因此除了抽象、封装、继承与多型的基础概念之外，有经验的老手可能还知道许多对象导向的设计原则，像是「封装变异」、使用复合技术代替继承、针对接口写而不是实作。

设计思维的传达与再利用
当你在利用上述这些设计思维来塑造软件时，出现的另一个问题是：大部分的软件开发不会是只由你一个人负责，而是团队作业，然而在一个团队中，要如何让伙伴了解你根据这些对象导向基础或原则所做的美妙设计呢？设计思维的传达，变成了下一个问题，而这也意味着一个很重要的概念，那就是设计思维应该是可以再利用的。

对象导向的重要概念－接口
在对象导向的设计里，表达抽象的一个重要设计概念就是「接口」，它也是对象导向的基石。这里所指的界面有2种意义：Java语言上的接口（interface），以及概念上的接口，此处我们所谈论的是后者──概念上的界面。

对象的接口界定出「外界」能送给它的讯息信息，也可以说是「限制」了外界对该对象所能影响的范围，对每个对象来说，接口也是了解另一个对象的唯一方法。以汽车的例子来说，我们看得到汽车的外观，也看得到汽车移动的方式，因此汽车的外观及移动方式，都是属于汽车的接口。

至于汽车是何以能如此移动，是利用什样的动力驱动－汽油引擎、柴油引擎或油电混合引擎，是采用什么样的传动机制－前轮驱动、后轮驱动或四轮驱动，以上这些则属于实作。

有趣的是，一个对象可以有一个以上的接口，这就是多形（polymorphism）的应用。举个例子来说，台湾之光－王建民，他是洋基队的球员，他也是台湾人，更是他父母的儿子，因此，以球队的观点来看，他可以帮洋基队投球，以台湾的观点来看，他有国民的义务，以家庭的观点来看，他必须尽到做儿子的责任，但是他都是王建民。所以，接口有点像是对象所扮演的角色，而角色当然就伴随着「责任」，对象导向设计时的重点之一就是在做对象的「责任分配」。

有许多的Pattern或者Framework都要靠稳定的接口为其发展的基础的，例如，DI（Dependency Injection）、MVC（Model View Controller）、Spring、Struts、JUnit等等，不胜枚举。

前几个月读了一本封面标题为「美力时代」的商业周刊，封面的小标──「当美成为时代的新竞争力，你也该为美感能力建立存折」，让我愣了几十秒：这是多么简单而又令人震撼的一句话，道尽了近年来世界科技及经济的进化。美感这两个字可以应用到人们感观所能触及到的所有事物，因此除了看到的商品，享用的服务也一样开始受着「美力」所影响。从最近苹果计算机的白色旋风 iPod，以及由ICQ启始而影响人们沟通习惯的网络实时传讯、部落格(Blog)到网络相簿(如最近热门的Flickr)等等，大家应该就可以感受到了吧。由「美力」所带来的经济力是如此强大，各行各业的产品也好，服务也好，都越来越讲究精致甚至豪华，产品或服务的功能面已经是基本的要求，似乎美的展现才是大家的决战点。

美的本质是创造力
其实美的追求是人类的天性，当社会进步到某一个程度，我想这是合理的现象，人类也是感观的动物，遇到美丽的事物，人们可以利用五官，甚至是心去感受，而「设计」，是表现出美的方法之一，例如华裔建筑师贝聿铭为法国罗浮宫设计了一个玻璃金字塔入口，那是一个很美的架构，人们即使不懂它的设计原理，也可以用眼睛去欣赏它的外观，用心去感受它古典造型及现代建材的融合。

我常常在想，那软件设计的工作呢？软件的「设计」有人能看的到吗？它的美有价值吗？当我在读《Software Architecture in Practice》一书时，封面的罗浮宫玻璃金字塔照片表达了软件架构的美──就和伟大的建筑一样，而差别只在于建筑是人人看得到摸得到，而软件架构却不是。既然如此，软件的设计需要美学吗？还是只在学理派的乌托邦才看得到呢？美学大师蒋勋的一句话「…美的本质是创造力…」，让我更相信自己心中的软件乌托邦，软件的本质也是创造力，「设计」则是让创造力具化出美的手段。

看到这里，也许有一些经验较丰富的软件人会笑说，在台湾的软件环境里，软件美学是没有价值的。可能是因为台湾的软件市场小，所以台湾的软件公司资本也比较小，让台湾的老板比较重视马上看得到的「钱」途，而大家也总是比较重视「看得到的设计」，对于「看不到的设计」，在没发生任何状况前，大多是自然地忽略，因此就养坏了市场对于软件设计的不尊重，并间接影响到软件开发人员的价值。我姑且不评论这个适合放到讨论网站的题目，以及会变成炮灰的答案，因为事情的看法常常和信仰有关，而现实的对与错是不会影响到信仰的，对不对？所以先来谈谈我所看到的软件美学吧。

软件架构之美好比建筑之美
我不得不拿建筑来比喻软件开发，因为真的太相似了，建筑师设计出建筑蓝图之后，需要有各类专家依照蓝图的设计，真正地将房子盖起来，而软件开发也是同样需要设计及实作的。那什么能够感觉到美呢？一个建筑师发挥创意所盖出来的房子，应该是兼具美丽外观、安全与实用等等，人们可以从建筑的实体，感受出建筑师的创意，进而感受出这一种美的「思维」，因此，除了形状、颜色、声音或者动作可以让人感觉到美，思维也应该能让人感觉美，而设计就是一种高度的思维活动。

从建筑师的「创意」到施工实作的过程中，还需要「沟通」，不然思维是无法实现的。相同的，软件的设计就是将「创意」的思维表现出来，有创意的软件设计必需要能与实作者沟通，而沟通最好的工具，就是共同的语言。

有空多敷Pattern面膜
近年来OOAD盛行后，汇集对象导件精髓的Design Pattern，就是用来发挥创意解决问题并且表达沟通最好的共同语言了，在软件设计人员驱之若骛学习之余，大家除了要了解它的使用时机，其沟通的意义也是很重要的。

美丽，真的该从头开始，身为软件开发人员应该有空就敷一下Pattern面膜，因为这些是许许多多前人所留下的智能，当你从其中感受出设计思维之后，对于这些美丽元素能不发出赞叹都会很难，我也是在了解Pattern的过程中，慢慢地体会到对象导向的精神。

软件架构的风格与结构
一个软件系统就像建筑一样，有其风格及结构，就是所谓的软件架构。调理出好的架构体质对软件系统未来的美丽外观、坚固安全与实用是非常重要的，这和一般迭床架屋的蛮干方式有很大的不同。

使用思维来塑造软件架构的美感，也就是使用Pattern来设计软件架构，并且以架构为中心的开发方式，可以让设计的美丽从软件核心一层一层地透出来。而对象导向的精髓提供了软件架构许多巧妙的设计或者扩充空间，进而影响软件未来的实作与发展。

一个软件项目的开发过程当然包含了许许多多不同领域及责任的专家们，这是一种需要团队合作的艺术，单纯的利用Pattern来沟通创意当然是不够的。专家们有不同的理念及需求，这是一个复杂的现实环境，而艺术与现实的结合才能实现创意，才能让人感动吧！

一个有效的软件开发流程就像是一位导演，指挥着不同的专家，在适当的时机使用相同的语言，来沟通整合大家的创意及需求。因此有了思维还不够，我们需要方法才能导演出美丽，苏醒软件美学。

讲了那么多虚无飘渺的东西，感觉像艺术一样距离遥远，也许这真的需要在乌托邦才做得到，当然，寻找软件乌托邦是充满挑战的，而胆识是必要的条件。

UML-项目开发的蓝图标准
P2P-点对点传输服务
Java-横跨多种平台的程序语言
.Net2.0-微软挑战Java的新利器
Eclipse-项目开发超人气工具
XML-网络信息交换标准什么是UML：简单来说，UML就是用来让开发者了解使用者需求的一种"工具语言"。
我对他的了解不深，当初专题的文件是用DFD(Data Flow Diagram)分析的，
有点后悔那时候懒的学了。
总之，我会去学啦，怎么可以落伍呢^_^!!

P2P他放这在里我就觉得有点莫名其妙了，他既不是语言，也不是软件，
充其量只能算是一种"行为概念"、"传输模式"之类的。
不过P2P的软件是真的满红的没错啦Netsper、ezPeer、Kuro还有啥eMule、BT，
到红的满天的Skype。
不过开发P2P的软件，哪一套算有在赚钱呢?

Java我记得是大二的时候开始接触，后来接触了JSP(Java Server Page)，
也选择以JSP为当时专题的撰写语言。
可惜久未接触，有点生疏了，这可能是我以后未来的饭碗之一吧，
待我好好恢复一下记忆力。

.Net2.0，这又是我没什么概念的一项了，从.Net推出之后，
可能是受Java的荼毒太深吧，对于.Net的新闻消息很少在注意，
不过听说.Net其实还是很不错的啦!!
退伍之后，有认识的朋友要我去他们那里作ASP.Net，
可是我不会阿，还在考虑要不要花心思去学呢!!

Eclipse：一个软件开发工具，颇受好评。
不过放在这里也很奇怪，
应该放在"6大程序开发工具" 才对吧?!

XML：XML 是 eXtensible Markup Language 的简称，中文翻译是 "可延伸标记性语言"。XML 以一种简单、标准、并可扩展的方式，将各种信息如：文字、数字、图片、影像、...等，以原始数据的方式储存。并在储存过程中加入一些可供辨识的标签 (tags)。藉此网站服务器或客户端可以把信息内涵做进一步处理。XML 技术则是指一系列基于 XML 语法所制定的标准的集合，在此我们把它称为 "XML 家族"。
上面这一段XML介绍是网络上找来的，简单的来说，XML你可以当作是一种，"资料交换的一种标准、格式"。必学!!