軟件

在眾多軟體相關的知識中，軟體工程絕對是很特別的一個。很多人很鄙視軟體工程，說：我一看到軟體工程的書就直接略過；與之相對應，很多人很推崇軟體工程，會花很大的心思去研究敏捷、CMMI等。剛入職場的程式員大致上是討厭軟體工程的，因為這東西離自己的實踐有點遠，並且主要是添加束縛。 但既然更加複雜紛繁的曆史都可以總結出規律，軟體開發沒道理就總結不出可以遵循的規律。也許真的事實是：並不是軟體工程沒有用，而實在是很多軟體工程的書籍理論飄的太高，落地上有困難。 軟體工程一個很大的困境在於，它總是試圖以軟體整體為

軟體開發是個奇妙的行業。你可以說它複雜，但與此同時，隨便有個人，只要接受點培訓就可以做軟體開發。你也可以說它簡單，但據統計世界上一半以上的軟體項目會以失敗收場。 強調軟體複雜的最有代表性的觀點來自《人月神話》：Brooks認為複雜性是軟體的根本特質，而非偶然特質。強調軟體簡單性的觀點則時見於國內某些MIS開發公司以及外包公司：他們大多時候會把需求分析（業務分析）的權重抬的很高，而把設計編碼的位置壓的很低。 這種迷思其實不難打破，但在此之前要對軟體的特質做一點考察。 軟體自身是一種固化的思維，其必

--願與勇於正視現實的人共勉 在開始任何其他文字之前，首先有必要正視一個根本現實：國內外軟體開發的水平是有差距的。這一結論的最直接證據是每一輪新技術的發起者基本上都是國外的人或公司：從方法論（CMMI，敏捷等）到各種架構（近來很熱的Hadoop等）再到新的程式設計語言都是如此。 總的來看這類差距似乎可以概括為“原創的缺失”，大多時候，我們只是處在一種“跟隨者”的角色上。RUP出來後我們跟誰RUP，敏捷出來我們跟誰敏捷，雲端運算出來後我們跟隨雲端運算，大致如此。 年紀小的時候，會單純的以為造成這種

（接前一篇，繼續）   第五重：技術變化快，積累上不去  設想一下，一個10年前的高手，這10年他什麼也不學，那他今天會是什麼樣的一個狀況。 我個人估計是快被淘汰了。 這是個極端的例子，但回顧一下軟體的發展曆程你會發現，新技術的出現是爆炸式的。 在DOS的時代裡，軟硬體的距離非常近，你只要會一種語言，瞭解基本演算法和資料結構，再瞭解電腦硬體的知識，你就可以寫大部分的程式。 接下來軟體和硬體間的層次越來越多，Windows加上一層，Java虛擬機器加上一層，瀏覽器加上一層，Flash等再加上一層，

一點說明：作為程式員，通常心裡是討厭軟體工廠的，但很多時候問題自身皆有其內在理性，並不以個人的偏好而改變其發展的軌跡。所以程式員一旦談及和自身喜好相關的問題時，尤其要摒絕個人好惡，否則就會離問題的真相越來越遠，而只有一腔情緒。  就我個人觀察軟體工廠大致處在這樣一種地位：經營管理者迫於成本的壓力，總是潛在的期望其可能實現；而程式員群體自身則總是對其嗤之以鼻。  為什麼在經營層面軟體工廠有如此大的誘惑力？ 這不難理解，如果軟體可以用工廠的模式來運作，那麼程式員的可替換性將被無限強化，這樣軟體開發的

軟體開發沉思錄--ThoughtWorks文集(china-pub首發)（來自軟體界思想領袖們的經驗心得）。看試讀的兩章：第五章充斥著狗屎，第十三章卻瑕不掩瑜。第五章的一個問題在於討論的大多數問題都是虛的：比如在Java與Ruby的比較中提到的落單方法。這樣的話題根本沒有真理可言，而作者卻毫無顧忌地認為它（沒錯，“它”）的觀點就是對的。但這還不是傷害性的；下面就這個例子說一下狗屎從何而來。仔細看Java版的isBlank函數，其中對null的判斷，對length的判斷，對每個元素（這裡是字元）是

1. 環形 Dock　　曾經很眼饞蘋果作業系統的 Dock，還專門安裝過好幾款在 Windows 下類比它的軟體，不過沒過多久就都被我卸載了。因為它們雖然很酷很漂亮，實際用起來卻不大舒服，還很佔地方，設為自動隱藏又不方便，又擔心它們浪費資源。　　另一方面，雖然我的辦公桌很髒、很亂，喝咖啡的杯子從來也不刷，但是卻不能容忍 Windows 案頭上放著一大堆亂七八糟的表徵圖。所以，Win7 的“將程式鎖定到工作列”成了我非常喜歡的功能。不過工作列畢竟地方有限，只能放一些最常用的程式表徵圖。直到有一天，

軟體名稱: HowTired (看看你的勞動強度)版本: 1.0 beta開發環境:Windows Server 2003 + .Net Framework 1.1C# + Win32 API功能:1. 監視滑鼠的點擊次數, 左鍵, 右鍵2, 監視滑鼠一共移動的距離3, 監視鍵盤的敲擊次數, 詳細統計到每個鍵.4, 開始運行以後最小化到工作列, 開始監視不足:1. 由於程式一直駐留後台, 導致所佔資源越來越大2. 準備加上一個每天日誌的功能, 記錄每天的勞動程度3. 有時候會造成系統特別的慢,

不知道怎麼就被裝上了這個軟體, 憑心而論, 這個軟體的功能還不錯, 創意也挺好但是請你能不能不要這樣無恥啊? 請神容易送神難!!!別的什麼通用網址下載豬之類的軟體, 好歹也有一個卸載的方法, 雖然麻煩一點, 但總歸還是可以卸載掉的.可是這個垃圾的劃詞搜尋, 真TM的無恥...自己的機器不小心也感染上了, 找了一堆軟體都卸載不掉, 最後進入安全模式先徹底刪掉檔案和檔案夾, 再去註冊表裡面搜尋所有跟zsearch, wsearch, movesearch有關的項全部刪除辦公室的機器就沒這麼幸運了,

聽了北京INTETA第三次活動的講座以後，最近對一些開發過程中的品質控制相關的東西感興趣，找了NUnit、NAnt、Draco等等相關的資料看了看，雖然都沒有深入瞭解，不過對於目前公司的開發流程的改進有了一些新的想法。按照我的想法，對於我們目前的團隊規模（項目都很小，一般就是2、3個人，最多的時候是5個人），開發流程可以這樣做：需求調研：是一個重點，雖然不至於要搞得非常清楚，但是對於要實現的商務程序、客戶的具體需求是一定要搞清楚的；目前的幾個項目都在這上面吃了大虧，甚至於由於設計無法修改而推翻重

幫LP找了一個osCommerce做網上商店，給自己在家裡的機器上裝了一個Plog寫日記；都是基於PHP+MySQL的開源項目，在Windows下運行都很順利，而且都找到了簡體中文語言套件，用起來很方便。工作中還用到了TortoiseCVS、Mantis、CommunityServer等開源軟體，有些有現成的簡體中文語言套件，有些需要自己手工修改，有些則只能使用英文版的軟體（只能對原始碼進行翻譯；雖然有原始碼，但是對原始碼進行一點點的翻譯工作量太大，而且這種翻譯方法在原始碼升級後就又要重新來過）

      近日，無意中發現塵封於書櫥一角多年的《軟體架構師職業導讀》這本書，5年前懷著對軟體架構師這一職業的嚮往，從china-pub上購得此書，希望能增進一些對這個職業的瞭解。第一遍讀的感覺是彷彿進入雲山霧海一般，整本書幾乎全是軟體與建築之間的各種類比，從兩種不同的領域，到軟體架構師--建築設計師、軟體工程師--建築工程師、程式員--各工種建築工人，當時的我，無法理解。重讀之後，感觸頗深，回想起來，的確是自身的原因，當年知識面、職業經驗都不足理解這些類比中想揭示的真正涵義。     

軟體架構引言之專案管理的問題 很多朋友都有過或者正在管理一個或者多個軟體項目，那麼我的文章就從這個問題開始：如果單純從表象來說，軟體專案管理過程中暴露的最大問題是什嗎？ 不同的人的會有不同的答案，但是大致這樣的答案我想大部分人都是會認可的，那就是“進度拖延”。進度拖延當然是表象之一了，其他諸如品質不過關、功能不完整等等，我覺得都是和進度拖延密切相關的。很多專案經理都想去做那些認為是十分必要的事情，比如計劃、測試等，但是“沒有時間”。為什麼會沒有時間？等到項目總結的時候，我們總會羅列出一大堆的理由

首先聲明，今天喝多了軟體是什麼?(在這裡我所提的軟體範圍限於公司專屬應用程式軟體)1.形象工程2.一套辦公輔助軟體3.一個全新的生產關係4.一個可以對企業產生深遠影響的先進生產力開發設計過的系統也不少了，平心而論，成功的少，失敗的多，但在這個時代，工程項目永遠都是勝利完成的，以前寫過一篇關於需求的文章，中心思想是需求在一定的時期內是不變的，說需求總在變的人，是從來都沒有真正看清需求的人。一個好的系統可以用5年以上，一個精確的需求至少可以用10年，或者幾十年我向來主張做需求不是問使用者要做什麼，而

摘自：《敏捷式軟體開發 (Agile Software Development)：原則、模式與實踐》 Robert C.Martin【著】，鄧輝【譯】敏捷式軟體開發 (Agile Software Development)宣言 : 個體和互動        勝過   過程和工具 可以工作的軟體    勝過   面面俱到的文檔 客戶合作          勝過   合約談判 響應變化          勝過   遵循計劃(雖然右項也具有價值，但左項具有更大的價值)  敏捷宣言遵循的12個原則：1.

"客戶說是這樣的！"，"客戶根本沒這個需求！"需求對程式員而言，往往猶如聖經，客戶說了，我們就要這樣做。但是，往往客戶明天就變了一幅嘴臉，原本明明說好按鈕在下面的，結果現在一定要挪到上面去，明明不需要儲存顏色的，結果現在一定要把顏色也加上。於是我們從頭改到尾，從下改到上，好不容易改完，好了，客戶明天想法又變了！怎麼辦？繼續改！ 好吧，厭倦了這種可怕的生活了吧，於是我們希望應對這種問題，於是我們決定，通過設計一個完美的架構來解決問題，我們希望，當客戶需求變更的時候，只要改改配置就可以應對。客戶不是

      聲明：我發布本章節主要是和大家分享這本書裡的知識點，如果涉及到了侵權請作者或是相關人士留言，我會刪除。　　      Factory Method模式是應用最為廣泛的設計模式，畢竟他負責了一系列對象的建立，而對象的建立正是物件導向編程中最為繁瑣的行為。《設計模式》一書寫到，“Factory Method模式使一個類的執行個體化延遲到子類。”準確的說，Factory

1 前言 　　一般來說，軟體工程師總是非常樂觀。當他們在計劃軟體項目時，經常認為每件事情都會像計劃那樣運行，或者，又會走向另外一個極端。軟體開發的創造性本質意味著我們不能完全預測會發生的事情，因此制定一個詳細計劃的關鍵點很難確定。當有預想不到的事情引起項目脫離正常軌道時，以上兩種觀點都會導致軟體項目的失敗。

      對於一個類，應該僅有一個引起它變化的原因，很簡單，如果一個類承擔了多餘一個的職責，那麼引起它變化的原因就會有多個。也就等於把這些職責耦合在了一起。當然了一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。最終的結果就是這種耦合會導致一種脆弱的設計。例子：Retangle類有兩個方法。一個方法把矩形繪製在表單上，另一個方法計算矩形的面積:                            多餘一個的職責的情況