概要
今天通过一个项目问题解决过程来分享，两种不同的思维方式在解决项目问题时的碰撞,中间引起的带入问题,请忽略不计。
背景
先说说前提,本身的技术路子比较野,啥东西都能摸两把,基本的思路和习惯都是以结果优先,技术作为手段,但这并不代表我没有标准化的基准和要求,只不过这个次序和容忍度有不同的理解、而我作为程序猿中的代码收容所,杂货收割机 ,可能是绝大部分标榜 "技术控、理论控、优雅控" 最不屑的。
文档、PPT、事务性、管理性、运维、交付、架构、甚至是商务、咨询、售前支撑都有涉及,这两年又对工控、数采非标互联网进一步在学习,说这些不是为了标榜啥，只是想说明我对技术的态度，是只要感觉缺的就会去补充学,早先,从一直排斥文档，认为这项工作是 "不务正业",到后来慢慢发现实际是有点儿恐惧写文档,天天被批判，再到后来反感的PPT和"跟傻子讲技术",心态上变化，看到差距，尊重别人的成就,就会自然而然的追赶,直到无所畏惧。
前因
Java属于可能我最先了解和尝试的编程语言,但怎么说呢,在当时的环境里面,C++、C# 是我选择的结果，期间也涉及了其他乱七八糟的语言,也都是副业需要，涉及到就捡起来用,可能内心觉得Java比较 "简单",直到工作里面不得不顶着运维和维护，说实话，没啥太大障碍，真正接受生态,也就近两年,心态的变化，感觉看到了不一样的新大陆,当然主要是各位开拓者的不断努力,不断的思维碰撞和实践努力,而我本身也不能说是专职做这块,只是有些块别人解决有问题，思维碰撞一下,以下就说说关于问题解决的剖析。
过程
同事A属于入行就做Java，也有个8年多工作经验,技术能力，执行力都不错，就是这个行业通病,沟通有所欠缺,这个只是一个点的分享，只是从思维上去谈问题，（我本身是个大白菜）,还是规则引擎的点,之前有过分享，整体是由我设计的方案，之前有分享,聊聊规则引擎的调研及实现全过程，因工期等其他影响，我把人员能力问题也考虑在内,在正式应用交互过程中,关于Mqtt处理相应速度问题和数据重复入库的问题得以复现，同事A有不少的参与度，因为某些原因（我不得不负起主责,前后端整体调整）,这是问题的大背景
复现排查
- 尝试1：这个问题同事A经过问题复现,初步确认是多线程循环引起的问题,解决的办法很粗暴，判断如果循环超过1000次就终止线程,导致的结果就是性能损耗和任务丢失,(这种情况在采集上是可以容忍的,数据是不间断的),就此就准备收手。我认为这个种解决办法是最终没办法下的妥协处置，而且问题也没分析定位清楚,做进一步尝试,此处是应该要执着的地方,
- 尝试2：于是A经过一顿跟踪，用了各种线程跟测工具和理论检索,通过方法锁尝试去解决该问题,造成的第二种后果是结果正确了,但及时性达不到，根本发挥不了性能。进一步也发现了消息密集的情况下会产生问题,中间也进行过任务队列的分组处置，（此项尝试基本属于A的各种线程理论一顿分析，进行尝试，得不出来啥有效结果，各种理论分析）
- 尝试3： 我经过不停得添加代码,定位异常，定位到了异常代码块，属于递归循环调用侧发生得异常,之前线程循环调用得问题也基本定位到,是因为父子线程得优先级，加上规则本身深度遍历及结果等待造成得问题，也就是Future得get等待引发得,此时,要验证该问题，把规则内部得递归任务添加调整为同步,（只涉及到一句代码）,循环得问题得以解决，处理速度也跟得上,（线程放置到了外侧处理消息（消息接收本身也是多线程）），但又引起了新得问题，入库得数据发生重复和不正常了（如果问题回溯，其实很快能发现，当然有点儿马后炮了）
- 尝试4 ：此时，同事A又尝试想放弃，认为在入库侧判断是否重复插入即可,并把别人得关于多线程入库重复得解决常规办法得内容做了共享,我给得理由是："再往前尝试以下，感觉马上就能找到真相，正是学技术得好时候，不要此时妥协"，很显示A在口头上答应，行动上已经放弃了,我就消息重复产生得地方又进行了各种锁尝试,也基本定位到了产生消息重复的地方，加上方法锁，结果和执行均验证没啥问题。
- 补上最后一药： 最后的相同broker相同主题下多个规则执行问题，其实不是啥大问题，很容易就解决了，两种方案，但实在是实践浪费的太久，我尝试了复杂的理想办法，交付中的问题都得以解决。
回溯
其实这个问题在回溯过程来看，在尝试4的时候，应该马上就能反应过来去解决的，但实际可能是周期和脑子都有点儿混乱，还是分析了执行结果和操作才做了验证，实在是我已经不敢太过相信线程理论，还是实践出真知,所以，这个过程中，我对Java的语法半吊子，但并不妨碍我去参与分析解决问题，而同事A，虽然知道线程的理论和各种语法，各个线程分析结果,但依然妨碍了他去解决此项问题，之前有听过软件的思维最重要，经验有时候会成为负担，可能在你们看来，这个问题其实有充足的理论基础，一定很容易解决定位这个问题，但怎么说呢，记得上计算机理论的时候，老师说过一句，编程就是抽象化具体事务到编程语言的过程、
在其后的过程中，好像绝大多数都是把问题分解成实现，排查分析问题的过程，我理解就是把具体的事务反推到程序上，很可惜这个过程，被归集到个人的能力或者习惯上,毕竟，对过程负责，是常态，项目的面试过程也就是说清过程，至于是谁解决的问题，并没有那么重要，这造成了两种分化，掌握全貌的失去了动手能力，对结果负责，不对过程负责，掌握单一的，失去了对结果负责的能力，掌握着对过程负责，新的纷争和各种千奇百怪的妥协结果也就是值得接受的。
分析
当你在执着各种编码规范，各种优雅简洁之道的同时,是否也能思考一下，我们所专注的语法，面试理论，就具体问题而言，真就是理论精通了之后，不会成为 "赵括",指点江山，飞扬文字。
而这种分化性，我已遇到了不下3种典型，要不点了吹牛逼的和撕逼的技能点、要不就点了技术理论的技能点，要不就去点了文档管理技能点,当然，只是个现象，躺平是常态，没啥压力和责任，谁愿意变成受虐狂，但有没有可能，也有那么一丝，对这个职业和技术的热爱? 可能又会变成鸡汤和躺着说话不腰疼，至于外在因素、想法和处境的不同,咱姑且就图一乐，从容面对吧、总之是,事不临身，我不愁，事临身，愁也没用，那能不能，稍微有一些，哪怕只有一丝希望的掌控呢，要说起怨怼，我有一肚子，但总不可能变成情绪发泄机吧，对结果有预期，但不放弃努力的过程，也许这是我此刻能够坚持做的。
PS
在这里申明一下，同事A的各方面能力我很认可，此处也只是精力有限下的小分享（有个小背景是，我们基本上背着2.5个以上的事在解决此项问题）、所以请各位不要基于我个人的认知有指摘。
最后再补充扩散，附上，我20年的职业生涯看看国外老哥的分享，说不得，接受变化也是个思路呢。
发现身边事儿、聊点周奇遇，我是沈二，期待奇遇的互联网灵魂~、一起聊天吹水，探索新的可能~wx:breathingss，入圈吧！