SamDeepThinking

概述 之前给公司的供应链同事开发了一个通过管理后台下单的功能，他们会把订单数据放到excel里，然后导入到管理后台，就能给门店下单了。 但是当时上线时，没有做校验excel里是否有重复记录的功能，导致

概述 做过餐饮行业的，应该知道如下的业务场景: 比如说，门店想跟供应商订橙子这种物料，供应商会要求说，至少订货20斤，最大不能超过100斤。供应商这个要求是正常的，订的太少，供应商觉得吃亏了，订的太多

如果你从事过类似B端进销存系统相关的开发工作，一定会遇到一个需求： 比如说门店每日的订货单： DH202407010001 DH202407010002 DH202407010003 DH202

概述 我正在参加「掘金·启航计划」 在2023年4月27日的中午，运维在值班群里发了一张截图，大意是说，数据库的负载突然变高了，因为这个时间刚好是饭点，大部分后端开发人员都在外面吃饭，我就让其中一个在

概述 最近一直在为系统的稳定性努力着，但凡线上有一些问题，都不轻易放过。尤其是在2023年，大环境不好的情况下，如果it团队系统稳定性都做的不好的话，很容易提桶走人的。 事情是这样的，在2023年3月

概述 在2023年3月11下午差不多六点左右，我正在工位上喝着香味扑鼻的金骏眉红茶，突然接到了一个电话，拿起手机一看，是阿里云告警电话，马上接通，听到的是下面这么一句话： 噗，已流入喉咙的红茶差点喷出

概述 在3月2日晚上，大概8点左右，本想打道回府，回家休息，突然被人在bug群@了一下，说是管理后台，访问不了，界面上出现了: 我赶紧尝试访问了一下，确实如此，但不是每次都不行，而是偶发503的错误提

出现问题的环节越靠后，代价就会越大，且是各个环节的角色，都要花时间去处理，会极大的降低项目的交付速度和质量。 之前常听人说，不要去打扰正在写代码的工程师，会有上下文切换的代价，有道理，但是有另外一个角

我心目中靠谱的产品经理长这个样子： 有产品规划 也即是你得有至少一个月或者三个月的产品规划，不能老是提一些零散的需求，这样会导致一旦有重要的大需求的时候，开发和测试人员都没有资源了，因为全部被零散的需