2020年终总结
1、流水账
买了房子 时间线 来自抖音号(杨子在东京)
- 规则1:一秒钟原则 感谢、感动、感同身受
- 规则2:无论做什么,要达到能给别人有点帮助的水平(坚持5年到10年)
- 规则3:感情只是生活的添加剂,不是生活中的必需品,婚姻是遇到真正爱情后的选择,无论下嫁还是高攀,都是理智的决定
- 规则4:
目标:在西湖区有一所自己的房子,现在是萧山的房子
总体原则:先脱贫,再脱单,这是最佳选择
幸运的原则:《总能做出正确决定的幸运法则》 《总能做出正确决定的幸运法则》
我的现状: | 序号 | 为了解决这件事我需要做些什么 | |
---|---|---|---|
学业上 | 1、 | ||
事业上 | 1、工作上 | ||
2、以后的发展2022年底或2023年年初跳槽到 滨江阿里,这样离家就17km,半个小时的车程,方便回家。 | |||
家人 | 1、父母的养老问题,医疗问题 | ||
2、工作中做的事情
1、类目属性相关需求 (主导 + 持续跟进,持续优化中)
2、类目配置项重构(主导 + 持续优化)
3、上海开放平台(主导 + 从0到1 + 持续优化)
3、思考力 思考力是程序员需要具备的一种至关重要的素质
3.1 背景:
- 你自认为付出了跟别人同样的努力,但是你的成长确实更慢一些,比如学得比别人慢,排查问题比别人慢,出的方案老是有漏洞等等;
- 你觉得你只是在疲于应付需求,自己做的事情完全没有技术含量(很多人觉得自己做的业务开发就是没有技术含量,但我认为每个领域都有自己的技术含量,只是你有没有get到);
- 你发现总是在犯同样的错误,或者做的事情不断地在同一个水平循环;
- 每次要晋升的时候,你发现根本讲不出来(很多人会认为是表达能力问题,但是我认为不是);
- 当你换到一个新的领域,你发现自己的经验好像用不上;
- 你一直很难搞懂老鸟说的“认知升级”到底是什么概念?不同级别的技术思维能力到底有什么差别?为什么晋升的是他,而不是我?
3.2 书籍:
- 1.《金字塔原理:思考、表达和解决问题的逻辑》-[美] 芭芭拉·明托,这本书系统阐述了思考、表达和解决问题的逻辑,也是麦肯锡的思维能力基础,算是一本比较标准的思考力教材;
- 2.《麦肯锡教我的思考武器》- [日] 安宅和人,作者根据自己在麦肯锡公司工作时积累的丰富经验以及脑神经学的专业背景,设计出一套极具逻辑性的问题解决思维模式;
- 3.《思维的本质》-[美]约翰·杜威 ,这本书是美国著名教育家约翰·杜威的代表作,阐述了思维训练的基础理论和实践;
3.3 有哪些对程序员最重要的思考力
分为下面四种,原理性思维/ 我依次阐述:
-
原理性思维:找出知识背后的原理
- 一个技术方案设计的案例:为什么订单要先create,然后enable?
- 这其实是一种采用二阶段提交解决分布式事务的思路,只是从一般的事务框架延展到交易领域;
- 业务系统中为什么要使用消息?
- 因为消息使用的是观察者模式,观察者模式的好处是可以实现多个消费事务与触发事务的解耦;
- 为什么业务系统中会使用DTS(数据传输系统)来做补偿?
- 这本质上是一种最终一致性BASE理论解决分布式事务的一种思路;
- 为什么更新数据时一定要在sql中加上版本比对或者状态比对?
- 这本质上是一种借助DB实现的乐观锁机制
进一步,你会发现大到系统架构和顶层设计的案例
- 比如阿里系的技术框架NBF,TMF、早期的webx,各类框架设计理念,逃不脱设计模式,比如开闭原则,模板方法、责任链、工厂模式、开闭原则;
- 不管是底层中间件,错综复杂的业务系统,在设计师永远无法离开核心的业务建模,比如实体与实体关系的构建;在分析这类系统的设计思想时,你会发现最好的工具就是UML;
- 一个技术方案设计的案例:为什么订单要先create,然后enable?
-
实际上除了软件领域的原理,还有商业设计的原理,比如案例;
- 所有的售中退款前必须要先取消履约,所有的履约过程汇总发生缺货都需要退款,为什么?因为交易的基本原则是:”钱货平衡“,钱和货的变更必须是最终同步的(允许短期的不平衡),你掌握了钱货平衡的基本原理,交易中很多复杂的流程设计就很好理解了;
- 在设计财务系统、库存系统时,业务流程、业务逻辑可能非常复杂,导致你晕头转向,这时候“有借必有贷,借贷必先等”的财务平衡性原理就发挥作用了,你只要知道这个原理,很快就能看懂各类财务流程、库存流转流程,以及各类数据对账逻辑;
- 在“高可用线下收银系统”进行线下系统容灾时,有各种容灾方案的设计,会员容灾、商品容灾、交易容灾、支付容灾。。不同的容灾手段看起来让你眼花缭乱,但他们有没有共同遵循的原则呢?这就是“让消费者最快速度完成交易,但保持最后追溯的能力”,只有get这个基本原理,设计各类容灾策略就会得心应手了。
-
此外,我们的工作流程、管理手段,同样也蕴含着深层的原因
- 为什么团队机制要透明?沟通要透明?
- 为什么要有owner意识,都是在工作,owner意识会有什么不同呢?
- 为什么管理者不能管得太细,也不能放养?到底哪些该管,哪些不该管?
-
因此,掌握了只是背后的原理,带来的好处是:
- 软件系统的复杂度越来越高,掌握原理实际上大幅度降低我们对于知识的记忆量,知识量是爆炸的,但是原理绝对是可控的;
- 原理性的东西比直接的知识有更强的复用性
- 比如我们学习dubbo等底层的RPC通信框架的基本原理,如果仅了解它的基本原理,你会发现对你做的业务系统没有什么帮忙,但是当你了解的是dubbo如何寻址,如何做容灾,如何做扩展,你在做业务系统,发现设计原理是一样的。
- 探求原理的过程,本身很有乐趣。
2.4 哪些原理性知识是我们需要掌握的呢
- java,linux,数据结构和算法,数据库,网络通信与分布式计算的原理,这几类是比较重要的基础知识,我们在做方案设计、编码、问题排查中会运用得很多;
- 设计模式,UML这个是对系统架构设计必要要掌握的知识,当你经历了很多大规模的软件系统设计,回到根本上,你会发现逃不出这一块的理论和工具
- 领域性的基本原则,比如我们上面提到的“钱货平衡”,“财务平衡公式”,“线下收银让消费者最快速度走人”,这种逻辑需要大家get到这些领域性的设计原理,甚至自己去总结出这种原理
- 关于管理学,人际沟通,心理学的一些基本原理,大家可以按照自己的实际需求去看一下
2.5 最佳实践
1、首先,对你可能有道的领域知识,建立一个基本的概念
2、在实践中,有个意识是“多问一下为什么”,并一直“刨根问底”,最终肯定能够最查到背后的最终原理;还需要思考下,为什么在这个地方会运用这个原理,也就是找到“场景”和“原理”的关联关系,这样印象会更加深刻;
3、了解了原理之后,在实践中运用一下,这样你对这个原理的理解就会非常深刻,并且知道该如何运用这个原理。
4、一个非常重要的原理,建议如有余力去结合经典的书籍系统化学习。
- 结构化思维:构建自己的知识树
- 知识树要解决的问题,我们看一些场景
- 1、为什么我知道很多东西,但是当场景来的时候老是会记不起来使用
- 2、完成一个方案你只能想到一些点状的手段,还有其他方案被漏掉了;
- 3、讲一件事情的时候逻辑非常混乱,前后没有逻辑性关联。
3、问题定位步骤
背景:项目中测试MM提了一个bug
1、确认刚才是否有过代码变更和部署,因为有比较高的概率是刚才变更的代码被搞坏了
2、追踪链路日志看链路是否有异常;
3、通过rpc的控制台(磐石)调用看接口输入输出是否符合预期;
4、追踪关键方法的入参和出参,看是否有问题;
5、定位到方法细节后,推理逻辑是否有问题;
6、如果无法通过推理,那就最后一招,回放异常流量debug,这样肯定能找到原因。
某个链路耗时比较长,需要进行性能优化,我的分析步骤是:
1、通过实际流量制造一个耗时较高的trace;
2、进行trace分析,看清楚耗时最多的原因,然后按优先级进行排序;
3、针对原因找解决方案,可能的方案有:
-
减少数据访问次数或计算量,常见手段是增加cache;线程内的invokeCache;分布式缓存tair;页面缓存。。。
-
增强处理速度,比如多线程加速;
-
减少循环调用次数,比如请求合并后再分发;
-
减少数据处理范围,比如减少查询内容,异步加载分页;
-
逻辑简化,比如逻辑进行优化,或者非核心逻辑异步化等;
4、改掉以后,回放同样的case,看性能消耗是否满足预期,不满足预期继续优化;
如何熟悉一个新系统,我的步骤是:
-
要一个测试账号,把相关功能走一遍,这样能非常快了解一个系统的功能;
-
看关键的核心表结构,这样可以快速了解系统的领域模型;
-
根据功能步骤找到系统对外的接口列表,了解系统的L0业务流程;
-
下载系统工程,熟悉整个工程接口和模块职责;
-
以一个最重要的流程为入手点,阅读代码,看清楚核心的执行逻辑,可以边看边画时序图;
-
制造一个debug场景,以debug方式走一遍流程,这样可以实际加深对系统的理解;
-
做一个小需求,掌握相关的流程和权限;
来了一个新的需求,出一个技术方案的步骤:
1、看清楚之前的需求,把这个需求所在的场景和链路大致阅读一遍,搞懂;
2、找到需求的变化点;
3、分析变更的方案,涉及的内容可能会有:
-
重构原有的方法,覆盖之前的逻辑,那就需要进行回归;
-
通过逻辑路由到新的方法,这里需要增加路由逻辑;
- 数据结构会不会变,如何变;
- 交互协议会不会变,如何变,交互协议分为:前端和组件要不要变,和下游的接口要不要变;
- 执行逻辑会不会边,如何变,执行逻辑变更的细化考虑点:是否变更域服务,是否变更流程编排;是否变更主干逻辑;是否变更扩展点是否变更扩展点的内部逻辑,变更内部逻辑时,又可以进一步拆解:
-
重构原有的方法,覆盖之前的逻辑,那就需要进行回归
-
通过逻辑路由到新的方法,这里需要增加路由逻辑;
4、稳定性方案;
5、发布方案;
做什么事情都有一个明确的分析和执行逻辑,不太可能产生遗漏和混乱。
如何训练自己的知识树呢?时间方案为:
-
1、一定要总结出自己的知识树,而不要盲从书本上或是别人的;
-
2、习惯性总结,做完任何一件事情,都习惯性回顾下,往自己的树上挂新东西
-
3、推荐一个很常见的工具:xmind,把自己的树记录下来;
-
4、训练自己的思维习惯和做事方式变得结构化,当你做事情的时候,习惯性用树的方式推进,强迫自己按照这个方式来。
-
拓展性思维:举一反三,拓展思维
- 拓展性思维的核心目标是提升我们思维的广度,也就是让我们的知识树变得更加开阔
-
举一反三:解决同类型的N个问题
- 当发现某个系统的jvm参数配置存在一个错误配置,不是仅仅修复这个系统的jvm参数,而是把负责的几个系统都检查一下是否需要统一修改;
- 系统中存在某个bug导致产生了脏数据,不是直接订正已发现的脏数据,而是根据特征拉取出所有的脏数据,进行一次性处理;
-
寻求更多的可能性:拓展解决问题的不同手段
- 产生故障时,快速止血除了回滚之外,还有哪些方案?(系统降级,运营活动降级)
- 除了写更加健壮的代码,还有哪些手段可以提升系统的容错性?还有数据监控,单据闭环等多宗手段
-
抓重点思维:提升效率,方便记忆和传递
- 当我们发现知识树构建起来,怎么样使得记忆和使用的效率变高?而且对外传递时更加容易让人理解?抓重点思维要解决的场景是:
- 如果每件事情都按照知识树方式做,效率可能不会特别高,有更快的办法吗?
- 在对外沟通表达时,要表达核心思想,否则别人会很难理解你的表达内容;比如大家在晋升答辩、项目汇报时一定会深有体会。(核心思路是抓住重点和脉络)
-
那么筛选重点的思路有哪些呢?
- 归纳法
- 采用归纳法,把细节隐藏掉,呈现知识的脉络,这是一种非常好的思路;尤其是大家在准备晋升ppt时,ppt的每一页都需要归纳一个核心观点,不是全是细节,这个非常重要
- 优先级法
- 优先级策略往往应用于在多项任务之间找到最最关键或者收益最大的那个任务项,比如完成一个事情可能有若干个步骤,其中哪个步骤是最有效的,大致可以做一个排序
- 归纳法
-
反思性思维:思考哪里可以做得更好
-
反思性思维是提升知识质量和深度的一个关键能力。**因为只有不断反思才能让下一次在上一次基础上升级,**而不是重复循环
-
常见的反思案例:
-
有个问题我查了2个小时,师兄只花了10分钟,这是为什么呢?是他的业务比我熟悉?思路比我清晰?还是知道某个我不知道的工具?一定要找到关键的差异点,然后弥补掉这个差距;
-
一个项目项目做完了,从方案设计,研发过程,质量保障上面,哪些地方下次可以做得更好?找到不足,下次避免;
对于我们技术团队,哪些内容值得反思,我们团队的经验是:
- 这个项目商业价值OK吗?是否取得了预期的效果?
- 项目中我的能力有哪些问题,有哪些做得好的和不好的?
- 系统设计的优势和不足?
- 项目质量保障是否可以做得更好一些?
- 研发过程和项目管理是否有不足?
-
-
反思性思维的实践,注意有两个点比较关键:
- **反思性思维最重要的意识:做事情的过程总有优化的空间,每次都要有进步;**如果没有这种心态,那么很难持续地进行反思;
- **反思是一种习惯和潜意识,可以在不经意之间经常进行,**其实不需要很形式化地花很多时间,有时候做完一个事情,习惯性思考一下就可以
锻炼思考力的有效实践
-
1、意识觉醒
- 意识觉醒是提升思考力最重要的一个点
- 从初级工程师,高级工程师,技术专家,高级专家,资深专家……级别提升靠什么?多接了多少需求?多写了多少代码?这些因素会有,但是关键因素不是这些,而是思考力在不断提升,思维方式在不断进化,进而导致业绩产出必变得更加优秀,产生的是事半功倍的效果
-
2、保持信心
-
3、空杯心态
-
4、思考的时间从哪里来?
-
1.利用碎片时间;2.抓住工作的过程
-
利用碎片时间,比如上下班路上的时间,吃饭的时候,可以把刚才或者今天的事情想一想,想通了,然后定期汇总一下就可以;
-
抓住工作的过程,注意,每次每次出技术方案,优化代码,排查问题,处理故障,准备晋升……都是一次训练的机会,在做事情的过程中就可以思考并快速实践
-
-
5、思考力提升有没有什么判断标准?
-
广度、深度、速度
-
**广度:**就是你自己的知识树能够长多大的范围,越广知识越渊博;比如从“如何写一个多线程程序”,提升到“如何做系统性能优化“,再到“如何做系统稳定性备战”,这就是一种广度的提升;
-
**深度:**就是你自己的知识树的叶子节点有多深,越深对知识了解越透彻;比如从“分布式事务问题解决思路”,到“利用最终一致性解决分布式事务”,再到“利用DTS解决分布式事务”,这就是一种深度的提升;
-
**速度:**就是建立和刷新知识树的速度了。比如原来你想清楚一个建模方案要一天,现在只需要半小时可以想清楚,那就是速度的提升了。
-
-
6、好的工具有推荐么?
- xmind
-
7、一定要相互分享
- 思考虽然主要是靠自己,但是一定要相互分享。因为思考是智力活动,相互分享完全能够取得1+1>2的效果
- 注意分享可以有很多形式:项目分享 **周会分享 **群内分享
- 年度/季度分享 小圈子
-
8.技术Leader在训练大家思考力中的职责
- 技术Leader的思考力意识、能力和实际行动,决定了一个团队的整体思考力水平和成长速度
- 先要把自己变成一个思考者,自己做表率,以身作则;
- 意识心态上先变过来,要把团队同学的成长速度最为最重要的职责之一,没有这个意识都是空谈;
- 多创造思考的条件和氛围,一定要抓住任何机会(代码reivew、方案评审、周会都可以)鼓励大家去思考和分享;
- 控制团队节奏,给大家学习和思考留出一定的时间
- **及时的引导和示范,**有的同学可能掌握会偏慢一些,这时候需要有耐心去引导同学找到思考的感觉;
- **不必过多干预细节,**发挥大家的群体智慧,而不必做过多干预,更不能以个人的意志去强迫别人接受
4、技术基础
-
java基础:
包装类(装箱、拆箱) 接口,抽象类
集合体系(Map, List, Set) 多线程(线程池,阻塞队列, 可见性,锁)
文件操作
-
spring系列 springMVc spring核心:Ioc, Aop spring事务
-
rpc dubbo(会用,完成一次RPC的调用过程)
- 注册中心
- 生产者、消费者
-
数据库持久层中间键: Mybatis(会用, 利用配置完成数据库读写)
-
redis
- 5种数据结构使用(会用,常用的string和map会用)
-
rocketMq
- 如何发消息,收消息
-
git(常用操作会用)
- 本地仓库和远程仓库
- 如何commit , pull , push
-
mvn
- mvn配置(库依赖, 插件依赖 )
- install和deploy
分享
小组内做一次技术分享(关于技术基础的,主题不限)
代码规范
1.二周内通过java考试
实战过程中对java整体代码规范要有意识:
1.异常处理(当程序抛出异常,如何兜底)
2.日志打印(对核心方法打关键日志,便于后续定位问题)
3.告警(当程序抛出异常,如何告警让自己感知到)
4.事务(尽量保障数据一致性,哪怕由于分布式不能保证也要提早提出来)
5.校验(所有的参数必填非必填都应该得到校验)
设计模式: 责任链, 装饰,单例,模板
职责:单一,开放封闭
业务要求
1个月内能够导师带着干活,3个月内能够独立干活(合格:分配的任务能够独立干且质量OK 优秀:承担一个业务模块并且部分对外答疑工作)
具体业务期望:导师给
3月份时候导师要对其做一个点评。
意识问题
1.师傅领进门,修行靠自己:导师能够做一些答疑解惑,帮助制定目标少走一些弯路;但是个人能在什么样的时间点达到什么样的能力,完全靠自己
2.技术基础只是入门,后续的技术积累要靠自己;技术这个领域谁都是小学生,做IT要做好学到老,活到老的准备。