#分手

记得大二那年,夏天一个周六下午,我正在宿舍睡得天昏地暗,昨晚去网吧刷游戏凌晨才回来。睡梦中手机响了，迷迷瞪瞪的接起电话，那头传来熟悉又甜美的声音，一听就是女朋友打来的：今天是我生日，咱们分手吧，我有新男朋友了。晴天霹雳啊！哪时候玩心太重了，神经大条后知后觉，女朋友跟人跑了还不知道。

#移情

现在想起来其实还好，当年女友(小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真言

推荐阅读：

相关文章