技术

并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go细节 codereview mat使用 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 MVCC 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes自动扩容缩容 神经网络模型优化 直觉上理解机器学习 knative入门 如何学习机器学习 神经网络系列笔记 TIDB源码分析 《阿里巴巴云原生实践15讲》笔记 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 扩展Kubernetes 副本一致性 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全机制 jvm crash分析 Prometheus 学习 Kubernetes监控 Kubernetes 控制器模型 容器日志采集 容器狂占cpu怎么办? 容器狂打日志怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes objects之编排对象 源码分析体会 自动化mock AIOps说的啥 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 kubernetes实践 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 marathon-client 源码分析 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 swagger PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 《深入剖析kubernetes》笔记 精简代码的利器——lombok 学习 编程语言的动态性 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 分布式计算系统的那些套路 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 mysql 批量操作优化 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 mesos 的一些tips mesos 集成 calico calico学习 AQS2——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 硬件对软件设计的影响 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记2 《mysql技术内幕》笔记1 log4j学习 为什么netty比较难懂? 回溯法 apollo client源码分析及看待面向对象设计 学习并发 从一个marathon的问题开始的 docker 环境(主要运行java项目)常见问题 Scala的一些梗 OpenTSDB 入门 spring事务小结 事务一致性 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型 java exception Linux IO学习 network channel network byte buffer 测试环境docker化实践 netty(七)netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 mesos深入 Macvlan Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker中涉及到的一些linux知识 hystrix学习 Linux网络源代码学习——整体介绍 zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty(六)netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 Redis概述 机器学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 那些有用的sql语句 异构数据库表在线同步 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring(八) 支持AOP 自己动手写spring(七) 类结构设计调整 分析log日志 自己动手写spring(六) 支持FactoryBean 自己动手写spring(九) 总结 自己动手写spring(五) bean的生命周期管理 自己动手写spring(四) 整合xml与注解方式 自己动手写spring(三) 支持注解方式 自己动手写spring(二) 创建一个bean工厂 自己动手写spring(一) 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM内存与执行 git spring rmi和thrift maven/ant/gradle使用 再看tcp mesos简介 缓存系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 VPN(Virtual Private Network) Kubernetes存储 Kubernetes 其它特性 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 使用etcd + confd + nginx做动态负载均衡 如何通过fleet unit files 来构建灵活的服务 CoreOS 安装 CoreOS 使用 Go学习 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

标签


2019年终小结

2019年07月03日

简介

改变别人是神经病

谈工程师成长的另一面,从老书新版开始Kelly从此获得了非常宝贵的经验:要学会带领(lead),而不是驱赶(drive)。必要的时候驱赶自己没有错,但绝对不要去驱赶其他人。在我看来,“驱赶”的做法对体力劳动或许有效,但对于脑力劳动,尤其是需要高度使用创造力的脑力劳动,“驱赶”绝对是不明智的。积极奋进的人或许很难找,但一门心思偷懒的人也不多,大多数人是需要被带动的。而且越是挑战大的项目越是不能用强,也越是需要尊重员工。普通人离开学校之后已经没有了“绝对权威”的概念,再也没有老师有权利“强迫”你接受什么学说。普遍的规律是,时间越晚,年纪越大,接受新东西的难度就越大。所谓“理性”,很多时候纯粹是惰性和惯性。这可能会让人更沉稳,更不容易被煽动,但如果缺失正确的信念,也可能一直缺失。

闲谈爱情、婚姻、家庭自己的许多追求和坚持,只适合用来约束自己,绝不是臧否其他人的利器;其他人的许多言行,即便自己看不惯,也未必需要时刻去讨伐、去纠正。如今许多人都会强调相处的“边界”,只要能把住这两点,哪怕大家差异很大,也比较愿意互相理解,边界就比较容易建立。如果把握不住这两点,即便划定了边界,也往往是徒有形式,矛盾仍然层出不穷。“严于律己,宽于待人”,其实并不是什么道德的煎熬,而是明白世界上不只有一种生活方式,一种价值观。

重设计,再一个参与所有设计(设计工作不下放)。有一个小伙伴, 我故意等了他一周让他自己试试做一下设计,但最后也是找不到关键点。以前碰到这种情况,我总是怨人不愿意主动,不愿意用功花心思。后来发现,越是设计的事情,越考验人的审美、对编程、工作的热情。很多人拿钱干活的状态, 不去研究过十个、八个的系统,干不了这种活。我总监教我最重要的一件事,说出来都不值一提,但很多人没有:要去做一点事,就去研究十个、八个的人这个事儿是怎么做的,基本上这个事儿有哪些关键、哪些坑就摸清楚了。这样最后设计出来的,基本就是一个不太差的系统。所谓管理,不是大家都很能干,你指点一下就行了。而是尽快识别出小伙伴是什么水平,给他能干的活儿,尽量人尽其用

混沌研习社李云龙 四级人才思维模型

  1. 四等人才赋予动作,这类人才,就是教一步会一步,但每一步都能完成好。如果连这一步都做不到,那真的不能称之为“人才”了。身处此层,是不可能获得提拔的,哪怕你自己感觉累的要死。
  2. 三等人才赋予方法,不需要领导告知每一个细节。只需要被教授一次方法,对于类似的问题都可以很好的解决掉。但是对于非同类问题又找不到方法了。
  3. 二等人才赋予原则,能够对不同领域问题的解决方法进行迁移,只需要被告知什么能做什么不能做,基本就可以很好的完成工作。
  4. 一等人才赋予角色。如果不是去创业,差不多能做到这一层就是最厉害的了。只要被赋予一个角色,便自然知道在在这个角色之下该怎么做,而且会主动驱动事情往前走。

优秀的人应该像海绵,在不停的吸收,吸收做成某个事情必要的信息,身边人的技能经验,一本书,一个框架源码,一个事儿的前因后果,给人一种这个人(可能当下绝对实力还不够)不能小看的感觉。

沟通

沟通的本质:换位思考,没有人喜欢被说服,被改变。

阿里产品专家:高情商的技术人,如何做沟通?沟通是“有目的的多向信息交流

  1. 沟通是有目的的:你的初衷是什么?你现在的行为和言语有没有妨碍你完成你的初衷?
  2. 沟通是多向信息交流:你有让对方get到你的真实想法么?你get到对方的真实想法了么?

“周哈里窗”根据信息是否被“我”知道,以及是否被“对方”知道,分成四个区域:

  1. 公众区:我知道且对方也知道的信息
  2. 隐私区:我知道的但对方不知道的信息
  3. 盲点区:我不知道但对方知道的信息
  4. 黑洞区:我跟对方都不知道的信息

周哈里窗模型认为沟通的关键是要“拓展公众区的信息”

不要一个人闷着,找高人请教, 安排一个小伙伴去做(一些新东西可以安排给小伙伴学习),只要可以形成讨论,就可以有意想不到的收获。

别人的任何动作,都先想想他想干啥。第一考虑情绪,第二才考虑内容

团队建设:程序员的品格:羞耻心、同理心与榜样的力量现在的互联网应用相对企业应用,可以更快更轻更容错,给年轻人一种错觉好像出点错没什么大不了的,也导致现在的年轻程序员对于BUG, 对于生产环境没有太多的敬畏心。

事儿

通过任务、流程来影响团队、个人、士气,用排期来安排、挡需求

一个项目换一个人就要让项目大地震一下、解决 bug 换一个人就不行因为只有老人知道要改哪一行的哪个关键字”,这不说明这个项目所涉及的技术有多复杂、不说明这个老人是什么技术大牛,而只说明这个项目的项目经理是蠢货,因为这个项目已经失控了。

有时候任务粒度要足够精细, 切记安排模糊的任务。研究性的任务要求较高,要找到合适的人。

真正去做一个带有数据反馈的闭环系统

如果你觉得学一个东西很吃力,那是因为你觉得每个东西都是新东西。如果你觉得学东西和推进工作不是一个事儿,那说明你一直在执行的层面。

《反脆弱》中有个观点:只有脆弱的人才会每时每刻努力证明自己是正确的,反脆弱的人则会时常思考自己还有哪些地方做错了,哪些地方可以改进。

长期利益往往意味着短期利益的下降,因为你在花更多的时间,做一个看似没有成果的事情。19世纪德国普鲁士军事理论家卡尔·冯·克劳塞维茨在《战争论》里讲到将领的作用时说,在茫茫的黑暗中,要能发出内在的微光。PS:很多时候,你是最后坚持的那个人,你再不坚持,这事儿就凉了

文档体现了一个人的思路,文档不是事无巨细的流水账,写文档以及组织文档是需要智商的、是需要架构师去设计的。

真正的高手,都有对抗熵增的底层思维。说白了就是控制复杂性,代码做的事情多了,要通过代码和架构设计控制复杂性,人员多了,要通过分级管理控制复杂性。

当你是组长时,你要放弃学一些东西,尤其是细枝末节的,必须去学原理那些一通百通的东西

有的人看见草原就知道有肉吃,有的人看见羊才知道有肉吃,有的人非得你杀好了羊烤成了羊肉串才知道有肉吃。

先想理想状态,一切以理想状态推进设计。

你得对你的环境先知先觉,你碰到的问题大部分时候都不是你独有的,一定可以抽象出一个问题,汇总几个解决方法, 然后去试错提炼,找到适合自己的最佳实践。

做工作

15 年工龄的资深技术专家职场历程自述一定要用 20% 的时间快速掌握 80% 的知识点,然后就可以开展工作,后续的 20% 知识点,可能会占用 80% 的时间掌握,可以拆散打乱到平时工作中继续学习,或者请教专业人士慢慢补足,没有必要为了追求完美持续学习,而是要转身开始开展工作或者开始其他方向的学习。

学习的最终目的不是获得现成的知识,更重要的是锻炼出“从已知到未知”,不断主动扩展知识领地的能力。要锻炼出这种能力,就必须在“获得知识”的过程中,不断审视自己已有的知识,不断培养自己的学习习惯,优化自己的学习方式。比如常常问自己“这是真的吗?”,反思“我之前错在哪里了”,自问“我还需要学习什么”,以及坦然面对与已有认知冲突甚至让自己“丢面子”的信息,从而获得更立体全面的认知…… ==> 糖衣炮弹来了怎么办?好办!糖衣吃掉,炮弹打回去。

15 年工龄的资深技术专家职场历程自述工程师的工作是千头万绪,有很多很多问题需要解决,那该怎么找到其中的关键点呢?我觉得吧,一定要时不时的停下手头的工作,环顾下自己的工作,看看里面哪些问题是只要自己个人投入足够时间就可以解决的,哪些问题是需要多方协调,需要其他资源投入才可以解决的,特别是对于第二种情况,一定要有危机感,一定要有警惕性和前瞻性,因为这种问题,可能就是我说的关键点,需要提高优先级来解决。,我们每天有很多重要而紧急的事情,我的时间管理该怎么做?其实,如果你有很好的危机感,或者前瞻性,及时规划重要而不紧急的事情,那么你接下来就不太容易碰到重要而紧急的事情。比如阿里有年度考评,需要做很多 PPT 和自评,这些事情平时做肯定是重要而不紧急,平时多收集汇报的素材,并记录下来,那么等到年度考评的事情,可以快速和轻松的做好。如果平时不收集素材,到了年度考评的时候,你就要花很多时间回忆自己一年都有哪些亮点,该怎么总结自己的一年工作,这样就把一个重要而不紧急的事情变成一个重要而紧急的事情。一个优秀工程师,有一个很重要的标准,那就是他不太有重要而紧急的事情,每天大部分时间,他都在处理重要而不紧急的事情,这样他的工作和学习都是非常的闲庭信步。打个比方,类似下棋走一步看三步,这个刚开始很难,只要你对项目的方方面面多思考,对技术保持前瞻性思考,你就慢慢会有这种能力。

技术人员如果要上升到技术管理,演讲力也是一个重要的考察指标,有很好演讲力,很好表达力的工程师,说明这个人,既有技术功底,又有宏观抽象能力,并可以从非技术角度思考问题,绝对是技术管理人员的好人选。

世界上没有技术驱动型公司?一个程序员,应该花 80% 的时间做代码设计、画 UML 图、画时序图,20% 的时间写 code 和 debug;菜鸟程序员的这个比例恰好是反的。一句话,不论这个需求有多紧急,你都一定要“想好再动手”;“想好”的标志就是设计文档写好了;文档一旦写好,写代码就是纯粹的无脑工作。 写文档的目的是让你在 coding 的时候,不需要停下来思考更不需要推倒重来。如果没有文档也可以做到这一点,你当然可以不写文档同时思考下自己水平这么高是不是可以要求升职加薪了……或者,你是不是在做无聊的 if else 编码工作?

我们不是在做系统,我们是在解决问题,系统存在了半年一年,问题依然没有解决,系统就毫无价值。我们在做任何一件事之前,重要的就是定义评价标尺,标尺的基本要素就是问题有没有解决。“为什么”“有什么价值”是真正的“核心思考区间”,而如何把how做到极致 只是“边缘思考区间”。对“为什么”没有认识和决心,执行“how”的时候就会犹疑不定。不管是任何工作,最根本、最核心的能力,一定是“识别问题”的能力,看清楚在当下的任务中,到底哪些事情才是它的“核心思考区间”,才是我们目前所遇到的“关键挑战”,将它解决,后续的边缘问题自然就会解决。

解决问题,close 问题,问题不解决,事情就没有结束。 一切问题 都可以变着法儿用技术问题去解决。测试环境配置瞎填,那就嗅探出来,做出报警。

为什么你的高效交付,却没有好的业务成果?当堆了那么多功能之后,突然发现竞品刚刚推出了一个很火的活动,不是自家刚做过的吗?我们没火但为什么竞品火了?是自家公司的人不行吗?是自家的用户不行吗?其实不是!这里有两个原因,一是在被误解的“小步快跑”交付思想下,许多业务的价值点没有挖透。二是职能团队之间没有形成联动,只做了功能的交付和自运营。试想,一个功能的交付如何打得过一个由产品、运营、PR、市场、渠道等多职能海陆空协同的业务交付呢?价值挖掘不到位,就好比下图的挖井,明知道下面有水源,但不管换多少个地方挖但总挖不出水来。

未来技术

未来,仅凭几个前端工程师,就能 hold 住一家企业吗?微前端架构旨在解决单体应用在一个相对长的时间跨度下,由于参与的人员、团队的增加,从一个普通应用演变成一个巨石应用(Frontend Monolith),随之而来的应用不可维护问题。

阿里云提供的很多商业化产品和服务,本质上是对外提供「能力」,普惠中小企业。目前,能力输出主要是通过 OpenAPI,用以集成到企业自己的业务场景中,这里主要解决的还是企业底层的能力问题——无需雇佣算法工程师,就可以拥有语音、图像识别等能力。但是,随着云技术不断的下沉,与产业结合的越来越紧密,OpenAPI 唯有把粒度做得越来越细,才能满足各种各样的业务场景,但同时企业侧的学习成本和开发复杂度自然就上去了。如果你问我 Ant Design 有什么技术价值?它的价值就是有大量的企业在用,形成某种能力依赖,不需要找设计师或者多么资深的前端工程师,就可以做出看上去很专业的后台界面。在这条价值链路上,OpenAPI 太底层,控制台不灵活,UI 库太通用。其中的空白点是绑定能力的商业化组件。举个例子,企业的后台管理页上,可以直接 inside 一个「漏洞管理」的微前端应用,和一个 DataV 的微前端应用展示数据,只需要简单配一下即可,不用开发,就能做到“就像自己开发的一样”。反过来也一样,ISV 在阿里云的产品平台上,不仅可以通过小程序的形式,也可以通过微前端应用的形式输入自己的服务。简单地说,搞微前端目的就是要将产品原子化(跟原子化的 OpenAPI 一个道理),再根据客户业务场景组合。每个功能模块能单独迭代,自由集成。云时代的开发模式注定是「碎片化」的,开发是面向模块的,而页面只是一种组合场景,一种运行时容器。我想,未来的产品开发主要时间是在「编排」——编排服务、编排逻辑、编排组件、编排访问策略、编排流程。