国庆就 4 号开了 30 公里的高速，没发现什么状况

前段时间重构了一部分代码。重构的目的是将一些重复的类、重复的逻辑抽取出来打成一个包给各个项目使用，以便维护这些公共的功能的时候，东改改西改改，万一哪里没改到出 bug 。

当然，这个目的很容易达成。但是，重构完发现这个复杂度并没有和预想中那样有所下降，反而还提升了不少。这究竟算重构成功了呢，还是算重构失败了？实在是有些难评。。。不过，这个副作用倒是收获了“防御式编码”的效果。毕竟，这代码被我搞得更难理解了！

显而易见的风险好规避，看不见的风险很多人当不存在。。。这样就容易出事

所以，要规避那些看不见的风险，就要看远一点，多用点脑子。

当然是自己搞一个可复用的框架啊

不知道方向说明没用，没用的东西学它作甚？？？

吾生也有涯，而知也无涯。以有涯随无涯，殆已！--庄子《逍遥游》

并不是，如果你没成功，那你天然不拥有解释权。如果你成功了，你又不需要什么解释权了，自然会有一群人为你辩经。

@wheat0r 确实，如果你不把用户当傻逼，那你会发现自己就是 tmd 傻逼

@ota 是的，这就是隐形的经营成本。大头主要是经营场所的租金、市场推广费用、人员薪资、各种税费……

看上去确实利润超高，但你进入这一行的话，发现赚不到钱。因为各种原因，导致经营成本非常高。你会发现这个行业只有头部几家能赚钱，但行业头部那几家也没发大财。这就奇怪了哈……
其实没啥好奇怪的，头部几家规模大是靠大工程撑起来的。大工程毛利率其实很低，而且经常拖欠工程款，坏账率也很高。搞到最后，就是没人能赚钱。

代码从不解决未来的问题

这个尺寸的结石真的是能自己排出来的吗？

大型系统或者复杂系统其实也没什么神秘的，一般都是臭不可闻的屎山。

要想设计好大型系统，就必须要做好这几点：
1 、抽象。要尽可能的将普适的、共性的功能抽取出来进行能力化。红极一时的中台就是具体的体现了。中台为啥最后变成人人喊打的落水狗，倒不是中台做错了，而是中台做多了。做了自己不该做的功能，结果就变成两面不讨好，人人厌弃了。
2 、分治。一定要将业务梳理清楚，不能多个业务纠缠在一起。微服务就是这个需求的最佳实践。但微服务有比较高的门槛，大多数程序员不懂业务不懂自动化运维玩不转。

所以，要想学习大型系统的设计，不但要有洞见本质的能力，还要精通业务，还需要对自动化运维有一定的了解。

我写的服务，接口响应速度一般都在 10ms 以下。1 秒的响应速度是不可能被接受的

我们的做法是倒挂一把雨伞

年龄肯定要算的，不管你存的是什么，反正都有办法算的。譬如你直接存注册时填写的年龄，那按楼上 V 友的算法就可以得到“理论上正确”的年龄了。

我 3 缸 06 开了 4 年多了，也没见出啥毛病。领克的质量还是在线的，可以放心买。

@Ketteiron “一个请求在微服务里弹十几次”。你这个是设计问题，你是怎么就敢把锅扣在模式的头上的？？？

你该不该上微服务，不取决于你的业务有多复杂，也不取决于你的团队规模。它只取决于你有没有具备玩转微服务的能力，能不能搞好微服务。

你能玩得转微服务，那即使只有一个人，也能上微服务。没这个能力，哪怕是万人团队，也不要去碰微服务，硬上只能给你带来无尽的麻烦，而且规模越大麻烦就越多。