让人又爱又恨的业务

让人又爱又恨的业务

序 经常刷到b站里面会有各种up教你怎么去解决业务中经常遇到的问题,你想的到的你想不到的都有,所以自己也会没事就思考,给自己营造各种问题场景,然后自问自答如何去解决,包括了如何架设服务、系统,优雅编码,产品设计,UI设计,生产部署问题,代码编写问题,合理设计优化问题等等。 最难的业务解决场景 - 面

经常刷到b站里面会有各种up教你怎么去解决业务中经常遇到的问题,你想的到的你想不到的都有,所以自己也会没事就思考,给自己营造各种问题场景,然后自问自答如何去解决,包括了如何架设服务、系统,优雅编码,产品设计,UI设计,生产部署问题,代码编写问题,合理设计优化问题等等。

最难的业务解决场景 - 面试

面试对于应届生来说好处是实际业务其实问的很少,也不会很深入,大多数还是喜欢提问八股和一些底层的问题,个人见解来说多问问网络和操作系统确实是一个挺好的选择,能够更深层次的看见应届生本身对于计算机的一个理解。

而对于大多数的职场人来说除过这些八股和基础,更多的就是业务上的拷打提问,无论是数据库设计,难题业务实亦或者其他的项目整体设计、迭代优化问题等。考虑的因素还有问题的复杂性会逐渐升高,这些问题的考量在平时自己工作过程中肯定是大家一起讨论然后出一套完善方案,然后逐步拆解执行,而面试你需要思考的地方就很多,最害怕面试官想听到的东西你并没有答上来,亦或者你的回答相较于其他面试者平平无奇,没有自己的思考只有死记烂背的八股回答,还有回答回答着感觉被面试官针对的心态炸裂等等。

环境决定解决方法

我为什么上面要提到面试,明明我想讲的是关于业务方面自己的一些思考,因为我觉得目前的面试很大程度上是一个完美化,非常自由能够任意发挥的一个场景有点背离了我们真正在面对业务时,对业务的深入思考。

你可能会说面试就是对自己之前业务处理结果的一个概括还有总结,这不就是基于实际的经验吗?

但面试恰恰遇到的问题就是,所有问题不可能跟你遇到过的完全一模一样,会有细微差别,场景也会不同,你还是基于之前的思考再加上自身的知识储备去做很多合理化的论证,还有对自己之前所犯错误的归纳总结,以展示你以后肯定不会再犯上一次同样的错误还有展示你会对这种问题有更高的解答方式和技巧。

OK,说了这么多,我真正想说的是,我们解决问题的过程中除了基础的知识储备,之前的经验可能会有一部分能被你运用到,但很多实际的经验可能你根本不会再碰到和运用到,而且最重要的一点且导致这个问题出现的原因是 你不可能理想化的去解决你所有遇到的问题

公司有公司的规定,技术选型有技术选型的限制,举一个简单的例子,你这次根据业务问题要异步的去处理一些数据,你需要用到MQ,可能这个时候公司没有那么多资源给你,因为你的业务处理体量不是很大;或者是公司压根就没有MQ这个技术栈。这个时候你可能就需要进行手搓一个简易的MQ,或者是其他直接使用java自身携带的并发类来处理业务,环境决定你的解决方法

所以你要问我真的有最优解吗?我想是应该没有的,不管是书上看见的,还是别人述说的,学到的就是里面的一些深层次的基础知识,这些深入的理解是你解决问题的过程中的利剑,你的业务场景、环境、排期以至于你自身的状态都会影响你哪怕遇到及其相似的问题都有可能会写出不同的答卷

最优解是什么

回到我思考的本质问题,最优解是什么,面试中、学习中、工作中遇到这些业务提问,最好的解决方式是什么。

我刚刚确实是说你很大程度上没办法套用之前的任何一次解决问题的方式来解决当下问题,能做的最好方式就是足够抽象化你的问题,将你的问题向上抽象,归纳他的特性;同时,把你所能够调用且拥有的技术框架,公司提供给你的资源还有自己曾经解决问题方式的具体表述同时向上抽象,在抽象层面梳理具体解决逻辑,制定流程的流转,最终有一个大概清晰的思路之后再足够具体化你抽象出来的东西,落实到你拥有的相应且合适的技术框架和解决办法中,这样也许不是一个很不错,很极致的方案。但很大程度上他能调用且充分利用你目前所拥有的一切资源。

结语

最后想讲讲我为什么会说这个问题,因为我在实际的工作中发现,方案无论再完善,还会存在大家为了排期只能暂且摈弃掉这些规则,甚至你经常可以看见用Map、List 接收处理参数,硬生生的把一个强语言写成一个弱语言,想着以后重新完善,但以后的以后也就是技术债的加深了。所以这些思考都是为了在以后的工作中,根据现有的所有环境情况去制定业务解决逻辑,至少能很大程度上避免一些问题。

最后我想说写代码跟保护地球一个道理,儿孙不是自有儿孙福,儿孙福靠的还是老一辈对环境的保护,人生还好走了就下辈子了,但写代码,很有可能就今天当完爷爷明天当孙子了。言尽于此好好吃饭

LICENSED UNDER CC BY-NC-SA 4.0
Comment