系统设计初涉及

伴随着系统走过了两个春秋，随着用户量的增加，系统也进行了多次调整，我也渐渐确定了我的职业生涯的一些规划。在这个过程中，我浅谈一下自己对系统升级改造整个过程的心得体会。

几乎所有系统最初的设计都是能用就行。

几乎所有的系统最初的设计就是能用。最初我以为只有企业级的应用是这种做法，因为他们面向的用户量少，客户固定，对使用者专业要求高等等。但是后来，我在参与到面向普通用户的互联网产品的时候，最初的开发原则，也是能用，然后根据互联网行业“小步快跑”的规则进行改进。这么做是有原因的，互联网方面相关的竞争压力大，这是公认的，几乎没有时间留给任何一家公司进行完整的设计和开发，所有的东西都是先拼凑出来上线，获取第一批用户，然后慢慢进行改进。甚至在首轮开发过程中，相关的开发人员对相关的业务模块没有深刻的了解。对于一个项目，我认为这是第一阶段，就是先拼凑出一个东西。都说万事开头难，但我并不认为这是最困难的一段时间。我认为最困难的是第二个阶段。

设计更新更多的是由外部压力造成的。

伴随着第一阶段的完成，第二阶段也就开始了，这个时间段会发生一些事情，比如：系统不稳定，在一些时候会有丢数据的情况发生；在一些时候会有系统崩溃的事情发生；在有一些时候，产品人员提出的新需求根本不能满足，一帮开发人员在纠结，在挣扎，在无能为力，在不停的开会商讨解决方案。对于丢数据，会增加监控，及时补充。对于崩溃，要部署集群以防止单机重启的时候出现用户连不上而引起的其他效应。对于新需求，就要和产品开会研究，找到折中的方案。

但这只是最初的解决办法，随着系统负载的增加，上面的解决方案不能从根本上解决问题，一个平庸的技术队伍，根本不能解决上面的问题。这个时候面临两个方向的抉择：要么会有大批的人离职，觉得这是个坑，根本填不上。在这里浪费生命没有任何意义。要么就是会有一种方案出现，目的是解决掉现存的问题。第一种方向，会决定这个项目失败了。大家各回各家，另找下家。但是第二个方向，会让技术团队里的人浴火重生，很不幸并且很幸运，我遇到了第二个方向。很不幸因为浴火是痛苦的，经历了整整一年的浴火，那个酸爽，简直爽爆了。

浴火的过程大概是这样子的。一方面的压力来自于现有的产品，需要不停的更新。每天都会有产品人员给我打电话：大兰竹你帮我查一下某某用户的资金是不是有500元没充上；大兰竹你帮我看一下为什么那个单子提交不上去；大兰竹你帮我看一下，那个审核为什么没有通过。在那段时间里，我充分体会到了“程序员每天需要两个小时安静的时间”这句话的含义。在维护现有产品的同时，还得参与到新产品新模块的开发中。所以说，整个浴火的过程，是最艰难的一段时间，很多人在这段时间里走掉了。补充进来的新人短时间内有没有“战斗力”。面临的问题和困难。有时候都是难以名状的。

最初省掉的设计，在后期是需要加倍的补偿的。

就像《无间道2》里面倪坤生前的口头话说的一样：出来混，迟早是要还的。最初省掉的设计，是需要后期加倍补偿的。这个并不是对前期拼凑代码的否定。而是现实中确实这样的。绝大部分的技术团队，在做产品初期，对产品是没有一个完整的定性的，对业务域模型也没有完整的建立起来。在产品初期，拥有一支专业化的开发队伍，是绝大多数公司做不到的(这里指的专业化的开发队伍，并不是指仅有高超的开发技术，还要求一半的开发人员对相关业务有比较深入的了解)。即使在产品稳定以后，如何拥有并维护一支专业化的开发队伍，对任何一家换联网公司都是一个绕不过的问题，这是后话，暂且不提。
伴随着拼凑的代码越来越不能满足现有的业务及性能需求，所以几乎所有产品都会经历一场脱胎换骨的变革。这个变革的代价是很高昂的，只有经历了这场架构级别重构，一个互联网产品才能真正的有未来。

业务域模型对系统的设计起到的作用是至关重要的。

前两天在知乎上看到一则提问，大概意思就是如何评价一个互联网创业团队说：我们都准备好了，就差一个写代码的了。我看了微微一笑，没有做过多的评论，因为问题下面的叫骂声已经够多了。

有些问题，代码是解决不了的。如果没有对行业相关的了解，没有经历过行业内部具体业务，单凭开发人员凭空想出来的业务逻辑，对用户来说，简直就是灾难。实话实说，我们最初的设计，并没有考虑到业务相关模型的建立。只是根据需求，拼凑出了相关的功能，(其实我们最初不认为我们是拼凑出来的，只是后来业务模域模型建立起来以后，才发现我们前期的开发是拼凑出来的)，所以到后期的需求变化时，我们便没有了应对措施。发现前期划分好的模块根本就没起作用。根本不是我们想的那样。

一位懂得业务的技术带头人的作用占到一个技术团队贡献的一半以上。

在最困难的时候，我们得到了以为大牛级别的人物。我对他的感觉，就是佩服。(当然了，他已经接近我父辈的人了，比我爸小不了几岁)。他不仅仅是对CoreJava有通透的理解，并且在我们相关的业务方面也是大拿。甚至在很多时候，需要他去给产品人员讲相关的业务知识--他专门学过会计。他带领架构师，花了半年的时间，做出了基于新的业务模型的技术框架。让各个业务模块真正的实现了分离。框架的大部分代码都是他亲自实现的。

我个人认为，他的作用真的占到我们开发团队贡献度的百分之五十以上。有些事情，并不是人多就能够解决的。他的出现也让我认识到，我以前解决的问题的方式是错误的。问我并没有从根本上解决掉所遇到的问题。

(语无伦次了)

写给自己的一些话。

1、增强知识储备。

我写的是增强知识储备，并没有单纯的说增强技术储备，是因为很多设计上的东西是技术外的，技术所做的是对设计的实现，是知识的一部分。

2、从根本上解决问题

这句话很空，但只有说这句话的人，才明白这句话的意思。

3、争取去做一个大牛

努力去实现这个梦想吧。