就这？我看了一下我们数据库里面几千行的 sql 在那笑而不语。。还有 20 多 M 的存储过程。。
代码里面随便拿出几百行的 sql 跟玩一样。。一开始还觉得新奇，现在基本麻木了

嗯。你看到二成首付就心动了。你别忘了。你的月供就多了 10%。按现在这个经济状况，后面真不好说。万一后面经济继续吃紧，工资下降或者大量的通胀来了，月供都成问题还想上车？

不折腾，吾宁死！

难道技术宅就不能折腾了？除了写代码以外就没自己的爱好了？这中批判的价值是什么？你不喜欢，你可以不去看。但不要来批判他存在的理由。人家都叫少数派了也没叫多数派吧？

现在软件说明书都写的跟天书一样，有些人就是喜欢折腾这些东西。有需要就拿走，不需要也没强迫你去买去用吧？

小红书除了广告类，我也没觉得什么不好。生活不是只有苟且也不是只是在歌词中，没有娱乐的生活是暗淡的。没有喜好的人生也是无趣的。

难怪人人都说现在程序员才是优质股，工作多，在家少，不花钱，不娱乐，走的早，回得晚，最最关键的还赚得多。完美接盘人设

你得说你有什么设备啊。。。
是主机还是 pc 还是 switch 。。。

需要这么复杂？你老家是在山里面？ 4g 只有 1M 左右？我老家 4 线城市的 4G 都有差不多 5G 的效果。。

先起来小平同志不错。问他去了。跟着去。

最理想的情况下：是的，所有外部都 mock 。
次理想情况下：把外部调用隔离开。就拿你说的计算折扣的方法。你不应该依赖外部的输入，而是你自己造数据传递给待测方法，观察输入和输出是不是符合期望
现实：谁愿意写谁写，996 时间不够

当然。。主动矛盾点是这种领导没什么跟的必要。
多做多错少做少错不做不错，只要做了必然出锅。出锅就要底下人背？这个领导也当的太舒服了。
当技术领导，窃以为，最大的责任是，背下所有手下人的锅。我背的最大的锅是手下刚进来把线上数据库给误删了。我当时高兴得不得了，要不是这次误操作，谁知道我们流程上有问题，谁知道我们没有线上操作要谨慎谨慎再谨慎的意识，不仅把锅拿过来自己背上，还请大家吃饭

但我说实话，你要是总想着线上出事故，测试都测过了，关我屁事。。那确实可以提桶跑路

这是两个问题
1.复杂关联查询，一般是八股文了关系型设计模式的。说明表依赖过多。优化表结构，制作一个宽表。抹平各种关系表。换句话说，可能这条查询并不适合关系型数据库，并不是一个 OLTP 的场景，应该转化成一个 OLAP 的业务场景。最简单的办法就是复杂关联查询建立一个视图，如果数据库支持固化视图就很好。如果不支持，定时倒到另一个 OLAP 的系统里面非常好处理。
2.全文检索如果懒得扔 es ，es 确实重。但确实是最简单的一个解决方案，在复杂可控就是自己写全文检索引擎。。lucene 的接口已经很干净了，自己做有工作量，但不是做不了。

另外，业务型接口，秒级是很慢很慢很慢了。。基本要求 100ms 甚至 30ms 一个接口完成功能请求

既然有亲友送补给。。
改一下地址邮递到亲友那，想想是不是有这种可能？

@binbinyouliiii 说到正题。。现在的 jave 开发不如说是 spring 开发。。。这是一个很矛盾的事。我倒觉得无所谓，业务要用什么就用什么。反正自己每有决定用什么语言的权利

我其实个人更倾向于 rust 要比 golang 更适合 web 开发。工程性要比 golang 强。1 年前写的 rust 。现在再去看是看得懂的。golang ？ what the fuck ，这个逻辑是干啥，那个逻辑头和尾在哪。。。

@binbinyouliiii 没错。是解决了转换的问题。但在代码的语意上发生了太多变化。其实这个设计本身倒没什么问题。我理解这样设计的原因是 rust 要求在于，请设计好自己的 Error 层次。其实看一些优秀开源代码，是都是自己设计好 Error 。。。

rust 的?的设计在层次深了之后也蛮讨厌。。。每格错误类都要做类型转换

除了你是老板。。那是够了。
农民工，只配用锄头。

现在不是性能问题。。你要是能在手机上装 win 。还没这么大的性能和电量损耗。就 ok 了

大部分(包括我自己)所谓重构就是堆新的屎山，这没什么稀奇的。但是自己拉的屎自己闻着香。

提醒一句。。对硬盘做操作。无论如何，再找一个硬盘过来。先把这个硬盘的数据备份过去。。有备无患

@HuPu 才工作一年不理解正常。再过 4-5 年回来再看