#分手

記得大二那年,夏天一個周六下午,我正在宿舍睡得天昏地暗,昨晚去網吧刷遊戲凌晨才回來。睡夢中手機響了，迷迷瞪瞪的接起電話，那頭傳來熟悉又甜美的聲音，一聽就是女朋友打來的：今天是我生日，咱們分手吧，我有新男朋友了。晴天霹靂啊！哪時候玩心太重了，神經大條後知後覺，女朋友跟人跑了還不知道。

#移情

現在想起來其實還好，當年女友(小Q),20,女,貌美,膚白,身嬌,體軟,長發,悶騷男想起她的音容笑貌,傷心欲絕,為了他幾度自殺未果，一天後走出被分手的痛苦陰影，移情別戀,愛上了計算機。從此一發不可收拾.再回首已經為愛堅守十幾年.

#反思

初戀畢竟是美好的,隨著年齡的增長,我有時候也會反思,如果當年少玩點遊戲多關心她一點,是不是就不會分手了？如果刷夜回來先別睡覺,打個電話給她估計也能想起來她的生日了?如果不是通電話,而是見面聊,會不會還有挽回的餘地?痛定思痛,我決定把跟初戀女友分手的事件用軟體架構的三原則:狀態,變化和同步重新梳理一下.

#狀態原則

狀態是人或事物表現出來的形態。是指現實（或虛擬）事物處於生成、生存、發展、消亡時期或各轉化臨界點時的形態或事物態勢。(以上來自百科)

女友(小Q),20,女,貌美,膚白,身嬌,體軟,長發,看到這些美好的描述當年她的狀態的辭彙,估計你的腦海裡面已經構建出了一個美女小Q的形象了.可能每個人想像的並不完全相同,但估計都類似.其實這就夠了,通過這些核心狀態辭彙,就已經能夠給你一個小Q的整體印象了.

軟體架構也是一樣的,狀態（狹義理解成數據結構）的梳理和設計是系統最關鍵最核心的工作,集中注意力找出系統中的關鍵實體和實體與實體之間的重要關聯關係是系統成敗的關鍵.

#狀態+抽象

完整準確定義一個人比如小Q其實很難,因為人本身就很複雜很多面,我只能帶著有色眼鏡,用我的視角抓住我認為關鍵的點,提煉這7個辭彙來定義她.其實現在想起來當年真是太傻了,富二代這個辭彙我抽象的時候居然給忽略了.要不然也不至於堆碼十幾年.

架構只能以一種抽象思維聚焦,細化,分解,映射事務的某個非常具體的片面,但世界不是這些片面的簡單加總,而是這些片面之間相互作用,相互疊加,互相影響的產物.有符合預期的也有有意外出現的,整體一定大於各個部分之和.猶如盲人摸象,很難看到全局.這也是架構的意義所在。

#狀態+元語

抽象的前提是你得認識漢字這是基礎,而且還要有社會化的認知,知道身嬌,體軟,貌美,膚白這次辭彙代表的含義.這樣溝通定義問題就簡單多了。

做架構也是一樣的.舉個例子 "板凳",大家聚在一起開會討論,說起板凳是三條腿的還是四條腿的?是方的還是圓的?有沒有靠背?如果定下來說板凳就是三條腿的無椅背的圓板凳.並把這個概念反覆強化,讓團隊所有人都接受這個概念.每當提起板凳,大家腦海裡面浮現出的板凳是一致的三腿無背圓板凳.

一個元語就成功建立了.隨著團隊的發展,這種概念會越來越多,分布在平台的各個層面上,可能會包含業務含義,也可能會包含系統實現邏輯,大家用元語溝通,幾個字,代替一大堆話,能顯著降低溝通成本,也能防止歧義產生.

#狀態+內聚

20,女,貌美,膚白,身嬌,體軟,長發,這些辭彙都是小Q的體貌特徵,聯繫緊密,共同作用,形成一個整體的美女的外貌形象.我並沒有描寫她的興趣,愛好,籍貫,職務,不是這些不重要而是這些跟初戀女友分手這件事兒關聯不大.

研發過程中設計數據結構也是一樣,用整體思維對重點進行分析,把注意力集中在少數的重要特性上面,少即是多.凸顯一些細節,忽略一些細節.

#狀態+耦合+環境+邊界

如果把清楚描述初戀分手作為目標實現,抽象提煉初戀女友的體貌特徵就是十分必要的.

小Q和我就是系統中相互作用相互關聯的兩個重點實體,一個美女,一個程序員苗子.

大學校園,宿舍,青春懵懂就是系統所處的環境.

系統邊界就是只描述跟初戀分手相關的事情不失去焦點.

再回顧一下傷心第一段"記得大二那年,夏天一個周六下午,我正在宿舍睡得天昏地暗,昨晚去網吧刷遊戲凌晨才回來。睡夢中手機響了，迷迷瞪瞪的接起電話，那頭傳來熟悉又甜美的聲音，一聽就是女朋友打來的：今天是我生日，咱們分手吧，我有新男朋友了。"

如果第一段是核心，哪核心系統的架構設計和基礎建設成功了嗎？留介面了嗎？考慮擴展性了嗎？

#變化原則

量子力學說時間並不存在，我覺得也是，時間只是命運不斷做的選擇,去年同學會，見到了闊別多年的小Ｑ，數據整體的結構沒變，狀態變化不少，不想描述具體的狀態了，心已稀碎，我特別不舍的更新掉記憶中的那個小Q的形象，可他的主鍵ID沒變她還是她，原來設計的數據結構（大腦）裡面不支持一個人多條記錄，好崩潰啊，我都不敢多看她，怕把大學的記憶update掉，好痛苦啊。

#狀態+變化+版本

更新會衝掉歷史記錄這太難受了，怎麼辦？哈哈！終於想到好辦法了！聚會回來連夜加班修改了一下大腦的數據結構，增加了一個版本（年齡）欄位，這樣大腦中就可以有兩個版本的小Q了！修改完數據結構，趕緊把大學相冊拿出來重新load到大腦中。心情終於好點了。

#同步原則

上學時太單純，小Q已經變化（變心），我還不知道，因為我們兩個傳遞消息用的是推模型，一般情況下她狀態有變化（喜，怒，哀，樂，餓）會主動發通知給我，我比較懶，沒有做超時控制和異常情況下發起主動查詢，過於被動和簡單，消息傳遞的推拉設計，同步非同步設計，都搞的不太好，導致極端情況下（刷夜）丟失了小Q的狀態（忘記生日）。信息不同步，信息不對稱，異常處理的不好，是分手的主要原因。

#事故復盤

狀態，變化，同步.是建設IT系統時三個非常重要的思考維度:

狀態是系統的靈魂,

狀態+格式=數據結構:數組,鏈表,map,

狀態+固化=資料庫

狀態+高速度=緩存:redis,cache,cdn,讀寫分離

狀態+大容量=分庫分表

狀態+海量數據=hadoop

狀態+關聯=實體建模:一對多,多對一,一對一.多對多

變化是系統的行為功能

變化+狀態=版本

變化+解耦=MQ

輸入+變化=輸出

信息同步是兩個系統的邊界交互

可推送

可拉取

可同步

可非同步

超時設置

異常處理機制

#面向對象（初戀）

爛程序員關心的是代碼。好程序員關心的是數據結構和它們之間的關係

面向對象語言以對象為核心，加一些相關聯的方法，簡直是囈語。

重要的東西應該是數據結構，對象本身有啥重要？

真正有意思的，

是在不同類型的不同對象交互而且有鎖規則的時候。

但是，即使是這時候，封裝什麼「對象介面」也絕對錯誤，

因為不再是單一對象的問題了。

他的結論是，

面向對象解決的都是一些小問題。

-----最後一段為linus真言

推薦閱讀：

相关文章