什么是HTTP協(xié)議

協(xié)議是指計(jì)算機(jī)通信網(wǎng)絡(luò)中兩臺(tái)計(jì)算機(jī)之間進(jìn)行通信所必須共同遵守的規(guī)定或規(guī)則，超文本傳輸協(xié)議(HTTP)是一種通信協(xié)議，它允許將超文本標(biāo)記語(yǔ)言(HTML)文檔從Web服務(wù)器傳送到客戶端的瀏覽器

目前我們使用的是HTTP/1.1 版本

Web服務(wù)器，瀏覽器,代理服務(wù)器

當(dāng)我們打開瀏覽器，在地址欄中輸入U(xiǎn)RL，然后我們就看到了網(wǎng)頁(yè)。 原理是怎樣的呢？

實(shí)際上我們輸入U(xiǎn)RL后，我們的瀏覽器給Web服務(wù)器發(fā)送了一個(gè)Request, Web服務(wù)器接到Request后進(jìn)行處理，生成相應(yīng)的Response，然后發(fā)送給瀏覽器， 瀏覽器解析Response中的HTML,這樣我們就看到了網(wǎng)頁(yè)，過(guò)程如下圖所示

我們的Request 有可能是經(jīng)過(guò)了代理服務(wù)器，最后才到達(dá)Web服務(wù)器的。

過(guò)程如下圖所示

代理服務(wù)器就是網(wǎng)絡(luò)信息的中轉(zhuǎn)站，有什么功能呢？

1. 提高訪問(wèn)速度， 大多數(shù)的代理服務(wù)器都有緩存功能。

2. 突破限制， 也就是翻-墻了

3. 隱藏身份。

URL詳解

 URL(Uniform Resource Locator) 地址用于描述一個(gè)網(wǎng)絡(luò)上的資源,  基本格式如下

schema://host[:port#]/path/.../[?query-string][#anchor]

scheme               指定低層使用的協(xié)議(例如：http, https, ftp)

host                   HTTP服務(wù)器的IP地址或者域名

port#                 HTTP服務(wù)器的默認(rèn)端口是80，這種情況下端口號(hào)可以省略。如果使用了別的端口，必須指明，例如 http://www.cnblogs.com:8080/

path                   訪問(wèn)資源的路徑

query-string       發(fā)送給http服務(wù)器的數(shù)據(jù)

anchor-             錨

URL 的一個(gè)例子

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協(xié)議是無(wú)狀態(tài)的

http協(xié)議是無(wú)狀態(tài)的，同一個(gè)客戶端的這次請(qǐng)求和上次請(qǐng)求是沒有對(duì)應(yīng)關(guān)系，對(duì)http服務(wù)器來(lái)說(shuō)，它并不知道這兩個(gè)請(qǐng)求來(lái)自同一個(gè)客戶端。 為了解決這個(gè)問(wèn)題， Web程序引入了Cookie機(jī)制來(lái)維護(hù)狀態(tài).

HTTP消息的結(jié)構(gòu)

先看Request 消息的結(jié)構(gòu),   Request 消息分為3部分，第一部分叫Request line, 第二部分叫Request header, 第三部分是body. header和body之間有個(gè)空行， 結(jié)構(gòu)如下圖

第一行中的Method表示請(qǐng)求方法,比如"POST","GET",  Path-to-resoure表示請(qǐng)求的資源， Http/version-number 表示HTTP協(xié)議的版本號(hào)

當(dāng)使用的是"GET" 方法的時(shí)候， body是為空的

比如我們打開博客園首頁(yè)的request 如下

GET http://www.cnblogs.com/ HTTP/1.1 Host: www.cnblogs.com

下面我們打開Fiddler 捕捉一個(gè)博客園登錄的Request 然后分析下它的結(jié)構(gòu), 在Inspectors tab下以Raw的方式可以看到完整的Request的消息，   如下圖

我們?cè)倏碦esponse消息的結(jié)構(gòu), 和Request消息的結(jié)構(gòu)基本一樣。 同樣也分為三部分,第一部分叫Response line, 第二部分叫Response header，第三部分是body. header和body之間也有個(gè)空行,  結(jié)構(gòu)如下圖

HTTP/version-number表示HTTP協(xié)議的版本號(hào)，  status-code 和message 請(qǐng)看下節(jié)[狀態(tài)代碼]的詳細(xì)解釋.

我們用Fiddler 捕捉一個(gè)博客園首頁(yè)的Response然后分析下它的結(jié)構(gòu), 在Inspectors tab下以Raw的方式可以看到完整的Response的消息，   如下圖

Get和Post方法的區(qū)別

Http協(xié)議定義了很多與服務(wù)器交互的方法，最基本的有4種，分別是GET,POST,PUT,DELETE. 一個(gè)URL地址用于描述一個(gè)網(wǎng)絡(luò)上的資源，而HTTP中的GET, POST, PUT, DELETE就對(duì)應(yīng)著對(duì)這個(gè)資源的查，改，增，刪4個(gè)操作。 我們最常見的就是GET和POST了。GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息.

我們看看GET和POST的區(qū)別

1. GET提交的數(shù)據(jù)會(huì)放在URL之后，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連，如EditPosts.aspx?name=test1&id=123456.  POST方法是把提交的數(shù)據(jù)放在HTTP包的Body中.

2. GET提交的數(shù)據(jù)大小有限制（因?yàn)闉g覽器對(duì)URL的長(zhǎng)度有限制），而POST方法提交的數(shù)據(jù)沒有限制.

3. GET方式需要使用Request.QueryString來(lái)取得變量的值，而POST方式通過(guò)Request.Form來(lái)獲取變量的值。

4. GET方式提交數(shù)據(jù)，會(huì)帶來(lái)安全問(wèn)題，比如一個(gè)登錄頁(yè)面，通過(guò)GET方式提交數(shù)據(jù)時(shí)，用戶名和密碼將出現(xiàn)在URL上，如果頁(yè)面可以被緩存或者其他人可以訪問(wèn)這臺(tái)機(jī)器，就可以從歷史記錄獲得該用戶的賬號(hào)和密碼.

狀態(tài)碼

Response 消息中的第一行叫做狀態(tài)行，由HTTP協(xié)議版本號(hào)， 狀態(tài)碼， 狀態(tài)消息 三部分組成。

狀態(tài)碼用來(lái)告訴HTTP客戶端,HTTP服務(wù)器是否產(chǎn)生了預(yù)期的Response.

HTTP/1.1中定義了5類狀態(tài)碼， 狀態(tài)碼由三位數(shù)字組成，第一個(gè)數(shù)字定義了響應(yīng)的類別

1XX  提示信息 - 表示請(qǐng)求已被成功接收，繼續(xù)處理

2XX  成功 - 表示請(qǐng)求已被成功接收，理解，接受

3XX  重定向 - 要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的處理

4XX  客戶端錯(cuò)誤 -  請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無(wú)法實(shí)現(xiàn)

5XX  服務(wù)器端錯(cuò)誤 -   服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求

看看一些常見的狀態(tài)碼

200 OK

最常見的就是成功響應(yīng)狀態(tài)碼200了， 這表明該請(qǐng)求被成功地完成，所請(qǐng)求的資源發(fā)送回客戶端

如下圖， 打開博客園首頁(yè)

302 Found

重定向，新的URL會(huì)在response 中的Location中返回，瀏覽器將會(huì)自動(dòng)使用新的URL發(fā)出新的Request

例如在IE中輸入， http://www.google.com. HTTP服務(wù)器會(huì)返回304， IE取到Response中Location header的新URL, 又重新發(fā)送了一個(gè)Request.

304 Not Modified

代表上次的文檔已經(jīng)被緩存了， 還可以繼續(xù)使用，

例如打開博客園首頁(yè), 發(fā)現(xiàn)很多Response 的status code 都是304

提示：　如果你不想使用本地緩存可以用Ctrl+F5 強(qiáng)制刷新頁(yè)面

400 Bad Request  客戶端請(qǐng)求與語(yǔ)法錯(cuò)誤，不能被服務(wù)器所理解

403 Forbidden 服務(wù)器收到請(qǐng)求，但是拒絕提供服務(wù)

404 Not Found

請(qǐng)求資源不存在（輸錯(cuò)了URL）

比如在IE中輸入一個(gè)錯(cuò)誤的URL， http://www.cnblogs.com/tesdf.aspx

500 Internal Server Error 服務(wù)器發(fā)生了不可預(yù)期的錯(cuò)誤

503 Server Unavailable 服務(wù)器當(dāng)前不能處理客戶端的請(qǐng)求，一段時(shí)間后可能恢復(fù)正常

HTTP Request header

使用Fiddler 能很方便的查看Reques header, 點(diǎn)擊Inspectors tab ->Request tab-> headers  如下圖所示.

header 有很多，比較難以記憶，我們也按照Fiddler那樣把header 進(jìn)行分類，這樣比較清晰也容易記憶。

Cache 頭域

If-Modified-Since

作用： 把瀏覽器端緩存頁(yè)面的最后修改時(shí)間發(fā)送到服務(wù)器去，服務(wù)器會(huì)把這個(gè)時(shí)間與服務(wù)器上實(shí)際文件的最后修改時(shí)間進(jìn)行對(duì)比。如果時(shí)間一致，那么返回304，客戶端 就直接使用本地緩存文件。如果時(shí)間不一致，就會(huì)返回200和新的文件內(nèi)容。客戶端接到之后，會(huì)丟棄舊文件，把新文件緩存起來(lái)，并顯示在瀏覽器中.

例如：If-Modified-Since: Thu, 09 Feb 2012 09:07:57 GMT

實(shí)例如下圖

If-None-Match

作用: If-None-Match和ETag一起工作，工作原理是在HTTP Response中添加ETag信息。 當(dāng)用戶再次請(qǐng)求該資源時(shí)，將在HTTP Request 中加入If-None-Match信息(ETag的值)。如果服務(wù)器驗(yàn)證資源的ETag沒有改變（該資源沒有更新），將返回一個(gè)304狀態(tài)告訴客戶端使用 本地緩存文件。否則將返回200狀態(tài)和新的資源和Etag.  使用這樣的機(jī)制將提高網(wǎng)站的性能

例如: If-None-Match: "03f2b33c0bfcc1:0"

實(shí)例如下圖

Pragma

作用： 防止頁(yè)面被緩存， 在HTTP/1.1版本中，它和Cache-Control:no-cache作用一模一樣

Pargma只有一個(gè)用法， 例如： Pragma: no-cache

注意: 在HTTP/1.0版本中，只實(shí)現(xiàn)了Pragema:no-cache, 沒有實(shí)現(xiàn)Cache-Control

Cache-Control

作用: 這個(gè)是非常重要的規(guī)則。 這個(gè)用來(lái)指定Response-Request遵循的緩存機(jī)制。各個(gè)指令含義如下

Cache-Control:Public   可以被任何緩存所緩存（）

Cache-Control:Private     內(nèi)容只緩存到私有緩存中

Cache-Control:no-cache  所有內(nèi)容都不會(huì)被緩存

還有其他的一些用法， 我沒搞懂其中的意思， 請(qǐng)大家參考其他的資料

Client 頭域

Accept

作用： 瀏覽器端可以接受的媒體類型,

例如：  Accept: text/html  代表瀏覽器可以接受服務(wù)器回發(fā)的類型為 text/html  也就是我們常說(shuō)的html文檔,

如果服務(wù)器無(wú)法返回text/html類型的數(shù)據(jù),服務(wù)器應(yīng)該返回一個(gè)406錯(cuò)誤(non acceptable)

通配符 * 代表任意類型

例如  Accept: */*  代表瀏覽器可以處理所有類型,(一般瀏覽器發(fā)給服務(wù)器都是發(fā)這個(gè))

Accept-Encoding：

作用： 瀏覽器申明自己接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什么壓縮方法（gzip，deflate），（注意：這不是只字符編碼）;

例如： Accept-Encoding: gzip, deflate

Accept-Language

作用： 瀏覽器申明自己接收的語(yǔ)言。 

語(yǔ)言跟字符集的區(qū)別：中文是語(yǔ)言，中文有多種字符集，比如big5，gb2312，gbk等等；

例如： Accept-Language: en-us

User-Agent

作用：告訴HTTP服務(wù)器， 客戶端使用的操作系統(tǒng)和瀏覽器的名稱和版本.

我們上網(wǎng)登陸論壇的時(shí)候，往往會(huì)看到一些歡迎信息，其中列出了你的操作系統(tǒng)的名稱和版本，你所使用的瀏覽器的名稱和版本，這往往讓很多人感到很神 奇，實(shí)際上，服務(wù)器應(yīng)用程序就是從User-Agent這個(gè)請(qǐng)求報(bào)頭域中獲取到這些信息User-Agent請(qǐng)求報(bào)頭域允許客戶端將它的操作系統(tǒng)、瀏覽器 和其它屬性告訴服務(wù)器。

例如： 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（通常我們說(shuō)Charset包括了相應(yīng)的字符編碼方案）；

例如：

Cookie/Login 頭域

Cookie:

作用： 最重要的header, 將cookie的值發(fā)送給HTTP 服務(wù)器

Entity頭域

Content-Length

作用：發(fā)送給HTTP服務(wù)器數(shù)據(jù)的長(zhǎng)度。

例如： Content-Length: 38

Content-Type

作用：

例如：Content-Type: application/x-www-form-urlencoded

Miscellaneous 頭域

Referer:

作用： 提供了Request的上下文信息的服務(wù)器，告訴服務(wù)器我是從哪個(gè)鏈接過(guò)來(lái)的，比如從我主頁(yè)上鏈接到一個(gè)朋友那里，他的服務(wù)器就能夠從HTTP Referer中統(tǒng)計(jì)出每天有多少用戶點(diǎn)擊我主頁(yè)上的鏈接訪問(wèn)他的網(wǎng)站。

例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT

Transport 頭域

Connection

例如：　Connection: keep-alive   當(dāng)一個(gè)網(wǎng)頁(yè)打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉，如果客戶端再次訪問(wèn)這個(gè)服務(wù)器上的網(wǎng)頁(yè)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接

例如：  Connection: close  代表一個(gè)Request完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接會(huì)關(guān)閉， 當(dāng)客戶端再次發(fā)送Request，需要重新建立TCP連接。

Host（發(fā)送請(qǐng)求時(shí)，該報(bào)頭域是必需的）

作用: 請(qǐng)求報(bào)頭域主要用于指定被請(qǐng)求資源的Internet主機(jī)和端口號(hào)，它通常從HTTP URL中提取出來(lái)的

例如: 我們?cè)跒g覽器中輸入：http://www.guet.edu.cn/index.html

瀏覽器發(fā)送的請(qǐng)求消息中，就會(huì)包含Host請(qǐng)求報(bào)頭域，如下：

Host：http://www.guet.edu.cn

此處使用缺省端口號(hào)80，若指定了端口號(hào)，則變成：Host：指定端口號(hào)

HTTP Response header

同樣使用Fiddler 查看Response header, 點(diǎn)擊Inspectors tab ->Response tab-> headers  如下圖所示

 我們也按照Fiddler那樣把header 進(jìn)行分類，這樣比較清晰也容易記憶。

Cache頭域

Date

作用:  生成消息的具體時(shí)間和日期

例如：　Date: Sat, 11 Feb 2012 11:35:14 GMT 

Expires

作用: 瀏覽器會(huì)在指定過(guò)期時(shí)間內(nèi)使用本地緩存

例如: Expires: Tue, 08 Feb 2022 11:35:14 GMT

Vary

作用：

例如: Vary: Accept-Encoding

Cookie/Login 頭域

P3P

作用: 用于跨域設(shè)置Cookie, 這樣可以解決iframe跨域訪問(wèn)cookie的問(wèn)題

例如: 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 發(fā)送到客戶端瀏覽器， 每一個(gè)寫入cookie都會(huì)生成一個(gè)Set-Cookie.

例如: Set-Cookie: sc=4c31523a; path=/; domain=.acookie.taobao.com

Entity頭域

ETag

作用:  和If-None-Match 配合使用。 （實(shí)例請(qǐng)看上節(jié)中If-None-Match的實(shí)例）

例如: ETag: "03f2b33c0bfcc1:0"

Last-Modified:

作用： 用于指示資源的最后修改日期和時(shí)間。（實(shí)例請(qǐng)看上節(jié)的If-Modified-Since的實(shí)例）

例如: Last-Modified: Wed, 21 Dec 2011 09:09:10 GMT

Content-Type

作用：WEB服務(wù)器告訴瀏覽器自己響應(yīng)的對(duì)象的類型和字符集,

例如:

Content-Type: text/html; charset=utf-8

Content-Type:text/html;charset=GB2312

Content-Type: image/jpeg

Content-Length

指明實(shí)體正文的長(zhǎng)度，以字節(jié)方式存儲(chǔ)的十進(jìn)制數(shù)字來(lái)表示。在數(shù)據(jù)下行的過(guò)程中，Content-Length的方式要預(yù)先在服務(wù)器中緩存所有數(shù)據(jù)，然后所有數(shù)據(jù)再一股腦兒地發(fā)給客戶端。

例如: Content-Length: 19847

Content-Encoding

WEB服務(wù)器表明自己使用了什么壓縮方法（gzip，deflate）壓縮響應(yīng)中的對(duì)象。

例如：Content-Encoding：gzip

Content-Language

作用： WEB服務(wù)器告訴瀏覽器自己響應(yīng)的對(duì)象的語(yǔ)言者

例如： Content-Language:da

Miscellaneous 頭域

Server:

作用：指明HTTP服務(wù)器的軟件信息

例如:Server: Microsoft-IIS/7.5

X-AspNet-Version:

作用：如果網(wǎng)站是用ASP.NET開發(fā)的，這個(gè)header用來(lái)表示ASP.NET的版本

例如: X-AspNet-Version: 4.0.30319

X-Powered-By:

作用：表示網(wǎng)站是用什么技術(shù)開發(fā)的

例如： X-Powered-By: ASP.NET

Transport頭域

Connection

例如：　Connection: keep-alive   當(dāng)一個(gè)網(wǎng)頁(yè)打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉，如果客戶端再次訪問(wèn)這個(gè)服務(wù)器上的網(wǎng)頁(yè)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接

例如：  Connection: close  代表一個(gè)Request完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接會(huì)關(guān)閉， 當(dāng)客戶端再次發(fā)送Request，需要重新建立TCP連接。

Location頭域

Location

作用： 用于重定向一個(gè)新的位置, 包含新的URL地址

 實(shí)例請(qǐng)看304狀態(tài)實(shí)例

HTTP協(xié)議是無(wú)狀態(tài)的和Connection: keep-alive的區(qū)別

無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。從另一方面講，打開一個(gè)服務(wù)器上的網(wǎng)頁(yè)和你之前打開這個(gè)服務(wù)器上的網(wǎng)頁(yè)之間沒有任何聯(lián)系

HTTP是一個(gè)無(wú)狀態(tài)的面向連接的協(xié)議，無(wú)狀態(tài)不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協(xié)議（無(wú)連接）

 Keep-Alive不會(huì)永久保持連接，它有一個(gè)保持時(shí)間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個(gè)時(shí)間

    收到一個(gè)朋友的郵件說(shuō)如何在Swing中實(shí)現(xiàn)組件的動(dòng)畫效果，就像JIDE的那些組件一樣。的確Swing框架的靈活性和可擴(kuò)展性，使得它非常適合做這樣Makeover工作。我簡(jiǎn)單總結(jié)一了以下，這種組件不外乎要有以下三種元素：

    1.外觀華麗。這包括使用漸變色，線條和字體反走樣，圖標(biāo)設(shè)計(jì)漂亮搶眼，界面變化要柔和等等。但要避免設(shè)計(jì)太花哨，給人華而不實(shí)的感覺。原則上避免顏色太 碎，圖標(biāo)應(yīng)以簡(jiǎn)潔為主，不可濫用圖片等。技術(shù)上沒有多大要求，主要是美工，你需要掌握各種做圖工具，自己最好有好的審美和設(shè)計(jì)能力。

    2.動(dòng)畫效果。組件行為變化要柔和化，盡量使用動(dòng)畫效果，如淡入淡出、滾動(dòng)彈出等等。技術(shù)上最常用的方法是使用javax.swing.Timer。為什 么要使用javax.swing.Timer，這是因?yàn)閖avax.swing.Timer觸發(fā)的事件都在EDT上執(zhí)行，是線程安全的。除此外還需掌握 Java 2D的常用接口及圖像處理的常見技巧。

    3.空間布局。這種組件空間布局的特點(diǎn)是立體、動(dòng)態(tài)、拖拽式的。這和人的認(rèn)知能力有關(guān)。人類認(rèn)知的特點(diǎn)是具體到抽象。二維、靜態(tài)和鍵盤式操作對(duì)普通用戶來(lái) 說(shuō)太過(guò)抽象和專業(yè)化，需要一定的輔助學(xué)習(xí)才能理解的。而三維、動(dòng)態(tài)、拖拽式操作更貼近于感性的認(rèn)知范疇。因此這類組件經(jīng)常有浮動(dòng)式窗口、組件布局動(dòng)態(tài)變化 及拖拽式操作等特征。實(shí)現(xiàn)技術(shù)包括布局管理器(LayoutManager)、Swing組件分層結(jié)構(gòu)、Swing事件體系結(jié)構(gòu)以及DnD接口等。   

    美工對(duì)于java程序員來(lái)說(shuō)可能比較缺乏，但是華麗外觀不僅僅是美工技術(shù)，這包括一些宏觀設(shè)計(jì)原則。java程序員完全可以通過(guò)掌握這些方針原則來(lái)提高自 己的設(shè)計(jì)水平。前面文章介紹那個(gè)《Swing外觀設(shè)計(jì)方針》就是一本這樣的書。至于美工，我覺得如果你有美術(shù)天分，那就要充分利用；如果沒有，那么你可以 模仿，熟悉幾種的圖形工具就完全可以不用自己的畫圖做出比較漂亮的圖標(biāo)、圖片（當(dāng)然沒有考慮版權(quán)問(wèn)題）。我就是后者，但是我發(fā)現(xiàn)我平時(shí)只需要PrScrn 鍵(抓圖）、Paint（Windows 畫圖工具，切圖、剪裁、轉(zhuǎn)換格式）、PowerPoint/OpenOffice Imprise（畫圖）、Google Image（搜索圖片）就已經(jīng)足夠了。其他所需的技術(shù)就需要你掌握Swing和Java 2D方方面面的技術(shù)了。當(dāng)然復(fù)雜的組件不僅僅是靠掌握這些技術(shù)能解決的，可能你還需要能比較好地熟悉各種編程模式。   

    這個(gè)朋友特別提到Windows上的折疊式操作面板，他說(shuō)：   

    另外，我對(duì)JIDE中兩個(gè)東西很感興趣，一個(gè)是CollapsiblePanel（Windows Explorer左邊的常見任務(wù)），點(diǎn)擊后折疊、展開子面板，而且是動(dòng)畫效果

    因此昨晚就特地試了一下。雖然以前就大概明白使用Timer和布局管理器以及圖像處理就可以實(shí)現(xiàn)這些東西，但一直沒有做。昨晚的實(shí)驗(yàn)還是很成功的，大概花 了兩個(gè)小時(shí)就實(shí)現(xiàn)了這個(gè)面板。工作過(guò)程大概就是分解這些面板組件、解析那部分需要?jiǎng)赢嫛?yīng)該在哪兒觸發(fā)何種事件。另外就是編寫這些組件，不斷調(diào)試。這個(gè)過(guò) 程的大部分時(shí)間都被效果調(diào)整占去了。你需要不斷的運(yùn)行程序，抓取屏幕，然后將它帖到Paint中，然后放大，然后和Windows上的抓圖比較，包括大 小、尺寸、顏色、字體、微觀變化等等。最后算是基本實(shí)現(xiàn)了Windows這個(gè)折疊式的面板組件。下面的是我的演示程序的一個(gè)抓圖：

這個(gè)是淡出淡入動(dòng)畫效果：

    下面的Enable Animation的JCheckBox可以設(shè)置是否使用動(dòng)畫效果。選擇上折疊和展開就具有動(dòng)畫效果。   

    這個(gè)組件的類名是dyno.swing.beans.FolderPane。使用比較簡(jiǎn)單： 

        主要接口有兩個(gè)：  

     1. 人得學(xué)習(xí)能力是否會(huì)隨著年齡的增長(zhǎng)而變差？

     可能是如此，我兩歲的兒子一首唐詩(shī)說(shuō)兩遍就記住了，很長(zhǎng)繞口的兒歌《小熊過(guò)橋》幾乎能一字不差的唱完；而我是顯然辦不到的。不過(guò)發(fā)現(xiàn)一個(gè)事實(shí)，就是人的學(xué) 習(xí)能力不僅僅是靠記憶能力，跟邏輯思維能力，還有人的經(jīng)驗(yàn)也有很大的關(guān)系；我們每個(gè)人也許都發(fā)現(xiàn)，你如果只是個(gè)優(yōu)秀的Java程序員，如果要你去維護(hù)一 個(gè).net的系統(tǒng)，不出兩個(gè)月， 你馬上就是一個(gè).net專家。因?yàn)槟阒老嚓P(guān)的知識(shí)怎么學(xué)習(xí)，知道如何才能最快定位問(wèn)題的一般方法。我個(gè)人是個(gè)完全不懂php得人，結(jié)果被強(qiáng)拉過(guò)去搞了個(gè) php的項(xiàng)目，結(jié)果被認(rèn)為是php expert!  所以我的最終答案是，人得記憶力更年齡成反比，但是學(xué)習(xí)能力跟年齡成正比。

      2. 人的年齡越大，精力會(huì)跟不上程序員這樣高強(qiáng)度的工作嗎？

      我的答案也是否定的。首先這是個(gè)偽命題，沒有哪件事情是輕松的；你覺得別人比你輕松，那也只是你覺得而已。大體上個(gè)人的回報(bào)跟付出是成正比的。其實(shí)隨著你 的年齡增長(zhǎng)，知識(shí)積累越多，經(jīng)驗(yàn)越豐富，你的工作效率會(huì)更高。5年前你修一個(gè)Bug要一個(gè)星期，現(xiàn)在也許10分鐘就夠了，并且是又快又好。難道不是這樣 嗎？所以你的工作強(qiáng)度事實(shí)上會(huì)變得更低，因?yàn)槟愕男矢撸銜?huì)有更多時(shí)間喝咖啡，也會(huì)遭你鄰桌的同事低語(yǔ)“這家伙每天無(wú)所事事，咋工資比我高那么多？” 因?yàn)槟愕?0分鐘就抵別人的一個(gè)星期。

     3. 人的年齡越大，就沒有激情學(xué)習(xí)新知識(shí)了嗎？

      對(duì)有些人是，對(duì)有些人不是。計(jì)算機(jī)科學(xué)日新月異，確實(shí)更新相當(dāng)快。你真的會(huì)跟不上腳步嗎？可能會(huì)，如果你自己不學(xué)習(xí)。但我一定要亦步亦趨嗎？也不見得，無(wú) 論如何，即便是軟件開發(fā)，也還是有方向，有領(lǐng)域，你只要更上你需要更上的節(jié)奏就夠了。今天請(qǐng)我的一個(gè)兄弟給我講了下Struts應(yīng)用，就是給我搞個(gè)最小化 的Struts項(xiàng)目，包含所有Struct的重要知識(shí)點(diǎn)，然后搬個(gè)椅子坐我旁邊，花上半個(gè)小時(shí)跟我講解；我現(xiàn)在儼然Struts專家了，不信，我跟你講講 看？ 呵呵，開玩笑了。

    如果我們覺得每天吃飯不是件枯燥無(wú)趣的事，我們應(yīng)該也不太會(huì)拒絕不斷學(xué)習(xí)；如果我們一定會(huì)因?yàn)樽匀灰?guī)律而失去某些優(yōu)勢(shì)，記得你其實(shí)有更多的優(yōu)勢(shì)可以彌補(bǔ)；最重要的是，做你喜歡的事，做你能做的事情。

    正月十五，明月高懸；祝福各位龍圖大展！

今天我不談抱負(fù)理想，也不談具體的技術(shù)，我來(lái)談幾個(gè)看法上的典型錯(cuò)誤。下面的這些問(wèn)題都是我曾經(jīng)遇到，或者是我的朋友們遇到過(guò)的問(wèn)題，這些都是我個(gè)人的理解，希望對(duì)大家有幫助。

關(guān)于設(shè)計(jì)模式、設(shè)計(jì)原則

有人認(rèn)為，熟悉了設(shè)計(jì)模式、設(shè)計(jì)原則，就學(xué)會(huì)了設(shè)計(jì)。其實(shí)，設(shè)計(jì)模式和設(shè)計(jì)原則，只是前人根據(jù)設(shè)計(jì)實(shí)踐做的總結(jié)和提煉，設(shè)計(jì)，歸根到底是要解決問(wèn)題的，把具體問(wèn)題的解決辦法，經(jīng)過(guò)一定的抽象，變成程序員的語(yǔ)言。

我見過(guò)一些人，他們知識(shí)淵博、見識(shí)廣博，甚至理論可以給你闡述得冠冕堂皇，但是到了實(shí)際需要解決問(wèn)題的時(shí)候，他們卻拿不出巧妙的、優(yōu)雅的辦法，這是典型的象牙塔人。

另一方面，也有一些人看不起學(xué)習(xí)設(shè)計(jì)模式的人，他們覺得他們已經(jīng)掌握了軟件設(shè)計(jì)的奧義，這些對(duì)他們來(lái)說(shuō)是毫無(wú)意義的詞匯，對(duì)此大可以一笑置之。

有時(shí)候我們反而被設(shè)計(jì)模式或設(shè)計(jì)原則粗暴的掌握束縛了手腳，譬如我遇到這樣一件事情，某位努力的程序員，設(shè)計(jì)的代碼用遍了組合（例如把User對(duì)象 放置到Administrator里面），我好奇地問(wèn)，有一些類和對(duì)象之間的關(guān)系很明顯符合繼承的特征，為什么不愿意用它？他說(shuō)，設(shè)計(jì)原則告訴我們，要多 用組合，少用繼承。我想，對(duì)這些優(yōu)秀的模式、原則、方法論，如果不能透徹地掌握，不能根據(jù)實(shí)際場(chǎng)景合適地運(yùn)用，是不是反而不如對(duì)其不了解來(lái)的好呢？

關(guān)于多種計(jì)算機(jī)語(yǔ)言的學(xué)習(xí)

有人覺得學(xué)習(xí)一種語(yǔ)言就可以了，學(xué)習(xí)那么多語(yǔ)言沒有必要。事實(shí)上，多掌握一門合適的計(jì)算機(jī)語(yǔ)言不僅僅是多掌握一種謀生的工具，如果一種新的語(yǔ)言能夠很大程度上改變你對(duì)編程、對(duì)設(shè)計(jì)的看法，那么興許它就值得你去學(xué)習(xí)。

譬如C語(yǔ)言，可以培養(yǎng)嚴(yán)謹(jǐn)?shù)乃季S；譬如動(dòng)態(tài)語(yǔ)言，它可以幫助程序員更好地做面向?qū)ο蟮腸oding；譬如函數(shù)式語(yǔ)言，它在工業(yè)生產(chǎn)、運(yùn)算領(lǐng)域有著不可替代的作用。

當(dāng)然話說(shuō)回來(lái)，所謂術(shù)業(yè)有專攻，對(duì)于某一門計(jì)算機(jī)語(yǔ)言（包括該語(yǔ)言所需的運(yùn)行時(shí)環(huán)境、其中的編譯或解釋的原理）深入的掌握，是很有必要的。

另外，我們時(shí)常看到諸多計(jì)算機(jī)語(yǔ)言孰優(yōu)孰劣的爭(zhēng)論，計(jì)算機(jī)語(yǔ)言歸根到底是一種工具，工具是隨著時(shí)代發(fā)展升級(jí)和變更的，單純的優(yōu)劣爭(zhēng)論沒有太大意義。

關(guān)于英語(yǔ)

中國(guó)人為什么要學(xué)英語(yǔ)，程序員為什么要學(xué)英語(yǔ)，當(dāng)我把那些方法名、變量名全部取成拼音，一樣可以，誰(shuí)下的這個(gè)破規(guī)定？

遺憾的是，諸多學(xué)習(xí)材料、論文、技術(shù)資料（尤其是一些剛出不久的技術(shù)），都是英語(yǔ)的；另一方面，國(guó)際標(biāo)準(zhǔn)、程序員交流的通用方式，都是英文的，我想肯定很難想象，那些有名的framework、lib的源碼，如果用拼音來(lái)寫變量名會(huì)成什么樣子。

所以，如果你的英語(yǔ)不好（至少讀寫不好），就不要給自己找太借口，英語(yǔ)是一個(gè)掌握其他工具的工具，除非你堅(jiān)信，中文很快就會(huì)在計(jì)算機(jī)界變成世界第一通用的語(yǔ)言。

關(guān)于算法

算法有多重要，這一件事的爭(zhēng)議一直都很大。

軟件歸根到底是用來(lái)解決問(wèn)題的，提到算法就不能不提到數(shù)學(xué)（這也是為什么很多軟件領(lǐng)域的大師都具備相當(dāng)?shù)臄?shù)學(xué)背景），對(duì)于解決問(wèn)題，這里可以簡(jiǎn)單歸納成兩步：

（1）把實(shí)際的問(wèn)題抽象成簡(jiǎn)化的數(shù)學(xué)模型

（2）用算法去解決這個(gè)數(shù)學(xué)問(wèn)題

算法，在這里應(yīng)該是一個(gè)廣義的概念（這里的算法并不僅僅指大學(xué)里學(xué)習(xí)的狹義的具體算法），算法是解決上述數(shù)學(xué)問(wèn)題的辦法。如果工作中你并未意識(shí)到它的存在，那只是說(shuō)明，你抽象出的數(shù)學(xué)模型比較簡(jiǎn)單，解決這個(gè)模型的辦法也很簡(jiǎn)單，或者有現(xiàn)成的方式可以模仿，或者有現(xiàn)成的框架幫你完成了，以至于你不去關(guān)注它、在乎它。

如果你做的事情是充滿創(chuàng)新意義的，是別人從沒有做過(guò)的，這時(shí)候算法興許就成了決定你成敗的因素。

在當(dāng)前中國(guó)的環(huán)境下，視野廣闊和經(jīng)歷豐富的人很好找，但是企業(yè)要招到具備上述兩點(diǎn)能力來(lái)解決問(wèn)題的人，其實(shí)是非常困難的。

關(guān)于經(jīng)驗(yàn)

唯經(jīng)驗(yàn)論者的人有很多，他們認(rèn)為，在軟件企業(yè)的職位、薪水、甚至決策能力，都取決于經(jīng)驗(yàn)，一個(gè)5年經(jīng)驗(yàn)的工程師，肯定比3年經(jīng)驗(yàn)的工程師能找到更好的飯碗：

“我是老員工，我工作5年了，憑什么工作3年的他薪水比我高那么多”

實(shí)際上，很多因素，包括領(lǐng)域積累（這是業(yè)務(wù)上的，例如互聯(lián)網(wǎng)領(lǐng)域、傳統(tǒng)軟件領(lǐng)域，這和所謂的純技術(shù)沒有直接關(guān)系）、視野、承受壓力的能力等等往往都 在很大程度上取決于“經(jīng)驗(yàn)”的積累，但是，這并不是絕對(duì)的。有句話叫做“事業(yè)一半是干出來(lái)的，一半是總結(jié)出來(lái)的”，也確實(shí)有一些出色的程序員，他們善于總 結(jié)、善于觀察和積累，并且善于不斷地思考，這樣的程序員就是擁有更多優(yōu)秀的經(jīng)驗(yàn)。

另一方面，程序員是要來(lái)解決問(wèn)題的，經(jīng)驗(yàn)不能代替解決問(wèn)題，有的人具備更優(yōu)秀的解決問(wèn)題的能力，他為什么就不能得到更優(yōu)厚的薪水？

越來(lái)越多人開始使用Java,但是他們大多數(shù)人沒有做好足夠的思想準(zhǔn)備(沒有接受OO思想體系相關(guān)培訓(xùn))，以致不能很好駕馭Java項(xiàng)目，甚至導(dǎo)致 開發(fā)后的Java系統(tǒng)性能緩慢甚至經(jīng)常當(dāng)機(jī)。很多人覺得這是Java復(fù)雜導(dǎo)致，其實(shí)根本原因在于：我們?cè)日莆盏年P(guān)于軟件知識(shí)(OO方面)不是太貧乏就是 不恰當(dāng)，存在認(rèn)識(shí)上和方法上的誤區(qū)。

　　軟件的生命性

　　軟件是有生命的，這可能是老調(diào)重彈了，但是因?yàn)樗玛P(guān)分層架構(gòu)的原由，反復(fù)強(qiáng)調(diào)都不過(guò)分。

　　一個(gè)有生命的軟件首先必須有一個(gè)靈活可擴(kuò)展的基礎(chǔ)架構(gòu)，其次才是完整的功能。

　　目前很多人對(duì)軟件的思想還是焦點(diǎn)落在后者：完整的功能，覺得一個(gè)軟件功能越完整越好，其實(shí)關(guān)鍵還是架構(gòu)的靈活性，就是前者，基礎(chǔ)架構(gòu)好，功能添 加只是時(shí)間和工作量問(wèn)題，但是如果架構(gòu)不好，功能再完整，也不可能包括未來(lái)所有功能，軟件是有生命的，在未來(lái)成長(zhǎng)時(shí)，更多功能需要加入，但是因?yàn)榛A(chǔ)架構(gòu) 不靈活不能方便加入，死路一條。

　　正因?yàn)槠胀ㄈ藢?duì)軟件存在短視誤區(qū)，對(duì)功能追求高于基礎(chǔ)架構(gòu)，很多吃了虧的老程序員就此離開軟件行業(yè)，帶走寶貴的失敗經(jīng)驗(yàn)，新的盲目的年輕程序員 還是使用老的思維往前沖。其實(shí)很多國(guó)外免費(fèi)開源框架如ofbiz compiere和slide也存在這方面陷阱，貌似非常符合胃口，其實(shí)類似國(guó)內(nèi)那些幾百元的盜版軟件，擴(kuò)展性以及持續(xù)發(fā)展性嚴(yán)重不足。

　　那么選擇現(xiàn)在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基礎(chǔ)架構(gòu)打好了呢？其實(shí)還不盡然，關(guān)鍵還是取決于你如何使用這些框架來(lái)搭建你的業(yè)務(wù)系統(tǒng)。

　　存儲(chǔ)過(guò)程和復(fù)雜SQL語(yǔ)句的陷阱

　　首先談?wù)劥鎯?chǔ)過(guò)程使用的誤區(qū)，使用存儲(chǔ)過(guò)程架構(gòu)的人以為可以解決性能問(wèn)題，其實(shí)它正是導(dǎo)致性能問(wèn)題的罪魁禍?zhǔn)字唬騻€(gè)比喻：如果一個(gè)人頻臨死亡，打一針可以讓其延長(zhǎng)半年，但是打了這針，其他所有醫(yī)療方案就全部失效，請(qǐng)問(wèn)你會(huì)使用這種短視方案嗎？

　　為什么這樣說(shuō)呢？如果存儲(chǔ)過(guò)程都封裝了業(yè)務(wù)過(guò)程，那么運(yùn)行負(fù)載都集中在數(shù)據(jù)庫(kù)端，要中間J2EE應(yīng)用服務(wù)器干什么？要中間服務(wù)器的分布式計(jì)算和 集群能力做什么？只能回到過(guò)去集中式數(shù)據(jù)庫(kù)主機(jī)時(shí)代。現(xiàn)在軟件都是面向互聯(lián)網(wǎng)的，不象過(guò)去那樣局限在一個(gè)小局域網(wǎng)，多用戶并發(fā)訪問(wèn)量都是無(wú)法確定和衡量， 依靠一臺(tái)數(shù)據(jù)庫(kù)主機(jī)顯然是不能夠承受這樣惡劣的用戶訪問(wèn)環(huán)境的。(當(dāng)然搞數(shù)據(jù)庫(kù)集群也只是五十步和百步的區(qū)別)。

　　從分層角度來(lái)看，現(xiàn)在三層架構(gòu)：表現(xiàn)層、業(yè)務(wù)層和持久層，三個(gè)層次應(yīng)該分割明顯，職責(zé)分明：持久層職責(zé)持久化保存業(yè)務(wù)模型對(duì)象，業(yè)務(wù)層對(duì)持久層 的調(diào)用只是幫助我們激活曾經(jīng)委托其保管的對(duì)象，所以，不能因?yàn)槌志脤邮潜９苷撸覀兙鸵云錇楹诵膰@其編程，除了要求其歸還模型對(duì)象外，還要求其做其做復(fù) 雜的業(yè)務(wù)組合。打個(gè)比喻：你在火車站將水果和盤子兩個(gè)對(duì)象委托保管處保管，過(guò)了兩天來(lái)取時(shí)，你還要求保管處將水果去皮切成塊，放在盤子里，做成水果盤給 你，合理嗎？

　　上面是談過(guò)分依賴持久層的一個(gè)現(xiàn)象，還有一個(gè)正好相反現(xiàn)象，持久層散發(fā)出來(lái)，開始擠占業(yè)務(wù)層，腐蝕業(yè)務(wù)層，整個(gè)業(yè)務(wù)層到處看見的是數(shù)據(jù)表的影子 (包括數(shù)據(jù)表的字段)，而不是業(yè)務(wù)對(duì)象。這樣程序員應(yīng)該多看看OO經(jīng)典PoEAA.PoEAA 認(rèn)為除了持久層，不應(yīng)該在其他地方看到數(shù)據(jù)表或表字段名。

　　當(dāng)然適量使用存儲(chǔ)過(guò)程，使用數(shù)據(jù)庫(kù)優(yōu)點(diǎn)也是允許的。按照Evans DDD理論，可以將SQL語(yǔ)句和存儲(chǔ)過(guò)程作為規(guī)則Specification一部分。

　　Hibernate等ORM問(wèn)題

　　現(xiàn)在使用Hibernate人也不少，但是他們發(fā)現(xiàn)Hibernate性能緩慢，所以尋求解決方案，其實(shí)并不是 Hibernate性能緩慢，而是我們使用方式發(fā)生錯(cuò)誤：

　　"最近本人正搞一個(gè)項(xiàng)目，項(xiàng)目中我們用到了struts1.2+hibernate3, 由于關(guān)系復(fù)雜表和表之間的關(guān)系很多，在很多地方把lazy都設(shè)置false,所以導(dǎo)致數(shù)據(jù)一加載很慢，而且查詢一條數(shù)據(jù)更是非常的慢。"

　　Hibernate是一個(gè)基于對(duì)象模型持久化的技術(shù)，因此，關(guān)鍵是我們需要設(shè)計(jì)出高質(zhì)量的對(duì)象模型，遵循DDD領(lǐng)域建模原則，減少降低關(guān)聯(lián)，通 過(guò)分層等有效辦法處理關(guān)聯(lián)。如果采取圍繞數(shù)據(jù)表進(jìn)行設(shè)計(jì)編程，加上表之間關(guān)系復(fù)雜(沒有科學(xué)方法處理、偵察或減少這些關(guān)系)，必然導(dǎo)致 系統(tǒng)運(yùn)行緩慢，其實(shí)同樣問(wèn)題也適用于當(dāng)初對(duì)EJB的實(shí)體Bean的CMP抱怨上，實(shí)體Bean是Domain Model持久化，如果不首先設(shè)計(jì)Domain Model,而是設(shè)計(jì)數(shù)據(jù)表，和持久化工具設(shè)計(jì)目標(biāo)背道而馳，能不出問(wèn)題嗎？關(guān)于這個(gè)問(wèn)題N多年就在Jdon爭(zhēng)論過(guò)。

　　這里同樣延伸出另外一個(gè)問(wèn)題：數(shù)據(jù)庫(kù)設(shè)計(jì)問(wèn)題，數(shù)據(jù)庫(kù)是否需要在項(xiàng)目開始設(shè)計(jì)？

　　如果我們進(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)，那么就產(chǎn)生了一系列問(wèn)題：當(dāng)我們使用Hibernate實(shí)現(xiàn)持久保存時(shí)，必須考慮事先設(shè)計(jì)好的數(shù)據(jù)庫(kù)表結(jié)構(gòu)以及他們的關(guān)系如何和業(yè)務(wù)對(duì)象實(shí)現(xiàn)映射，這實(shí)際上是非常難實(shí)現(xiàn)的，這也是很多人覺得使用ORM框架棘手根本原因所在。

　　當(dāng)然，也有腦力相當(dāng)發(fā)達(dá)的人可以實(shí)現(xiàn)，但是這種圍繞數(shù)據(jù)庫(kù)實(shí)現(xiàn)映射的結(jié)果必然扭曲業(yè)務(wù)對(duì)象，這類似于兩個(gè)板塊(數(shù)據(jù)表和業(yè)務(wù)對(duì)象)相撞，必然產(chǎn) 生地震，地震的結(jié)果是兩敗俱傷，軟的一方吃虧，業(yè)務(wù)對(duì)象是代碼，相當(dāng)于數(shù)據(jù)表結(jié)構(gòu)，屬于軟的一方，最后導(dǎo)致業(yè)務(wù)對(duì)象變成數(shù)據(jù)傳輸對(duì)象DTO, DTO滿天飛，性能和維護(hù)問(wèn)題隨之而來(lái)。

　　領(lǐng)域建模解決了上述眾多不協(xié)調(diào)問(wèn)題，特別是ORM痛苦使用問(wèn)題，關(guān)于 ORM/Hibernate使用還是那句老話：如果你不掌握領(lǐng)域建模方法，那么就不要用Hibernate,對(duì)于這個(gè)層次的你：也許No ORM 更是一個(gè)簡(jiǎn)單之道： No ORM: The simplest solution

　　Spring分層矛盾問(wèn)題

　　Spring是以挑戰(zhàn)EJB面貌出現(xiàn)，其本身?yè)碛械膹?qiáng)大組件定制功能是優(yōu)點(diǎn)，但是存在實(shí)戰(zhàn)的一些問(wèn)題，Spring作為業(yè)務(wù)層框架，不支持業(yè)務(wù)層Session 功能。

　　具體舉例如下：當(dāng)我們實(shí)現(xiàn)購(gòu)物車之類業(yè)務(wù)功能時(shí)，需要將購(gòu)物場(chǎng)合保存到 Session中，由于業(yè)務(wù)層沒有方便的Session支持，我們只得將購(gòu)物車保存到 HttpSession,而HttpSession只有通過(guò)HttpRequest才能獲得，再因?yàn)樵赟pring業(yè)務(wù)層容器中是無(wú)法訪問(wèn)到 HttpRequest這個(gè)對(duì)象的，所以，最后我們只能將"購(gòu)物車保存到HttpSession"這個(gè)功能放在表現(xiàn)層中實(shí)現(xiàn)，而這個(gè)功能明顯應(yīng)該屬于業(yè)務(wù) 層功能，這就導(dǎo)致我們的Java項(xiàng)目層次混亂，維護(hù)性差。 違背了使用Spring和分層架構(gòu)最初目的。

　　領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD

　　現(xiàn)在回到我們討論的重點(diǎn)上來(lái)，分層架構(gòu)是我們使用Java的根本原因之一，域建模專家Eric Evans在他的"Domain Model Design"一書中開篇首先強(qiáng)調(diào)的是分層架構(gòu)，整個(gè)DDD理論實(shí)際是告訴我們?nèi)绾问褂媚Ｐ蛯?duì)象oo技術(shù)和分層架構(gòu)來(lái)設(shè)計(jì)實(shí)現(xiàn)一個(gè)Java項(xiàng)目。

　　我們現(xiàn)在很多人知道Java項(xiàng)目基本有三層：表現(xiàn)層 業(yè)務(wù)層和持久層，當(dāng)我們執(zhí)著于討論各層框架如何選擇之時(shí)，實(shí)際上我們真正的項(xiàng)目開發(fā)工作還沒有開始，就是我們選定了某種框架的組合(如 Struts+Spring+Hibernate或Struts+EJB或Struts+ JdonFramework)，我們還沒有意識(shí)到業(yè)務(wù)層工作還需要大量工作，DDD提供了在業(yè)務(wù)層中再劃分新的層次思想，如領(lǐng)域?qū)雍头?wù)層，甚至再細(xì)分為 作業(yè)層、能力層、策略層等等。通過(guò)層次細(xì)化方式達(dá)到復(fù)雜軟件的松耦合。DDD提供了如何細(xì)分層次的方式

　　當(dāng)我們將精力花費(fèi)在架構(gòu)技術(shù)層面的討論和研究上時(shí)，我們可能忘記以何種依據(jù)選擇這些架構(gòu)技術(shù)？選擇標(biāo)準(zhǔn)是什么？領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD 回答了這樣的問(wèn)題，DDD會(huì)告訴你如果一個(gè)框架不能協(xié)助你實(shí)現(xiàn)分層架構(gòu)，那就拋棄它，同時(shí)，DDD也指出選擇框架的考慮目的，使得你不會(huì)人云亦云，陷入復(fù) 雜的技術(shù)細(xì)節(jié)迷霧中，迷失了架構(gòu)選擇的根本方向。

　　現(xiàn)在也有些人誤以為DDD是一種新的理論，其實(shí)DDD和設(shè)計(jì)模式一樣，不是一種新的理論，而是實(shí)戰(zhàn)經(jīng)驗(yàn)的總結(jié)，它將前人 使用面向模型設(shè)計(jì)的方法經(jīng)驗(yàn)提煉出來(lái)，供后來(lái)者學(xué)習(xí)，以便迅速找到駕馭我們軟件項(xiàng)目的根本之道。

ActionScript/MXML

線程

線程是指進(jìn)程中的一個(gè)單一順序的控制流，是操作系統(tǒng)能夠調(diào)度的最小單位，一個(gè)進(jìn)程中可以有多條線程，分別執(zhí)行不同的任務(wù)。線程有內(nèi)核線程和用戶線程之分，但在本文中僅指內(nèi)核線程。在軟件開發(fā)中，使用線程有以下好處：
1、在多核或多路 CPU 的機(jī)器上多線程程序能夠并發(fā)執(zhí)行，提高運(yùn)算速度；
2、把 I/O，人機(jī)交互等與密集運(yùn)算部分分離，提升 I/O 吞吐量和增進(jìn)用戶體驗(yàn)。
線程的缺點(diǎn)也很明顯：
1、創(chuàng)建一條線程需要較大的內(nèi)存開銷，導(dǎo)致不能創(chuàng)建海量的線程；
2、線程由操作系統(tǒng)調(diào)度（分配時(shí)間片），線程切換的 CPU 成本比較高，導(dǎo)致大量線程存在時(shí)大量 CPU 資源消耗在線程切換上；
3、同一進(jìn)程的多條線程共享全部系統(tǒng)資源，在多線程間共享資源需要進(jìn)入加鎖，大量的鎖開銷不提，重要的是加大了編寫程序的復(fù)雜性，這一點(diǎn)你看看有多少書名含有“多線程”三個(gè)字就明白寫個(gè)多線程應(yīng)用有多難了；
4、 I/O 方面，多線程幫助有限，以 TCP Socket Server 為例，如果每一個(gè) client connection 由一條專屬的線程服務(wù)，那么這個(gè) server 可能并發(fā)量很難超過(guò) 1000。為了進(jìn)一步解決并發(fā)帶來(lái)的問(wèn)題，現(xiàn)代服務(wù)器都使用 event-driven i/o 了。
event-driven i/o 解決了并發(fā)量的問(wèn)題，但引入了“代碼被回調(diào)函數(shù)分割得零零碎碎”的問(wèn)題。特別是當(dāng) event-driven i/o 跟 multi-threading 結(jié)合在一起的時(shí)候，麻煩就倍增了。解決這個(gè)問(wèn)題的辦法就使用綠色線程，綠色線程可以在同一個(gè)進(jìn)程中成千上萬(wàn)地存在，從而可以在異步 I/O 上封裝出同步的 APIs，典型的就是用基于 greenlet + libevent 開發(fā)的 python 庫(kù) gevent。綠色線程的缺陷在于操作系統(tǒng)不知道它的存在，需要用戶進(jìn)行調(diào)度，也就無(wú)法利用到多核或多路 CPU 了。為了解決這個(gè)問(wèn)題，很多大牛都做出了巨大的努力，并且成果斐然，scala、google go 和 rust 都較好地解決了問(wèn)題，下文以 rust 的并發(fā)模型為例講一下。
rust 提出一個(gè) Task 的概念，Task 有一個(gè)入口函數(shù)，也有自己的棧，并擁有進(jìn)程堆內(nèi)存的一部分，為方便理解，你可以把它看作一條綠色線程。rust 進(jìn)程可以創(chuàng)建成千上萬(wàn)個(gè) Tasks，它們由內(nèi)建的調(diào)度器進(jìn)行調(diào)度，因?yàn)?Tasks 之間并不共享數(shù)據(jù)，只通過(guò) channels/ports 通信，所以它們是可并行程度很高。rust 程序啟動(dòng)時(shí)會(huì)生成若干條（數(shù)量由 CPU 核數(shù)決定或運(yùn)行時(shí)指定）線程，這些線程并行執(zhí)行 Tasks，從而利用多個(gè) CPU 核心。

如 上圖，rust 應(yīng)用程序不停地 spawn 出一個(gè)又一個(gè) Tasks，它們由 tasks 調(diào)度器管理，在適當(dāng)?shù)臅r(shí)機(jī)，調(diào)度器會(huì)把某一個(gè) Task 分配給原生線程執(zhí)行，如果這個(gè) Task 進(jìn)入 I/O 等待或主動(dòng)讓出 CPU（sleep），那么這個(gè) Task 會(huì)被交回給調(diào)度器，而相應(yīng)的原生線程會(huì)執(zhí)行另一個(gè)新分派的 Task。盡管使用 rust 編程語(yǔ)言是不能創(chuàng)建線程的（直接調(diào)用 C 函數(shù)不算），但 rust 應(yīng)用程序?qū)嶋H上是多線程的（一般情況下），它能夠充分地利用多核或多路 CPU。
綜上，類似 rust 的 Task 的概念是比線程更好的并發(fā)模型，更安全，編寫的代碼也更加容易維護(hù)（關(guān)于維護(hù)性，我相信寫過(guò) gevent 程度或 go 程序的同學(xué)會(huì)認(rèn)同的）。線程當(dāng)然不會(huì)消亡，但隨著 scala/go/rust 的成熟，在可以預(yù)見的將來(lái)，線程會(huì)退到它呆著的角落：遠(yuǎn)離普通程序員，只有少數(shù)人需要了解它的細(xì)節(jié)。

C++

C++ 在 2011 年其實(shí)風(fēng)頭甚勁，C++2011 標(biāo)準(zhǔn)出臺(tái)，gcc/msvc/clang 都很快速地支持了許多新特性，新興的移動(dòng)設(shè)備的性能較差，更是 C++ 的新舞臺(tái)，在這個(gè)時(shí)候唱衰 C++，壓力很大。我使用 C++ 年頭不少，但除了在校的時(shí)候?qū)戇^(guò)兩個(gè)小游戲參加過(guò)兩個(gè)比賽（分別是面向社會(huì)和面向大學(xué)生的）弄些證書好找工作以外，在工作中只用過(guò)大概不到一年半，做《斬 魂》（http://zh.163.com）的早期版本，寫了服務(wù)器端的幾條進(jìn)程和客戶端的 GameAI 部分。經(jīng)驗(yàn)少，而且寫得不好，所以基本上有人在 weibo 上問(wèn)我 C++ 的問(wèn)題，我都是轉(zhuǎn)發(fā)給 @bnu_chenshuo 和 @miloyip 等真正的行家去回答的。所以實(shí)際上今天寫這一篇，我底氣很是不足，但是朋友們給前兩篇很大面子，弄得我騎虎難下，只好硬著頭皮寫了。
前 文提到 C++ 的新標(biāo)準(zhǔn)，很有必要提一下標(biāo)準(zhǔn)化對(duì) C++ 的影響。首先我們要肯定標(biāo)準(zhǔn)定制對(duì) C++ 的積極作用，但標(biāo)準(zhǔn)化過(guò)程中的超長(zhǎng)流程，一次次將 C++ 推向深淵。C++ 的第一個(gè)標(biāo)準(zhǔn)是 1998 年的 ISO/IEC 14882:1998，距離整個(gè) 90 年代最流行的 C++ 程序庫(kù) MFC（Microsoft Foundation Class Library）的第一個(gè)版本發(fā)行時(shí)間已經(jīng)整整  6 年。1998 年，MFC 版本號(hào)為 6.0，與其一起發(fā)布的 Visual C++ 6.0 占有了巨大的市場(chǎng)。因?yàn)?MFC 發(fā)布得標(biāo)準(zhǔn)制定的時(shí)間早，所以 MFC 內(nèi)部實(shí)現(xiàn)了許多后來(lái)標(biāo)準(zhǔn)庫(kù)里也有的組件，比如各種數(shù)據(jù)結(jié)構(gòu)容器。VC6 的市場(chǎng)占有率讓 windows 平臺(tái)下開發(fā)的許多 C++ 程序員甚至不知道有 STL，同時(shí)也無(wú)視 C++98 標(biāo)準(zhǔn)，從更兼容標(biāo)準(zhǔn)的 VC2002/2003 的市場(chǎng)占有率就可以看出來(lái)，直到今天，我知道國(guó)內(nèi)不少公司還是只用 VC6 的。
其實(shí)在 90 年代，計(jì)算機(jī)的運(yùn)算能力有限，市場(chǎng)上非常需要一款性能較高、抽象較強(qiáng)的編程語(yǔ)言，C++ 獲得了成功，但它標(biāo)準(zhǔn)化的時(shí)間過(guò)長(zhǎng)，造成各種編譯器有各自互不兼容的“方言”，成了它的第一個(gè)軟肋。第一個(gè)瞄準(zhǔn)這個(gè)軟肋的就是 java，java 在 1995 年推出，雖然性能稍遜，但它有更高的抽象能力、也更安全，并且更容易跨平臺(tái)，所以迅速獲得了成功；第二個(gè)瞄準(zhǔn)這個(gè)軟肋的是 C#，微軟不能推動(dòng) C++ 發(fā)展，又不愿 C++ 的市場(chǎng)被 java 鯨吞，于是在 2001 年推出了 C#，經(jīng)過(guò) 10 年的發(fā)展和微軟大量的金錢推廣，C# 已經(jīng)成功獲得了它應(yīng)有的江湖地位。
雖然 java/c# 都不是善類，但 C++ 在 21 世紀(jì)的第一個(gè)十年里仍然地位穩(wěn)固，這是因?yàn)? Linux 和 MacOS X 大獲成功，在這兩個(gè)平臺(tái)上 C++ 都是非常有競(jìng)爭(zhēng)力的編程語(yǔ)言，C++ 自然水漲船高。但隨著 web2.0 和 web app 概念的興起，以及 CPU 的主頻進(jìn)一步提升，服務(wù)器端編程語(yǔ)言漸漸地對(duì)執(zhí)行效率不再敏感，而是更在意程序員的開發(fā)效率，眾多的腳本語(yǔ)言開始蠶食 C++ 的市場(chǎng)份額，從早期的 perl 到后期的 python/php/ruby，在 2005 年以后，C++/java/C# 等靜態(tài)類型的編譯型語(yǔ)言的市場(chǎng)份額都下降了，新興的貴族是動(dòng)態(tài)語(yǔ)言。面對(duì)動(dòng)態(tài)語(yǔ)言在開發(fā)效率上的強(qiáng)勁挑戰(zhàn)，C++ 社區(qū)除了在 2003 年對(duì) C++98 做了小小的 patch，基本上睡著了，完全沒有應(yīng)對(duì)之策，哦不，連應(yīng)用的姿態(tài)都沒有。
進(jìn)入 21 世紀(jì)的第二個(gè)十年，市場(chǎng)又發(fā)生了變化，云計(jì)算越走越近，也許我們中的大部分人今天還可以說(shuō)只聞其聲不見其形，但 The Data Center Is the Computer 這句話大家應(yīng)該覺得很務(wù)實(shí)：完成一個(gè)用戶操作，在服務(wù)器端的進(jìn)程間通信次數(shù)前所未有地多。在這個(gè)十年，我們需要這樣的編程語(yǔ)言：
1、能充分利用現(xiàn)代 CPU 的計(jì)算能力，不僅僅是多個(gè)核心，更是巨大的 L1/L2/L3 Cache、超線程等；
2、能夠大量減小異步 I/O 的性能提升的同時(shí)帶來(lái)的副作用：異步編程的復(fù)雜性以及對(duì)可維護(hù)性的傷害；
兩 句話其實(shí)也可以壓縮為一句：需要有更好的并發(fā)模型的語(yǔ)言。一開始大家都在已有的編程語(yǔ)言中尋找，然后找到了 erlang，實(shí)踐證明 erlang 自有其局限，所以 google go/scala/rust 等新語(yǔ)言如同雨后春筍般撥地而出。C++2011 標(biāo)準(zhǔn)努力降低 C++ 的編程難度，并提供了線程庫(kù)以支持現(xiàn)代 CPU，如果在 2005 年，這個(gè)標(biāo)準(zhǔn)絕對(duì)有競(jìng)爭(zhēng)力，但在今天，它只能成為新的編程語(yǔ)言的墊腳石。正如 IE 最大的用處是用來(lái)下載其它瀏覽器，不久之后，也許會(huì)流行新的冷笑話：C++ 最大的用處就是用來(lái)實(shí)現(xiàn)其它編程語(yǔ)言。
市場(chǎng)一直在尋找一門中間的高級(jí) 語(yǔ)言，它上承 C 語(yǔ)言和匯編語(yǔ)言，下啟腳本語(yǔ)言。C++ 最先搶占了高地，并在與 java/c# 的爭(zhēng)斗中不落下風(fēng)，但新的十年，它的對(duì)手又增加了 google go/scala/rust 等新銳，并且新的標(biāo)準(zhǔn)不可能在兩三年內(nèi)再次出臺(tái)，兩三年內(nèi)新銳成長(zhǎng)起來(lái)后，留給它的位置就不多了。
上 文討論的基本上都是服務(wù)器編程，有必要再來(lái)看一下桌面和移動(dòng)設(shè)備領(lǐng)域。首先看桌面軟件，rust 是 mozilla 基金會(huì)開發(fā)系統(tǒng)程序語(yǔ)言的，它的定位是部分取代 C++ 開發(fā) firefox 的瀏覽器，所以 rust 會(huì)進(jìn)入桌面開發(fā)，google go 肯定會(huì)順道啃一口。移動(dòng)設(shè)備方面，主要是 android、ios 和 windows phone，隨著移動(dòng)設(shè)備性能增強(qiáng)，編譯型語(yǔ)言加腳本的模式就會(huì)占大頭，編譯型語(yǔ)言方面主要是 C++ 和 Objective-C 在競(jìng)爭(zhēng)，C++ 會(huì)占上風(fēng)（但需求量遠(yuǎn)遠(yuǎn)小于腳本，從 lua 在 2011 年的增長(zhǎng)速度可以印證），但是誰(shuí)知道 rust 之類的會(huì)不會(huì)進(jìn)入移動(dòng)設(shè)備呢，畢竟移動(dòng)設(shè)備的 CPU 核心也越來(lái)越多了呀，C++ 還是前景堪憂。
回首 C++ 的 30 年，展望它的未來(lái)，總結(jié)起來(lái)可能就是：標(biāo)準(zhǔn)化流程拖死人了。如果不是 15 年不能標(biāo)準(zhǔn)化，java/c# 的攪局可能不會(huì)出現(xiàn)；如果在 2005 年能夠應(yīng)對(duì)動(dòng)態(tài)語(yǔ)言……如果云時(shí)代有更好的并發(fā)模型……
題 外話：java/c# 不會(huì)有 C++ 的問(wèn)題，因?yàn)樗鼈冇凶约旱钠脚_(tái)，有巨大的財(cái)富支撐。特別是平臺(tái)的作用非常巨大，你可以想像一下如果 Adobe 有自己的瀏覽器或手機(jī)操作系統(tǒng) ActionScript/MXML 會(huì)不會(huì)是今天的境地；也可以想像一下 google go 的飛速發(fā)展動(dòng)力是什么。

兩點(diǎn)解釋

勞動(dòng)密集型公司

這樣的公司以業(yè)務(wù)為導(dǎo)向，市場(chǎng)團(tuán)隊(duì)在公司中占據(jù)較高的地位。每一個(gè)技術(shù)人員最終被折算到了“人天”里面去，團(tuán)隊(duì)規(guī)模相對(duì)較大，所有技術(shù)人員都比較容 易被替代，能力強(qiáng)的可以做更多的事情，能力弱的就少做一些。通過(guò)強(qiáng)有力的制度、政策和流程的規(guī)約，團(tuán)隊(duì)有條不紊地運(yùn)作起來(lái)。業(yè)務(wù)氛圍強(qiáng)勢(shì)，技術(shù)通道升級(jí)較 慢，需要非常長(zhǎng)期的積累才可以獲得豐厚的回報(bào)，諸多優(yōu)秀人才脫離編碼，而潛心轉(zhuǎn)管理、談需求并獲得回報(bào)。愿意招納畢業(yè)生編碼，以減小運(yùn)營(yíng)成本。只鼓勵(lì)小范 圍、淺層次的創(chuàng)新，對(duì)于優(yōu)秀的創(chuàng)意、想法，必須轉(zhuǎn)化為生產(chǎn)力才能夠被認(rèn)可。

技術(shù)密集型公司

這樣的公司較為重視技術(shù)和創(chuàng)新，敢于在產(chǎn)品中使用預(yù)期能夠帶來(lái)收益的技術(shù)。公司非常愿意招聘一些有豐富研發(fā)經(jīng)驗(yàn)、有廣泛閱歷的程序員加入，同時(shí)也能 吸引一些比較優(yōu)秀的技術(shù)人才，并且長(zhǎng)期為公司工作。團(tuán)隊(duì)人員較少，研發(fā)過(guò)程無(wú)論是從時(shí)間還是環(huán)境來(lái)看，通常比較寬松，用較少約束、任務(wù)驅(qū)動(dòng)的形式，鼓勵(lì)程 序員按期完成下發(fā)的任務(wù)。技術(shù)人員層次劃分較多，不同層次技術(shù)人員在一起辦公，往往都不脫離編碼，和項(xiàng)目結(jié)合緊密。愿意招不同層次的研發(fā)人員，不愿意招經(jīng) 驗(yàn)豐富但脫離技術(shù)的人到研發(fā)團(tuán)隊(duì)。

思維密集型公司

這樣的公司對(duì)研發(fā)人員思辨能力要求較高，愿意做一些創(chuàng)造性的產(chǎn)品。公司技術(shù)人員的招聘較為嚴(yán)格，更看重人員的創(chuàng)新氣質(zhì)、解決問(wèn)題的思路、建模和抽象 的能力，而對(duì)于具體的某種技術(shù)實(shí)現(xiàn)，并沒有很高的要求。團(tuán)隊(duì)人員不多，項(xiàng)目壓力不大，任務(wù)給定的要求和流程約束較少，需要團(tuán)隊(duì)成員較強(qiáng)的自主能力來(lái)解決問(wèn) 題。技術(shù)人員層次劃分不多，討論氣氛濃厚，設(shè)計(jì)精益求精，創(chuàng)新的點(diǎn)子容易得到認(rèn)可并嘗試實(shí)現(xiàn)。

你所在的公司，屬于哪一種？

博士
　　　有一個(gè)博士分到一家研究所，成為學(xué)歷最高的一個(gè)人。
　　　有一天他到單位后面的小池塘去釣魚，正好正副所長(zhǎng)在他的一左一右，也在釣魚。
　　　他只是微微點(diǎn)了點(diǎn)頭，這兩個(gè)本科生，有啥好聊的呢？
　　　不一會(huì)兒，正所長(zhǎng)放下釣竿，伸伸懶腰，蹭蹭蹭從水面上如飛地走到對(duì)面上廁所。
　　　博士眼睛睜得都快掉下來(lái)了。水上飄？不會(huì)吧？這可是一個(gè)池塘啊。
　　　正所長(zhǎng)上完廁所回來(lái)的時(shí)候，同樣也是蹭蹭蹭地從水上飄回來(lái)了。
　　　怎么回事？博士生又不好去問(wèn)，自己是博士生哪！
　　　過(guò)一陣，副所長(zhǎng)也站起來(lái)，走幾步，蹭蹭蹭地飄過(guò)水面上廁所。這下子博士更是差點(diǎn)昏倒：不會(huì)吧，到了一個(gè)江湖高手集中的地方？
　　　博士生也內(nèi)急了。這個(gè)池塘兩邊有圍墻，要到對(duì)面廁所非得繞十分鐘的路，而回單位上又太遠(yuǎn)，怎么辦？
　　　博士生也不愿意去問(wèn)兩位所長(zhǎng)，憋了半天后，也起身往水里跨：我就不信本科生能過(guò)的水面，我博士生不能過(guò)。
　　　只聽咚的一聲，博士生栽到了水里。
　　　兩位所長(zhǎng)將他拉了出來(lái)，問(wèn)他為什么要下水，他問(wèn)：“為什么你們可以走過(guò)去呢？”  
　　　兩所長(zhǎng)相視一笑：“這池塘里有兩排木樁子，由于這兩天下雨漲水正好在水面下。我們都知道這木樁的位置，所以可以踩著樁子過(guò)去。你怎么不問(wèn)一聲呢？”  

　　　這個(gè)故事告訴我們：學(xué)歷代表過(guò)去，只有學(xué)習(xí)力才能代表將來(lái)。尊重經(jīng)驗(yàn)的人，才能少走彎路。一個(gè)好的團(tuán)隊(duì)，也應(yīng)該是學(xué)習(xí)型的團(tuán)隊(duì)。 

個(gè)人理解和感悟：看學(xué)歷更要看能力

　　　招聘廣告上面我們經(jīng)常會(huì)看到“要求本科以上學(xué)歷”，很少有企業(yè)招聘的時(shí)候 是不在乎學(xué)歷的，而且在一些正規(guī)的企業(yè)里，如果沒有足夠的學(xué)歷，是不予以考慮加薪升職的。企業(yè)在人才的競(jìng)爭(zhēng)上面出現(xiàn)了一種盲目攀比學(xué)歷的不良傾向，現(xiàn)在經(jīng) 常可以看到在某些企業(yè)的官方介紹上面寫“公司的本科以上學(xué)歷占有xx比例”的字眼，，似乎聘用的人才學(xué)歷越高
越好，在職員工高學(xué)歷的越多越好。有一則消息稱研究生學(xué)歷的人比本科學(xué)歷的人平均年薪要高出2w元，從這里看出，學(xué)歷在企業(yè)招聘和考核中的重要性。

　　　現(xiàn)在越來(lái)越多的人堅(jiān)持考研或者讀MBA,他們認(rèn)為一旦有了高的學(xué)歷就可以“春風(fēng)得意馬蹄疾，一頁(yè)看遍長(zhǎng)安花”了。目前學(xué)歷仍然是一個(gè)隱形的、力量巨大的“殺手”，生生的把沒有一紙文憑的人拒之門外。

　　　有文憑不等于有水平，沒有學(xué)歷不等于沒有能力，大量的事實(shí)說(shuō)明， 不少才華橫溢、能力卓越的人才，他們并沒有高的學(xué)歷，有的甚至沒有大學(xué)文憑，例如愛迪生、高爾基諾貝爾 比爾蓋茨 喬布斯等，這些人雖然沒有高的學(xué)歷，但是他們?nèi)〉玫某删褪欠欠驳模瑯蝇F(xiàn)實(shí)中生活中也能輕易的發(fā)現(xiàn)，很多擁有高學(xué)歷的人在工作中能力平平、毫無(wú)建樹、庸庸 碌碌的過(guò)萬(wàn)了一生，管理者在選擇人才時(shí)，只能把學(xué)歷當(dāng)作一種參考條件，更重要的是要看這個(gè)人的實(shí)際能力。如果企業(yè)不從實(shí)際出發(fā)，競(jìng)相制定一些高學(xué)歷的規(guī) 定，對(duì)學(xué)歷的要求過(guò)為嚴(yán)格，甚至唯學(xué)歷取人，很難選拔出優(yōu)秀的人才，衡量人才既要有文化程度方面的要求，更總要視履行崗位職責(zé)的能力，真正使那些有學(xué)歷， 有智慧又有能力的人得到重用.

　　　 伯 樂(lè)相馬，主要是看馬能否跑千里而不是看馬的出身。近有消息說(shuō)，有些用人單位招聘人才的取向已更加務(wù)實(shí)，選才標(biāo)準(zhǔn)正在由“學(xué)歷型”向“能力型”轉(zhuǎn)變，這是一 種令人欣慰的轉(zhuǎn)變。畢竟，千里馬是跑出來(lái)的，人才是干出來(lái)的。創(chuàng)造業(yè)績(jī)主要不是靠職前的學(xué)歷，而是靠任職后的實(shí)踐經(jīng)歷和創(chuàng)造性努力。但愿我們公開選拔干部 時(shí)，能夠更重任職的能力而不是更重職前的學(xué)歷。

　　　一個(gè)人是否真正的有才能，并不能以學(xué)歷作為衡量的唯一標(biāo)準(zhǔn)，管理者在選人、用人時(shí)，不要被學(xué)歷遮住了視野，二應(yīng)該把有實(shí)際能力的員工放在最重要的位置上

春節(jié)前和同事在回家的路上看到了建筑工地，不由的感慨建筑業(yè)相比軟件業(yè)來(lái)講實(shí)在是成熟太多了！ 想想看，建筑師設(shè)計(jì)好圖紙，交給建筑公司（大包工頭）， 大包工頭再報(bào)給小包工頭， 小包工頭隨便抓一些農(nóng)民工就可以干活了！ 農(nóng)民工們可不懂得那么多高深的建筑原理， 對(duì)整個(gè)建筑也并不了解，可是他們只需要把自己的一磚一瓦做好，整個(gè)建筑就能做成了 -- 當(dāng)然也有豆腐渣工程-- 但畢竟是少數(shù)，排除在外。

更重要的是他們根本不用擔(dān)心項(xiàng)目的后期客戶突然想改設(shè)計(jì)方案，客戶不會(huì)也不可能要求你把朝北的窗戶挪到南邊去，也不會(huì)要求把10層樓中的第3層和第7層扒掉重蓋。

我們這些苦苦掙扎的碼農(nóng)們肯定會(huì)想， 什么時(shí)候軟件業(yè)也能這樣啊，什么時(shí)候我們也能快樂(lè)編程，按時(shí)上下班，或者以后這些底層的Labor work都讓機(jī)器人做了， 我們都去做需求，架構(gòu)，設(shè)計(jì)， 然后項(xiàng)目按進(jìn)度，高質(zhì)量的完成， 大家都很happy...

但是無(wú)數(shù)的無(wú)情現(xiàn)實(shí)告訴教育我們：別做夢(mèng)了，這是絕對(duì)不可能的， 至少在可以預(yù)見的時(shí)間段(比如50年)是不可能的， 原因就在于軟件的復(fù)雜性，在現(xiàn)有的技術(shù)情況下， 軟件的固有復(fù)雜性無(wú)法解決， 只有依靠我們這么碼農(nóng)們?nèi)浹a(bǔ)。

為什么軟件這么復(fù)雜， 為什么我們無(wú)法像建筑業(yè)蓋房子，汽車業(yè)裝配汽車一樣去寫軟件？

布魯克斯 在著名的《人月神話》中提到軟件的內(nèi)在復(fù)雜性， 的確，軟件系統(tǒng)的復(fù)雜性遠(yuǎn)遠(yuǎn)超過(guò)建筑業(yè)和制造業(yè)， 軟件的需求是在人的腦子中的， 用自然語(yǔ)言都很難完整、準(zhǔn)備的表達(dá)出來(lái)，更不用說(shuō)用計(jì)算機(jī)（好吧，更好聽的名字是”電腦“）這種原始的工具了。 不錯(cuò)，我用的正是”原始“這個(gè)詞， 從二進(jìn)制語(yǔ)言，到匯編語(yǔ)言，再到高級(jí)語(yǔ)言，其最基本的、最核心的東西依然是順序，循環(huán)，分支， 即使加上面向?qū)ο螅瑒?dòng)態(tài)語(yǔ)言，庫(kù)， 框架，計(jì)算機(jī)語(yǔ)言的本質(zhì)仍然沒有改變，我們只是在已經(jīng)建好的大廈上做裝飾而已。  使用這種原始的工具，怎么能夠表示復(fù)雜的需求？ 

程序員的出現(xiàn)正是為了填充這之間的巨大鴻溝，程序員需要用自己的大腦，使用極其”原始“的工具， 把無(wú)法準(zhǔn)確表述的，尚在腦子中的需求映射到代碼上，其難度可想而知！

當(dāng)然我們程序員也不笨， 在長(zhǎng)期的斗爭(zhēng)中，我們學(xué)會(huì)了把一個(gè)問(wèn)題用劃分為一個(gè)一個(gè)的模塊， 讓這些模塊低耦合，高內(nèi)聚，  我們還學(xué)會(huì)了分層，讓各個(gè)部分的聯(lián)系達(dá)到最小， 可是所有的這些努力只是把復(fù)雜性降低了一點(diǎn)， 本質(zhì)的復(fù)雜性依然存在。

未完待續(xù)。。。

歷史上的今天
回顧歷史的今天,歷史就像生活的一面鏡子;可以了解歷史的這一天發(fā)生的事件;借古可以鑒今;歷史是不能忘記的.要記住歷史的每一天
http://www.todayx.org/

酒宴開始。

酒杯盛酒，酒杯碰撞，這是物理層；

你要根據(jù)不同人的外貌特征找到你要敬酒的人所坐的位置，這是IP協(xié)議（網(wǎng)絡(luò)層）；

你明白，敬酒的實(shí)際目的是加深感情，這在應(yīng)用層，而這酒中的感情，才是報(bào)文的數(shù)據(jù)部分。

你和某位新見面的兄弟互相來(lái)回敬酒，這叫TCP；

你給同一位好兄弟敬酒好多次，死命灌他，他也不回禮，這叫UDP；

你對(duì)全桌的人說(shuō)，來(lái)，咱們同歸于盡，這叫廣播；

你在對(duì)這一桌的人順序挨個(gè)敬酒，這叫令牌環(huán)。

你對(duì)該兄弟說(shuō)，初次見面，請(qǐng)多關(guān)照，請(qǐng)問(wèn)閣下尊姓大名，敬酒一杯，這叫SYN報(bào)文；

這位兄弟說(shuō)，同是天涯淪落人，相逢何必曾相識(shí)，喝！這叫ACK報(bào)文；

你一看，對(duì)方的啤酒怎么沒有氣泡啊，不行，你怎么能拿茶水當(dāng)啤酒呢？這叫數(shù)據(jù)校驗(yàn)。

有一個(gè)兄弟過(guò)來(lái)給你桌上的領(lǐng)導(dǎo)敬酒，你說(shuō)不行，領(lǐng)導(dǎo)喝多了，不能再喝了，這叫防火墻；

有一位兄弟過(guò)來(lái)敬酒，你說(shuō)10分鐘里面已經(jīng)喝了5杯了，達(dá)到我極限了，這叫帶寬；

而且我還沒回禮呢，現(xiàn)在喝不下了，先緩緩，這叫擁塞控制；

你現(xiàn)在要給你最好的兄弟敬酒，于是你先找到了他所在的桌子（網(wǎng)絡(luò)號(hào)），再找到他本人的位置（主機(jī)號(hào)）；

從你要準(zhǔn)備敬酒到敬酒完成，這叫時(shí)延，其中要經(jīng)歷倒酒（發(fā)送時(shí)延）、碰杯（傳播時(shí)延）、你的兄弟被灌下（處理時(shí)延）這幾個(gè)過(guò)程。

終于，你醉了，你吐了一地，不省人事，這叫緩沖區(qū)溢出。

歷史上的今天
回顧歷史的今天,歷史就像生活的一面鏡子;可以了解歷史的這一天發(fā)生的事件;借古可以鑒今;歷史是不能忘記的.要記住歷史的每一天
http://www.todayx.org/

歷史上的今天
回顧歷史的今天,歷史就像生活的一面鏡子;可以了解歷史的這一天發(fā)生的事件;借古可以鑒今;歷史是不能忘記的.要記住歷史的每一天
http://www.todayx.org/

歷史上的今天
回顧歷史的今天,歷史就像生活的一面鏡子;可以了解歷史的這一天發(fā)生的事件;借古可以鑒今;歷史是不能忘記的.要記住歷史的每一天
http://www.todayx.org/

等于還是不等于？

看來(lái)看下面的一段代碼：

   代碼片段1

Java代碼  

1. public static void main(final String[] args) {  
2.     Integer a = new Integer(100);  
3.     Integer b = 100;  
4.     System.out.println(a == b);   
5. }  

 這段代碼的輸出是什么？相信很多人都會(huì)很容易的猜到：false，因?yàn)閍、b兩個(gè)對(duì)象的地址不同，用“==”比較時(shí)是false。恭喜你，答對(duì)了。

再看下面的一段代碼：

   代碼片段2

Java代碼  

1. public static void main(final String[] args) {  
2.     Integer a = 100;  
3.     Integer b = 100;  
4.     System.out.println(a == b);   
5. }  

你可能會(huì)回答，這沒什么不一樣啊，所以還是false。很遺憾，如果你執(zhí)行上面的一段代碼，結(jié)果是true。

上面的代碼可能讓你有些意外，那好吧，再看看下面的這段代碼：

    代碼片段3

Java代碼  

1. public static void main(final String[] args) {  
2.     Integer a = 156;  
3.     Integer b = 156;  
4.     System.out.println(a == b);   
5. }  

 結(jié)果是true嗎？很遺憾，如果你執(zhí)行上面的一段代碼，結(jié)果是false。

 感到吃驚嗎？那最后再看下面的一段代碼：

    代碼片段4

Java代碼  

1. public static void main(final String[] args) {  
2.     Integer a = Integer.valueOf(100);  
3.     Integer b = 100;  
4.     System.out.println(a == b);   
5. }  

最后的結(jié)果，可能你已經(jīng)猜到了，是true。

為什么會(huì)這樣？

現(xiàn)在我們分析一下上面的代碼。可以很容易的看出，這一系列代碼的最終目的都是用“==”對(duì)兩個(gè)對(duì)象進(jìn)行比較。Java中，如果用“==”比較兩個(gè)對(duì)象結(jié)果為true，說(shuō)明這兩個(gè)對(duì)象實(shí)際上是同一個(gè)對(duì)象，false說(shuō)明是兩個(gè)對(duì)象。

現(xiàn)在，我們來(lái)看看為什么會(huì)出現(xiàn)上面的現(xiàn)象。

我們先看代碼片段4：最后的運(yùn)行結(jié)果是true，說(shuō)明a、b兩個(gè)對(duì)象實(shí)際上是同一個(gè)對(duì)象。但是a對(duì)象是通過(guò)調(diào)用Integer的valueOf方法創(chuàng)建的，而b對(duì)象是通過(guò)自動(dòng)裝箱創(chuàng)建出來(lái)的，怎么會(huì)是同一個(gè)對(duì)象呢？難道問(wèn)題在字節(jié)碼那里，畢竟Java程序是依靠虛擬器運(yùn)行字節(jié)碼來(lái)實(shí)現(xiàn)的。

通過(guò)jdk中自帶的工具javap，解析字節(jié)碼，核心的部分摘取如下：

Java代碼  

1. 0:  bipush  100  
2. 2:  invokestatic    #16; //Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;  
3. 5:  astore_1  
4. 6:  bipush  100  
5. 8:  invokestatic    #16; //Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;  

代碼中我們只調(diào)用了一次Integer.valueOf方法，但是字節(jié)碼中出現(xiàn)了兩次對(duì)Integer.valueOf方法的調(diào)用。那么另一次是哪里呢？只可能在自動(dòng)裝箱時(shí)調(diào)用的。因此這段代碼實(shí)際上等價(jià)于：

Java代碼  

1. public static void main(final String[] args) {  
2.     Integer a = Integer.valueOf(100);  
3.     Integer b = Integer.valueOf(100);  
4.     System.out.println(a == b);   
5. }  

 現(xiàn)在問(wèn)題就簡(jiǎn)單了：看jdk源代碼，查看valueOf方法的具體實(shí)現(xiàn)：

Java代碼  

1. public static Integer valueOf(int i) {  
2.     final int offset = 128;  
3.     if (i >= -128 && i <= 127) { // must cache   
4.         return IntegerCache.cache[i + offset];  
5.     }  
6.     return new Integer(i);  
7. }  

看到這兒，上面的代碼就很明確了：對(duì)于-128到127的數(shù)字，valueOf返回的是緩存中的對(duì)象。所以兩次調(diào)用Integer.valueOf(100)返回的都是同一個(gè)對(duì)象。

我們?cè)傧瓤创a片段3：根據(jù)上面的分析，代碼片段3實(shí)際上等價(jià)于以下代碼：

Java代碼  

1. public static void main(final String[] args) {  
2.     Integer a = Integer.valueOf(156);  
3.     Integer b = Integer.valueOf(156);  
4.     System.out.println(a == b);   
5. }  

 由于156不在-128到127范圍內(nèi)，所以兩個(gè)對(duì)象都是通過(guò)new Integer()的方式創(chuàng)建的，所以最后結(jié)果為false。

 片段1和片段2就不做具體分析了，相信讀者可以自行分析。

 最后，請(qǐng)大家思考一下問(wèn)題：通過(guò)上面的分析，了解到整數(shù)的自動(dòng)裝箱是通過(guò)Integer.valueOf(int number)實(shí)現(xiàn)的，那么自動(dòng)拆箱是如何實(shí)現(xiàn)的呢？