# 背景
小猫维护现有的系统也有一段时间了,踩坑也不少,事故不少。感兴趣的小伙伴可以了解一下,往期的小猫踩坑记合集
这天,小猫找到了商城系统的第一任开发老A开始聊天。
“你们这系统是真坑,我都吃过好多次亏了,太烂了...”小猫开玩笑地吐槽道。
“我们当时其实还是花了很长的一段时间去做设计以及评审的,每一步都是有严格把控的,当时系统总体骨架还是相当清晰的,也没有那么多新的概念,你说现在系统不行了,可不能怪我们啊。一会我给你原始设计文档看看。后面经过了很多研发的手了,甚至运营和产品都换了好几拨了,每任运营可能对当前系统的要求都不一样吧,大家理解可能都不同......”老A侃侃而言着。
小猫抿了口刚倒的茶,意味深长地看着老A...
# 故事
春天,办公室外的世界总是让人神往的,小猫带着耳机,托着腮帮,望着外面美好的春光神游着...
一声不和谐的座机电话声打破这份本该属于小猫的宁静,“hi,小猫,线上有个客户想购买A产品规格的商品,投诉说下单总是失败,帮忙看一下啥原因。”客服部小姐姐甜美的声音从电话那头传来。“哦哦,好,我看一下,把商品编号发一下吧......”
由于前一段时间的系统熟悉,小猫对现在的数据表模型已经了然于胸,当下就直接定位到了商品规格信息表,发现数据库中客户想购买的规格已经被下架了,但是前端的缓存好像并没有被刷新。
小猫在系统中找到了之前开发人员留的后门接口,直接curl语句重新刷新了一下接口,缓存问题搞定了。
关于商品缓存和数据库不一致的情况,其实小猫一周会遇到好几个这样的客诉,他深受DB以及缓存不一致的苦,于是他下定决心想要从根本上解决问题,而不是curl调用后门接口......
地铁上刷到一个话题,觉得挺有意思的,如下。
看到很多朋友在下面吐槽,有说加班是真的多,有说找对象是真的难,有说程序员爱穿格子衫是假爱背电脑是真的等等,大家吐槽得都挺欢乐的。老猫也开始复盘这些年的经历,更多想聊的可能还是一个后端程序员的真实感悟。
分享是最有效的学习方式。
博客:https://blog.ktdaddy.com/
# 故事
新年新气象,小猫也是踏上了新年新征程,自从小猫按照老猫给的建议【系统梳理大法
类似于开放平台的老六接到客户的需求,需要在查询订单新增一个下单时间的返回值,然后这就需要提供底层服务的小猫在接口层给出这个字段,然后老六通过包装之后给客户。由于需求比较简单,所以加完字段之后,老六和小猫也就直接上线了。
上线之后事儿来了,对面客户研发一直询问为什么还是没有下单时间,总是空的。老六于是直接找到了小猫,可是小猫经过了一些列的自测发现返回值都是有的,后来排查到在老六封装之后值不见了。经过仔细排查,终于找到了问题,虽然没有造成太大的影响,但是总归给客户研发的心里留下了一个不好的印象。
虽然下单时间老六和小猫定义的都是orderTime这样一个字段,但是字段类型小猫用的是Date类型而老六用的是LocalDate,恰巧老六在进行对象赋值的时候偷了个懒直接用了spring的BeanUtils.copyProperties工具类,于是导致日期类型的值并没有被赋值过去,踩坑了。
老六这才回想起前段时间架构师在群里@ALL的一段话,“大家用BeanUtils拷贝对象的时候注意点,有坑啊,大家尽量用get,set方法啊”。当时的老六不以为意,想着,“切,这得多麻烦,一个个set不花时间啊,有工具类不用”。现在想来看来是真踩到BeanUtils的坑了。
老六一边改着代码一边叨叨:“这也没说坑在哪里啊......”
# 从最近一个经历说起
周五了,轻松点儿,今天破例不写纯技术类的干货文了,聊聊最近一个比较郁闷的经历,这事儿发生在老猫自己身上,不是“总是遇到事故深陷于系统重构泥潭的倒霉小猫”,也不是苦苦面试找工作的“张小帅”(如果想要知道小猫和张小帅的故事,欢迎订阅专栏)。
春节假期即将结束,去了趟老丈人家拜了年,准备坐高铁回来的路上悲剧斜跨背包丢了,现金、银行卡、驾照、身份证、最爱的文玩串串、耳机等等都没了。细节就不多聊了,越想越心痛。证件现金等等都可以不论,尤其是盘了多年的文玩串串,之前一天刚在朋友圈嘚瑟,结果第二天就给丢了,真的是后悔懊恼万分。
当意识到事情发生之后,大脑一片空白,口干舌燥,着急万分,因为距离高铁发车还有40分钟的时间,在这个时间段内要找到,简直就是痴人说梦。于是草率下定决心,要是监控调不出来就不走了,一定要找到,当时冲动之后也就只有这一个想法......后来媳妇的一句话让我冷静了下来,“事情都发生了,着急有什么用,最多损失一个包,人都还在慌什么?”。是啊,遇到突发状况究竟在慌什么呢?做好最坏的打算去争取解决问题就行了。于是就有了下面这样的流程。
分享是最有效的学习方式。
博客:https://blog.ktdaddy.com/
老猫的设计模式专栏已经偷偷发车了。不甘愿做crud boy?看了好几遍的设计模式还记不住?那就不要刻意记了,跟上老猫的步伐,在一个个有趣的职场故事中领悟设计模式的精髓。还等什么?赶紧上车吧
如果把系统软件比喻成江湖的话,那么设计原则绝对是OO程序员的武功心法,而设计模式绝对是招式。光知道心法是没有用的,还是得配合招式。只有心法招式合二为一,遇到强敌(“坑爹系统”)才能见招拆招,百战百胜。# 故事
之前让小猫梳理的业务流程以及代码流程基本已经梳理完毕【系统梳理大法
在小猫接手的系统中,线程池的创建基本是想在哪个类用多线程就在那个类中直接创建。所以基本上很多service服务类中都有创建线程池的影子。那么他又该如何应对呢?
# 写在前面
遇到上述小猫的这种情况,我们的思路是采用单例模式进行提取公共线程池执行器,然后根据不同的业务类型使用工厂模式进行分类管理。
接下来,我们就单例模式开始吧。
# 故事
这段时间以来,小猫按照之前的系统梳理方案【系统梳理大法
系统中涉及的业务以及模型也基本了然于胸,但是这代码写的真的是...
小猫也终于知道了为什么每天都有客诉,为什么每天都要去调用curl语句去订正生产的数据,为什么每天都在Hotfix...
整理了一下,大概出于这些原因,业务流程复杂暂且不议,光从技术角度来看,整个代码体系臃肿不堪,出问题之后定位困难,后面接手的几任开发为了解决问题都是“曲线救国”,不从正面去解决问题,为了解决一时的客诉问题而去解决问题,于是定义了各种新的修复流程去解决问题,这么一来,软件系统“无序”总量一直在增加,整个系统体系其实在初版之后就已经在“腐烂”了,如此?且抛开运维稳定性不谈,就系统本身稳定性而言,能好?
整个系统,除了堆业务还是堆业务,但凡有点软件设计原则,系统也不会写成这样了。
# 故事
地铁上,小帅无力地倚靠着杆子,脑子里尽是刚才面试官的夺命连环问,“用过TheadLocal么?ThreadLocal是如何解决共享变量访问的安全性的呢?你觉得啥场景下会用到TheadLocal? 我们在日常用ThreadLocal的时候需要注意什么?ThreadLocal在高并发场景下会造成内存泄漏吗?为什么?如何避免?......”
这些问题,如同阴影一般,在小帅的脑海里挥之不去。
是的,他万万没想到,自诩“多线程小能手”的他栽在了ThreadLocal上。
这是小帅苦投了半个月简历之后才拿到的面试机会,然而又丧失了。当下行情实在是卷到了极点。
都两个月了,面试机会少,居然还每次都被问翻,这样下去真要回老家另谋出路了,小帅内心五味成杂......
小伙伴们,试问一下,如果是你,面对上述的问题,你能否对答如流呢?
上一页
下一页
公众号
关注公众号,和老猫一起交流