本文只是作者在對
soa有了淺顯認識後進行的學習心得總結，內容肯定存在很多的理解偏差，希望同行能批評指正，並一起**，共同學習提高。
以下圖說明了產品，系統，模組，功能之間的關係。
系統n系統2
系統1產品1
產品n模組n
模組3
模組2
模組1
功能1
功能2
功能3
功能4
功能n
產品是由不同的系統構成，系統是由不同的模組構成，模組是由不同的功能構成。本文的作者比較愚笨，只能這樣機械的理解。
從上圖看出，各層級之間的關係都是1：
n的，各功能不同，各模組不同，各系統不同，各產品不同。在這種情況我們去選擇功能
1，功能
2，就可以構建乙個模組
1出來。這樣構建乙個模組是不是效率就會很高呢？但是我們如果去重複創造出乙個功能
1，構建模組
1所需的過程時間自然就加大了。我們只有利用現有的功能，我們的工作效率自然就提公升了。（
btw：好像有點廢話，現在誰不知道重用能提高效率）
未來的企業需要的資訊化系統？我們誰也不知道！至少在某些領域，有專人在研究它，我們就暫且拿這些已經存在的對未來變化的分析做個自我理解吧。
soa（面向服務的架構），是目前在產品架構方面討論的非常火熱的話題，它和
mvc不一樣，
soa重在解決各業務模組，系統之間的關係，而
mvc重在解決具體系統設計上的問題。個人在
soa方面的理解如下：
1、soa
的核心是元件化、鬆散耦合
2、soa
的目標是能快速響應業務的變化
元件化，如何將模組元件化？我們去思考一下螺絲和螺帽，它們是有標準的，只要復合標準，任何螺帽可以套在和它配套的螺絲上。這個是乙個比較簡單的理解。做為業務模組，如何設定乙個標準，讓它能夠元件化？我們暫且考慮簡單一點，其實就是功能的使用和資料的展現：
1、如何讓使用者能快速的獲取到能操作的功能？
2、如何能將資料快速的展現？
我們以「待辦工作」（因為大量的業務系統可能都存在待辦工作）為例進行分析，待辦工作主要是紀錄當前使用者需要辦理的工作，將它元件化後，在不同的平台，不同的業務系統之間就可以相互應用了。那麼如何在不同的平台，不同的業務系統之間實現「待辦工作」的應用呢，我們要從以下方面考慮：
(注：這裡我們暫且不去考慮不同平台，不同系統之間的耦合時需要解決的統一目錄，單點，許可權等問題。
)
1、待辦工作的資料結構
ø基本：待辦人，待辦標題，閱讀標誌
ø擴充套件：待辦**，待辦資訊傳送時間，待辦緊急程度
2、待辦的存在消亡：
ø生成待辦
ø更新待辦
ø刪除待辦
3、待辦展現的要求：
ø全部待辦資訊
ø根據個人待辦資訊
ø根據某時間段內個人以及全部待辦資訊
ø根據閱讀標誌顯示待辦資訊
ø根據待辦**展現待辦資訊
ø根據緊急程度展現待辦資訊
ø展現待辦對應文件的詳細資訊
我們將待辦的存在消亡和待辦的展現裡面涉及到的全部看成是服務，這個時候，元件化的思路就有了。
如何去快速響應業務的變化？對於變化，作者的理解是我們能掌握住有規律的變化，但絕對掌握不了未知的變化，因為它是創造出來的，而不是推理出來的。我們無法避免業務系統的變化，業務的變化必然導致程式，架構的變化，但是我們要努力地減少系統重構的過程，新增加的功能以插入的方式介入。（
btw：這一段好像有點唐僧）
當然，圍繞著這些功能，模組，系統，我們還必須提供一套完整的策劃，運維，實施機制去不斷的改造，以應對不同的市場要求，如下圖所示。
策略和規劃
（定期的）
服務工程
（專案實施）
生產運營
（持續優化）
（未完待續）
對補碼的學習心得
初學c語言，著實為補碼，反碼，原碼這樣的術語傷了一番腦筋。最近終於感覺弄明白了，趕緊記錄一下。以32位數為例，無符號數的32位都代表正數或零，最大111 11,一共32個1,最小是000 000。有符號數的正數只用31位，最高位是區分正負,最大數011111 111，共31個1,還包含0的情況。最大...
學習心得 我的學習心得
我是乙個已經步入中年的70後，離開校園已經20年了，因為當年的政策因素而未能圓我的大學夢，在20年的工作過程中總是因為缺少一張大學文憑而失去了很多機會，曾經也考慮過自考，但是乙個人去面對的時候總感覺心有餘而力不足。2018年3月份偶然讓我認識了尚德，原來自考還可以這樣學習。一直懷疑自己年紀大了記憶力...
學習心得 python學習心得
自從來了深圳工作以後，尤其是屢屢面試碰壁以後。發現其實自己的知識面很窄，做筆試題的時候絞盡腦汁還是漏洞百出，並不是不會做，而是出現一大堆不該有的失誤。每次被問道，對資料庫了解嗎？說一大堆看起來很高階的東西 好啊，那我們寫幾個sql語句吧。馬上完蛋了，沒了手冊關鍵字都記不起。了解哪幾種指令碼語言，sh...