序言

    闷热,无风。。。


不醉不会田馥甄 - 浙江卫视春季盛典


    一天又要过去了,我又在床上思考了一天的人生。。。我。。。这是在养生。。。


    没有风怎么办?要浪。。。就现在。。。

驱动力

     快速迭代的时代,碰到的问题一次一次的出现,每次都在思考如何应对,每次出现的时候又在不断的演进。。。


    关注点发生变化,原来关注的都是技术层面,现在好像有微妙的发展,技术不再是主要的驱动力,而业务变成了主要的驱动因素,各种业务,人员的变化,促使技术的优先级慢慢的降低。。。


    驱动力分为两种,一种是自驱动,一种是业务驱动


    所谓的自驱动,就是根据自己的感觉,选择牛逼的技术,牛逼的方式,感觉比较酷的技术。。。例如docker很叼,玩一玩,例如k8s解决了那么多的问题,了解一下,然后一头扎进各种细节,例如docker的使用,镜像仓库的搭建,网络的构建,集群的使用方式,docker的各种操作命令,最后。。。死在技术的海洋中


    自驱动,有好处也有坏处,好处在于不论你在哪,不论你在哪家公司,不论你做的是什么工作,都可以不断的了解你想了解的技术,坏处在于了解之后就不知道干什么了,了解到什么样的程度才算是可以?度。。。量变引起质变,例如去玩玩docker,了解到什么程度才算一个头,能搭建集群,能追查数据流,熟悉整体的架构,还是要看docker的源码?顺便学学go语言。。。入门还是很简单的。。。


    自驱动,坏处在于走的太快,容易迷路,走着走着下一步就不知道干什么,当没有合适业务使用的时候,就会发现这个技术,用不上啊用不上啊。。。迷茫的感觉了解一下。。


    自驱动,坏处在于,不撞南墙誓不回,但是很多时候,撞了南墙也不会回。。。因为有的时候,就是不信,南墙都撞不破。。。我不信!!!


    自驱动可以认为自身推动技术的发展,无论你是看中间件,还是各种缓存,还是看各种高性能的架构,还是可扩展,可靠性啥的,都是以自己为中心去推动发展,而业务推动则不同,是业务在不同的发展变化,逼着你去用更好的技术,更好的架构,更好的方法去解决这些问题。。。


    业务高速发展,用户并发增多,数据库响应很慢,怎么办?推动你必须去了解一下缓存,了解一下memcache,了解一下redis,使用缓存?如何解决缓存穿透的问题,如何解决缓存的命中率问题,如何解决缓存雪崩效应。。。


    业务高速发展,用户并发增多,各种系统之间的调用经常出现各种小问题,网络超时啦,网络抖动了,追查问题的时候,各个团队都要上了,怎么办?消息系统,异步执行,发送订阅消息,系统之间解耦。。。那么就需要在各种消息系统中选择,我是使用kafka还是使用rocketmq。。。选择恐惧症了解一下。。。


    业务驱动,这种方式最好的地方就是有一个具体的场景,你可以根据这个场景选择合适的方案。。。场景,最重要,合适的业务,合适的技术,合适的工具,用最简单的方式来解决问题。。。    

        

    或许没有那么好的业务场景,或许没有太合适的业务来尝试一些新的技术,例如应用系统的解耦合,你还要弄俩强依赖的系统来玩玩。。。例如你要使用rocket MQ,你用python写一下消息队列,你会发现。。。他没有python的SDK。。


    在自驱动的时候,每次做之前或者做之后,都要想想,这种技术适合于什么样的场景。。。在很多时候,我们都喜欢上来就安装一个玩玩,先跑起来。。。偶尔可以尝试一下,先了解一下基本功能,然后再根据功能去尝试一下。。。例如使用redis的时候,可以先看看redis支持的数据结构,可以存储各种结构化的数据,适用的场景是用来做缓存,对于那种实时性要求不高的进行缓存,然后使用命令行写入几个试试,然后使用python写一个客户端玩玩。。。有目的性的尝试一些新的技术总是好的。。


    如果一项技术,在你看来只是比较潮流,而在你以后的职业生涯中,根本用不上,那么这个技术可能在你身上,一无是处。。。完全没有价值。。。


    价值,你和我谈价值,我值多少。。。

价值

     问题总是在快速迭代,你可以从每个人嘴中看到对于相同的事情的看法,有的人觉得很棒,有的觉得是个渣渣,有的人觉得开心就好。。。


    有的时候,会有价值,有的时候,完全没有价值。。。


    用的上的东西,就有价值,用不上的东西,就没有价值。。。。


    如果我不和你吹牛逼,你知道我有多少价值???你设定了一个特殊的场景,那么在场景中有多少价值???是否可以换一个场景,可能能发现更多潜在的价值。。。


    那么问题来了,本来这个职位是有固定责任的,突然发现还有其他更大的价值,怎么玩???


    那么问题来了,招聘的时候是按照技术点来选人,还是按照解决问题的能力来选人呢?低级的都会按照技术点来选人,因为只想要一个能解决目前问题的人,而没有想着以后会要一个什么样的人。。。对这个人是怎么设计的,是需要高可用?高可靠?还是高性能,随着业务的发展。。。对这个人有什么期望?是否存在达成这种期望的特质???


    体现价值。。。用什么来体现,结果。。。结果是衡量价值的唯一标准!!!能解决复杂问题的能力就能反映出你的能力有多强。。。


    期望形态是一个缓存,你最后弄成了一个数据库。。。怎么玩

    期望形态是支持百万并发,你非要用一个nginx。。。怎么选

    期望形态是分布式存储,你非要用个单点。。。怎么用


    要达到期望状态,除了技术方面的努力,还有业务方面的共同促进,有的时候,技术只能解决百分之二十的问题,而。。。业务可能解决百分之八十的问题。


    没等到风来。。。何解。。。


©著作权归作者所有:来自51CTO博客作者mb5fdb131956bf3的原创作品,如需转载,请注明出处,否则将追究法律责任

更多相关文章

  1. Ipsec *** 中 NAT 穿越技术
  2. 华为路由交换技术:VRRP-虚拟网关冗余协议配置
  3. 【扯淡篇】APM,IT能力的一面镜子
  4. 第14章 0301-实战会话控制技术,(项目实战:主页登录、用户注册 + 整
  5. 第13章 0225-PDO操作数据库技术,学习心得、笔记(员工管理系统(mysql
  6. Facade技术和composer入门基础知识
  7. 大家好我是破壳数据技术研究者,多多指教
  8. 身为在软件测试摸爬滚打多年工程师的感悟,写给正在迷茫的你!
  9. 媒体报道 | 刘译璟:未来3-5年,数据智能技术应用五大趋势

随机推荐

  1. android studio调整默认的debug.keystore
  2. android 读取raw文件下文件内容
  3. android-2.2以下杀进程方法:restartPackag
  4. SystemUI9.0系统应用图标加载流程
  5. Android 精仿QQ登录界面源码
  6. android 全屏 无标题
  7. android中播放音乐的实例
  8. Android AsyncTask 那些你不知道的事
  9. Android 出现open failed: EACCES (Permi
  10. android 选择本地图片并预览