我的软件架构方法论

我们公司内部职级晋升中，当目标职级比较资深或者专家后，有一项考察内容是：有自己的方法论。

什么是方法论

方法论很多人听过，可是很多人也在问什么是方法论？

方法论是我们对于很多事情进行思考沉淀后，具有总结性的指导思想。

比如很多名言警句就可以是方法论。

• 近朱者赤，近墨者黑
• 勤能补拙
• 等

软件架构方法论

少即是多

一次有人问我，你有没有总结过你的方法论？ 我说我的方法论是：少即是多。

之前对系统接口进行性能和稳定性的优化，第一期优化的效果还可以，他们问我都用了哪些技术手段，用了哪些新东西。 我说我删了5k行代码，他没说你的方法论就是“删代码”。

最开始接到这个系统的时候，努力去整明白他里面做的事情是很难的。 等一部分代码逻辑明白后，发现里面做了很多无用功，可能是之前的系统设计的太烂了，完全没有考虑到后续扩展的方向，也可能是产品的需求改了又改，大部分代码都只能为了适应业务迭代而修修补补，结果造成了一大堆无效而冗余的代码存在。

于是首先是梳理系统响应接口的主要目的，梳理上下文逻辑，梳理数据流逻辑，删除冗余代码，让代码编写的更易读，更整洁，更优雅。 对代码逻辑进行抽离，和封装，复用。

很多人看待代码分离，都只是简单对分层，分模块。 我写代码主要的分离除了上面两点，还有一个是计算和存储分离，这个点后面讲。

总之这个可用性和性能优化，仅仅通过“删代码”就达到了目标，为未来的进一步优化带来了很多空间。

我们内部有个代码统计系统，每次发版打tag都会进行一次统计，别人每次都是绿色的加号，+500，代码增加了500行。 我的每次都是红色的减号，-1500，我又删了1500行代码。

面向大数据系统设计

上面说了，我分代码逻辑还有一个是计算和存储分离。

很多人写代码，除了写面条代码外，虽说可以分成很多子方法，子模块，代码行数控制到80行，可是依然难读。 因为这样做只是简单的文字分页而已，并不是一个软件开发的思想。

我写代码一般会考虑这个功能是读功能还是，写功能，进行抽离，这样的话读功能在数据量上来之后我们可以做很多我们可扩展的能力，比如拆库拆表，比如引入缓存，比如多存储介质存储等，完全不用关系业务逻辑问题。

计算和存储分离是数据库的执行方式，底层在磁盘上的B树负责存储，上层的SQL Parser负责计算，我们系统也可以具有这样的逻辑，这样我们可以零成本的切换存储，而不该上层代码逻辑，达到更好的单元测试。

所以这里的方法论是：面向大数据系统设计。

在互联网系统中，数据的增长，业务的发展，用户的增加，是远远快于系统迭代的，只有我们将我们的单机系统代码设计的具有面向大数据高并发场景的时候，系统才具有可扩展，易扩展的能力，才能承载更多的数据压力，也变得更稳定。