其他

參考了張逸的書,對抽象工廠這個建立型模式進行了複習.關於該模式的一些介紹和應用場合,我就不再多說了，有很多人的blog 和書上都有介紹.下面把項目的 架構和實現給大家。架構：實現代碼：IReportFactory.csusing System;using System.Collections.Generic;using System.Linq;using System.Text;namespace AbstractFactory{    public interface

在別人實現的基礎上進行開發，基本是一種常態。特別是對原來的代碼陌生的情況下，有沒有什麼好的實踐方法呢？基本原則:類似重構一樣，盡量減少對原有流程和結構的修改，最好能相容原有結構。上來就按自己的相法來修改代是比較容易的，這樣做很大程度是因為理解原有的代碼需要較長的時間且有一定的難度，但這樣會增加系統的複雜度，也會引入許多不必要的風險。除非得到項目負責人的同意，否則相當然的直接動手重寫，絕非是什麼好事！那麼如何做呢？要花大量的時間從頭閱讀代碼嗎？你以為文檔寫得那麼好嗎？嗯，閱讀代碼和文檔是免不了得，

轉載請註明出處:http://blog.csdn.net/horkychen循環複雜度用來評價代碼複雜度，以函數為單位，數值越大表示代碼的邏輯分支越多，理解起來也更複雜。循環複雜度可以成為編碼及重構的重要參考指標，以指導撰寫可讀性高的代碼。有關循環複雜度的定義，可以自行搜尋。《代碼大全》有如下的定義:計運算元程式中決策點數量的技術 (代碼大全2,19章P458)1.由1計數，一直往下通過程式。2.一旦遇到以下關鍵字，或者其同類的詞，就加1：  if, while, repeat, for,

轉載請註明來源:http://blog.csdn.net/horkychen 解bug應當是修複代碼中的缺陷，而不只是隱藏起來!(譯註 ：解Bug時常發生分析時總感覺快找到答案了，而後面卻一再陷入僵局。比如，將線程同步問題引起的一些時而有，時而沒有的問題。分析時可能會認為這是個典型的線程同步問題，A線程沒有按照預期的方式改變某個變數，導致了B線程處理出錯。這樣的分析結果如果沒有調試(Debug)的支援，就有可能將開發人員帶入死胡同，找出一大堆的解決方案可能都無法完整地解掉Bug。一定要在每次陷入

 團隊應該一致同意採用一套簡單的格式規則，可以運用將這些規則自動化的工具。代碼格式關乎溝通，而溝通是專業開發人員的頭等大事。或許你認為“讓代碼能工作”才是專業開發人員的第一優先順序。你今天編寫的功能，極有可能在下一版本中被修改，但代碼的可讀性卻會對以後可能發生的修改行為產生深遠影響。原始代碼修改之後很久，其代碼風格和可讀性仍會影響到可維護性和擴充性。即便代碼已不複存在，你的風格和律條仍存活下來。向報紙學習看看寫得很好的報紙。從上到下閱讀，在頂部，有頭條，告訴你故事主題。然後第一段是大綱，接著細節

 6.1 資料抽象隱藏實現並非只是在變數之間放上一個函數層那麼簡單。類並不簡單地用getter和setter將變數推向外間，而是暴露抽象介面，以便使用者無需瞭解資料的實現就能操作資料本體。如下面是一個閱讀器，需要擷取當前閱讀進度。介面定義如下：   public interface PaperReader   {       double getTotalPages();       double getCurrentPageIndex();   } 而較好的方式是:   public

模組化是一個"發現"模組化(Modularity)這個概念與其說是一種創新，不如說是一個"發現"。這正是人們在解決問題時常用的行為方式和思維過程。它不是單純的技術問題，更深深地影響著整個社會生活。可以讀讀<<設計原則:模組化的力量>>,

做了一個小東西，裡面有多個角色，每個角色都有特殊的功能表項目，現使用原則模式對其簡單實現。關於策略模式的介紹請參考其他書籍。下面是項目架構和實現：架構：實現：IMenuStrategy.csusing System;using System.Collections.Generic;using System.Linq;using System.Text;namespace StrategyPattern.BLL{    public interface  IMenuStrategy    {   

DWR（Direct Web

“不想當將軍計程車兵不是個好廚子”，《武林外傳》中的一句台詞，讓我們捧腹大笑的同時，更讓很多人都記住了編劇寧財神這個才子。當一個人在某些時候被稱之為“人才”的時候，實際上是因為此人在某一“專業”方面具有紮實的功底，這些“專業”本身也許並沒有很大價值，但是發揮“專業”後卻能夠為他人創造出非凡的價值，這也是一個人有其個人價值的原因。網上很多人都在說，在美國請律師是一個很燒錢的事兒，你向他提問，他要收費；你讓他往你公司趕，他也要收費；你讓他去搜集證據，他更要收費。所以，有時候我會經常在想：為什麼美國的

MediaPlayer同MediaPlayerPrivateInterface，再同播放控制項的互動過程應當要簡單、清晰。MediaPlayer通過自身的狀態(Network States 和 Ready

識人用人是指識別和發掘下屬的優勢與潛能，用人之長。對於不足的部分，也可以有效地加以補強。雖然這個工作很重要，但相關的研究和方法五花八門。個人覺得適合就好，倒不一定非要熟讀九型人格，然後再加以套用,並且不見得合適。準確的認識一個人總需要一些過程，中間需要多次修正，才可能比較完整。結合所從事軟體開發工作的特點，我使用了能力賬戶(靈感來自<<高效能人士的七個習慣>>中的情感賬戶)的概念來識人用人。   表格樣本:  各項的評價都以正向的方式進行，有利於將焦點定位於"所長"! 對

HTML的每個元素都可以讓JavaScript在某些事件發生時，進行處理。就比如onclick="clickButton()"之類的屬性設定。像下面這篇部落格所講的一樣,在WebKit中每個元素都有其對應的JS綁定的實現：[WebKit]為JavaScript

轉載請註明出處:http://blog.csdn.net/horkychen來源 Check In, Don't Check Up (照看而不是介入!)我從來不是微觀管理者(micro-manager)，特別是應用agile和Scrum之後。初入職場時，要不是太忙於和別人攪和在一起處理問題，我很可能就會成為一個微觀管理者。但是當盡量避免同大家一起檢討細節問題時，仍要認真地照看(check-in)他們。我是從這篇文章(細小的成功多麼重要)得到啟示的。 介入(check-up) &

轉載請註明出處:http://blog.csdn.net/horkychen(節選自MSDN-Coding Techniques and Programming Practices)命名

研究發現，縮排可以提高程式員的理解能力(<<Program Indentation and Comprehensibility>>, Miaria et al.

項目最本質的一個特性是不確定性，所以實際的執行與預估有些偏差很正常。預估較實際所花費的工作量時大時小，有人快，有人慢。單獨從個人能力來解釋進度並不客觀，因為本來項目排程時就應當考慮到人的能力的不同。既然一切都在項目進度規劃中定義，所有工作都能按步就搬的完成自然最好，但項目的不確定性告訴我們這是難以確定的。總有些任務會提前，也總有些任務會滯後。如果我們只關注滯後的任務，那可以想像項目總會延期的，最好的結果也只能是按時完成。但如果我們能利用到提前完成的時間呢？項目中識別關鍵路徑並嚴加監控是常用的做法

為什麼程式要瞭解思維的障礙，並要練習有意識的加以克服？這裡舉一個實際發生的問題。寫代碼像寫作一樣，有時思如泉湧，順著思路就把一段代碼寫得有模有樣。下面是一個狀態代碼檢查的例子(這種寫法本身並不嚴謹，但這裡要討論是一個更為嚴重的問題.)：typedef enum { STATE_DEFAULT, STATE_A = 1, STATE_B = 2, STATE_C = 4} STATE_ITEM;// state為獲得的狀態 if (STATE_A & state) { }

一、概念AOP（Aspect Oriented Programming）：面向切面編程。面向切面編程（也叫面向方面編程），是目前軟體開發中的一個熱點，也是Spring架構中的一個重要內容。利用AOP可以對商務邏輯的各個部分進行隔離，從而使得商務邏輯各部分之間的耦合度降低，提高程式的可重用性，同時提高了開發的效率。二、用途日誌記錄，效能統計，安全控制，許可權管理，交易處理，異常處理，資源集區管理。三、詳解注意：代碼請見下篇博文1.

sql語句有一種特別的用法，相信很多人還不知道，我也是後來學到的，因此拿來跟大家分享下：產生sql指令碼舉個例子：select 1 from student;如果表中有資料的話，你就會發現查詢的結果會是：根據這個原理，我們可以用來產生sql指令碼，以下就是執行個體：執行個體1：一個簡單的例子select * from Popedomselect 'insert intoPopedom(id,popedom_name,popedom_value) values('+cast(id as