其他

上一篇介紹了微核心流程引擎開發背景，這篇介紹它的功能描述。準系統：1、能夠通過指令碼定義流程，更改流程。2、對軟交換系統應用伺服器的所有的介面都可以編輯。3、異常處理，實現補償機制。4、流程要支援：順序執行，分支處理，跳轉執行。5、指令碼中支援簡單的資料庫操作，比如：記錄查詢（根據查詢結果決定流程），欄位查詢，記錄增刪改。擴充功能：1、提供多種調用形式：1）動態連結程式庫直接調用；2）socket通訊調用；3）遠程調用；4）WSDL方式調用。2、實現一個流程引擎虛擬機器。專門處理流程。3、支援業

自從接觸設計模式以來，一般看到的評論是以推崇為多。不過比較欣慰的是，最近在看《編程人生》中，有兩個人對設計模式比較不屑。 之所以欣慰，並不是因為湊個熱鬧看他們互相攻擊，互相批評——而是因為出現了不同的觀點，特別是兩位非常有分量的人物的觀點。在技術領域，眾口一詞是一件非常恐怖的事情；百花齊放百家爭鳴才是我們樂於看到的。因為不同觀點的出現，特別是大師級的不同觀點，能夠促進更多的人去獨立的思考與探索。 好了，迴歸主題。編程人生中，《編程人生》中至少有兩個人談到了設計模式。

我設計的流程引擎是腳步驅動的。指令碼中定義了流程執行的環境，流程操作的對象，流程執行的步驟。下面是一個流程指令碼的樣本：<?xml version="1.0" encoding="utf-8"?> <process name="make_call">     <data type="user_tel">called_number</data>      <object type="user"

在公司工作了四年組織了兩次新員工培訓，馬上還要組織今年的新員工培訓。這過程中有些經驗和想法和大家分享一下。第一次：照虎畫貓第一次組織新員工培訓時，自己剛工作也沒有多長時間，能力實在有限。唯一的優勢是我之前在前一家公司參加過一次系統的培訓，當時還算印象深刻，就和另外一個同事一起組織了這次培訓。這次培訓除了培訓的內容不同外，培訓的步驟基本照搬。所以不敢自稱“照貓畫虎”。其實這次培訓除了照搬步驟外，我也想把他們培訓灌輸的那種精神和文化業複製過來：職業化的態度，奮鬥的精神。。。這次培訓我投入了很大的精力

以前看贏在中國，一個評委問一個選手一個問題：　　“如果給客戶，利潤，員工排一下順序，企業（企業家）應該把誰放在第一位？”　　選手的答案我記不大清楚了。我後來對這個問題思考過一段時間。確切的說，我認為這個問題應該是一個遞進的問題，而不是一個順序的問題。我個人認為應該是這樣的一個邏輯：　　“對一個企業來說，三者都是必不可少的一部分：利潤是企業存在的根本，客戶是利潤的源泉，員工是贏得客戶的動力。”　　如果真要給這三者排一下順序，我認為，企業（企業家）應該把員工放在第一位。因為，企業（企業家）只有把員工

《重構》第三章學習筆記我們必須培養自己的判斷力，來決定在什麼時候進行重構。1.1  Duplicate Code（重複代碼）如果你在一個以上地點看到相同的程式結構，那麼將他們合而為一會更好。1.2  Long Method（過長函數）擁有短函數的對象會活得比較好，比較長。間接層所能帶來的全部益處：解釋能力（可讀性），共用能力（重用性），選擇能力（？）。現在OO 語言基本解決了函數調用所產生的開銷。“

文章目錄 1  構築測試體系 1  構築測試體系如果你想進行重構，首要前提就是要擁有一個可靠的測試環境。“編寫優良的測試程式，可以極大的提高我的編程速度，即使不進行重構也是如此。”1.1  自我測試代碼（Self-testing Code ）的價值“Class 應該包含他們自己的測試代碼。”“每個Class 都有一個測試函數，並用它測試自己這個 Class

最近在學習《unix編程藝術》。第一章非常不錯，講了很多Unix的曆史，哲學基礎，其中最重要的是提到的十七條設計原則。很多原則自己也知道，但是從來沒有總結的如此詳細深刻。下面的內容大部分來自《unix編程藝術》這本書，少部分是我的一些理解。這是我讀書的一個習慣，對於我認為重要的，我會把它打出來，在打字的過程中我會根據深入的思考理解。所以，筆記對我來說是一個思考和記憶的輔助手段。 1、模組原則：使用簡單的介面拼接簡單的組件 “電腦編程的本質就是控制複雜度”。

下面內容來自：《分析模式》。分析和設計存在很多的不同之處，設計的目的是為了更高實現一個技術方案，而分析的目的是為了理解問題的本質。這不僅僅是用用例列出需求清單那麼簡單的事情。假設我們想開發一個斯諾克撞球類比遊戲，擊打白球後，白球按照一定的軌跡運動，並且撞擊紅球。用例可以列出成千上萬，但是這不足以讓我們開發出一個更好的軟體——你必須瞭解運動背後蘊含的規律。這個問題不難解決，因為這些規律已經眾所周知。但是在很多的應用領域，相關的規律並不讓人易於理解。為此，我們建立了概念性模型——一種運行我們瞭解並簡

為什麼需要簡單的設計？我想這和人的特點有關。我不止在一個地方看到過，人同時能夠處理的資訊不超過7個。我想這應該就是人們追求簡單設計的根本原因，人需要用一個簡單的設計去解決現實中的問題。如果真的存在完美，也許簡單的東西就是完美的東西。很多人都崇尚簡單設計的思想，那麼什麼是簡單設計？下面談談我的理解：1、首先要能夠解決實際問題的；這是所有設計要達到的目標，雖然實現的手段和方法，效果不同。簡單的設計也必須達到這個目標。2、易於理解的；易於實現的；易於維護的；我認為這是簡單的設計最迷人的地方，也是它最有

下面是最近對公司研發管理的一些思考，和大家一起討論。一：關于敏捷：1）敏捷是否適合電信行業？對於想互連網這樣“小而快”的行業，敏捷開發無疑是適合的。但是對於電信行業這種“大而笨”的行業，是否也適合？我一直有這樣的疑問。電信行業有他自身的特點，比如，需求變化一般不大，相對比較穩定；對穩定性的要求比對快速發布的要求要高，如果穩定性有問題，影響一般很嚴重；一般採用更底層的語言（比如c）來進行開發。將敏捷理解成“裸奔”，通過犧牲品質來達到快速交付也許有些狹隘，但是在快速的交付的同時保持高品質，這對開發人

文章目錄 明智而審慎的使用private繼承（Use private inheritance judicious.） 明智而審慎的使用private繼承（Use private inheritance judicious.）private繼承的兩條規則： 1、 編譯器不會將一個derived class轉化為baseclass，但是卻可以顯示轉換。也就是，他們之間不是is-a的關係。 2、

這一塊對我來說是一個新的領域，所以剛開始看起來有些吃力。希望能夠慢慢的進入狀態。也許需要依靠筆記的幫忙。在我的學習中，學習筆記佔有很大的地位，他不但是記錄，更重要的是，他協助我更深入的思考。不寫筆記我會感覺沒有學到東西。1.1.1. 層可以將系統劃分為子任務組，每個子任務組在一個特定的抽象層次上。 1． 例子 ISO7層模型。 2． 語境 一個需要分解的大系統 3． 問題 假設有一個系統，它明顯的混合了底層與高層的問題。 強制條件： 1）

最近讀完《unix編程藝術》，一本不錯的書，值得好好讀一下。書中提到了一些非常有啟發性的設計概念，這裡和大家分享一下。模組性：要編寫複雜軟體又不至於一敗塗地的唯一方法，就是用定義清晰的介面把若干簡單的模組組合起來。模組性可以說是聽到的最多的一個，它已經深入程式員的心中。它的本質其實就是用分而治之的方法來分解複雜度。關於模組的大小，本書有精彩的論述，有興趣可以詳讀。緊湊性：就是一個設計能否裝進人腦的特性。我把它理解為設計的可讀性。緊湊不等以薄弱：如果一個設計構建在易於理解利於組合的抽象概念上，則這

軟體領域一個非常大的特點是流程和技術變化相當的快。作為一個軟體企業，面對日新月異的開發流程和開發技術，何時、如何選擇及引進新的流程和技術變得十分重要。這篇文章主要討論的是進行選擇和引進時的出發點，我稱之為“缺陷驅動”。什麼是缺陷驅動？這涉及到引進新技術的根本原因。其實很簡單，就是為瞭解決軟體開發過程中遇到的問題。但是實際操作時，面對外界的宣傳和影響，人們往往會偏離這個初衷——從追求問題的解決到追求技術的“先進與流行”。學習引進一種新的技術，新的開發方法和流程，根本的原因不是因為它有多新，有多少人

代理者系統結構模式可以用來構建帶有隔離組件的分布式系統，該軟體通過遠程服務調用進行互動。代理者組件負責協調通訊，諸如訊息轉寄，以及傳回結果和異常。我所知的一個應用代理者模式的架構是SOA。1. 例子分布式的城市資訊系統。2. 語境系統由獨立的、相互協作的、分布式的、異構的組件構成。3.

本文範例程式碼採用的是c語言。之前介紹過資料驅動編程《什麼是資料驅動編程》。裡面介紹了一個簡單的資料驅動手法。今天更進一步，介紹一個稍微複雜，更加實用的一點手法——表驅動法。關於表驅動法，在《unix編程藝術》中有提到，更詳細的描述可以看一下《代碼大全》，有一章專門進行描述(大概是第八章)。簡單的表驅動：《什麼是資料驅動編程》中有一個程式碼範例。它其實也可以看做是一種表驅動手法，只不過這個表相對比較簡單，它在收到訊息後，根據訊息類型確定使用調用什麼函數進行處理。複雜一點的表驅動：考慮一個訊息（事

現在的學習筆記要側重自己的理解。用自己的語言，經驗來闡釋它。讀一段後，寫下我的理解。管道和過濾器體繫結構模式為資料流的系統提供了一種結構。每個處理步驟封裝在一個過濾器組件中，過濾器組件間通過通道串連。重組管理器組件可以得到不同的系統族。這個和之前見過的一個語音流的處理結構非常相似。1. 例子這裡列舉了一個編譯器軟體。從代碼到可執行檔經過了很多步驟，每個步驟都抽象成一個過濾器組件。和處理資料流的例子很像。比如一個資料流，從接收到用擴音器播放，會經過很多的編解碼步驟。每個步驟其實也是過濾器。2.

首先聲明一點：這裡的“高並發”是相對的，相對於硬體而言，而不是絕對的高並發。後者需要分布式來實現，這裡不做討論。本文關注的是單機的高並發。最近在做一個語音通訊系統，要求線上使用者2W，並發1K路通話。硬體是兩台伺服器，酷睿多核，4G記憶體，千兆網卡（我用過的最好的硬體，負擔這些應該問題不大）。系統的另一個指標是呼叫時延和語音時延。這是這個系統的關鍵。最終我們的系統拿到使用者現場測試的時候，效果可能有點太好，對方測試不大相信。其實降低時延只要幾個地方把握好了，應該問題不大的。這裡總結一下。 1、 

這兩天在看《編程人生》，這本書確實非常不錯。而且看得也特別的輕鬆。其中有幾個人都談到了如何學習新的語言，但是給我最深刻的是google的首席java架構師joshua