網上有人貼出了直接計算的代碼，在這里，填入你的Blog地址即可。

　　昨天看完《一九八四》了，聯想到之前看過的《林昭》《兄弟》，頗有些感想。

 

　　《兄弟》是最能讓人動情的一部書，但是也是最感性的一部書。而對于極權主義的批判，僅僅有感性是遠遠不夠的。這一點，《一九八四》就實在是太到位了。深刻的，理性的，不動聲色的，鎮定自若的分析，越讀越讓人感到毛骨悚然。

　　一種絕對不會讓你變成烈士的權力。你一定能夠被改造好。你會真誠的相信，2+2=5，或者是4，是3，都有可能。每一個被送入101房間的人，都會出賣一切，出賣人類所能擁有的一切美好的事物。真、善、美、愛，全部都可以出賣。

 

　　太絕望了！

 

　　林昭的死，給了我信心。是的，不是讓我絕望，反而是給了我信心。因為，有這樣的人，在這個世界上存在過，她可以被消滅，但是不可戰勝！

 

　　另外推薦一篇blog，不像書評的書評。主題有點相關，但是并不直接。大多數人，既不是強者，也不是弱者，僅僅是在中間。這些在中間的人，如果他勇于欺凌弱者，也往往會非常痛快的屈服于強者。換句話說，那些在極權主義制度下，快速屈服的人們，才是迫害弱者的主力軍。這樣的人，實在是太多了！

　　討論軟件開發的特征，需要站在一個大的背景下來看。我以前考過PMP，在PMBOK中，軟件項目管理，是作為項目管理下的子課題來討論的。看看下面這張圖：

　　按照PMBOK的知識結構圖，PMBOK已經告訴了我們那么大一個園。而要進一步搞好軟件的項目管理，我們只需要再掌握相關應用領域的知識和實踐，就ok了。

 

 　　這其實是大多數項目管理的理論，對于軟件項目管理的看法，所有的項目，都是項目。軟件項目與大多數其它項目，大同而小異。至于差異部分，往往被歸入“風險管理”的領域，就算是“一切盡在掌握了”。

 

　　而事實上，軟件項目與其它項目的差異是如此之大，以至于由量變而導致了質變，使得我們以傳統的工程項目管理的方式來管理軟件開發項目，注定是要失敗的。

 

　　我們來看看這樣一個關鍵詞：“迭代”。這是其它的項目管理中，基本上不可能出現的概念，而在軟件項目管理領域，卻是幾乎每一種方法學中，都要極力強調的概念。這就是最大的區別。如果我們能夠搞清楚迭代的本質，也就能夠搞清楚軟件項目與其它項目的本質區別了。

 

　　在我看來，在軟件開發的過程中，引入迭代，就是承認，軟件開發需要承受大大小小的失敗，而減少失敗的辦法，就是不跑步，不走路，盡可能的爬行，這樣就算跌倒，也不會跌得太重。我們來看一個有趣的數據。這是我在竹筍炒肉的blog上看到的一段話。

 

　　1994年，由于其非凡的軟件開發能力和優秀的軟件質量，SEL成為第一個因軟件過程的成就而贏得IEEE獎勵的軟件開發組織。與普通的軟件開發組織相比，在同樣的軟件開發條件下，NASA所開發的軟件的質量要好10到20倍。

 

　　這個成就是如何得出的呢？那么是怎樣的項目呢？我搜索了一個google，找到另外一段話：

 

　　To put it a little differently, the average MIS shop would need about 14 calendar months and 110 staff-months to deliver a 100,000 line-of-code MIS system, and it would typically contain about 850 defects when delivered. The NASA SEL would deliver a system of that size with about the same amount of time and effort, but it would contain only about 50 defects.

 

　　也就是說，10萬行代碼的一個MIS系統，他們花了110個人月，一共14個月，才完成。平均下來，每個人每天大約需要寫30行代碼！如果這樣也算成功的軟件項目管理的話，我以后只要將所有的項目工作量估算，乘以10，就能同樣拿到IEEE的獎勵了，如果我的老板允許的話。

 

(未完待續)

　　最近一段時間，特別容易買書。11月5日，本來是打算給我的外甥女買一本小學生詞典的，想想干脆上當當搜一下。結果發現還真是挺便宜的，會員價只要12.6，實在是不好意思，就另外挑了兩本，一本《世界盡頭與冷酷仙境》，一本余華的《兄弟》。但是，那該死的當當，竟然在訂單完成之后的第二天，才告訴我只有一本《兄弟》。我當時就想，干脆一本都不要，反正是貨到付款。

 

 

 

 

　　因為對當當送書的速度印象相當深刻，于是還是去當當又訂了三本書《非常道》、《楊柳風》、《一九八四》。當當還是以非常迅速的速度，分兩次，給我送來了。他們這樣做，唯一的目的是，能夠收我兩次的送貨費。值得慶幸的是，書的確是不錯。《非常道》我已經看完了，現在在看《一九八四》。

 

　　我之前寫過一篇關于林昭的blog。因此而認識了一個朋友，他也是林昭的老鄉，蘇州人。看到我這么喜歡林昭，于是說要送一本林昭的書給我，今天，書又寄到家里來了。《追尋林昭》，另外還有一本他們出版社的《擋不住的趨勢》。

 

　　今天早上，我還在蔚藍書店訂了三本書。《隨想錄》、《人類群星閃耀的時刻》、《斷頭王后》。然后呢，今天還收到一封郵件，我郵購的一本《讀庫0600》也已經寄出來了。

 

　　唉，實在是太多了一點，來不及看啊。俗話說：書籍是人類的朋友。又說：有朋自遠方來，不亦樂乎。所以，有好書自遠方來，不亦樂乎！

 

 

還有一本，屬于“地下刊物”，只能搞到很大的照片。

 

這本書的介紹，可以去看這個blog：見招拆招

  1 package tv.recool.misc;
  2 
  3 import java.io.*;
  4 import java.text.*;
  5 import java.util.*;
  6 import javax.servlet.*;
  7 import javax.servlet.http.*;
  8 import java.net.MalformedURLException;
  9 import java.net.URL;
 10 import java.net.URLConnection;
 11 
 12 import magick.ImageInfo;
 13 import magick.MagickImage;
 14 import magick.MontageInfo;
 15 
 16 public class PutBooks extends HttpServlet {
 17 
 18     //根據url，取得圖片的byte[]
 19     private static byte[] getImageBytes(String url){
 20         try {
 21             return StreamUtils.read((new URL(url)).openStream());
 22         } catch (Exception e) {
 23             return null;
 24         }
 25     }
 26     
 27     //根據url，取得文字
 28     private static String getImageText(String url){
 29         try {
 30             URL u=new URL(url);
 31             URLConnection uc=u.openConnection();
 32 
 33             //要做足功夫，不然豆瓣就會拒絕你的請求
 34             uc.setRequestProperty("Host","www.douban.com");
 35             uc.setRequestProperty("Accept","*/*");
 36             uc.setRequestProperty("Referer","http://www.douban.com/");
 37             uc.setRequestProperty("User-Agent","Mozilla/4.0 (compatible; MSIE 5.00; Windows 98)");
 38             uc.setRequestProperty("Pragma","no-cache");
 39             uc.setRequestProperty("Cache-Control","no-cache");
 40             uc.setRequestProperty("Connection","close");
 41 
 42             //StreamUtils是一個輔助工具，就不再給出了
 43             return new String(StreamUtils.read(uc.getInputStream()),"utf-8");
 44         }  catch (Exception e) {
 45             return "";
 46         }
 47     }
 48 
 49     public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException{
 50         //取得參數
 51         String uid=req.getParameter("uid");
 52         String n=req.getParameter("n");
 53         String columns=req.getParameter("columns");
 54         String select=req.getParameter("select");
 55         String picsize=req.getParameter("picsize")+"";
 56         String show=req.getParameter("show");        
 57 
 58         try {
 59             //設置JMagick的ClassLoader，否則會報錯
 60             System.setProperty("jmagick.systemclassloader","no");
 61 
 62             String str= getImageText("http://www.douban.com/service/badge/"+
 63                 uid+"/?show="+show
 64                 +"&select="+select
 65                 +"&n="+n
 66                 +"&picsize="+picsize
 67                 +"&columns="+columns);
 68 
 69             int getSize=Integer.parseInt(n);
 70             int colSize=Integer.parseInt(columns);
 71             int len=getSize/colSize;
 72 
 73             //申請一個數組
 74             MagickImage images[] = new MagickImage[getSize];
 75 
 76             //用最簡單的辦法解析字符串，因為豆瓣的輸出是固定的
 77             String imgstr[]=str.split(".jpg");
 78 
 79             for(int i=0;i<getSize;i++){
 80                 if(i<imgstr.length){
 81                     String picurl="";
 82 
 83                     //根據圖片大小的設定，解析有所不同
 84                     if(picsize.equals("medium")){
 85                         String temps[]=imgstr[i].split("http://www.douban.com/mpic/");
 86                         picurl="http://www.douban.com/mpic/"+temps[1]+".jpg";
 87                     } else {
 88                         String temps[]=imgstr[i].split("http://www.douban.com/spic/");
 89                         picurl="http://www.douban.com/spic/"+temps[1]+".jpg";
 90                     }
 91                     MagickImage image = new MagickImage(new ImageInfo(),getImageBytes(picurl));
 92                     images[i]=image;
 93                 }
 94             }
 95 
 96             //建立一個圖片組
 97             MagickImage seqImage = new MagickImage(images);
 98 
 99             //建立一個圖片框架
100             MontageInfo montageInfo = new MontageInfo(new ImageInfo());
101 
102             //setGeometry(String)設置圖片的幾何特征
103             if(picsize.equals("medium")){
104                 montageInfo.setGeometry("99x149+1+1>");
105             } else {
106                 montageInfo.setGeometry("66x99+1+1>");
107             }
108 
109             //NxM的一個表格
110             montageInfo.setTile(colSize+"x"+len);
111             montageInfo.setBorderWidth(0);
112 
113             //得到一張組合后的圖片
114             MagickImage montage = seqImage.montageImages(montageInfo);
115             montage.writeImage(new ImageInfo());
116             montage.setMagick("JPG");
117 
118             //輸出到byte[]
119             byte data[]=montage.imageToBlob(new ImageInfo());
120 
121             //通過Servlet輸出
122             res.setContentType("image/*");
123             OutputStream toClient=res.getOutputStream();
124             toClient.write(data);
125             toClient.close();
126         }
127         catch (Exception ex) {
128         }
129     }
130 }

軟件開發的定義：“軟件開發，就是在一個受到限制的環境中，利用環境提供的可能性，修改或添加環境允許的各種狀態，去滿足某一組需求。”

1) 軟件開發所處的環境，不僅僅是一個限制，同時也是一個可能性。軟件的能力，局限性與硬件的能力，比如說，如果計算機沒有喇叭，那么任何軟件都不能使計算機播放音樂。但是，另一個必須考慮的方面是，同樣有能力發聲的計算機，要想使他播放音樂，可能很容易，也可能很困難。用專業一點話來描述就是：“有些硬件的API設計很合理，有些則非常愚蠢。”由于我們對于軟、硬件的定義是一個連續體，因此，這個觀點不只是可以用來評價硬件API設計，也可以用來評價語言、虛擬機、框架、平臺等等軟件的一個方面的優缺點——是否有利于二次開發，這是一個重要的評價標準。

2) 修改、添加狀態，比較拗口，其實就是編程的意思。在一個受限制的范圍內編程，我們需要考慮很多東西，語法、接口、規范、內存大小諸如此類，當然，不同級別的，不同領域的編程，需要考慮的限制是有巨大差別的。軟件開發的水平高低也就體現在，滿足同樣的需求，有些方法速度更快，有些方面卻要慢很多。而軟件開發的方法的選擇，受到很多因素的影響：環境限制，經驗多少以及對于需求的了解程度等等。

3) 滿足需求，是啊！提起這個需求，每一個程序員都會有好多的苦水要倒出來。為什么滿足需求就這么難呢？因為，對于程序員來說，那是另外一個世界(這是比較客氣的說法)，那些提需求的家伙根本不懂怎么說話(這個說法稍為激烈一些)，那是一些不知道自己要什么的蠢貨(你遇到過這樣的用戶嗎？)作為程序員，我知道我有很多同行，非常苦惱于與客戶談需求這樣的任務——“至少電腦不會出現前后矛盾的邏輯錯誤”——這就是做程序員的難處。如果我們不僅僅是抱怨的話，也必須承認，程序員是非常挑戰的職業，一個好的程序員，不但得是軟件開發領域的專家，還得是他開發的那一類軟件所在領域的專家。但事實上，其他行業的人，只需要做一種專家就能夠混得很好了。

　　軟件開發的實質，與軟件開發的特征之間，還是有區別的。畢竟我的前一篇文章，是從技術的角度出發來看軟件開發，而現在我們的要討論的是從管理的角度來看待，它又有哪些特征呢？

　　軟件開發的管理特征，在外行看來，也就是一堆人在做個東西。但是，軟件開發的獨特之處就在于，軟件開發是由一堆獨特的人，以獨特的方式，做獨特的東西。我們先來看看軟件開發，遇到了哪些獨特的困難：

 

　　1、溝通困難：同為軟件開發，可能面對的思維模式，是完全不同的世界。比如二進制的世界，函數的世界、邏輯的世界、過程的世界、對象的世界、二維表的世界等等等等。在這些不同的世界中開發軟件，需要的思考方式、思維習慣都是不同的。開發項目大到一定程度以后，不同的世界必須在一個完整的項目中和諧并存，這些差異，有時候就會帶來溝通障礙。再加上技術與需求世界之間的差異，溝通成為一個非常重要的工作。軟件開發中的人與事，如何才能有效溝通，是一個非常重大的課題。

　　2、控制困難：程序員都是些怪人，至少都是些聰明人。要讓他們聽話，很難啊。一個項目，要想順利進行，程序員們能夠接受的，必須是“穩定而合理的命令”。而在軟件開發過程中，往往需求頻繁變動，領導層層疊疊，用戶花樣百出，計劃一改再改。程序員們經常會接到朝令夕改的命令，而且還來自于那些莫名其妙，連說話的邏輯都成問題的家伙。如何才能知道，那些小伙子是在嚴格地執行命令而不是在那里磨洋工呢？

　　3、評價困難：要控制，必須要能夠賞善罰惡，但是在軟件開發中，何為善？何為惡？如何評價一個程序員的工作？我們當然可以在項目計劃該結束的時候，再去問他們，做完了嗎？但是如果他們那時候沒有完成，再要挽救就來不及了。必須在項目開發過程中建立即使有效的反饋機制。以小而高密度的評價手段，來對開發過程進行較為準確的控制，這一切，都必須建立在合理的評價機制的基礎上。但是，這樣一套評價機制，非常困難。什么才算是好的需求分析？好的代碼？好的設計？好的測試用例？沒有定論。舉個例子：兩三年前，在項目中加入EJB的成分，越多越好。現在呢？設計人員，隨時都可能被人指責濫用EJB。這風向變得也太快了。

　　4、估算困難：這個在上一章我們也討論到了，軟件開發與其它行業的一個重大區別，就在于對于軟件開發的估算成本，不能忽略不計。想要估算變動劇烈的項目的時間、人力、成本，簡直就是不可能的任務。

 

　　怎么辦？

 

(未完待續)