油腻代码大叔与蝴蝶效应

作者：开涛

好久没写博客了，好久没看书了，好久没拍到让自己欣喜的照片了，好久没……，突然间好害怕。手触动键盘时，其实脑子是一片空白的，呆呆的坐着并没什么想法，难道是因为好久没看书的原因吗？

前些天突然觉得自己是不是得了老年痴呆，脑子总忘事，遇到佳纯同学喊她姜楠，遇到周聪喊她“洋葱”。

自己已是油腻大叔年纪了，大肚腩、大脸和双下巴已经陪伴我多年。昨天晚上还疯狂的吃了一顿火锅，吃的时候幸福感是爆表，过后想想我应该很快就超越油腻大叔，变成肥肉大叔。这可能是小时候做过些坏事，上天对我的惩罚。

哎呀，写着写着馋虫上来了，叫个小龙虾外卖吃一吃，不过小龙虾吃起来好麻烦，没有吃火锅爽，可以大口大口涮毛肚吃。

我想像《蝴蝶效应》的伊万一样回到过去改变自己。不过像我这种从小学习不好的，再怎么改变也应该就这样了。能改变什么呢？

就像伊万为了弥补错误，返回过去试图消除痕迹，但总是事与愿违，并没有变好而是更糟糕。于是反反复复，他奔波于日益混乱的过去与现实之间，直到不可挽回的结局。伊万试图改变过去，希望能与他暗恋的凯蕾一起幸福生活的梦想，也成为了泡影。

既然这样，“过去的已然成为过去，不要把精力用在追忆并后悔人生转折点时作出的任何决定”。该吃吃该喝喝，做个没心没肺的人好像也挺好。

回归正题。

=======================

当我在设计开发一个系统时，一开始觉得自信满满，一切在控制当中。随着时间流逝，出现了各种各样的问题，项目交付时间一二三的被延期。心里想自己到底做错了什么，为什么呢？

当我在维护一个系统时，为什么总是不稳定，修复一个BUG又出现另一个，出问题后不断的重启系统，总是被业务方投诉，为什么它就不能老老实实的好好运行，让我省点心。我们到底做错了什么？

先来看看我们开发一个系统需要做些什么吧：

1. 首先产品会出PRD，大家一起评审，此时程序员需要去理解其中的逻辑：业务语言、流程、功能、异常；
2. 接着定义业务架构和系统架构，是分布式还是单体，业务和系统模块怎么划分，边界如何界定，业务上下游依赖和边界是什么；
3. 接着开始进行项目搭建，用Java还是Go，用Git还是SVN，是基于Maven构建还是Gradle；
4. 接着进行一些技术选型，用SpringCloud还是Dubbo，要不要用Guava，用Slf4j还是直接Log4j；存储选什么；用不用缓存；
5. 明确分工，构建各自的模块和系统，码代码；
6. 进行模块集成或系统集成；
7. 测试、交付上线。

这是比较理想的一个开发方式，实际过程要复杂很多。我们会遇到需求不明确，需求错误，细节考虑不周全，技术上不可行等等很多问题。

在开发过程中还有一些非功能性需求要考虑：

1. 提升工程开发效率；
2. 鲁棒性、可维护性、可扩展性；
3. 高并发、高可用、SLA；
4. 兼容性；
5. A/B测试；
6. 可回归测试；
7. DevOps；
8. 管理复杂度；

还有我们解决问题的方式：

1. 当我们在解决一个类似问题时，有些人是通过抽象来解决；有些人觉得反正代码逻辑超简单，复制代码来解决；
2. 有些不应该出生的代码出生了，维护一些乱七八糟的代码；
3. if/else嵌套超过三层；
4. 看框架源码又不能帮我提高写代码的速度，浪费我时间；
5. 反正我能看懂，不写注释和文档了；
6. 复杂的解决方案没有迭代优化；
7. 明天就上线，今天必须交付，然后就没然后了；
8. 重启来解决问题；
9. 不去学习解决问题的工具；
10. ……

可以看出开发一个系统从来不是一件简单的事情，除了完成业务逻辑，还要考虑很多非功能性需求，其中一个没有做好都会引起蝴蝶效应。用户/数据量大会导致大的风暴，而用户/数据量小可能就是下点小雨。

蝴蝶效应定义：

“蝴蝶效应是指在一个动力系统中，初始条件下微小的变化能带动整个系统的长期的巨大的连锁反应。”

我们看过的源代码、看过的书并不是没用的，每一个知识可能在未来的某一时刻被我用到，学习会使我的思路开放，而不是封闭。通过不断微小的学习，触发蝴蝶效应，得到巨大的收获。

不过我好像已经走上了另一条不归路，油腻代码大叔之路越走越踏实了！

不管怎么学习也都是一个坑一个坑的挖，一个坑一个坑的埋。一开始就设计的很完美的系统是没有的，系统是是不断迭代出来了。另外推荐接着读读《亿级流量》第一章 交易型系统设计的一些原则来看看一个高可用高并发系统需要填多少坑。