区块链技术博客
www.b2bchain.cn

从组员到Leader的心路历程分享求职学习资料

本文介绍了从组员到Leader的心路历程分享求职学习资料,有助于帮助完成毕业设计以及求职,是一篇很好的资料。

对技术面试,学习经验等有一些体会,在此分享。

大家好,好久不见。

目前在互联网工作的这些年,大厂和小厂都待过,也接触过各种各样的管理者和组员,直到近两年自己开始成为技术 Leader,算是在两种角色上都有些切身的心得体会,这里给大家分享下,希望能给大家的职场工作带来一些启发。

简单说明下,在毕业不久加入阿里的第一年,团队大概十几个人,作为三个新人之一,便拿到了全年度的团队最高绩效;并在毕业工作三年多后,开始在大厂里担任技术Leader。当然这些是过去式,这里主要把期间的经验分享出来,主要从下面的一些方面来分享:

  • 快速成长
  • 技术能力的深度与广度
  • 思维的升级
    • 兜底思维
    • 复盘思维
    • RootCause思维
  • 组员和Leader的本质区别
  • 对于大厂晋升的看法
  • 需求背后的换位思考
  • 从需求驱动人,到人驱动需求
  • 我们学不会所有的技术
  • 忘记工作

快速成长

刚刚工作的前两年,作为新人初入职场,在我看来最重要的是保持快速成长。好比把海绵突然泡在水里,开始时水分的吸收是特别快的。而且新人对于职场的热情、激情往往也是更强烈的;同时由于刚离开学校,学习速度仍是非常快的。

因此前两年一定要把自身的成长放在第一位。在选择工作时,相比于薪资、工作环境、工作地点等因素,自身的成长速度应该排在最前面。

那具体如何成长呢?

技术能力的深度与广度

作为一名技术人员,由于在大厂和小厂都工作过,在我看来,大厂更看重技术深度,小厂更看重技术广度。

如果你在大厂,那一定要在自己所处的技术领域里,足够深入的钻研。因为大厂人员较多,每个人能涉及到的领域不会太多;而且大厂都有完善的基础组件、平台系统,让你能够傻瓜式去使用。不过千万不要误以为能够把各种API融会贯通就表示技术过硬了,因为一旦换一家公司,这些API可能就不再有了,你才发现自己其实被大厂惯成了一名“调包侠”。因此,我们在使用各种功能丰富的 SDK 时,一定要在完成业务需求之外,自己去挑一些感兴趣的SDK去深入分析原因,而且一旦遇到问题,你甚至能轻松找到 SDK 的作者去深入探讨一番,这才是大厂人才培养的优势,千万不能错过,否则大厂的经历只是熟悉了各种API,算不上真正的提升。

如果你在小厂,由于人员较少,你可能需要承担多个开发角色,而且需求的上线更讲究快速迭代,不一定会有大厂严格的稳定性要求。因此你可能需要去快速学习多种技术栈。而且小厂一般为了吸引人才,会突出极客属性,这背后就是在技术不断更新的同时,持续追求更高效的开发工具、更实用简便的技术栈等。好处是能够扩展你的视野,让你见识更多种多样的技术,而你可以去思考这些工具背后的设计原理。

当然,如果你追求成为一名脱颖而出的开发者,最好能够同时在深度和广度上面去挖掘。

思维的升级

这里总结一些我认为非常有效的思维方式,是摸爬滚打、不断踩坑里学习到的。

1. 兜底思维

这个思维是在大厂的工作里总结出来的,由于大厂的DAU 往往能达到千万甚至亿级,假设除了一个线上问题,影响千分之一的用户,在大厂的背景下,可能就影响了数万个用户。如果是电商业务,而你出的问题会导致用户打不开商品详情页或者下单付款时会失败,那对于公司的影响其实就非常大了。

但是我们又不能保证,快速迭代的同时能够不出认为问题。即使强如微信且功能迭代不算频繁的情况下,也偶尔会出一些奇奇怪怪的线上问题。

想想一旦出了线上问题时,需要心跳加速地去止损、排查、修复,你就会悔恨当时怎么没早点发现这个bug。

因此,作为一名技术人员需要时刻保持“兜底思维”:不论你的代码出了什么问题,已知或未知的,都要提前做好兜底处理,尝试去降低影响程度,并确保在某些体验受损的情况下,核心流程能够正常运行。

以下载一个文件为例,一般只要处理下成功和失败的不同展示就行,失败的话就让用户去重启下网络就结束了。但是,如果这个文件是一个非常关键的文件,假设是支付阶段必须的文件,那我们做法就不一样了。首先我们优先考虑把文件内置到安装包里,这样能确保一定有一份文件可用。但如果这个文件需要动态更新呢?那我们就要添加一个完善的下载机制,比如在进程启动、网络连接上等时机去触发文件检查,如果有更新就去下载。

  • 那下载失败怎么办呢?我们要拆分成各种失败原因,如果是设备无网络,可以要求用户联网;如果是CDN有问题,那就需要增加异常上报实时监控;
  • 如果文件出现下载损坏呢?那我们可以在header里给文件增加md5校验,如果不匹配也可以上报;
  • 如果文件和md5都被恶意篡改呢?那我们可以对文件的md5进行RSA加密,后台用私钥加密,客户端用公钥解密;
  • 如果文件比较敏感不希望其他人看到呢?那我们可以对文件进行加密,保证传输链路其他人无法拿到文件;同时增加https通信;
  • 文件加密后,到了客户端使用时仍然要解密怎么办呢?那我们可以下载解密后存储到私有目录。
  • 如果用户是root手机可以随意读取所有目录呢?那我们下载后先不解密,等到需要使用时再把加密文件读取到内存,同时从后端下发秘钥实时解密。这样又增加了破解的难度。
  • 下载这里,如果网络差呢?那我们可以增加重试机制,失败后再次重试;
  • 如果是CDN压力太大导致下载都很慢呢?这时客户端的不断重试反而可能更加加重CDN压力,因此重试要加上冷却,或者指数退避,逐步增加重试间隔。

等等。

上面说的大家可能会觉得是不是考虑太多了,没有必要。但我要说明的是,上面所有的方案,都在微信里实现过。当年春晚期间有一个特殊的红包弹窗资源,就是通过上面的加密方式下发并动态解密的;微信的长连接SDK Mars里也有各种的重试机制以在提高连接成功率的同时又不对后端产生太多压力造成雪崩。

除了上面提到的编码兜底,很多大厂也会有一套线上兜底系统。比如AB系统,功能上线前,会先进行用户灰度,选择一批用户先去体验;而且代码内也要对所有可能出问题的地方加好开关,一旦线上功能出现问题,可以做到实时关闭开关止损;另外也要配套好快速稳定的热修复机制,如果功能无法关闭,则要快速准备好补丁下发。

另外在代码架构上,也要做好核心链路与业务新功能的隔离。因为核心链路一般是相对固定的,而业务新功能是天天在变的,这两部分代码要做好仓库和结构的隔离,以防止产生严重问题。

2. 复盘思维

由于企业和人员都是在不断的犯错和纠错中前进的,如果想要保持较快的迭代速度又能确保线上功能的稳定性,那么一定要配备一套完整的复盘机制。

当线上问题发生时,我们要有足够实时的监控数据能够立即发现问题;同时能够自动找到对应的业务和技术同学尽快开始排查,并能够在问题现场采集到尽可能多的信息上报上来,方便快速定位问题根源。找到问题后,需要第一时间止损(如关闭开关)并及时修复(下发补丁、客户端进入安全模式等)。

当然,这是一条理想的链路,我们不可能在第一天就搭建好,而且即使有这样一套链路,我们仍然应该去尽可能避免重复出现类似问题。

因此,我们在每次出现严重问题并妥善解决后,应第一时间对整件事情的前因后果进行完整的梳理。这个梳理的重点并不在于追责,而是尝试从里面发现平常忽视却又隐藏的问题,不管是平台系统问题、代码开发流程的问题,还是编码习惯问题、公共组件问题。针对发现的问题,能够提出尽可能通用的优化方案,不仅要防止未来再出现同一类问题,甚至能够预防其他潜在的隐患。最终把优化方案落地成具体可行的步骤,由对应同学去执行改进。并且把踩坑的经验梳理出来分享给大家。

稳定的系统不是一蹴而就的。适合一家公司的系统和流程也绝不是可以通过金钱可以直接引入或买来的,而是需要整个公司、各个部门、各个系统一起踩坑、不断进化出来的。而且要明白,不管多稳定的系统,多完善的流程,都不可避免会持续存在大大小小的问题,只是看具体什么时候暴露了。

3. RootCause思维

在遇到问题时,我发现有两类人,一类是对问题做表层的处理,比如在一个发生Crash的地方,增加一个try catch,增加日志或上报,或者简单看下为什么会Crash,后续做下留意,看起来处理得已经算比较完善了。

大家好,好久不见。

目前在互联网工作的这些年,大厂和小厂都待过,也接触过各种各样的管理者和组员,直到近两年自己开始成为技术 Leader,算是在两种角色上都有些切身的心得体会,这里给大家分享下,希望能给大家的职场工作带来一些启发。

简单说明下,在毕业不久加入阿里的第一年,团队大概十几个人,作为三个新人之一,便拿到了全年度的团队最高绩效;并在毕业工作三年多后,开始在大厂里担任技术Leader。当然这些是过去式,这里主要把期间的经验分享出来,主要从下面的一些方面来分享:

  • 快速成长
  • 技术能力的深度与广度
  • 思维的升级
    • 兜底思维
    • 复盘思维
    • RootCause思维
  • 组员和Leader的本质区别
  • 对于大厂晋升的看法
  • 需求背后的换位思考
  • 从需求驱动人,到人驱动需求
  • 我们学不会所有的技术
  • 忘记工作

快速成长

刚刚工作的前两年,作为新人初入职场,在我看来最重要的是保持快速成长。好比把海绵突然泡在水里,开始时水分的吸收是特别快的。而且新人对于职场的热情、激情往往也是更强烈的;同时由于刚离开学校,学习速度仍是非常快的。

因此前两年一定要把自身的成长放在第一位。在选择工作时,相比于薪资、工作环境、工作地点等因素,自身的成长速度应该排在最前面。

那具体如何成长呢?

技术能力的深度与广度

作为一名技术人员,由于在大厂和小厂都工作过,在我看来,大厂更看重技术深度,小厂更看重技术广度。

如果你在大厂,那一定要在自己所处的技术领域里,足够深入的钻研。因为大厂人员较多,每个人能涉及到的领域不会太多;而且大厂都有完善的基础组件、平台系统,让你能够傻瓜式去使用。不过千万不要误以为能够把各种API融会贯通就表示技术过硬了,因为一旦换一家公司,这些API可能就不再有了,你才发现自己其实被大厂惯成了一名“调包侠”。因此,我们在使用各种功能丰富的 SDK 时,一定要在完成业务需求之外,自己去挑一些感兴趣的SDK去深入分析原因,而且一旦遇到问题,你甚至能轻松找到 SDK 的作者去深入探讨一番,这才是大厂人才培养的优势,千万不能错过,否则大厂的经历只是熟悉了各种API,算不上真正的提升。

如果你在小厂,由于人员较少,你可能需要承担多个开发角色,而且需求的上线更讲究快速迭代,不一定会有大厂严格的稳定性要求。因此你可能需要去快速学习多种技术栈。而且小厂一般为了吸引人才,会突出极客属性,这背后就是在技术不断更新的同时,持续追求更高效的开发工具、更实用简便的技术栈等。好处是能够扩展你的视野,让你见识更多种多样的技术,而你可以去思考这些工具背后的设计原理。

当然,如果你追求成为一名脱颖而出的开发者,最好能够同时在深度和广度上面去挖掘。

思维的升级

这里总结一些我认为非常有效的思维方式,是摸爬滚打、不断踩坑里学习到的。

1. 兜底思维

这个思维是在大厂的工作里总结出来的,由于大厂的DAU 往往能达到千万甚至亿级,假设除了一个线上问题,影响千分之一的用户,在大厂的背景下,可能就影响了数万个用户。如果是电商业务,而你出的问题会导致用户打不开商品详情页或者下单付款时会失败,那对于公司的影响其实就非常大了。

但是我们又不能保证,快速迭代的同时能够不出认为问题。即使强如微信且功能迭代不算频繁的情况下,也偶尔会出一些奇奇怪怪的线上问题。

想想一旦出了线上问题时,需要心跳加速地去止损、排查、修复,你就会悔恨当时怎么没早点发现这个bug。

因此,作为一名技术人员需要时刻保持“兜底思维”:不论你的代码出了什么问题,已知或未知的,都要提前做好兜底处理,尝试去降低影响程度,并确保在某些体验受损的情况下,核心流程能够正常运行。

以下载一个文件为例,一般只要处理下成功和失败的不同展示就行,失败的话就让用户去重启下网络就结束了。但是,如果这个文件是一个非常关键的文件,假设是支付阶段必须的文件,那我们做法就不一样了。首先我们优先考虑把文件内置到安装包里,这样能确保一定有一份文件可用。但如果这个文件需要动态更新呢?那我们就要添加一个完善的下载机制,比如在进程启动、网络连接上等时机去触发文件检查,如果有更新就去下载。

  • 那下载失败怎么办呢?我们要拆分成各种失败原因,如果是设备无网络,可以要求用户联网;如果是CDN有问题,那就需要增加异常上报实时监控;
  • 如果文件出现下载损坏呢?那我们可以在header里给文件增加md5校验,如果不匹配也可以上报;
  • 如果文件和md5都被恶意篡改呢?那我们可以对文件的md5进行RSA加密,后台用私钥加密,客户端用公钥解密;
  • 如果文件比较敏感不希望其他人看到呢?那我们可以对文件进行加密,保证传输链路其他人无法拿到文件;同时增加https通信;
  • 文件加密后,到了客户端使用时仍然要解密怎么办呢?那我们可以下载解密后存储到私有目录。
  • 如果用户是root手机可以随意读取所有目录呢?那我们下载后先不解密,等到需要使用时再把加密文件读取到内存,同时从后端下发秘钥实时解密。这样又增加了破解的难度。
  • 下载这里,如果网络差呢?那我们可以增加重试机制,失败后再次重试;
  • 如果是CDN压力太大导致下载都很慢呢?这时客户端的不断重试反而可能更加加重CDN压力,因此重试要加上冷却,或者指数退避,逐步增加重试间隔。

等等。

上面说的大家可能会觉得是不是考虑太多了,没有必要。但我要说明的是,上面所有的方案,都在微信里实现过。当年春晚期间有一个特殊的红包弹窗资源,就是通过上面的加密方式下发并动态解密的;微信的长连接SDK Mars里也有各种的重试机制以在提高连接成功率的同时又不对后端产生太多压力造成雪崩。

除了上面提到的编码兜底,很多大厂也会有一套线上兜底系统。比如AB系统,功能上线前,会先进行用户灰度,选择一批用户先去体验;而且代码内也要对所有可能出问题的地方加好开关,一旦线上功能出现问题,可以做到实时关闭开关止损;另外也要配套好快速稳定的热修复机制,如果功能无法关闭,则要快速准备好补丁下发。

另外在代码架构上,也要做好核心链路与业务新功能的隔离。因为核心链路一般是相对固定的,而业务新功能是天天在变的,这两部分代码要做好仓库和结构的隔离,以防止产生严重问题。

2. 复盘思维

由于企业和人员都是在不断的犯错和纠错中前进的,如果想要保持较快的迭代速度又能确保线上功能的稳定性,那么一定要配备一套完整的复盘机制。

当线上问题发生时,我们要有足够实时的监控数据能够立即发现问题;同时能够自动找到对应的业务和技术同学尽快开始排查,并能够在问题现场采集到尽可能多的信息上报上来,方便快速定位问题根源。找到问题后,需要第一时间止损(如关闭开关)并及时修复(下发补丁、客户端进入安全模式等)。

当然,这是一条理想的链路,我们不可能在第一天就搭建好,而且即使有这样一套链路,我们仍然应该去尽可能避免重复出现类似问题。

因此,我们在每次出现严重问题并妥善解决后,应第一时间对整件事情的前因后果进行完整的梳理。这个梳理的重点并不在于追责,而是尝试从里面发现平常忽视却又隐藏的问题,不管是平台系统问题、代码开发流程的问题,还是编码习惯问题、公共组件问题。针对发现的问题,能够提出尽可能通用的优化方案,不仅要防止未来再出现同一类问题,甚至能够预防其他潜在的隐患。最终把优化方案落地成具体可行的步骤,由对应同学去执行改进。并且把踩坑的经验梳理出来分享给大家。

稳定的系统不是一蹴而就的。适合一家公司的系统和流程也绝不是可以通过金钱可以直接引入或买来的,而是需要整个公司、各个部门、各个系统一起踩坑、不断进化出来的。而且要明白,不管多稳定的系统,多完善的流程,都不可避免会持续存在大大小小的问题,只是看具体什么时候暴露了。

3. RootCause思维

在遇到问题时,我发现有两类人,一类是对问题做表层的处理,比如在一个发生Crash的地方,增加一个try catch,增加日志或上报,或者简单看下为什么会Crash,后续做下留意,看起来处理得已经算比较完善了。

大家好,好久不见。

目前在互联网工作的这些年,大厂和小厂都待过,也接触过各种各样的管理者和组员,直到近两年自己开始成为技术 Leader,算是在两种角色上都有些切身的心得体会,这里给大家分享下,希望能给大家的职场工作带来一些启发。

简单说明下,在毕业不久加入阿里的第一年,团队大概十几个人,作为三个新人之一,便拿到了全年度的团队最高绩效;并在毕业工作三年多后,开始在大厂里担任技术Leader。当然这些是过去式,这里主要把期间的经验分享出来,主要从下面的一些方面来分享:

  • 快速成长
  • 技术能力的深度与广度
  • 思维的升级
    • 兜底思维
    • 复盘思维
    • RootCause思维
  • 组员和Leader的本质区别
  • 对于大厂晋升的看法
  • 需求背后的换位思考
  • 从需求驱动人,到人驱动需求
  • 我们学不会所有的技术
  • 忘记工作

快速成长

刚刚工作的前两年,作为新人初入职场,在我看来最重要的是保持快速成长。好比把海绵突然泡在水里,开始时水分的吸收是特别快的。而且新人对于职场的热情、激情往往也是更强烈的;同时由于刚离开学校,学习速度仍是非常快的。

因此前两年一定要把自身的成长放在第一位。在选择工作时,相比于薪资、工作环境、工作地点等因素,自身的成长速度应该排在最前面。

那具体如何成长呢?

技术能力的深度与广度

作为一名技术人员,由于在大厂和小厂都工作过,在我看来,大厂更看重技术深度,小厂更看重技术广度。

如果你在大厂,那一定要在自己所处的技术领域里,足够深入的钻研。因为大厂人员较多,每个人能涉及到的领域不会太多;而且大厂都有完善的基础组件、平台系统,让你能够傻瓜式去使用。不过千万不要误以为能够把各种API融会贯通就表示技术过硬了,因为一旦换一家公司,这些API可能就不再有了,你才发现自己其实被大厂惯成了一名“调包侠”。因此,我们在使用各种功能丰富的 SDK 时,一定要在完成业务需求之外,自己去挑一些感兴趣的SDK去深入分析原因,而且一旦遇到问题,你甚至能轻松找到 SDK 的作者去深入探讨一番,这才是大厂人才培养的优势,千万不能错过,否则大厂的经历只是熟悉了各种API,算不上真正的提升。

如果你在小厂,由于人员较少,你可能需要承担多个开发角色,而且需求的上线更讲究快速迭代,不一定会有大厂严格的稳定性要求。因此你可能需要去快速学习多种技术栈。而且小厂一般为了吸引人才,会突出极客属性,这背后就是在技术不断更新的同时,持续追求更高效的开发工具、更实用简便的技术栈等。好处是能够扩展你的视野,让你见识更多种多样的技术,而你可以去思考这些工具背后的设计原理。

当然,如果你追求成为一名脱颖而出的开发者,最好能够同时在深度和广度上面去挖掘。

思维的升级

这里总结一些我认为非常有效的思维方式,是摸爬滚打、不断踩坑里学习到的。

1. 兜底思维

这个思维是在大厂的工作里总结出来的,由于大厂的DAU 往往能达到千万甚至亿级,假设除了一个线上问题,影响千分之一的用户,在大厂的背景下,可能就影响了数万个用户。如果是电商业务,而你出的问题会导致用户打不开商品详情页或者下单付款时会失败,那对于公司的影响其实就非常大了。

但是我们又不能保证,快速迭代的同时能够不出认为问题。即使强如微信且功能迭代不算频繁的情况下,也偶尔会出一些奇奇怪怪的线上问题。

想想一旦出了线上问题时,需要心跳加速地去止损、排查、修复,你就会悔恨当时怎么没早点发现这个bug。

因此,作为一名技术人员需要时刻保持“兜底思维”:不论你的代码出了什么问题,已知或未知的,都要提前做好兜底处理,尝试去降低影响程度,并确保在某些体验受损的情况下,核心流程能够正常运行。

以下载一个文件为例,一般只要处理下成功和失败的不同展示就行,失败的话就让用户去重启下网络就结束了。但是,如果这个文件是一个非常关键的文件,假设是支付阶段必须的文件,那我们做法就不一样了。首先我们优先考虑把文件内置到安装包里,这样能确保一定有一份文件可用。但如果这个文件需要动态更新呢?那我们就要添加一个完善的下载机制,比如在进程启动、网络连接上等时机去触发文件检查,如果有更新就去下载。

  • 那下载失败怎么办呢?我们要拆分成各种失败原因,如果是设备无网络,可以要求用户联网;如果是CDN有问题,那就需要增加异常上报实时监控;
  • 如果文件出现下载损坏呢?那我们可以在header里给文件增加md5校验,如果不匹配也可以上报;
  • 如果文件和md5都被恶意篡改呢?那我们可以对文件的md5进行RSA加密,后台用私钥加密,客户端用公钥解密;
  • 如果文件比较敏感不希望其他人看到呢?那我们可以对文件进行加密,保证传输链路其他人无法拿到文件;同时增加https通信;
  • 文件加密后,到了客户端使用时仍然要解密怎么办呢?那我们可以下载解密后存储到私有目录。
  • 如果用户是root手机可以随意读取所有目录呢?那我们下载后先不解密,等到需要使用时再把加密文件读取到内存,同时从后端下发秘钥实时解密。这样又增加了破解的难度。
  • 下载这里,如果网络差呢?那我们可以增加重试机制,失败后再次重试;
  • 如果是CDN压力太大导致下载都很慢呢?这时客户端的不断重试反而可能更加加重CDN压力,因此重试要加上冷却,或者指数退避,逐步增加重试间隔。

等等。

上面说的大家可能会觉得是不是考虑太多了,没有必要。但我要说明的是,上面所有的方案,都在微信里实现过。当年春晚期间有一个特殊的红包弹窗资源,就是通过上面的加密方式下发并动态解密的;微信的长连接SDK Mars里也有各种的重试机制以在提高连接成功率的同时又不对后端产生太多压力造成雪崩。

除了上面提到的编码兜底,很多大厂也会有一套线上兜底系统。比如AB系统,功能上线前,会先进行用户灰度,选择一批用户先去体验;而且代码内也要对所有可能出问题的地方加好开关,一旦线上功能出现问题,可以做到实时关闭开关止损;另外也要配套好快速稳定的热修复机制,如果功能无法关闭,则要快速准备好补丁下发。

另外在代码架构上,也要做好核心链路与业务新功能的隔离。因为核心链路一般是相对固定的,而业务新功能是天天在变的,这两部分代码要做好仓库和结构的隔离,以防止产生严重问题。

2. 复盘思维

由于企业和人员都是在不断的犯错和纠错中前进的,如果想要保持较快的迭代速度又能确保线上功能的稳定性,那么一定要配备一套完整的复盘机制。

当线上问题发生时,我们要有足够实时的监控数据能够立即发现问题;同时能够自动找到对应的业务和技术同学尽快开始排查,并能够在问题现场采集到尽可能多的信息上报上来,方便快速定位问题根源。找到问题后,需要第一时间止损(如关闭开关)并及时修复(下发补丁、客户端进入安全模式等)。

当然,这是一条理想的链路,我们不可能在第一天就搭建好,而且即使有这样一套链路,我们仍然应该去尽可能避免重复出现类似问题。

因此,我们在每次出现严重问题并妥善解决后,应第一时间对整件事情的前因后果进行完整的梳理。这个梳理的重点并不在于追责,而是尝试从里面发现平常忽视却又隐藏的问题,不管是平台系统问题、代码开发流程的问题,还是编码习惯问题、公共组件问题。针对发现的问题,能够提出尽可能通用的优化方案,不仅要防止未来再出现同一类问题,甚至能够预防其他潜在的隐患。最终把优化方案落地成具体可行的步骤,由对应同学去执行改进。并且把踩坑的经验梳理出来分享给大家。

稳定的系统不是一蹴而就的。适合一家公司的系统和流程也绝不是可以通过金钱可以直接引入或买来的,而是需要整个公司、各个部门、各个系统一起踩坑、不断进化出来的。而且要明白,不管多稳定的系统,多完善的流程,都不可避免会持续存在大大小小的问题,只是看具体什么时候暴露了。

3. RootCause思维

在遇到问题时,我发现有两类人,一类是对问题做表层的处理,比如在一个发生Crash的地方,增加一个try catch,增加日志或上报,或者简单看下为什么会Crash,后续做下留意,看起来处理得已经算比较完善了。

部分转自互联网,侵权删除联系

赞(0) 打赏
部分文章转自网络,侵权联系删除b2bchain区块链学习技术社区 » 从组员到Leader的心路历程分享求职学习资料
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

b2b链

联系我们联系我们