在軟件這個行業里有些規則是很有殺傷力的，比如很有名的摩爾定律。
總結出這些規則的意義在于可以大致的照明方向，免得努力來努力去卻走到了陰溝里。
現實中種種利益紛爭、觀點之爭看似紛繁，但在大時間尺度下來看卻都是規則的實現手段。
這就好比下圍棋，每一手都要為謀得利益而計算，但結局卻只有三種：贏、輸或和，這就是規則的力量。
民以食為天，所以第一定律從收入開始。
程序員第一定律可以表述為：程序員的收入是技能復雜度和技能實現可能程度的函數。
如果程序員的工資是S，社會平均水平的工資為A，程序員掌握的技能復雜度為C，實現程度為P。
那么S = A x C x P。
這里面的實現程度P不太好理解，額外做點說明。
好比說有人在東北種了很多白菜，并獲得了大豐收。與此同時廣州也確實需要大白菜，按批發價他的這批白菜可以買10萬。
但關鍵是這個人找不到車皮，大白菜就只能在當地零售，這個時候這批大白菜就只能買1萬塊錢。
這就是實現程度。
大白菜內蘊了既定的價值，這種價值并不因為賣多少錢而改變，但這種價值能實現到什么程度則依賴于現實的可能性。
這視乎很簡單，但其實不是，很多人的一生就籠罩在這條定律下面，我們來基于這第一定律繼續做些推導。
- 推論1：越容易上手的技術，其內蘊價值越低。
技能的復雜度C可以大致等價于掌握一門技術所需要的時間。
各種集成的開發環境，各種容易學習的類庫等使軟件開發的門檻降得很低，這對整個產業是有利的，但對個體而言則是不利的。
你花5個月可以學會的技術，其他人花5個月也可以學會，而5個月可以學會的東西所蘊含的價值一定是低的。
與之相對5年才可以學會的東西，其內蘊價值一定是高的。
內蘊價值低，所對應的收入必然偏低。
為避免爭議，我這里就不寫技術的名字了，但大家可以從學習所需要的時間上來對各種技術做個分類。
有時候很多人會有一種錯覺，認為越熱門的技術收益越好。
這在大多時候是錯的。
越熱的技術，越成熟的技術越是大眾的，而越是大眾的技術內蘊價值越低，所以收益越不好。
熱度能夠幫助找到工作，但對技能復雜度C沒有影響。
- 推論2：單純的涉獵廣泛，沒有專精，對收入的影響是負面的。
各種技術的復雜度大概是呈指數增長的，越到后面前進一步越困難。
好比說學會5門語言所需要的時間大多時候遠比學精一門語言要短。
在特定年紀尚，每樣技術都會一點，對提高實現程度P略有幫助，但自身可替代性很強，對技能復雜度C的影響為負面。
長期來看得不償失。
- 推論3：實現程度P越高，風險越大。
有些技術領域很窄，上手也慢，實現程度卻高，比如顯卡驅動，打印驅動等。
但這類工作好比在鋼絲上跳舞：只要能實現自己的價值，那么回報大體不錯，但最怕技術更迭。
技術一換代，可能多年積累十去六七。
總結來看，程序員要想獲得不錯的收入，第一要掌握稀缺的技術，即技術的內蘊價值要高；第二要找到實現稀缺技術的場景。
《微軟的秘密》一書中提到，微軟里面優秀的程序員是可以擁有許多輛保時捷的。
用上面兩條做分解，就會發現原因很簡單：
一是這樣的人是NT的核心開發人員，這類人員內蘊價值極高，處于稀缺狀態；二是微軟提供了實現這種技能內蘊價值的機會。
這二者缺一不可。
#根據大家的回復做了點修改把"實現可能性"替換成了"實現程度"。
什么是HTTP協議
協議是指計算機通信網絡中兩臺計算機之間進行通信所必須共同遵守的規定或規則，超文本傳輸協議(HTTP)是一種通信協議，它允許將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器
目前我們使用的是HTTP/1.1 版本
Web服務器，瀏覽器,代理服務器
當我們打開瀏覽器，在地址欄中輸入URL，然后我們就看到了網頁。 原理是怎樣的呢？
實際上我們輸入URL后，我們的瀏覽器給Web服務器發送了一個Request, Web服務器接到Request后進行處理，生成相應的Response，然后發送給瀏覽器， 瀏覽器解析Response中的HTML,這樣我們就看到了網頁，過程如下圖所示
我們的Request 有可能是經過了代理服務器，最后才到達Web服務器的。
過程如下圖所示
代理服務器就是網絡信息的中轉站，有什么功能呢？
1. 提高訪問速度， 大多數的代理服務器都有緩存功能。
2. 突破限制， 也就是翻-墻了
3. 隱藏身份。
URL詳解
URL(Uniform Resource Locator) 地址用于描述一個網絡上的資源, 基本格式如下
schema://host[:port#]/path/.../[?query-string][#anchor]
scheme 指定低層使用的協議(例如：http, https, ftp)
host HTTP服務器的IP地址或者域名
port# HTTP服務器的默認端口是80，這種情況下端口號可以省略。如果使用了別的端口，必須指明，例如 http://www.cnblogs.com:8080/
path 訪問資源的路徑
query-string 發送給http服務器的數據
anchor- 錨
URL 的一個例子
http://www.mywebsite.com/sj/test/test.aspx?name=sviergn&x=true#stuff Schema: http host: www.mywebsite.com path: /sj/test Query String: name=sviergn&x=true Anchor: stuff
HTTP協議是無狀態的
http協議是無狀態的，同一個客戶端的這次請求和上次請求是沒有對應關系，對http服務器來說，它并不知道這兩個請求來自同一個客戶端。 為了解決這個問題， Web程序引入了Cookie機制來維護狀態.
HTTP消息的結構
先看Request 消息的結構, Request 消息分為3部分，第一部分叫Request line, 第二部分叫Request header, 第三部分是body. header和body之間有個空行， 結構如下圖
第一行中的Method表示請求方法,比如"POST","GET", Path-to-resoure表示請求的資源， Http/version-number 表示HTTP協議的版本號
當使用的是"GET" 方法的時候， body是為空的
比如我們打開博客園首頁的request 如下
GET http://www.cnblogs.com/ HTTP/1.1 Host: www.cnblogs.com
下面我們打開Fiddler 捕捉一個博客園登錄的Request 然后分析下它的結構, 在Inspectors tab下以Raw的方式可以看到完整的Request的消息， 如下圖
我們再看Response消息的結構, 和Request消息的結構基本一樣。 同樣也分為三部分,第一部分叫Response line, 第二部分叫Response header，第三部分是body. header和body之間也有個空行, 結構如下圖
HTTP/version-number表示HTTP協議的版本號， status-code 和message 請看下節[狀態代碼]的詳細解釋.
我們用Fiddler 捕捉一個博客園首頁的Response然后分析下它的結構, 在Inspectors tab下以Raw的方式可以看到完整的Response的消息， 如下圖
Get和Post方法的區別
Http協議定義了很多與服務器交互的方法，最基本的有4種，分別是GET,POST,PUT,DELETE. 一個URL地址用于描述一個網絡上的資源，而HTTP中的GET, POST, PUT, DELETE就對應著對這個資源的查，改，增，刪4個操作。 我們最常見的就是GET和POST了。GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息.
我們看看GET和POST的區別
1. GET提交的數據會放在URL之后，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數據放在HTTP包的Body中.
2. GET提交的數據大小有限制（因為瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制.
3. GET方式需要使用Request.QueryString來取得變量的值，而POST方式通過Request.Form來獲取變量的值。
4. GET方式提交數據，會帶來安全問題，比如一個登錄頁面，通過GET方式提交數據時，用戶名和密碼將出現在URL上，如果頁面可以被緩存或者其他人可以訪問這臺機器，就可以從歷史記錄獲得該用戶的賬號和密碼.
狀態碼
Response 消息中的第一行叫做狀態行，由HTTP協議版本號， 狀態碼， 狀態消息 三部分組成。
狀態碼用來告訴HTTP客戶端,HTTP服務器是否產生了預期的Response.
HTTP/1.1中定義了5類狀態碼， 狀態碼由三位數字組成，第一個數字定義了響應的類別
1XX 提示信息 - 表示請求已被成功接收，繼續處理
2XX 成功 - 表示請求已被成功接收，理解，接受
3XX 重定向 - 要完成請求必須進行更進一步的處理
4XX 客戶端錯誤 - 請求有語法錯誤或請求無法實現
5XX 服務器端錯誤 - 服務器未能實現合法的請求
看看一些常見的狀態碼
200 OK
最常見的就是成功響應狀態碼200了， 這表明該請求被成功地完成，所請求的資源發送回客戶端
如下圖， 打開博客園首頁
302 Found
重定向，新的URL會在response 中的Location中返回，瀏覽器將會自動使用新的URL發出新的Request
例如在IE中輸入， http://www.google.com. HTTP服務器會返回304， IE取到Response中Location header的新URL, 又重新發送了一個Request.
304 Not Modified
代表上次的文檔已經被緩存了， 還可以繼續使用，
例如打開博客園首頁, 發現很多Response 的status code 都是304
提示： 如果你不想使用本地緩存可以用Ctrl+F5 強制刷新頁面
400 Bad Request 客戶端請求與語法錯誤，不能被服務器所理解
403 Forbidden 服務器收到請求，但是拒絕提供服務
404 Not Found
請求資源不存在（輸錯了URL）
比如在IE中輸入一個錯誤的URL， http://www.cnblogs.com/tesdf.aspx
500 Internal Server Error 服務器發生了不可預期的錯誤
503 Server Unavailable 服務器當前不能處理客戶端的請求，一段時間后可能恢復正常
HTTP Request header
使用Fiddler 能很方便的查看Reques header, 點擊Inspectors tab ->Request tab-> headers 如下圖所示.
header 有很多，比較難以記憶，我們也按照Fiddler那樣把header 進行分類，這樣比較清晰也容易記憶。
Cache 頭域
If-Modified-Since
作用： 把瀏覽器端緩存頁面的最后修改時間發送到服務器去，服務器會把這個時間與服務器上實際文件的最后修改時間進行對比。如果時間一致，那么返回304，客戶端 就直接使用本地緩存文件。如果時間不一致，就會返回200和新的文件內容。客戶端接到之后，會丟棄舊文件，把新文件緩存起來，并顯示在瀏覽器中.
例如：If-Modified-Since: Thu, 09 Feb 2012 09:07:57 GMT
實例如下圖
If-None-Match
作用: If-None-Match和ETag一起工作，工作原理是在HTTP Response中添加ETag信息。 當用戶再次請求該資源時，將在HTTP Request 中加入If-None-Match信息(ETag的值)。如果服務器驗證資源的ETag沒有改變（該資源沒有更新），將返回一個304狀態告訴客戶端使用 本地緩存文件。否則將返回200狀態和新的資源和Etag. 使用這樣的機制將提高網站的性能
例如: If-None-Match: "03f2b33c0bfcc1:0"
實例如下圖
Pragma
作用： 防止頁面被緩存， 在HTTP/1.1版本中，它和Cache-Control:no-cache作用一模一樣
Pargma只有一個用法， 例如： Pragma: no-cache
注意: 在HTTP/1.0版本中，只實現了Pragema:no-cache, 沒有實現Cache-Control
Cache-Control
作用: 這個是非常重要的規則。 這個用來指定Response-Request遵循的緩存機制。各個指令含義如下
Cache-Control:Public 可以被任何緩存所緩存（）
Cache-Control:Private 內容只緩存到私有緩存中
Cache-Control:no-cache 所有內容都不會被緩存
還有其他的一些用法， 我沒搞懂其中的意思， 請大家參考其他的資料
Client 頭域
Accept
作用： 瀏覽器端可以接受的媒體類型,
例如： Accept: text/html 代表瀏覽器可以接受服務器回發的類型為 text/html 也就是我們常說的html文檔,
如果服務器無法返回text/html類型的數據,服務器應該返回一個406錯誤(non acceptable)
通配符 * 代表任意類型
例如 Accept: */* 代表瀏覽器可以處理所有類型,(一般瀏覽器發給服務器都是發這個)
Accept-Encoding：
作用： 瀏覽器申明自己接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什么壓縮方法（gzip，deflate），（注意：這不是只字符編碼）;
例如： Accept-Encoding: gzip, deflate
Accept-Language
作用： 瀏覽器申明自己接收的語言。
語言跟字符集的區別：中文是語言，中文有多種字符集，比如big5，gb2312，gbk等等；
例如： Accept-Language: en-us
User-Agent
作用：告訴HTTP服務器， 客戶端使用的操作系統和瀏覽器的名稱和版本.
我們上網登陸論壇的時候，往往會看到一些歡迎信息，其中列出了你的操作系統的名稱和版本，你所使用的瀏覽器的名稱和版本，這往往讓很多人感到很神 奇，實際上，服務器應用程序就是從User-Agent這個請求報頭域中獲取到這些信息User-Agent請求報頭域允許客戶端將它的操作系統、瀏覽器 和其它屬性告訴服務器。
例如： User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.2; .NET4.0E)
Accept-Charset
作用：瀏覽器申明自己接收的字符集，這就是本文前面介紹的各種字符集和字符編碼，如gb2312，utf-8（通常我們說Charset包括了相應的字符編碼方案）；
例如：
Cookie/Login 頭域
Cookie:
作用： 最重要的header, 將cookie的值發送給HTTP 服務器
Entity頭域
Content-Length
作用：發送給HTTP服務器數據的長度。
例如： Content-Length: 38
Content-Type
作用：
例如：Content-Type: application/x-www-form-urlencoded
Miscellaneous 頭域
Referer:
作用： 提供了Request的上下文信息的服務器，告訴服務器我是從哪個鏈接過來的，比如從我主頁上鏈接到一個朋友那里，他的服務器就能夠從HTTP Referer中統計出每天有多少用戶點擊我主頁上的鏈接訪問他的網站。
例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT
Transport 頭域
Connection
例如： Connection: keep-alive 當一個網頁打開完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接
例如： Connection: close 代表一個Request完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接會關閉， 當客戶端再次發送Request，需要重新建立TCP連接。
Host（發送請求時，該報頭域是必需的）
作用: 請求報頭域主要用于指定被請求資源的Internet主機和端口號，它通常從HTTP URL中提取出來的
例如: 我們在瀏覽器中輸入：http://www.guet.edu.cn/index.html
瀏覽器發送的請求消息中，就會包含Host請求報頭域，如下：
Host：http://www.guet.edu.cn
此處使用缺省端口號80，若指定了端口號，則變成：Host：指定端口號
HTTP Response header
同樣使用Fiddler 查看Response header, 點擊Inspectors tab ->Response tab-> headers 如下圖所示
我們也按照Fiddler那樣把header 進行分類，這樣比較清晰也容易記憶。
Cache頭域
Date
作用: 生成消息的具體時間和日期
例如： Date: Sat, 11 Feb 2012 11:35:14 GMT
Expires
作用: 瀏覽器會在指定過期時間內使用本地緩存
例如: Expires: Tue, 08 Feb 2022 11:35:14 GMT
Vary
作用：
例如: Vary: Accept-Encoding
Cookie/Login 頭域
P3P
作用: 用于跨域設置Cookie, 這樣可以解決iframe跨域訪問cookie的問題
例如: P3P: CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR
Set-Cookie
作用： 非常重要的header, 用于把cookie 發送到客戶端瀏覽器， 每一個寫入cookie都會生成一個Set-Cookie.
例如: Set-Cookie: sc=4c31523a; path=/; domain=.acookie.taobao.com
Entity頭域
ETag
作用: 和If-None-Match 配合使用。 （實例請看上節中If-None-Match的實例）
例如: ETag: "03f2b33c0bfcc1:0"
Last-Modified:
作用： 用于指示資源的最后修改日期和時間。（實例請看上節的If-Modified-Since的實例）
例如: Last-Modified: Wed, 21 Dec 2011 09:09:10 GMT
Content-Type
作用：WEB服務器告訴瀏覽器自己響應的對象的類型和字符集,
例如:
Content-Type: text/html; charset=utf-8
Content-Type:text/html;charset=GB2312
Content-Type: image/jpeg
Content-Length
指明實體正文的長度，以字節方式存儲的十進制數字來表示。在數據下行的過程中，Content-Length的方式要預先在服務器中緩存所有數據，然后所有數據再一股腦兒地發給客戶端。
例如: Content-Length: 19847
Content-Encoding
WEB服務器表明自己使用了什么壓縮方法（gzip，deflate）壓縮響應中的對象。
例如：Content-Encoding：gzip
Content-Language
作用： WEB服務器告訴瀏覽器自己響應的對象的語言者
例如： Content-Language:da
Miscellaneous 頭域
Server:
作用：指明HTTP服務器的軟件信息
例如:Server: Microsoft-IIS/7.5
X-AspNet-Version:
作用：如果網站是用ASP.NET開發的，這個header用來表示ASP.NET的版本
例如: X-AspNet-Version: 4.0.30319
X-Powered-By:
作用：表示網站是用什么技術開發的
例如： X-Powered-By: ASP.NET
Transport頭域
Connection
例如： Connection: keep-alive 當一個網頁打開完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接
例如： Connection: close 代表一個Request完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接會關閉， 當客戶端再次發送Request，需要重新建立TCP連接。
Location頭域
Location
作用： 用于重定向一個新的位置, 包含新的URL地址
實例請看304狀態實例
HTTP協議是無狀態的和Connection: keep-alive的區別
無狀態是指協議對于事務處理沒有記憶能力，服務器不知道客戶端是什么狀態。從另一方面講，打開一個服務器上的網頁和你之前打開這個服務器上的網頁之間沒有任何聯系
HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協議（無連接）
Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間
作為一個開發者，尤其是web開發人員，我想你有必要去了解這一系列的處理流程，在這期間，瀏覽器和服務器到底是如何打交道的？服務器又是如何處理的？瀏覽器又是如何將網頁顯示給用戶的呢？......
疑惑和細節真是太多了。坦白講，要想徹徹底底的弄清楚以上每個疑惑和處理細節，至少需要十本書的厚度，所謂“底層無極限”嘛，而且不同的web服務 器和服務器端編程語言的實現和處理流程不盡相同（但本質都是相通的）。本文中，我將根據http協議的有關知識，跟大家講解一些web開發的本質。不管你 是從事.NET，還是J2EE或者php開發等等，都離不開這些本質。希望你讀完本文，能有新的收獲和見解。由于本人水平和經驗有限，難免有誤，望讀者見 諒。
何為http協議（Hypertext Transfer Protocol，超文本傳輸協議）？
所謂協議，就是指雙方遵循的規范。http協議，就是瀏覽器和服務器之間進行“溝通”的一種規范。我們在看空間，刷微博...都是在使用http協議，當然，遠遠不止這些應用。
筆者一直聽說http是屬于“應用層的協議”，而且是基于TCP/IP協議的。這個不難理解，如果你上大學時候學過“計算機網絡”的課程，就一定知 道OSI七層參考協議（我當時是死記硬背的）。如果你接觸過socket網絡編程，就應該明白TCP和UDP這兩種使用廣泛的通信協議（建立連接、三次握 手等等，當然，這不是本文討論的重點）。如圖：
既然TCP/UDP是廣泛使用的網絡通信協議，那為啥有多出個http協議來呢？
筆者曾自己動手寫過一個簡單的web服務器處理軟件，根據我的推斷（不一定準確）。UDP協議具有不可靠性和不安全性，顯然這很難滿足web應用的需要。
而TCP協議是基于連接和三次握手的，雖然具有可靠性，但人具有一定的缺陷。但試想一下，普通的C/S架構軟件，頂多上千個Client同時連接，而B/S架構的網站，十萬人同時在線也是很平常的事兒。如果十萬個客戶端和服務器一直保持連接狀態，那服務器如何滿足承載呢？
這就衍生出了http協議。基于TCP的可靠性連接。通俗點說，就是在請求之后，服務器端立即關閉連接、釋放資源。這樣既保證了資源可用，也吸取了TCP的可靠性的優點。
正因為這點，所以大家通常說http協議是“無狀態”的，也就是“服務器不知道你客戶端干了啥”，其實很大程度上是基于性能考慮的。以至于后來有了session之類的玩意。
實戰準備工作：
在監視網絡方面，windows平臺上有一款叫做Sniffer的優秀軟件，這也是很多“黑客”經常使用的嗅探工具。 在研究http協議時，推薦大家使用一款
叫作httpwatch的工具。（遺憾的是，該工具是收費的。該咋辦就咋辦，你懂的）。安裝完成后，可以在IE瀏覽器的tools中直接打開（目前也支持firefox）。如圖所示：
點擊Record，就可以開始監視并記錄http消息了。stop、Clear等等按鈕的功能，這里就不一一介紹了。拿實例來說話，下面就是我記錄訪問main.aspx頁面的時候記錄的，能夠清晰的看到http報文消息的詳細信息，如圖：
學習http協議，主要需要了解http的請求和響應（當然，還有get、post等請求方式，狀態碼、URI、MIME等）
首先看看http請求消息（就是瀏覽器丟給服務器的）：
一個http請求代表客戶端瀏覽器向服務器發送的數據。一個完整的http請求消息，包含一個請求行，若干個消息頭（請求頭），換行，實體內容
請求行：描述客戶端的請求方式、請求資源的名稱、http協議的版本號。 例如： GET/BOOK/JAVA.HTML HTTP/1.1
請求頭（消息頭）包含（客戶機請求的服務器主機名，客戶機的環境信息等）：
Accept：用于告訴服務器，客戶機支持的數據類型 （例如：Accept:text/html,image/*）
Accept-Charset：用于告訴服務器，客戶機采用的編碼格式
Accept-Encoding：用于告訴服務器，客戶機支持的數據壓縮格式
Accept-Language：客戶機語言環境
Host:客戶機通過這個服務器，想訪問的主機名
If-Modified-Since：客戶機通過這個頭告訴服務器，資源的緩存時間
Referer：客戶機通過這個頭告訴服務器，它（客戶端）是從哪個資源來訪問服務器的（防盜鏈）
User-Agent：客戶機通過這個頭告訴服務器，客戶機的軟件環境（操作系統，瀏覽器版本等）
Cookie：客戶機通過這個頭，將Coockie信息帶給服務器
Connection：告訴服務器，請求完成后，是否保持連接
Date：告訴服務器，當前請求的時間
（換行）
實體內容：
就是指瀏覽器端通過http協議發送給服務器的實體數據。例如：name=dylan&id=110
（get請求時，通過url傳給服務器的值。post請求時，通過表單發送給服務器的值）
再看看HTTP響應消息（服務器返回給瀏覽器的）：
一個http響應代表服務器端向客戶端回送的數據，它包括：
一個狀態行，若干個消息頭，以及實體內容
響應頭(消息頭)包含:
Location：這個頭配合302狀態嗎，用于告訴客戶端找誰
Server：服務器通過這個頭，告訴瀏覽器服務器的類型
Content-Encoding：告訴瀏覽器，服務器的數據壓縮格式
Content-Length：告訴瀏覽器，回送數據的長度
Content-Type：告訴瀏覽器，回送數據的類型
Last-Modified：告訴瀏覽器當前資源緩存時間
Refresh：告訴瀏覽器，隔多長時間刷新
Content- Disposition：告訴瀏覽器以下載的方式打開數據。例如： context.Response.AddHeader("Content-Disposition","attachment:filename=aa.jpg"); context.Response.WriteFile("aa.jpg");
Transfer-Encoding：告訴瀏覽器，傳送數據的編碼格式
ETag：緩存相關的頭（可以做到實時更新）
Expries：告訴瀏覽器回送的資源緩存多長時間。如果是-1或者0，表示不緩存
Cache-Control：控制瀏覽器不要緩存數據 no-cache
Pragma：控制瀏覽器不要緩存數據 no-cache
Connection：響應完成后，是否斷開連接。 close/Keep-Alive
Date：告訴瀏覽器，服務器響應時間
理解了以上的http請求消息和響應消息，相信你對于http協議已經理解得足夠深刻了。關于http協議的更多具體細節，可以參照http RFC文檔。
大致步驟就是：瀏覽器先向服務器發送請求，服務器接收到請求后，做相應的處理，然后封裝好響應報文，再回送給瀏覽器。瀏覽器拿到響應報文后，再通過 瀏覽器引擎去渲染網頁，解析DOM樹，javascript引擎解析并執行腳本操作，插件去干插件該干的事兒...關于瀏覽器渲染、解析的原理，可以參考 http://kb.cnblogs.com/page/129756/
說白了，所謂web的本質，無非是：請求/處理/響應 ，任何的web服務器，任何的服務端編程語言，都沒法脫離這個本質。 而瀏覽器端解析html、圖片等靜態內容，呈現給用戶，腳本引擎執行腳本代碼，完成腳本代碼要做的事兒（例如dom操作，css屬性更改，發送ajax請 求等等）。
筆者淺淺的認為，其實瀏覽器就是一種特殊的Client，而B/S架構也是一種特殊的C/S架構。這里值得一提的是，不同的web服務器和編程語 言，又是如何接收用戶http請求。如何處理，如何響應的呢？筆者拿熟悉的ASP.NET為例，通過反編譯工具查看源代碼（微軟這家伙實在封裝的太好了） 從底層進行了剖析，如圖：
由于篇幅有限，無法再繼續將asp.net、iis web服務器的細節及底層實現再做進一步地進行剖析了。因為微軟的asp.net技術體系實在龐大，而且很復雜。有時間筆者會繼續更新系列文章，歡迎讀者繼續關注。
2012世界末日暨環境保護主題站,關注國內外最新2012世界末日信息,旨在通過關注,收集,展示2012世界末日相關資料的方式,喚醒并提高人們保護環境與愛護地球的意識,引導人類保護環境.
最近一直比較忙，所以一連幾天都沒有更新。本來覺得沒什么，后來有幾個網友都問起為什么沒有更新，才覺得大家對我的博客還是比較關心的。于是覺得挺對不起大家的。終于到了周末，昨天晚上忙乎了一晚上，寫了個Swing演示，今天把它共享出來，算是彌補。
這個是淡出淡入動畫效果：
| |
| |
1. 人得學習能力是否會隨著年齡的增長而變差？
可能是如此，我兩歲的兒子一首唐詩說兩遍就記住了，很長繞口的兒歌《小熊過橋》幾乎能一字不差的唱完；而我是顯然辦不到的。不過發現一個事實，就是人的學 習能力不僅僅是靠記憶能力，跟邏輯思維能力，還有人的經驗也有很大的關系；我們每個人也許都發現，你如果只是個優秀的Java程序員，如果要你去維護一 個.net的系統，不出兩個月， 你馬上就是一個.net專家。因為你知道相關的知識怎么學習，知道如何才能最快定位問題的一般方法。我個人是個完全不懂php得人，結果被強拉過去搞了個 php的項目，結果被認為是php expert! 所以我的最終答案是，人得記憶力更年齡成反比，但是學習能力跟年齡成正比。
2. 人的年齡越大，精力會跟不上程序員這樣高強度的工作嗎？
我的答案也是否定的。首先這是個偽命題，沒有哪件事情是輕松的；你覺得別人比你輕松，那也只是你覺得而已。大體上個人的回報跟付出是成正比的。其實隨著你 的年齡增長，知識積累越多，經驗越豐富，你的工作效率會更高。5年前你修一個Bug要一個星期，現在也許10分鐘就夠了，并且是又快又好。難道不是這樣 嗎？所以你的工作強度事實上會變得更低，因為你的效率更高，你會有更多時間喝咖啡，也會遭你鄰桌的同事低語“這家伙每天無所事事，咋工資比我高那么多？” 因為你的10分鐘就抵別人的一個星期。
3. 人的年齡越大，就沒有激情學習新知識了嗎？
對有些人是，對有些人不是。計算機科學日新月異，確實更新相當快。你真的會跟不上腳步嗎？可能會，如果你自己不學習。但我一定要亦步亦趨嗎？也不見得，無 論如何，即便是軟件開發，也還是有方向，有領域，你只要更上你需要更上的節奏就夠了。今天請我的一個兄弟給我講了下Struts應用，就是給我搞個最小化 的Struts項目，包含所有Struct的重要知識點，然后搬個椅子坐我旁邊，花上半個小時跟我講解；我現在儼然Struts專家了，不信，我跟你講講 看？ 呵呵，開玩笑了。
如果我們覺得每天吃飯不是件枯燥無趣的事，我們應該也不太會拒絕不斷學習；如果我們一定會因為自然規律而失去某些優勢，記得你其實有更多的優勢可以彌補；最重要的是，做你喜歡的事，做你能做的事情。
正月十五，明月高懸；祝福各位龍圖大展！
org.jfree.chart.JFreeChart ：圖表對象，任何類型的圖表的最終表現形式都是在該對象進行一些屬性的定制。JFreeChart引擎本身提供了一個工廠類用于創建不同類型的圖表對象
org.jfree.data.category.XXXDataSet: 數據集對象，用于提供顯示圖表所用的數據。根據不同類型的圖表對應著很多類型的數據集對象類
org.jfree.chart.plot.XXXPlot ：圖表區域對象，基本上這個對象決定著什么樣式的圖表，創建該對象的時候需要Axis、Renderer以及數據集對象的支持
org.jfree.chart.axis.XXXAxis ：用于處理圖表的兩個軸：縱軸和橫軸
org.jfree.chart.render.XXXRender ：負責如何顯示一個圖表對象
org.jfree.chart.urls.XXXURLGenerator: 用于生成Web圖表中每個項目的鼠標點擊鏈接
XXXXXToolTipGenerator: 用于生成圖象的幫助提示，不同類型圖表對應不同類型的工具提示類
JFreeChart類：
void setAntiAlias(boolean flag) 字體模糊邊界
void setBackgroundImage(Image image) 背景圖片
void setBackgroundImageAlignment(int alignment) 背景圖片對齊方式（參數常量在org.jfree.ui.Align類中定義）
void setBackgroundImageAlpha(float alpha) 背景圖片透明度（0.0～1.0）
void setBackgroundPaint(Paint paint) 背景色
void setBorderPaint(Paint paint) 邊界線條顏色
void setBorderStroke(Stroke stroke) 邊界線條筆觸
void setBorderVisible(boolean visible) 邊界線條是否可見
-----------------------------------------------------------------------------------------------------------
TextTitle類：
void setFont(Font font) 標題字體
void setPaint(Paint paint) 標題字體顏色
void setText(String text) 標題內容
-----------------------------------------------------------------------------------------------------------
StandardLegend(Legend)類：
void setBackgroundPaint(Paint paint) 圖示背景色
void setTitle(String title) 圖示標題內容
void setTitleFont(Font font) 圖示標題字體
void setBoundingBoxArcWidth(int arcWidth) 圖示邊界圓角寬
void setBoundingBoxArcHeight(int arcHeight) 圖示邊界圓角高
void setOutlinePaint(Paint paint) 圖示邊界線條顏色
void setOutlineStroke(Stroke stroke) 圖示邊界線條筆觸
void setDisplaySeriesLines(boolean flag) 圖示項是否顯示橫線（折線圖有效）
void setDisplaySeriesShapes(boolean flag) 圖示項是否顯示形狀（折線圖有效）
void setItemFont(Font font) 圖示項字體
void setItemPaint(Paint paint) 圖示項字體顏色
void setAnchor(int anchor) 圖示在圖表中的顯示位置（參數常量在Legend類中定義）
-----------------------------------------------------------------------------------------------------------
Axis類：
void setVisible(boolean flag) 坐標軸是否可見
void setAxisLinePaint(Paint paint) 坐標軸線條顏色（3D軸無效）
void setAxisLineStroke(Stroke stroke) 坐標軸線條筆觸（3D軸無效）
void setAxisLineVisible(boolean visible) 坐標軸線條是否可見（3D軸無效）
void setFixedDimension(double dimension) （用于復合表中對多坐標軸的設置）
void setLabel(String label) 坐標軸標題
void setLabelFont(Font font) 坐標軸標題字體
void setLabelPaint(Paint paint) 坐標軸標題顏色
void setLabelAngle(double angle) 坐標軸標題旋轉角度（縱坐標可以旋轉）
void setTickLabelFont(Font font) 坐標軸標尺值字體
void setTickLabelPaint(Paint paint) 坐標軸標尺值顏色
void setTickLabelsVisible(boolean flag) 坐標軸標尺值是否顯示
void setTickMarkPaint(Paint paint) 坐標軸標尺顏色
void setTickMarkStroke(Stroke stroke) 坐標軸標尺筆觸
void setTickMarksVisible(boolean flag) 坐標軸標尺是否顯示
ValueAxis(Axis)類：
void setAutoRange(boolean auto) 自動設置數據軸數據范圍
void setAutoRangeMinimumSize(double size) 自動設置數據軸數據范圍時數據范圍的最小跨度
void setAutoTickUnitSelection(boolean flag) 數據軸的數據標簽是否自動確定（默認為true）
void setFixedAutoRange(double length) 數據軸固定數據范圍（設置100的話就是顯示MAXVALUE到MAXVALUE-100那段數據范圍）
void setInverted(boolean flag) 數據軸是否反向（默認為false）
void setLowerMargin(double margin) 數據軸下（左）邊距
void setUpperMargin(double margin) 數據軸上（右）邊距
void setLowerBound(double min) 數據軸上的顯示最小值
void setUpperBound(double max) 數據軸上的顯示最大值
void setPositiveArrowVisible(boolean visible) 是否顯示正向箭頭（3D軸無效）
void setNegativeArrowVisible(boolean visible) 是否顯示反向箭頭（3D軸無效）
void setVerticalTickLabels(boolean flag) 數據軸數據標簽是否旋轉到垂直
void setStandardTickUnits(TickUnitSource source) 數據軸的數據標簽（可以只顯示整數標簽，需要將AutoTickUnitSelection設false）
NumberAxis(ValueAxis)類：
void setAutoRangeIncludesZero(boolean flag) 是否強制在自動選擇的數據范圍中包含0
void setAutoRangeStickyZero(boolean flag) 是否強制在整個數據軸中包含0，即使0不在數據范圍中
void setNumberFormatOverride(NumberFormat formatter) 數據軸數據標簽的顯示格式
void setTickUnit(NumberTickUnit unit) 數據軸的數據標簽（需要將AutoTickUnitSelection設false）
DateAxis(ValueAxis)類：
void setMaximumDate(Date maximumDate) 日期軸上的最小日期
void setMinimumDate(Date minimumDate) 日期軸上的最大日期
void setRange(Date lower,Date upper) 日期軸范圍
void setDateFormatOverride(DateFormat formatter) 日期軸日期標簽的顯示格式
void setTickUnit(DateTickUnit unit) 日期軸的日期標簽（需要將AutoTickUnitSelection設false）
void setTickMarkPosition(DateTickMarkPosition position) 日期標簽位置（參數常量在org.jfree.chart.axis.DateTickMarkPosition類中定義）
CategoryAxis(Axis)類：
void setCategoryMargin(double margin) 分類軸邊距
void setLowerMargin(double margin) 分類軸下（左）邊距
void setUpperMargin(double margin) 分類軸上（右）邊距
void setVerticalCategoryLabels(boolean flag) 分類軸標題是否旋轉到垂直
void setMaxCategoryLabelWidthRatio(float ratio) 分類軸分類標簽的最大寬度
-----------------------------------------------------------------------------------------------------------
Plot類：
void setBackgroundImage(Image image) 數據區的背景圖片
void setBackgroundImageAlignment(int alignment) 數據區的背景圖片對齊方式（參數常量在org.jfree.ui.Align類中定義）
void setBackgroundPaint(Paint paint) 數據區的背景圖片背景色
void setBackgroundAlpha(float alpha) 數據區的背景透明度（0.0～1.0）
void setForegroundAlpha(float alpha) 數據區的前景透明度（0.0～1.0）
void setDataAreaRatio(double ratio) 數據區占整個圖表區的百分比
void setOutLinePaint(Paint paint) 數據區的邊界線條顏色
void setOutLineStroke(Stroke stroke) 數據區的邊界線條筆觸
void setNoDataMessage(String message) 沒有數據時顯示的消息
void setNoDataMessageFont(Font font) 沒有數據時顯示的消息字體
void setNoDataMessagePaint(Paint paint) 沒有數據時顯示的消息顏色
CategoryPlot(Plot)類：
void setDataset(CategoryDataset dataset) 數據區的2維數據表
void setColumnRenderingOrder(SortOrder order) 數據分類的排序方式
void setAxisOffset(Spacer offset) 坐標軸到數據區的間距
void setOrientation(PlotOrientation orientation) 數據區的方向（PlotOrientation.HORIZONTAL或PlotOrientation.VERTICAL）
void setDomainAxis(CategoryAxis axis) 數據區的分類軸
void setDomainAxisLocation(AxisLocation location) 分類軸的位置（參數常量在org.jfree.chart.axis.AxisLocation類中定義）
void setDomainGridlinesVisible(boolean visible) 分類軸網格是否可見
void setDomainGridlinePaint(Paint paint) 分類軸網格線條顏色
void setDomainGridlineStroke(Stroke stroke) 分類軸網格線條筆觸
void setRangeAxis(ValueAxis axis) 數據區的數據軸
void setRangeAxisLocation(AxisLocation location) 數據軸的位置（參數常量在org.jfree.chart.axis.AxisLocation類中定義）
void setRangeGridlinesVisible(boolean visible) 數據軸網格是否可見
void setRangeGridlinePaint(Paint paint) 數據軸網格線條顏色
void setRangeGridlineStroke(Stroke stroke) 數據軸網格線條筆觸
void setRenderer(CategoryItemRenderer renderer) 數據區的表示者（詳見Renderer組）
void addAnnotation(CategoryAnnotation annotation) 給數據區加一個注釋
void addRangeMarker(Marker marker,Layer layer) 給數據區加一個數值范圍區域
PiePlot(Plot)類：
void setDataset(PieDataset dataset) 數據區的1維數據表
void setIgnoreNullValues(boolean flag) 忽略無值的分類
void setCircular(boolean flag) 餅圖是否一定是正圓
void setStartAngle(double angle) 餅圖的初始角度
void setDirection(Rotation direction) 餅圖的旋轉方向
void setExplodePercent(int section,double percent) 抽取的那塊（1維數據表的分類下標）以及抽取出來的距離（0.0～1.0），3D餅圖無效
void setLabelBackgroundPaint(Paint paint) 分類標簽的底色
void setLabelFont(Font font) 分類標簽的字體
void setLabelPaint(Paint paint) 分類標簽的字體顏色
void setLabelLinkMargin(double margin) 分類標簽與圖的連接線邊距
void setLabelLinkPaint(Paint paint) 分類標簽與圖的連接線顏色
void setLabelLinkStroke(Stroke stroke) 分類標簽與圖的連接線筆觸
void setLabelOutlinePaint(Paint paint) 分類標簽邊框顏色
void setLabelOutlineStroke(Paint paint) 分類標簽邊框筆觸
void setLabelShadowPaint(Paint paint) 分類標簽陰影顏色
void setMaximumLabelWidth(double width) 分類標簽的最大長度（0.0～1.0）
void setPieIndex(int index) 餅圖的索引（復合餅圖中用到）
void setPieIndex(int index) 餅圖的索引（復合餅圖中用到）
void setSectionOutlinePaint(int section,Paint paint) 指定分類餅的邊框顏色
void setSectionOutlineStroke(int section,Stroke stroke) 指定分類餅的邊框筆觸
void setSectionPaint(int section,Paint paint) 指定分類餅的顏色
void setShadowPaint(Paint paint) 餅圖的陰影顏色
void setShadowXOffset(double offset) 餅圖的陰影相對圖的水平偏移
void setShadowYOffset(double offset) 餅圖的陰影相對圖的垂直偏移
void setLabelGenerator(PieSectionLabelGenerator generator) 分類標簽的格式，設置成null則整個標簽包括連接線都不顯示
void setToolTipGenerator(PieToolTipGenerator generator) MAP中鼠標移上的顯示格式
void setURLGenerator(PieURLGenerator generator) MAP中鉆取鏈接格式
PiePlot3D(PiePlot)類：
void setDepthFactor(double factor) 3D餅圖的Z軸高度（0.0～1.0）
MultiplePiePlot(Plot)類：
void setLimit(double limit) 每個餅圖之間的數據關聯（詳細比較復雜）
void setPieChart(JFreeChart pieChart) 每個餅圖的顯示方式（見JFreeChart類個PiePlot類）
-----------------------------------------------------------------------------------------------------------
AbstractRenderer類：
void setItemLabelAnchorOffset(double offset) 數據標簽的與數據點的偏移
void setItemLabelsVisible(boolean visible) 數據標簽是否可見
void setItemLabelFont(Font font) 數據標簽的字體
void setItemLabelPaint(Paint paint) 數據標簽的字體顏色
void setItemLabelPosition(ItemLabelPosition position) 數據標簽位置
void setPositiveItemLabelPosition(ItemLabelPosition position) 正數標簽位置
void setNegativeItemLabelPosition(ItemLabelPosition position) 負數標簽位置
void setOutLinePaint(Paint paint) 圖形邊框的線條顏色
void setOutLineStroke(Stroke stroke) 圖形邊框的線條筆觸
void setPaint(Paint paint) 所有分類圖形的顏色
void setShape(Shape shape) 所有分類圖形的形狀（如折線圖的點）
void setStroke(Stroke stroke) 所有分類圖形的筆觸（如折線圖的線）
void setSeriesItemLabelsVisible(int series,boolean visible) 指定分類的數據標簽是否可見
void setSeriesItemLabelFont(int series,Font font) 指定分類的數據標簽的字體
void setSeriesItemLabelPaint(int series,Paint paint) 指定分類的數據標簽的字體顏色
void setSeriesItemLabelPosition(int series,ItemLabelPosition position) 數據標簽位置
void setSeriesPositiveItemLabelPosition(int series,ItemLabelPosition position) 正數標簽位置
void setSeriesNegativeItemLabelPosition(int series,ItemLabelPosition position) 負數標簽位置
void setSeriesOutLinePaint(int series,Paint paint) 指定分類的圖形邊框的線條顏色
void setSeriesOutLineStroke(int series,Stroke stroke) 指定分類的圖形邊框的線條筆觸
void setSeriesPaint(int series,Paint paint) 指定分類圖形的顏色
void setSeriesShape(int series,Shape shape) 指定分類圖形的形狀（如折線圖的點）
void setSeriesStroke(int series,Stroke stroke) 指定分類圖形的筆觸（如折線圖的線）
AbstractCategoryItemRenderer(AbstractRenderer)類：
void setLabelGenerator(CategoryLabelGenerator generator) 數據標簽的格式
void setToolTipGenerator(CategoryToolTipGenerator generator) MAP中鼠標移上的顯示格式
void setItemURLGenerator(CategoryURLGenerator generator) MAP中鉆取鏈接格式
void setSeriesLabelGenerator(int series,CategoryLabelGenerator generator) 指定分類的數據標簽的格式
void setSeriesToolTipGenerator(int series,CategoryToolTipGenerator generator) 指定分類的MAP中鼠標移上的顯示格式
void setSeriesItemURLGenerator(int series,CategoryURLGenerator generator) 指定分類的MAP中鉆取鏈接格式
BarRenderer(AbstractCategoryItemRenderer)類：
void setDrawBarOutline(boolean draw) 是否畫圖形邊框
void setItemMargin(double percent) 每個BAR之間的間隔
void setMaxBarWidth(double percent) 每個BAR的最大寬度
void setMinimumBarLength(double min) 最短的BAR長度，避免數值太小而顯示不出
void setPositiveItemLabelPositionFallback(ItemLabelPosition position) 無法在BAR中顯示的正數標簽位置
void setNegativeItemLabelPositionFallback(ItemLabelPosition position) 無法在BAR中顯示的負數標簽位置
BarRenderer3D(BarRenderer)類：
void setWallPaint(Paint paint) 3D坐標軸的墻體顏色
StackedBarRenderer(BarRenderer)類：
沒有特殊的設置
StackedBarRenderer3D(BarRenderer3D)類：
沒有特殊的設置
GroupedStackedBarRenderer(StackedBarRenderer)類：
void setSeriesToGroupMap(KeyToGroupMap map) 將分類自由的映射成若干個組（KeyToGroupMap.mapKeyToGroup(series,group)）
LayeredBarRenderer(BarRenderer)類：
void setSeriesBarWidth(int series,double width) 設定每個分類的寬度（注意設置不要使某分類被覆蓋）
WaterfallBarRenderer(BarRenderer)類：
void setFirstBarPaint(Paint paint) 第一個柱圖的顏色
void setLastBarPaint(Paint paint) 最后一個柱圖的顏色
void setPositiveBarPaint(Paint paint) 正值柱圖的顏色
void setNegativeBarPaint(Paint paint) 負值柱圖的顏色
IntervalBarRenderer(BarRenderer)類：
需要傳IntervalCategoryDataset作為數據源
GanttBarRenderer(IntervalBarRenderer)類：
void setCompletePaint(Paint paint) 完成進度顏色
void setIncompletePaint(Paint paint) 未完成進度顏色
void setStartPercent(double percent) 設置進度條在整條中的起始位置（0.0～1.0）
void setEndPercent(double percent) 設置進度條在整條中的結束位置（0.0～1.0）
StatisticBarRenderer(BarRenderer)類：
需要傳StatisticCategoryDataset作為數據源
LineAndShapeRenderer(AbstractCategoryItemRenderer)類：
void setDrawLines(boolean draw) 是否折線的數據點之間用線連
void setDrawShapes(boolean draw) 是否折線的數據點根據分類使用不同的形狀
void setShapesFilled(boolean filled) 所有分類是否填充數據點圖形
void setSeriesShapesFilled(int series,boolean filled) 指定分類是否填充數據點圖形
void setUseFillPaintForShapeOutline(boolean use) 指定是否填充數據點的Paint也被用于畫數據點形狀的邊框
LevelRenderer(AbstractCategoryItemRenderer)類：
void setItemMargin(double percent) 每個分類之間的間隔
void setMaxItemWidth(double percent) 每個分類的最大寬度
CategoryStepRenderer(AbstractCategoryItemRenderer)類：
void setStagger(boolean shouldStagger) 不同分類的圖是否交錯
MinMaxCategoryRenderer(AbstractCategoryItemRenderer)類：
void setDrawLines(boolean drawLines) 是否在每個分類線間畫連接線
void setGroupPaint(Paint groupPaint) 一組圖形連接線的顏色
void setGroupStroke(Stroke groupStroke) 一組圖形連接線的筆觸
void setMaxIcon(Icon maxIcon) 最大值的ICON
void setMinIcon(Icon minIcon) 最小值的ICON
void setObjectIcon(Icon objectIcon) 所有值的ICON
AreaRender(AbstractCategoryItemRenderer)類：
沒有特殊的設置
StackedAreaRender(AreaRender)類：
沒有特殊的設置
今天我不談抱負理想，也不談具體的技術，我來談幾個看法上的典型錯誤。下面的這些問題都是我曾經遇到，或者是我的朋友們遇到過的問題，這些都是我個人的理解，希望對大家有幫助。
關于設計模式、設計原則
有人認為，熟悉了設計模式、設計原則，就學會了設計。其實，設計模式和設計原則，只是前人根據設計實踐做的總結和提煉，設計，歸根到底是要解決問題的，把具體問題的解決辦法，經過一定的抽象，變成程序員的語言。
我見過一些人，他們知識淵博、見識廣博，甚至理論可以給你闡述得冠冕堂皇，但是到了實際需要解決問題的時候，他們卻拿不出巧妙的、優雅的辦法，這是典型的象牙塔人。
另一方面，也有一些人看不起學習設計模式的人，他們覺得他們已經掌握了軟件設計的奧義，這些對他們來說是毫無意義的詞匯，對此大可以一笑置之。
有時候我們反而被設計模式或設計原則粗暴的掌握束縛了手腳，譬如我遇到這樣一件事情，某位努力的程序員，設計的代碼用遍了組合（例如把User對象 放置到Administrator里面），我好奇地問，有一些類和對象之間的關系很明顯符合繼承的特征，為什么不愿意用它？他說，設計原則告訴我們，要多 用組合，少用繼承。我想，對這些優秀的模式、原則、方法論，如果不能透徹地掌握，不能根據實際場景合適地運用，是不是反而不如對其不了解來的好呢？
關于多種計算機語言的學習
有人覺得學習一種語言就可以了，學習那么多語言沒有必要。事實上，多掌握一門合適的計算機語言不僅僅是多掌握一種謀生的工具，如果一種新的語言能夠很大程度上改變你對編程、對設計的看法，那么興許它就值得你去學習。
譬如C語言，可以培養嚴謹的思維；譬如動態語言，它可以幫助程序員更好地做面向對象的coding；譬如函數式語言，它在工業生產、運算領域有著不可替代的作用。
當然話說回來，所謂術業有專攻，對于某一門計算機語言（包括該語言所需的運行時環境、其中的編譯或解釋的原理）深入的掌握，是很有必要的。
另外，我們時常看到諸多計算機語言孰優孰劣的爭論，計算機語言歸根到底是一種工具，工具是隨著時代發展升級和變更的，單純的優劣爭論沒有太大意義。
關于英語
中國人為什么要學英語，程序員為什么要學英語，當我把那些方法名、變量名全部取成拼音，一樣可以，誰下的這個破規定？
遺憾的是，諸多學習材料、論文、技術資料（尤其是一些剛出不久的技術），都是英語的；另一方面，國際標準、程序員交流的通用方式，都是英文的，我想肯定很難想象，那些有名的framework、lib的源碼，如果用拼音來寫變量名會成什么樣子。
所以，如果你的英語不好（至少讀寫不好），就不要給自己找太借口，英語是一個掌握其他工具的工具，除非你堅信，中文很快就會在計算機界變成世界第一通用的語言。
關于算法
算法有多重要，這一件事的爭議一直都很大。
軟件歸根到底是用來解決問題的，提到算法就不能不提到數學（這也是為什么很多軟件領域的大師都具備相當的數學背景），對于解決問題，這里可以簡單歸納成兩步：
（1）把實際的問題抽象成簡化的數學模型
（2）用算法去解決這個數學問題
算法，在這里應該是一個廣義的概念（這里的算法并不僅僅指大學里學習的狹義的具體算法），算法是解決上述數學問題的辦法。如果工作中你并未意識到它的存在，那只是說明，你抽象出的數學模型比較簡單，解決這個模型的辦法也很簡單，或者有現成的方式可以模仿，或者有現成的框架幫你完成了，以至于你不去關注它、在乎它。
如果你做的事情是充滿創新意義的，是別人從沒有做過的，這時候算法興許就成了決定你成敗的因素。
在當前中國的環境下，視野廣闊和經歷豐富的人很好找，但是企業要招到具備上述兩點能力來解決問題的人，其實是非常困難的。
關于經驗
唯經驗論者的人有很多，他們認為，在軟件企業的職位、薪水、甚至決策能力，都取決于經驗，一個5年經驗的工程師，肯定比3年經驗的工程師能找到更好的飯碗：
“我是老員工，我工作5年了，憑什么工作3年的他薪水比我高那么多”
實際上，很多因素，包括領域積累（這是業務上的，例如互聯網領域、傳統軟件領域，這和所謂的純技術沒有直接關系）、視野、承受壓力的能力等等往往都 在很大程度上取決于“經驗”的積累，但是，這并不是絕對的。有句話叫做“事業一半是干出來的，一半是總結出來的”，也確實有一些出色的程序員，他們善于總 結、善于觀察和積累，并且善于不斷地思考，這樣的程序員就是擁有更多優秀的經驗。
另一方面，程序員是要來解決問題的，經驗不能代替解決問題，有的人具備更優秀的解決問題的能力，他為什么就不能得到更優厚的薪水？
越來越多人開始使用Java,但是他們大多數人沒有做好足夠的思想準備(沒有接受OO思想體系相關培訓)，以致不能很好駕馭Java項目，甚至導致 開發后的Java系統性能緩慢甚至經常當機。很多人覺得這是Java復雜導致，其實根本原因在于：我們原先掌握的關于軟件知識(OO方面)不是太貧乏就是 不恰當，存在認識上和方法上的誤區。
軟件的生命性
軟件是有生命的，這可能是老調重彈了，但是因為它事關分層架構的原由，反復強調都不過分。
一個有生命的軟件首先必須有一個靈活可擴展的基礎架構，其次才是完整的功能。
目前很多人對軟件的思想還是焦點落在后者：完整的功能，覺得一個軟件功能越完整越好，其實關鍵還是架構的靈活性，就是前者，基礎架構好，功能添 加只是時間和工作量問題，但是如果架構不好，功能再完整，也不可能包括未來所有功能，軟件是有生命的，在未來成長時，更多功能需要加入，但是因為基礎架構 不靈活不能方便加入，死路一條。
正因為普通人對軟件存在短視誤區，對功能追求高于基礎架構，很多吃了虧的老程序員就此離開軟件行業，帶走寶貴的失敗經驗，新的盲目的年輕程序員 還是使用老的思維往前沖。其實很多國外免費開源框架如ofbiz compiere和slide也存在這方面陷阱，貌似非常符合胃口，其實類似國內那些幾百元的盜版軟件，擴展性以及持續發展性嚴重不足。
那么選擇現在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基礎架構打好了呢？其實還不盡然，關鍵還是取決于你如何使用這些框架來搭建你的業務系統。
存儲過程和復雜SQL語句的陷阱
首先談談存儲過程使用的誤區，使用存儲過程架構的人以為可以解決性能問題，其實它正是導致性能問題的罪魁禍首之一，打個比喻：如果一個人頻臨死亡，打一針可以讓其延長半年，但是打了這針，其他所有醫療方案就全部失效，請問你會使用這種短視方案嗎？
為什么這樣說呢？如果存儲過程都封裝了業務過程，那么運行負載都集中在數據庫端，要中間J2EE應用服務器干什么？要中間服務器的分布式計算和 集群能力做什么？只能回到過去集中式數據庫主機時代。現在軟件都是面向互聯網的，不象過去那樣局限在一個小局域網，多用戶并發訪問量都是無法確定和衡量， 依靠一臺數據庫主機顯然是不能夠承受這樣惡劣的用戶訪問環境的。(當然搞數據庫集群也只是五十步和百步的區別)。
從分層角度來看，現在三層架構：表現層、業務層和持久層，三個層次應該分割明顯，職責分明：持久層職責持久化保存業務模型對象，業務層對持久層 的調用只是幫助我們激活曾經委托其保管的對象，所以，不能因為持久層是保管者，我們就以其為核心圍繞其編程，除了要求其歸還模型對象外，還要求其做其做復 雜的業務組合。打個比喻：你在火車站將水果和盤子兩個對象委托保管處保管，過了兩天來取時，你還要求保管處將水果去皮切成塊，放在盤子里，做成水果盤給 你，合理嗎？
上面是談過分依賴持久層的一個現象，還有一個正好相反現象，持久層散發出來，開始擠占業務層，腐蝕業務層，整個業務層到處看見的是數據表的影子 (包括數據表的字段)，而不是業務對象。這樣程序員應該多看看OO經典PoEAA.PoEAA 認為除了持久層，不應該在其他地方看到數據表或表字段名。
當然適量使用存儲過程，使用數據庫優點也是允許的。按照Evans DDD理論，可以將SQL語句和存儲過程作為規則Specification一部分。
Hibernate等ORM問題
現在使用Hibernate人也不少，但是他們發現Hibernate性能緩慢，所以尋求解決方案，其實并不是 Hibernate性能緩慢，而是我們使用方式發生錯誤：
"最近本人正搞一個項目，項目中我們用到了struts1.2+hibernate3, 由于關系復雜表和表之間的關系很多，在很多地方把lazy都設置false,所以導致數據一加載很慢，而且查詢一條數據更是非常的慢。"
Hibernate是一個基于對象模型持久化的技術，因此，關鍵是我們需要設計出高質量的對象模型，遵循DDD領域建模原則，減少降低關聯，通 過分層等有效辦法處理關聯。如果采取圍繞數據表進行設計編程，加上表之間關系復雜(沒有科學方法處理、偵察或減少這些關系)，必然導致 系統運行緩慢，其實同樣問題也適用于當初對EJB的實體Bean的CMP抱怨上，實體Bean是Domain Model持久化，如果不首先設計Domain Model,而是設計數據表，和持久化工具設計目標背道而馳，能不出問題嗎？關于這個問題N多年就在Jdon爭論過。
這里同樣延伸出另外一個問題：數據庫設計問題，數據庫是否需要在項目開始設計？
如果我們進行數據庫設計，那么就產生了一系列問題：當我們使用Hibernate實現持久保存時，必須考慮事先設計好的數據庫表結構以及他們的關系如何和業務對象實現映射，這實際上是非常難實現的，這也是很多人覺得使用ORM框架棘手根本原因所在。
當然，也有腦力相當發達的人可以實現，但是這種圍繞數據庫實現映射的結果必然扭曲業務對象，這類似于兩個板塊(數據表和業務對象)相撞，必然產 生地震，地震的結果是兩敗俱傷，軟的一方吃虧，業務對象是代碼，相當于數據表結構，屬于軟的一方，最后導致業務對象變成數據傳輸對象DTO, DTO滿天飛，性能和維護問題隨之而來。
領域建模解決了上述眾多不協調問題，特別是ORM痛苦使用問題，關于 ORM/Hibernate使用還是那句老話：如果你不掌握領域建模方法，那么就不要用Hibernate,對于這個層次的你：也許No ORM 更是一個簡單之道： No ORM: The simplest solution
Spring分層矛盾問題
Spring是以挑戰EJB面貌出現，其本身擁有的強大組件定制功能是優點，但是存在實戰的一些問題，Spring作為業務層框架，不支持業務層Session 功能。
具體舉例如下：當我們實現購物車之類業務功能時，需要將購物場合保存到 Session中，由于業務層沒有方便的Session支持，我們只得將購物車保存到 HttpSession,而HttpSession只有通過HttpRequest才能獲得，再因為在Spring業務層容器中是無法訪問到 HttpRequest這個對象的，所以，最后我們只能將"購物車保存到HttpSession"這個功能放在表現層中實現，而這個功能明顯應該屬于業務 層功能，這就導致我們的Java項目層次混亂，維護性差。 違背了使用Spring和分層架構最初目的。
領域驅動設計DDD
現在回到我們討論的重點上來，分層架構是我們使用Java的根本原因之一，域建模專家Eric Evans在他的"Domain Model Design"一書中開篇首先強調的是分層架構，整個DDD理論實際是告訴我們如何使用模型對象oo技術和分層架構來設計實現一個Java項目。
我們現在很多人知道Java項目基本有三層：表現層 業務層和持久層，當我們執著于討論各層框架如何選擇之時，實際上我們真正的項目開發工作還沒有開始，就是我們選定了某種框架的組合(如 Struts+Spring+Hibernate或Struts+EJB或Struts+ JdonFramework)，我們還沒有意識到業務層工作還需要大量工作，DDD提供了在業務層中再劃分新的層次思想，如領域層和服務層，甚至再細分為 作業層、能力層、策略層等等。通過層次細化方式達到復雜軟件的松耦合。DDD提供了如何細分層次的方式
當我們將精力花費在架構技術層面的討論和研究上時，我們可能忘記以何種依據選擇這些架構技術？選擇標準是什么？領域驅動設計DDD 回答了這樣的問題，DDD會告訴你如果一個框架不能協助你實現分層架構，那就拋棄它，同時，DDD也指出選擇框架的考慮目的，使得你不會人云亦云，陷入復 雜的技術細節迷霧中，迷失了架構選擇的根本方向。
現在也有些人誤以為DDD是一種新的理論，其實DDD和設計模式一樣，不是一種新的理論，而是實戰經驗的總結，它將前人 使用面向模型設計的方法經驗提煉出來，供后來者學習，以便迅速找到駕馭我們軟件項目的根本之道。