问题倒逼改革

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

相关文章

解决hive启动时java.net.ConnectException:拒绝连接的问题

《解决hive启动时java.net.ConnectException:拒绝连接的问题》Hadoop集群连接被拒,需检查集群是否启动、关闭防火墙/SELinux、确认安全模式退出,若问题仍存,查看日志... 目录错误发生原因解决方式1.关闭防火墙2.关闭selinux3.启动集群4.检查集群是否正常启动5.

idea Maven Springboot多模块项目打包时90%的问题及解决方案

《ideaMavenSpringboot多模块项目打包时90%的问题及解决方案》:本文主要介绍ideaMavenSpringboot多模块项目打包时90%的问题及解决方案,具有很好的参考价值,... 目录1. 前言2. 问题3. 解决办法4. jar 包冲突总结1. 前言之所以写这篇文章是因为在使用Mav

解决pandas无法读取csv文件数据的问题

《解决pandas无法读取csv文件数据的问题》本文讲述作者用Pandas读取CSV文件时因参数设置不当导致数据错位,通过调整delimiter和on_bad_lines参数最终解决问题,并强调正确参... 目录一、前言二、问题复现1. 问题2. 通过 on_bad_lines=‘warn’ 跳过异常数据3

解决RocketMQ的幂等性问题

《解决RocketMQ的幂等性问题》重复消费因调用链路长、消息发送超时或消费者故障导致,通过生产者消息查询、Redis缓存及消费者唯一主键可以确保幂等性,避免重复处理,本文主要介绍了解决RocketM... 目录造成重复消费的原因解决方法生产者端消费者端代码实现造成重复消费的原因当系统的调用链路比较长的时

深度解析Nginx日志分析与499状态码问题解决

《深度解析Nginx日志分析与499状态码问题解决》在Web服务器运维和性能优化过程中,Nginx日志是排查问题的重要依据,本文将围绕Nginx日志分析、499状态码的成因、排查方法及解决方案展开讨论... 目录前言1. Nginx日志基础1.1 Nginx日志存放位置1.2 Nginx日志格式2. 499

kkFileView启动报错:报错2003端口占用的问题及解决

《kkFileView启动报错:报错2003端口占用的问题及解决》kkFileView启动报错因office组件2003端口未关闭,解决:查杀占用端口的进程,终止Java进程,使用shutdown.s... 目录原因解决总结kkFileViewjavascript启动报错启动office组件失败,请检查of

SpringBoot 异常处理/自定义格式校验的问题实例详解

《SpringBoot异常处理/自定义格式校验的问题实例详解》文章探讨SpringBoot中自定义注解校验问题,区分参数级与类级约束触发的异常类型,建议通过@RestControllerAdvice... 目录1. 问题简要描述2. 异常触发1) 参数级别约束2) 类级别约束3. 异常处理1) 字段级别约束

Python错误AttributeError: 'NoneType' object has no attribute问题的彻底解决方法

《Python错误AttributeError:NoneTypeobjecthasnoattribute问题的彻底解决方法》在Python项目开发和调试过程中,经常会碰到这样一个异常信息... 目录问题背景与概述错误解读:AttributeError: 'NoneType' object has no at

Spring的RedisTemplate的json反序列泛型丢失问题解决

《Spring的RedisTemplate的json反序列泛型丢失问题解决》本文主要介绍了SpringRedisTemplate中使用JSON序列化时泛型信息丢失的问题及其提出三种解决方案,可以根据性... 目录背景解决方案方案一方案二方案三总结背景在使用RedisTemplate操作redis时我们针对

Kotlin Map映射转换问题小结

《KotlinMap映射转换问题小结》文章介绍了Kotlin集合转换的多种方法,包括map(一对一转换)、mapIndexed(带索引)、mapNotNull(过滤null)、mapKeys/map... 目录Kotlin 集合转换:map、mapIndexed、mapNotNull、mapKeys、map