軟體方法就是用來編寫電腦程式的一套規則和慣例。重量級方法具有很多規則、慣例、和文檔。正確地遵循它們需要訓練及時間。輕量級方法僅具有很少的一些規則和慣例，或者說，這些規則和慣例遵守起來很容易。
基本介紹
- 中文名：輕量級方法
- 外文名：Lightweight way
- 編寫：電腦程式的一套規則和慣例
- 成型：Edsger Dijkstra
- 1968年：CACM
簡介,英文介紹,成功秘訣,原則及原理,如何減輕容器,Spring 露出水面,容器比較,敏捷開發,持久性策略,Java 替代方案,Seaside,Continuation 框架,
簡介
在20世紀的60年代後期以及70年代早期，計算機程式設計師隨意使用他們能夠使用的任何方式來寫軟體是件非常常見的事情。
很多程式設計師競相寫出複雜得對於任何人來說都無法理解的軟體。
如果有一個程式，它沒有任何的bug，在那時可稱得上是個奇蹟。
大家都認為讓計算機有用武之地是個有價值的追求，不能說不象老早的西部冒險之旅。
Edsger Dijkstra於1968年給CACM（應該是Communication of the Association for Computing Machinery: 計算機器 協會 通信）寫了一封題為“GOTO語句其實有害”的信。
自此，軟體工程的主要概念開始成型。
那時大家認為更全面、更嚴謹的方法可以幫助我們創建品質可靠、成本可準確估計的軟體。
無法無天、牛仔式的編碼者們被懸崖勒馬。
20世紀80年代正是電腦程式員們的好時光。
我們有了一些規則和慣例。從質量上講，我們這時寫的軟體遠遠優於僅僅是寫於幾年前的軟體。
似乎可以認為：如果能夠建立足夠多的規則，可適用於所有能夠碰到的問題，我們就能夠寫出完美的軟體，並且還能按時完工。
於是乎就有了越來越多的、適用於所有潛在問題的規則和慣例，
現已進入了21世紀，我們發現，這些規則遵守起來非常困難，其過程很複雜，也沒有得以透徹地理解；使用各種抽象符號寫就的、海一樣的文獻猶如脫韁的野馬紛至沓來。
大家熱火朝天，都想提出更全面、更好的方法，跟California（加利福尼亞，加州）淘金熱似的真有一比；每個到了西部的人卻都很失望。
我們寫出了能夠幫助我們寫軟體的軟體。
但是，這很快就亂了套，各種重磅炸彈似的CASE工具迎面而來。
這些工具原本是用來幫助我們遵守規則的，可它們用起來很是困難，簡直都沒法用。
要按時完工，電腦程式員發現他們必須抄近路，忽略一些重要的慣例。
實際上沒有一個人真的遵守那些曾經用來自縛的重量級方法。
牛仔又回來了，我們回到了俄克拉荷馬州（譯者註：俄克拉荷馬州是偶對OK的猜測，因為偶了解到俄克拉荷馬州曾經是往美國西部輸出勞工的一個大州，但可能有誤，呵呵）的畜欄之中。
當程式設計師忽略了他們的方法中的規則時，他們（實際上是）本能地脫離重量級方法，回到了早期較為簡單的、輕量級方法時代，很少的規則便夠了。
可我們並不想忘記我們已經學到的東西。
我們可以把（能夠）幫助我們寫出高質量軟體的規則保留下來，而摒棄哪些阻礙我們前進的哪些規則。
我們可以對那些複雜得難以遵循的規則進行簡化。
我們也不想回到早期根本沒有任何規則可言的牛仔式編碼時代。
而是讓我們止於足夠能使我們的軟體可靠、適度定價的規則吧。
我們接受軟體行政長官而不要牛仔式的編碼者；我們作為團隊工作在一起，反應敏捷，僅僅用那些輕量級的、簡練的和有效的規則和慣例把我們武裝起來。
極度編程（XP）就是若干這種新式的、輕量級的方法之中的一種。
XP具有若干規則和適當數量的慣例，且所有這些遵守起來都很容易。
XP是一種乾淨簡潔的環境，它形成於對到底是哪些東西能夠加速軟體開發，以及哪些東西卻起著減速作用的觀察。
它是一種使程式設計師能夠自由發揮其創造力和生產力，卻同時有保持組織性和凝聚力的環境。
英文介紹
A software methodology is the set of rules and practices used to create computer programs.
A heavyweight methodology has many rules, practices, and documents.
It requires discipline and time to follow correctly.
A lightweight methodology has only a few rules and practices or ones which are easy to follow.
In the late 1960s and early 1970s it was common practice for computer programmers to create software any way they could.
Many programmers excelled at creating software too complex for anyone to understand.
At that time it was a miracle if a program ran without any bugs.
Making computers useful was considered a worthy quest and not unlike an adventure into the old west.
In 1968 Edsger Dijkstra wrote a letter to CACM entitled GOTO Statement Considered Harmful.
The central ideas of software engineering were being born.
At that time we believed that bigger, more disciplined methodologies would help us create software with consistent quality and predictable costs.
The lawless cowboy coders were being reined in.
The 1980s were good times for computer programmers.
We had a few rules and practices to create software that was far superior in quality to what we were creating only a few years earlier.
It seemed like if we could just create enough rules to cover the problems we encounter we could create perfect software and be on time.
We added more and more rules and practices to cover all the potential problems.
Now in the 21st century we find these rules are hard to follow, procedures are complex and not well understood and the amount of documentation written in some abstract notation is way out of control.
Trying to come up with a bigger and better methodology was like a California gold rush; everyone headed west only to be disappointed.
We created software to help us create software.
But this quickly got out of control and dreadnought CASE tools were born.
These tools, originally created to help us follow the rules, are too hard to use themselves.
Computer programmers find it necessary to cut corners and skip important practices to stay on schedule.
No one is actually following the heavy methodologies we have handcuffed ourselves with.
The cowboys have returned and we find ourselves back at the OK Corral.
When programmers ignore the rules of their methodology they are instinctively moving away from heavyweight methodologies and back toward an earlier, simpler time of lightweight methodologies when a few rules were enough.
But we don't want to forget what we have learned.
We can choose to keep the rules that help us create quality software and throw away those that hinder our progress.
We can simplify those rules that seem too complex to follow correctly.
We don't want to return to the early days of cowboy coding when there were no rules at all.
But instead let's stop at just enough rules to keep our software reliable and reasonably priced.
Instead of cowboy coders we have software sheriffs; working together as a team, quick on the draw, armed with a few rules and practices that are light, concise, and effective.
Extreme Programming (XP) is one of several new lightweight methodologies.
XP has a few rules and a modest number of practices, all of which are easy to follow.
XP is a clean and concise environment developed by observing what makes software development go faster and what makes it move slower.
It is an environment in which programmers feel free to be creative and productive but remain organized and focused.
成功秘訣
原則及原理
依賴注入
最新一代容器稱為輕量級容器，它們使用一個共同設計原理：依賴注入。 對這個簡單思想來說，這是一個複雜的術語。依賴注入讓您將對象和它所依賴的東西交給第三方。然後第三方創建所有對象並將它們綁在一起。比方說，稱為 myDao 的數據訪問對象需要一個稱為 ds 的數據源。那么該容器會一同創建它們，並設定一個屬性：
清單 1. 創建一個第三方彙編程式
myDao = new Dao();
ds = new DataSource();
myDao.setDataSource(ds);
當然，不創建這種第三方彙編程式的話，您也可以使用框架來做其他附加的工作（如提供配置支持）。Spring 框架、Pico 和 HiveMind 就扮演了這個角色。其他像 JavaServer Faces(JSF) 框架也利用了依賴注入。
面向對象編程
您現在已經得到了關於 POJO 的聲明性事務，這對企業應用程式非常有用。使用這些工具，您可以完全放棄 EJB，或者最小化它的作用。而這正是輕量級組件所要做的。
透明持久性
持久性也是建立在較簡單的編程模型之上。透明持久性框架通過配置而不是編寫代碼，來使您為應用程式添加持久性。因為大多數應用程式是面向對象的，並且訪問一個關係資料庫，所以一些專家斷言，我們最終將進入對象關係映射的時代。我目前發現的頂級持久性解決方案是 SolarMetric 的 Kodo JDO 和 Hibernate。在後面的文章中我將詳細比較這些解決方案。其他輕量級解決方案，例如 iBATIS 和 Active Record 設計模式，根本不會試圖進行對象關係映射。
如何減輕容器
然而，這裡存在一些開銷。重量級架構對於解決許多問題都過於複雜。例如，實體 bean 會讓您為每個實體編寫 7 個檔案。因此 EJB 技術就不值得用來解決日常問題。如今，許多業務仍然需要企業服務，但它們正在尋找達到該目標的新方向。它們使用輕量級容器。實際上，最新的 EJB V3.0 標準就使用了輕量級容器模型。
什麼是輕量級容器？
大多數容器 API（如 EJB API）強迫您編寫一些接口或一個組件模型。將您的組件放入該容器後，容器會為您處理一些事情。EJB 容器提供企業服務。Servlet 容器（例如 Apache Jakarta Tomcat）實現了 Servlet API，使您可以將動態內容建立到伺服器頁面中，該頁面隨後會被傳送到 Web 瀏覽器。
傳統容器強迫使用指定的編程模型，輕量級容器則不是。它們使用普通 Java 對象（plain old Java object，POJO）。容器然後將 POJO 綁在一起，並將服務與它們相關聯。
Spring 露出水面
Spring 是什麼？
容器比較
本文介紹合力完成一種不同的活動：應用程式開發。敏捷開發流程，比如極限編程（Extreme Programming，XP）和 Scrum，尋求降低流程開銷。儘管存在許多不同的流程，但它們當中都有一些共同的趨勢：
越來越重視客戶參與，而非重量級需求文檔
通過重構改進質量和設計；重的、自動化的單位測試；連續集成
小團隊，較少的正式溝通和更多的非正式溝通（15 分鐘的站立早會，更多的配對編程）
短而一致的周期，最後是客戶反饋
敏捷方法剔除了不需要的流程，直到只留下完成工作所必需的流程。儘管許多編程人員理解輕量級、敏捷方法的強大功能，但許多管理人員習慣使用更傳統的流程。如果您認為敏捷可以幫助您，那么通過套用下列思想來學習如何協調傳統管理與敏捷開發流程：
將您使用的語言改為側重於原則，而非流程。
創建小而靈巧的團隊。
重視可測量的交付。
重視簡約性。
重構代碼並自動化測試。
獲得客戶反饋。
原則而非教條
當編程人員或架構師試圖將敏捷流程注入保守公司時，最好是拋開教條 —— 即，將重點放在原則而非教條上。如果您對 XP 的優點大肆吹噓 10 分鐘，典型的老闆會關注一個詞 極限。因為老闆關注的是減輕風險，所以您注定失敗。相反，您可以挑選一些您的管理層想要解決的問題。然後，選擇敏捷原則來幫助解決這些問題。
敏捷開發
本文介紹合力完成一種不同的活動：應用程式開發。敏捷開發流程，比如極限編程（Extreme Programming，XP）和 Scrum，尋求降低流程開銷。儘管存在許多不同的流程，但它們當中都有一些共同的趨勢：
越來越重視客戶參與，而非重量級需求文檔
通過重構改進質量和設計；重的、自動化的單位測試；連續集成
小團隊，較少的正式溝通和更多的非正式溝通（15 分鐘的站立早會，更多的配對編程）
短而一致的周期，最後是客戶反饋
敏捷方法剔除了不需要的流程，直到只留下完成工作所必需的流程。儘管許多編程人員理解輕量級、敏捷方法的強大功能，但許多管理人員習慣使用更傳統的流程。如果您認為敏捷可以幫助您，那么通過套用下列思想來學習如何協調傳統管理與敏捷開發流程：
將您使用的語言改為側重於原則，而非流程。
創建小而靈巧的團隊。
重視可測量的交付。
重視簡約性。
重構代碼並自動化測試。
獲得客戶反饋。
原則而非教條
當編程人員或架構師試圖將敏捷流程注入保守公司時，最好是拋開教條 —— 即，將重點放在原則而非教條上。如果您對 XP 的優點大肆吹噓 10 分鐘，典型的老闆會關注一個詞 極限。因為老闆關注的是減輕風險，所以您注定失敗。相反，您可以挑選一些您的管理層想要解決的問題。然後，選擇敏捷原則來幫助解決這些問題。
持久性策略
選擇合適的工具
對於帶 i-drive（它投入更多的力量到踏板曲柄而不是彈起的後避震）的山地腳踏車、低容量的皮划艇（它讓我使用河面下的水流）和框架，我有著相似的經歷。當我的客戶處理持久性時，為他們找到合適的框架可以把一個艱難掙扎的、沮喪的團隊轉變為一個運轉良好的機器。但是，您必須小心。改變框架可能是昂貴的。本系列的 第 3 部分 展示了 Spring 如何幫助您最佳化諸如持久性（persistence）之類的服務。本文則關注尋找合適的持久性框架。首先，讓我來破除幾個神話。
神話 1：技術總是最要緊的。
不論您是在談論 RDBMS 還是持久性框架，持久關係都是長期的。您需要知道您選擇的方案將長時間擁有市場份額。如果不是，您將冒著被迫離開指定框架的風險，而這並非您的意願。
神話 2：對象關係映射程式（Object Relational Mappers，ORM）隱藏了所有的資料庫問題。
持久性框架簡化了一些問題，但引入了一些其他的問題。如果您不理解底層架構，那么找懂的人問，或者不要使用對象關係框架。
神話 3：JDBC 總是比 ORM 要快。
神話 4：ORM 總是合適的工具。
常常，您會發現要求更好的訪問 SQL 的問題。您也會發現面向批處理的而非互動式的問題，或要求直接訪問資料庫行，而非完整的對象模型。這些問題並沒有充分利用 ORM。更糟糕的是，一些解決方案也許會礙事。
Java 替代方案
在給 Java 技術飛艇戳幾個洞之前，我應該提醒您一點兒歷史。Java 程式語言來自一個沒有希望的來源（Sun Microsystems），為了與控制伺服器端的統治語言（C++）競爭，那時一個程式設計範例正在尋求擺脫困境的辦法（過程客戶端 - 伺服器代碼）。網際網路爆炸，突然帶有內置 Java 虛擬機（JVM）的 Netscape 出現在每個桌面上。為了被廣泛接受，Java 語言向 C++ 社區做出了幾個重大妥協：
像 C++ 一樣，它是靜態類型，而不是像 Samlltalk 那樣的動態類型。
像 C++ 一樣，它允許原語和對象。
它涵蓋了 C++ 的語法和控制結構。
為了獲得市場，Sun 保留了與 C++ 足夠接近的東西來吸引社區。Java 語言沒有必要比所有其他的面向對象語言都好。它只需比 C++ 好就行了。現在，其中的一些妥協開始損害 Java 語言。
閉包
Java 語言允許比 C++ 更高的抽象，比如管理記憶體和字元串。但是，要達到像 Ruby 或 Smalltalk 語言那樣高的抽象，Java 語言還有很長的路要走。以疊代為例：用 Java 技術來完成一個數組的疊代，要這樣寫：
Seaside
用 Smalltalk 編程？
Continuation 框架
使用 Java™ 程式語言進行 Web 程式開發與騎腳踏車這個例子有幾分相似。我們總是把原本簡單的事情複雜化。您需要確保一切無狀態，才能獲得更好的可伸縮性。如果以 Servlet 或 JavaServer Page（JSP）的形式為用戶請求編寫多種獨立回響，就會留下許多散亂無章的獨立請求/回響塊。每個塊都需要確定其在整個應用程式上下文中的位置。您必須繞過前進路上的每一塊小石塊，牢記各請求的狀態。如果顧慮得過多，在用戶單擊 Back 按鈕、打開第 2 個會話或者是嘗試直接轉到一個較舊的 URL 時，您會發現自己“從把手上方翻了出去”。您希望可以假設用戶將按正確的順序執行任務，但這顯然是不可能的。絕大多數 Java 框架都不是以這樣的方式運作的。
