其他

 手工作坊式的企業，對程式員的要求是比較高的。每一個程式員，都要對整個項目有比較深的認識，就要求程式員的個人能力要超群卓越。但是，這種人畢竟是少數的。 從企業的角度，是人才短缺。而對於廣大的程式員群體來說，就是職位少。 如何能適度的降低對程式員技能的要求？我覺得並不是教育能解決的，重點不在於程式員，而在於企業。企業規範自己的用工環境，降低對程式員的要求才是好方法。 中國有龐大的程式員群體，但是能利用上的很少，這是因為企業制度和流程的落後。

關聯內容： 物件導向思想的頭腦風暴（一）關聯的文章討論了一個開放封閉原則的具體案例，其中前兩個是超級複雜化的設計，而且還完全不符合開放封閉原則。但是，我想如果沒有學習過所謂的設計模式的人，絕對不會犯前兩個這種“模式過度”的錯誤的。因此，設計模式的愛好者們，要小心了，讓你代碼變得噁心的，往往就是你所熱衷的東西。然後第三個用委託。第四個用組合介面的方式。也許是例子不夠好，我覺得第三第四也是不完美。我們回顧一下設計要求：“需要處理三種產品圖書，數位，消費，需要計算產品的稅率，圖書的稅率為價格的0.1，

一提到資料校正，大家都會覺得非常熟悉，因為做UI部分的人居多，而只要有UI，就有資料校正。很多時候，一個每個頁面的資料校正都要重新寫過，因為判斷的邏輯不同，而且整合起來似乎不是很有必要，但也有點麻煩。由於開始使用.net以來，大部分工作是做winform部分，所以對校正的問題，自然是經常碰到，每個頁面都要寫校正，碰到的多了，就想這個問題有沒有好點的解決辦法呢？想了好久，整理了一下，願和大家分享。資料校正，我把它分為三個層次。第一個層次是，資料校正。也就是對一個數值進行校正，比如判斷一個字串是否為

 很多人學習物件導向和設計模式，往往是為了技術而技術，只是學到了形式，很僵化。這都是因為沒有把握好技術的目的是為了什麼。對於設計來說，他的目的就是為了方便軟體開發和軟體維護。  不提倡濫用設計，在於設計是和你當前的軟體開發需要是相匹配的。對於你這個項目的要求，可能平鋪直敘，直觀的方式是最有效率的。因為只有你一個人在幹，你就沒有必要通過設計來分配功能任務給若干個開發人員，沒有這種需求，就沒有這個設計的必要。又因為你這個項目很小，設計一個高度抽象的架構出來，卻只有一個簡單的實現，架構的靈活性完全排不

workflow service，是通過WorkflowServiceHost來託管的，WorkflowServiceHost繼承自ServiceHostBase，因此workflow service具有普通的wcf service的所有feature。但是workflow service還是有一些不同：1)不用定義介面作為Service Contract，而是直接在Receive上定義介面訊息。然後在Receive上可以指定ServiceContractName來約束service

 很多新手，總是把使用者介面的代碼和商務邏輯的代碼 混在一起。到 最後，導致整個流程變得很複雜，要理解很不容易。 好 的代碼應該是結構清楚的。而將介面代碼和商務邏輯的代碼區分開來，是新手進階的第一步，也是比較容易實踐的一步。 比如五子棋遊戲，在邏輯層面，下一個子不過是在二維數組寫入一個標誌。但是使用者介面介面的代碼就包括，讀取鍵盤的輸入，判斷輸入是否合法，輸入的內容是什麼，然後再調用邏輯代碼。如果將這些混在一起，本來很清晰的邏輯代碼，變得無比複雜。保持邏輯代碼的清晰是很重要的，這些是核心功能。 

現在這個項目裡，我們使用了jenkins (原hudson, http://www.jenkins-ci.org/)作為CI server，開源肯定是最基本的考慮，此外這個決定是受到了前任老大的影響，jenkins是java生態圈中的一個不錯的選擇，現在我們這個項目採用的是.net技術，能否很好的用起來呢，有點兒擔憂，一路見佛殺佛見魔殺魔，磕磕碰碰，到現在基本是搭建起來了。基本的組合是，jenkins + svn + msbuild + mstest

每天，總有幾樣事情等你處理，這個時候應該先把重要的做好，這樣才可以有精力做到最好。這個道理很淺顯，但是很多人有意無意就打亂了這個順序。比如做作業，老是能拖就拖，最後越來越不想去做，這是因為把精力花在其他地方了，缺少精力提高了完成作業的難度。娛樂等瑣事是永無止境的，可以把你最後一點精力的消磨掉，當你精神狀態不好的時候，怎麼可能把重要的事情完成呢？事實上，重要的事情本身不是很難完成的，只是把它放在後面來完成這個習慣，導致我們很難去完成。一個老是無法把重要事情完成的人，很難有什麼幸福。建議：當你有幾件

 結構優美的代碼，是每個程式員的追求。可能這個沒有嚴格的標準，但是有些原則會有助編寫結構優美的代碼。 1.對代碼的邏輯層次要有感覺。比如大體上，一個程式會分三個層次：介面層，邏輯層，資料層。簡化後一般也有兩個層次：介面和邏輯層。邏輯層是去掉外表的，內在的，實質的東西。一般來說，就是表現為對資料的一組操作。而介面層，是關注程式應該如何和使用者溝通的。比如可視的視窗，圖表，控制項等。它是內部邏輯的呈現，也是使用者和內部邏輯溝通的橋樑。 區分這兩個層次的好處，一個是這兩個層次所注重的核心內容有所不同，

在我的項目代碼中，我習慣於把一些對象進行序列化，然後存入資料庫，出於節省空間的考慮，我一般使用.net 4.0中帶的DataContractJsonSerializer類來實現，一般我我會寫兩個方法（Serialize方法和Deserialize方法）放到我的Utility項目中。Serialize和Deserialize方法分別如下：  /// <summary>/// Serialize T to string/// </summary>/// <

 最近看到一個報紙報道：《富同學窮同學》。裡面列出了一大堆的所謂窮同學和富同學的對比，但我感覺，認識太刻板。下面說說我對成功的認知。 1.成功是一種機率。 成功不是必然的，失敗也不是必然的，雖然這樣，但成功機率的大小是可以改變的。任何人都能成功，機率多少而已。但也有這種可能性：有些人機會多，但是沒去把握。有些人可能一輩子就一兩個機會，可是他牢牢把握住了。一個只有幾次機會的人，實際上卻成功了，而一個機會很多的人，卻沒成功。因此，並不是所有成功的人都有漂亮的故事可以訴說。  2

上周五碰到一個問題，我部署到IIS 7上的應用程式訪問不了了，瀏覽WCF服務時報HTTP ERROR 503。檢查時發現Application Pool停止了，手動啟動起來後，重新瀏覽頁面，還報503錯誤，再看Application Pool，發現它又自動停止了。起初以為IIS重啟一下就好了，可是沒用，機器重啟也沒用。究竟是什麼原因呢？最近我的機器也沒做什麼啊？除了改了一次密碼。哦！問題就出在這裡。Application

 顧名思義，就是介面加上測試代碼。 任何符合這個介面的，除了介面樣式要對應之外，同時還要運行通過測試。 interface iphone{       void call(string number):　　 test{ ... } ;} class Nokia : iphone{            void call(string number){...} }  class Motorola : iphone{          void call(string number){...} }

<p$1$2$3$4$5$6> c#有個new函數的文法，但是我覺得這個東西用途很少。很多時候容易出現設計上的錯誤。<p$1$2$3$4$5$6> 基類有個虛A（）函數，子類不想覆蓋，但是又想要這個名字，怎麼辦，那就是new

首先要明白 需求 和 （代碼）實現 是怎樣的對應關係。假設需求和實現是一一對應的。那麼需求改變一處，代碼也必然改變一處。有人想要需求變了，卻也不改寫實現，是不符合邏輯的。變化有三種，一句話：增刪改。對三種情況作分析：增：不需要改寫原來的，而增加新的實現。刪：只需要去掉對應的部分。改：改掉對應的部分。因此，結論是，軟體設計，應該滿足在增加功能的時候，不修改固有代碼這個原則。雖然刪除需求的需求不多見~嗯~~~，這個其實是上一個規則的不同表訴。改，嗯~~~本質上也是第一個規則。如何應對需求不斷的變化？

以下為最近的一些個人思考，對於專案管理中，如何管理一個Work Item，從建立到完成的整個周期，如何高效的進行，並能夠根據相關的統計資料（反饋）進行不斷的改進，我想這是所有PM/team leader最為關心的核心問題之一。對於一個任務，有幾個核心的節點：Work Item, Test Suite, Changesets, Work Log。一個任務對應著一段需求或一個bug或一個改進要求，那麼就會有相應的一系列的測試案例來衡量其產出物是否滿足該work item，同時該work

國家公務員往往是“低工資”，高福利。這樣會造成很多不明不白的數目出來，同時也會造成不必要的浪費。如果有一大鍋粥，限定每人拿一小碗，然後大家的福利是可以偶爾去喝一點鍋裡的，這種制度只會防止君子，不會防止小人。如果把這個大鍋，一開始就平均分配，起碼還能做到公平公正。公務員薪酬改革，主要方向是減少福利，提高工資待遇，讓隱藏了的實際數目，浮上水面。高福利的策略不可取。高福利可能造成很大的浪費，福利應該是有限度的，用在必要的地方。比如人身保險，大宗醫學保險等。這些不靠福利，靠工資是有很大風險的，福利的作用

內向不是病，但是往往適應不了這個紛亂的社會。內向者喜愛靜，有道家的風骨，佛家的清靜，這些都是和當前的社會氛圍格格不入的。為了在職場中，生活中更加如魚得水，必須要認清內向者的劣勢：<p$1$2$3$4$5$6> 一、內向者容易被誤解為以自我為中心，不為他人著想。事實是怎樣？大多數外向者都是自我為中心，因為有很強烈的個性主張，只不過是善於建立交流渠道，和善於利用他人，並不是真心真意為他人的處境著想；而內向者總是會考慮到對方的處境，反思自己的行為，謹言慎行，以免對對方造成傷害。這對內向者有

UI，邏輯，資料三層模式是最為經典的面向大規模資料處理的項目情境的解決方案。下面是我的看法：UI層使用邏輯層，而邏輯層使用資料層。也就是，UI依賴邏輯，邏輯依賴資料。從物件導向角度，資料層位於抽象的頂端。物件導向的原則，是抽象頂端盡量不要變動，否則依賴他的底層必然需要修改。而底層可以變動，頂層無需更改。在這種三層模式下，資料層是最不允許變動的。不過實際項目的後期維護中，我們絕不會無端端為了修改UI而修改UI，而是使用者的需求發生了變化，其中變化的主要層次，就是資料層的變化。這種現實下，三層模式是

我的機器上IIS7不知曾幾何時竟然打不開了，重裝了兩次依舊不行，我的作業系統是WIN7 企業版。問題的癥狀是在管理工具中雙擊IIS 資訊服務管理器後，在工作列上會顯示，但是不會顯示出介面，在瀏覽器中敲入http://localhost/，可以正常顯示有多種語言顯示welcome的IIS7的歡迎介面，非常奇怪。在baidu上找到了一些同病相憐的問題，但都沒有解決辦法，只好找google幫忙，找到了一篇文章：Can't open IIS