軟件

類WindowXp 開始菜單到現在基本上是完美實現，在功能上基本和WindowXp 與Vista 作業系統的開始菜單一樣，介面當然漂亮，通過編程能實現風格多樣，具有個人化的功能菜單。為了方便使用，本人對其進行了封裝，庫名曰：完美類WindowXp 開始菜單。1、完美類WindowXp 開始菜單（CYisongStartMenu）有如下主要特點：a. 在C＋＋環境實現，介面風格可實現自訂;b. 不僅適用Mouse 操作，還支援回應程式向按鍵,快速鍵功能;c. 可增加和刪除菜單中的子項;d.

漂亮介面的軟體應該有漂亮的菜單，大家對 Windows XP 的開始菜單肯定不陌生吧，那種菜單獨具風格。於是去研究了一下，發現其實它並不是真CMenu也不是其衍生類別，分析其結構發現其主要是兩個 ListView、一個ToolBar、一個 Button 組成的。於是也寫了個菜單類，但我並沒有用 ListView 去實現，雖然不敢和 Windows XP相比，但我認為其是一種有個性的菜單，拿出和大家分享!

一、統一風格漂亮介面設計的理論與實現a．視窗和對話方塊Windows操作系中視窗和對話方塊在我們看來是一樣的，就是一個四邊形，有標題列、系統按鈕，邊框等，可移動和可變大小。實際上視窗和對話方塊是有的區別的。在建立對話方塊視窗時的工作中要發生兩個主要過程：對話方塊的過程和其視窗過程。Win32

實現令人滿意的風格統一的軟體介面確實很難,　象網友提到的MessageBox、FileDialog、FontDialog、目錄選擇對話方塊等MFC內部甚至系統DLL內的對話方塊，要想讓它變臉可不容易。有人說HOOK技術可以，HOOK技術確實可以，HOOK可以說是無孔不入，但HOOK的使用效率卻是令人難以滿意的，從目前大多數采HOOK技術的換膚軟體使用方式來看，完全可以證明這一點。今天我們將討論另外一技術來實現FileDialog的變臉，這種技術叫替換視窗過程法（註：本人杜撰）。視窗過程函數是大多

我們使用過很多的軟體， 給我們留下印象很深的是那些介面漂亮且迷人的軟體，

由於工作需要，使用了Tangram團隊開發的TangramMini組件。自認為對此組件瞭解得足夠深入，並且網上相關此產品的文檔不多，所以從今天開始寫幾篇TangramMini組件教程。TangramMini組件是Tangram團隊從Tangram架構產品中演繹出來的迷你微型版本，在非商業產品中可以免費使用，認證後還可以做商業開發，功能強大，主要用於軟體產品架構設計、B/S與C/S無縫結合能及軟體快速二次開發等。TangramMini組件包內部提供兩個主要COM組件，一個為TangramMiniC

現在有很多軟體都推出了試用版，其中就有一些是限定軟體的使用次數的，我用MFC也寫了一個類似的程式。其實很簡單，只要在程式初始化時（InitInstance()函數中），加上以下幾句：unsigned char buffer[255]={0};unsigned long length;unsigned long type;HKEY

本文介紹了軟體體系架構產生的背景和架構模式的基本理論。重點介紹管道與過濾器體系架構模式的結構，實現，優缺點等，然後以J2EE的Servlet Filter為例進行剖析它是怎樣應用該架構模式的，最後簡單闡述了在其它J2ee應用中(Jboss和Axis)的實踐。軟體體系架構1、軟體體系架構產生背景在經曆60年代的軟體危機之後，使人們開始重視軟體工程的研究。來自不同應用領域的軟體專家總結了大量的有價值的知識。 當初，人們把軟體設計的重點放在資料結構和演算法的選擇上，如Knuth提出了資料結構+演算法=

背景資料：據悉，2004

一般來說，選擇一種軟體開發方法，更像是加入一個邪教組織，而不像是做出了一個技術決策。許多公司 甚至從未試圖去評估這些方法，而僅僅是盲目採用最流行的方法，這就造成了如今五花八門的各種敏捷方法。 因此本文將使用包括功能點、缺陷移除率（DRE）、品質成本（COQ）以及總擁有成本（TCO）在內的一些標準 的度量指標，對現代軟體開發方法的樣本進行比較。目前有約55種已命名的軟體開發方法正在使用， 還有更大數量的混合方法。這些開發方法中包括傳統的瀑布方法、各種花樣的敏捷、Rational統一過程（RUP ）

1. 突破性與非突破性《黑天鵝》裡談到了突破性與非突破性的概念。這世界上有些職業的 收入是不具突破性的，比如麵包師、諮詢師、按摩師、牙醫等等，其收入受到既定時間內所服務的客人的數量 的限制，這種工作在很大程度上是可以預測的，麵包師必須為每一位客戶烤出新麵包，不論他出售的麵包單價 有多貴，其收入總是受到限制的。而另外一些職業如錄音師、電影演員、作家、投機師等等，他們只 需花費單次的投入而不必過多勞動就有可能使得收入後面增加幾個零，《哈利·傳輸速率》的作者不必每次有讀者

軟體架構師是開發軟體時在使用者需求分析與系統設計階段的靈魂人物，與傳統的系統分析員相比，軟體架構師的工作能為接下來的代碼設計，以及將來的運行都提供更好的指導。有人把架構師的工作定義為分解系統模組以及定義相互之間的關係，也有人認為架構師就是對軟體設計核心環節設計的一系列決策；之所以架構師在現代軟體開發體系中越來越重要，還與目前流行的軟體開發組織圖有一定的關係。一、“軟體人”面臨的困惑：隨著軟體行業競爭的加劇，有資料顯示一個商業軟體推出的周期不能超過九個月。客戶為了適應市場的

介紹：對于敏捷Team Dev來說，團隊管理也是必不可少的，我帶領的團隊分2部分，1個是Team Dev，一個是測試團隊。Team

介紹：在開完了Sprint Setup Meeting,並且吧所有的Story Point都合理的估算之後，下面一步就是吧story細分到每個開發人員/測試者手裡，讓他們在story下面建sub-task. 這裡最關鍵的問題是，如何更高效的利用團隊的人力資源並且做最合理的分配。實現方式：這個其實都是根據skill

介紹：對於story來說，一個很重要的衡量它的大小的因素就是story point,它不等同於軟體工作量評估中的Function Point,因為story point只是用來粗略的相對的估計story的大小，而Function Point則是用來衡量功能模組的精確大小並且要參與到公式計算的，這裡澄清下。story

介紹：對于敏捷軟體開發來說，能時刻保持跟進項目的進度是非常重要的，因為你可以隨時瞭解團隊的健康情況，並且對各種突發情況進行突發的處理，從而保證每個迭代結束後我們的項目可以按時的交付。實現方式：看項目進度的最好的工具當然是burndown chart,我們使用Jira做專案管理工具，Jira中有一個Report視圖，可以非常直觀的顯示story的burn down 曲線，從而讓團隊直觀的明白這個sprint進展的如何。當然了，這個是從story層級的，它衡量的是隨著時間的流失，story

介紹：對於一個迭代周期Sprint來說，最先開始的活動並且也是最重要的活動之一就是Sprint Setup Meeting. 在這個會議上，我們主要會去探討一些這個Sprint我們需要完成哪些story，並且這些story的具體需求是什麼。其實，我們公司走的是離岸開發模式，這種模式下，我們由於和我們的客戶有個時差（9小時） ，所以很難大家坐在一起然後和標準的Sprint Setup Meeting一樣開始plan.

介紹：因為我們的開發週期是迭代進行的，以Sprint為單位，我們每個Sprint如何去和客戶說我們的成 果呢，那麼我就需要Demo和release一些新功能，或者一些bug fixing。Demo我這裡不討論了， 大體上就是部 署都伺服器上然後運行下給meeting的所有人看下，我們這裡主要討論和發布(release)有關的話題。實現方式：話題1：我們如何讓發行者知道我們這個Sprint做的功能？因為就像jdk一樣，它的每次大

介紹：在敏捷式軟體開發 (Agile Software Development)中，從代碼的產生速度上來看，要比傳統Waterfall產生速度高很多。因為我們把時間安排的更加緊湊了。那麼這麼多的代碼，如何能保證這些代碼品質呢？很多人可能直接想到靜態代碼偵查工具。沒錯，那些是可以定義一個代碼檢查規則來確保代碼的品質，但是那個僅僅是從語言角度，那麼邏輯是否已經最佳化了？可重用性是否已經最佳化到極致了？這些是靜態代碼工具不能完成的，所以我們需要Code

應朋友之邀，我準備寫一組文章關于敏捷軟體開發的實踐，也協助廣大沒有用過Agile的或者只停留在書本內容上的朋友親臨敏捷式軟體開發 (Agile Software