尽量用简单方法处理复杂问题

在大学里,用复杂的逻辑去解决问题。会让老师觉得这个学生很聪明,很有能力。

而在公司这样做,只会得到各种鄙视。


下面说说采用复杂逻辑解决问题的弊处:

1.可控性差。

当你的算法复杂了,很多边界问题和异常情况是很难考虑周到的,最后你会被各种段错误、踩内存、异常结果搞的焦头烂额。


2单元测试难进行

复杂的逻辑对应的一定是高耦合的代码,函数间关联太大,流程间相互依赖强,很多函数无法跑单元测试或是很难跑单元测试。


3.可扩展性和可维护性差

你很难保证一年后是谁来维护或是升级你的代码。就算是你自己来维护,你也很难保证自己在看这复杂的逻辑,还能记得自己设计这段代码的时候是怎么想的。更何况是别人来维护。在别人被你这复杂的逻辑绕的晕头转向的时候,说不定会开始破口大骂甚至重新来实现这块功能。


4.测试同事会缠着你

因为测试为你的功能写测试用例的时候,往往会一遇到不懂的就来问你,常常会带个凳子做你旁边问上个把时辰,而且常常问的是一些重复的问题(即使你概设和详设写得再详细),而你则只能放下手上的活耐着性子和他一遍又一遍的讲解(自作孽呀!)。而且吃饭、休息时间,测试同事往往会某个地方想不通了,然后找到你,然后各种....

到了联调后期,测试会相当欢乐,因为在你的这个模块他可以获得很好的绩效(提出大量的BUG)。


总结:问题尽量简单化,并用自己熟悉的方式去解决,要让别人一眼就能看懂你表达的是什么。


血和泪的教训,谨此为戒

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
界定事务的简单复杂主要是根据以下几个方面: 1. 事务的隔离级别:不同的隔离级别会影响事务的复杂程度,例如在 READ UNCOMMITTED 隔离级别下,可能会出现脏读、不可重复读和幻读等问题,需要开发人员进行更加精细的事务管理。 2. 事务的传播行为:事务的传播行为会影响事务的范围和边界,例如在一个方法内部调用了另一个方法,如果两个方法的事务传播行为不同,可能会出现事务无法提交或回滚的问题。 3. 事务的异常处理:事务中可能会出现各种异常和错误,需要开发人员进行相应的异常处理,例如在事务中出现了空指针异常或数据库连接异常等问题,需要进行相应的回滚操作。 举个例子来说,比如一个简单的事务场景是在一个方法内部进行数据库的插入和更新操作,只有一个隔离级别和一个传播行为,异常处理也比较简单,只需要进行基本的回滚和日志记录即可。 而一个复杂的事务场景可能是在一个分布式系统中,多个服务之间进行协同处理,涉及到多个隔离级别和传播行为,需要进行跨库事务管理、异常处理、回滚补偿等复杂操作,需要开发人员具备较高的数据库知识和经验,保证数据的一致性和可靠性。 因此,界定事务的简单复杂并不是单纯的根据事务的大小和规模来衡量,而是需要结合具体的隔离级别、传播行为和异常处理等方面进行综合评估。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值