问题倒逼改革

2023-11-06 10:11
文章标签 问题 改革 倒逼

本文主要是介绍问题倒逼改革,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

众多的改变总是靠着压死骆驼的最后一根稻草来推动完成的,所谓凤凰涅槃、浴火重生。

起因

上周去了一趟惠州(于是就偷懒少写了一篇文章),欣赏了一波惠州西湖,与大学三个室友小聚了一番,没有聊太多工作上的事情,旧友聚会嘛,不应该有太多工作上面的事情来掺和,我自己也尝试着去保持那最纯净的大学生之间的那种友谊关系。

中转广州的时候,广州人是真的多呀,不知道是只有周末这么多还是平时就是这么多,话说不知道怎么回事,我虽然早前的时候没有去过广州,但是对广州的印象却是不怎么好,不知道是城市宣传的原因还是什么!这波广州去了下,感觉确实跟自己固有的印象差不多,就这么扯,不好的印象来得莫名其妙,这让我想起东野的《恶意》,虽然我并没有恶意。

扯回正题,去惠州玩儿也是为了缓解下工作的压力,顺便拜会同学加散散心。自从忙过前一段时间之后,最近又渐渐有一种强烈的愧疚感,感觉自己每天的进步越来越少,前进的动力也有所不足,“温水煮青蛙”的感觉也在与日俱增,学习也不能使我快乐了。于是突然有了一种想法,难道不是很多事情都是在随着问题的不断曝现之下才逐渐向好,所谓:「问题倒逼改革」。

难得的主动改变

主动改变说到底是个成本问题,比如在一个地方已经安定下来了,虽然可能月工资就那么点儿,但是在这里,我有已经建立了朋友关系的诸多同事,有欣赏我的上司,有一个安定的住处。如果说要改变的话看起来好像也不应该是现在,或许是等家人不断催着你结婚,与此同时伴随着买房的压力,那时会发现目前的状况根本不足以支付预期的生活,于是就会渴望改变,希望能够投入精力去构建一个新的环境。

主动改变会有一个矛盾点,如果这次成了,那自然是没有问题,但是如果没成呢?那是不是还不如不变,有了这么一个风险深渊在凝望着我,我也不愿意主动去做这样的尝试。等到局面已经到了不得不改变的境地:不这样就要凉了。于是我的处境就会变成:如果我不改变,那肯定就完蛋,如果变了还有可能成功。那我肯定就没纠结了,只能干了。

比如产品想要换一个新的架构,它会有下面几个问题:

  • 新的架构需要投入巨大的人力去开发,需要人力成本、时间成本。
  • 新的架构刚刚完成的时候肯定不稳定,需要承受来自客户的质疑(请收起新架构搞出来就能稳如狗这种大胆的想法)。
  • 新的架构能否完成预期的设想?开发到一半发现成本与收益不匹配,刹不住车开沟里怎么办?就算是提前做了非常详细的预研与分析,这种风险还是存在的。
  • 新的架构带来的适应期,开发者需要适应、维护者也需要适应,有些情况下,终端客户、消费者也需要适应,说不定还会给架构设计者的家人带去关切的问候。

这么一看,光想想这么多问题就愁 skr 人,我还折腾个啥,原来的能用就行了,等到扛不住了再去搞新架构吧,兵来将挡、水来土掩,啥事儿没有就睡大觉。

另一个角度就是「懒癌爆发」。一个事情已经趋于稳定了,我是不太愿意再去重复折腾的,想想有那么多亟待解决的事情就觉得麻烦,为什么不保持现状呢,何必要自找麻烦。懒得花费时间去搬一个新的地方;懒得学习一个新的技术;懒得维护一段新的友谊等等。

事与愿违

古时候连发机枪刚刚被造出来的时候,精度还不如弓弩,易用性极差,没有人想要去用它,这也是新生事物出现之后第一个要面临的囧境,有很多时候都是如此。

WIN10 系统刚刚出来的时候,微软或强或软地推广过这个系统,为什么不顺着 WIN7、WIN8 的思路搞呢?偏偏要再搞出来一个妄想一统江湖的 WIN10,初期的推广也确实费了一番功夫,并且很多人觉得这玩意儿真不如前任好用,虽然他们最终都会说出「真香」这句话。

  • 重构一个代码或者系统的心理变化
    这个系统看起来太 Shit 了,我需要重构一番;浏览了一下代码,构思了几天,发现还行,要改的东西也不是非常多;开始动手了,今天先改一部分简单的;几天后,这个看起来好像不是想象中的那么简单哦,他看起来好像是个砖头,但它实际上是一部诺基亚啊;好了,费了好大的力气,终于重构完了,开始运行,发现某个功能不正常,改之,发现另一个功能也不太正常,改之;终于改完了,功能也差不多了,重新审视了下自己的“杰作”,但是,它怎么感觉跟逝去的“前任”那么像呢!结论,白改了,改半天又改回去了。

改革是需要面临很大风险的,奥卡姆告诫我们:「如无必要,勿增实体」。也可以说:如无必要,别瞎JB搞了。往往是,改革之后你还真的没法准确判断他是不是比以前好用,一夜重回大清也不是不可能。尤其是一个大的系统架构更是如此,改着改着会发现露出地面的一颗小树苗实际上根须遍布整个大陆。

重新看待一些事物

知道了「问题倒逼改革」这一点,会发现有很多事情原来不是很能理解的,现在好像看起来是有其合理性啊。

  1. 公司里面总会有一些老旧的技术存在。不是公司垃圾,而是这玩意儿就没有更新的动力,换句话说,它还没有到问题多到解决不了的地步。
  2. 操作系统总会有那么一些 bug、不好用的地方,消费者怨声载道,然后才有持续不断的改进。
  3. 往大了说,社会层面的,我们会经常抱怨某些不公正的现象、流程,不是因为人为故意导致的这些问题,而是这些问题本来就存在,但是需要在大家不断的抱怨声中才能促进改革。想想手机操作系统的 bug 都解不完,更别说放在国家层面的 bug 了,那只会更加复杂,更加难以根绝,只能与时俱进。
  4. 失去了才觉得珍惜,未尝不是问题倒逼改革的一种,“失去”便是一个「问题」,一个难以忍受的「问题」,于是才促进“珍惜”的产生,这就是「改革」了。

老大也说过:“改革是由问题的倒逼而产生”。从这个角度去看待一些问题就能够找到一些解决办法,比如如何促进去重建一个新的秩序,那就是让旧的秩序不断暴露出问题,可以人为加速问题的暴露,等到原有的秩序已经完全无法解决这些问题的时候,便是新秩序产生的起点。

从个人的角度来讲,如何促进自己的不断进步、不断升级、不断改革呢?也可以从「问题倒逼改革」来入手。我经常会陷入局部困境,就是我很容易陷入一种让自己的生活处于不好不坏的状态,一旦有坏的趋势,就立刻改善,一旦有好的趋势,就触发我的惰性,进而不去继续改进。

我也会经常性的选择忽视自己的问题,比如技术,我是不太愿意去真真正正地找一个机会全面检视一遍;比如体检,除非公司组织,自己也懒得去定期做一个全面的检查,虽然明知它们肯定或多或少会有一些问题,但是毕竟问题还没有到不可控制的地步,于是就选择性忽视。

把自己放在聚光灯下,比如检视技术,就可以做一个主题分享,邀请别的部门的人过来旁听(欢迎来怼),这时就会发现自己原来还有那么多地方没有涉猎。定期做一些其它公司的面试,不管是真的想换工作还是仅仅检阅自己的水平,都可以以一年为周期或者更短时间来积极参与一些更高规格公司的面试,被面试官怼过才能发现自己的不足。

End

倘若有人在没有问题或者问题还可以稳住的情况下依然选择去不断改革,那就是探索了。比如太空探索计划、哥伦布发现新大陆、第一个轮子的制作。由于人本身的原因,就显得这些探索显得十分难能可贵。工作当中也是如此,「瞎折腾」就是十分珍贵的东西,它意味着没有明确的回报,意味着巨大的时间、人力成本(很多公司的现实条件是不允许的),但是有瞎折腾也会产生更屌的新生事物。

不过对于很多公司来讲,仅解决自己生存的问题就很困难了,更别说去探索了,好像这些事情 Google 来做才是正常的,他们才有充足的人力、物力、时间来做一些看似毫无卵用的探索型项目上。说到这里,我还是很想提一嘴小米,从一代目开始,小米就一直在做探索,在 mix 时为我等广大吃瓜群众所熟知,虽然他们并不缺钱,于是这种探索精神就更加是十分让我佩服的一面。然后我相信一定有一部分小米的原因,倒逼了 OV 也开始做出一些改变,OV 从头到尾就没缺过钱,但是之前给人的感觉一直是根本就没想把一个产品做好,反正能收割智商税就可以了(虽然现在大差不差),但是总归是作出了一些改变,有了这些改变,手机市场才会不断前进,做出更加感动人心的作品。

至于我,想来应该是需要时不时把自己拿出来“羞辱”一番,而后就能发现问题,并持续不断地改进。光靠我自己的自觉性,我有十足的把握,我无法做到面面俱到,持续进步。当我真的想优化自己的时候,不要听别人怎么夸我的,而要听别人是怎么怼我的。


想做的事情就去做吧

这篇关于问题倒逼改革的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/355988

相关文章

MySQL主从同步延迟问题的全面解决方案

《MySQL主从同步延迟问题的全面解决方案》MySQL主从同步延迟是分布式数据库系统中的常见问题,会导致从库读取到过期数据,影响业务一致性,下面我将深入分析延迟原因并提供多层次的解决方案,需要的朋友可... 目录一、同步延迟原因深度分析1.1 主从复制原理回顾1.2 延迟产生的关键环节二、实时监控与诊断方案

SQLyog中DELIMITER执行存储过程时出现前置缩进问题的解决方法

《SQLyog中DELIMITER执行存储过程时出现前置缩进问题的解决方法》在SQLyog中执行存储过程时出现的前置缩进问题,实际上反映了SQLyog对SQL语句解析的一个特殊行为,本文给大家介绍了详... 目录问题根源正确写法示例永久解决方案为什么命令行不受影响?最佳实践建议问题根源SQLyog的语句分

解决IDEA报错:编码GBK的不可映射字符问题

《解决IDEA报错:编码GBK的不可映射字符问题》:本文主要介绍解决IDEA报错:编码GBK的不可映射字符问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录IDEA报错:编码GBK的不可映射字符终端软件问题描述原因分析解决方案方法1:将命令改为方法2:右下jav

MyBatis模糊查询报错:ParserException: not supported.pos 问题解决

《MyBatis模糊查询报错:ParserException:notsupported.pos问题解决》本文主要介绍了MyBatis模糊查询报错:ParserException:notsuppo... 目录问题描述问题根源错误SQL解析逻辑深层原因分析三种解决方案方案一:使用CONCAT函数(推荐)方案二:

Redis 热 key 和大 key 问题小结

《Redis热key和大key问题小结》:本文主要介绍Redis热key和大key问题小结,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录一、什么是 Redis 热 key?热 key(Hot Key)定义: 热 key 常见表现:热 key 的风险:二、

IntelliJ IDEA 中配置 Spring MVC 环境的详细步骤及问题解决

《IntelliJIDEA中配置SpringMVC环境的详细步骤及问题解决》:本文主要介绍IntelliJIDEA中配置SpringMVC环境的详细步骤及问题解决,本文分步骤结合实例给大... 目录步骤 1:创建 Maven Web 项目步骤 2:添加 Spring MVC 依赖1、保存后执行2、将新的依赖

Spring 中的循环引用问题解决方法

《Spring中的循环引用问题解决方法》:本文主要介绍Spring中的循环引用问题解决方法,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录什么是循环引用?循环依赖三级缓存解决循环依赖二级缓存三级缓存本章来聊聊Spring 中的循环引用问题该如何解决。这里聊

Spring Boot中JSON数值溢出问题从报错到优雅解决办法

《SpringBoot中JSON数值溢出问题从报错到优雅解决办法》:本文主要介绍SpringBoot中JSON数值溢出问题从报错到优雅的解决办法,通过修改字段类型为Long、添加全局异常处理和... 目录一、问题背景:为什么我的接口突然报错了?二、为什么会发生这个错误?1. Java 数据类型的“容量”限制

关于MongoDB图片URL存储异常问题以及解决

《关于MongoDB图片URL存储异常问题以及解决》:本文主要介绍关于MongoDB图片URL存储异常问题以及解决方案,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐... 目录MongoDB图片URL存储异常问题项目场景问题描述原因分析解决方案预防措施js总结MongoDB图

SpringBoot项目中报错The field screenShot exceeds its maximum permitted size of 1048576 bytes.的问题及解决

《SpringBoot项目中报错ThefieldscreenShotexceedsitsmaximumpermittedsizeof1048576bytes.的问题及解决》这篇文章... 目录项目场景问题描述原因分析解决方案总结项目场景javascript提示:项目相关背景:项目场景:基于Spring