2018.5.31~2019.5.31，精彩的旅程，在阿里度过了一年，这段时间有快乐，有焦虑，有迷茫，有更多的思考，想着自己过去的不足，想着一些现在看来是错误的错误想法，想着如何成为一个更好的技术人，把这些想法分享给看到这些话的大家，互相鼓励。1.线上看似无意义的异常/故障如何处理？如何处理在线异常/故障？最近想想“防火”这个词，很有意思。它其实有两层意思：“消除”是消除问题；“防”就是防止出现问题。也就是说，“救火”一词应该是先消除问题，再防止同样问题再次发生的意思。其实线上异常/故障也是如此。及时止血，处理问题，然后深挖问题，找出根源。下面举几个例子：假设是某段代码中的空指针异常引起的，那么你是否考虑加强CodeReview，或者使用findbugs插件自动扫描代码中可能存在的异常？假设是网上某项配置修改引起的，是不是需要以后有人仔细检查修改后才能修改？假设由于系统重启，导致本地内存中的某些值丢失，是否需要引入定时任务，定时将值写入本地内存？假设某段代码逻辑没有测试，你能否反思和总结这段逻辑为什么没有测试，以后的测试应该如何改进？根据我以往的经验，太多的公司、太多的团队处理线上问题只解决问题而忽略问题的review，这对团队/公司的发展是不利的。2、什么是真正的技术能力？之前加了几个技术微信群，看到很多技术小伙伴兴致勃勃的讨论各种源码。我彻底阅读了spring源代码。最近在深入研究dubbo的底层实现。我也是这样。记得我在学习volatile的时候，挖出了volatile在硬件层面的实现，但这真的说明我技术能力很强吗？以今天的思维来看这个问题，我觉得更多的是体现了一个人的学习能力、研究能力、对技术的热情，并没有体现太多其他的东西。这个话题可能是今年思考最多的话题。钻研是好事，但其实很多时候，深入研究在实际工作中是没有用的，而且研究得越深，忘得越快，因为越学越快忘记。往深了，跟这个技术点相关的技术点越多，边角角边都忘了，核心的东西也不好串起来。那么什么才是真正的技术能力呢，我画个图总结一下：简单来说，技术能力=解决问题的能力，那么他们也是在解决问题，大家的技术水平有什么区别呢？我认为有以下几个层次：第一层次，解决当前的问题；第二层，以优雅且可重用的方式解决当前问题；第三个层次，解决问题不仅要满足现在，还要满足未来一段时间。其实从这个角度来看，不同的技术能力在工作过程中是可以明确区分的：写的代码是否存在异常风险，多线程运行下是否存在线程安全问题，某块是否存在的代码会导致内存泄漏；编写的代码是否优雅可复用，设计的框架是否符合开闭原则，代码结构层次是否清晰；对于一个特定的场景，技术选型和库表结构设计是否足够合理，你今天设计的框架只能用一年，还是可以在未来三五年内持续使用；有一个很大的需求，比如一个App的会员系统功能，是否可以在充分分析需求后，将需求准确的分成几份？具体的子模块和模块之间的关系梳理。越厉害的人，在代码设计开发的过程中，就越能看到和想到一些别人看不到、想不到的问题。问，这叫轻举重。因此，我认为解决问题的能力才是技术能力的真正体现。在这一年的技术研究中，我也从学习源代码转变为学习设计模式，学习分布式环境下各种NoSql类型的比较，学习使用Lambda让代码更简洁，朝着解决问题的方向努力实际工作。另外，抛开这一点，这两天我一直在思考，还有一点是体现技术能力的，那就是学习能力。现实中全栈的很少，互联网行业程序员的方向通常分为几类：服务器端；前端;移动端；人工智能；嵌入式；大数据。同一个范畴，基础知识、基本概念、思维方向相同，更多可能的差异在于开发工具和语言。我精通Java，但如果明天有需要，还是用nodejs、scala、go比较好。能否快速学习、快速上手？甚至明天还要写前端代码。能不能快速开发上线，没有bug？所以，解决问题的能力+学习能力才是我认为的真正的技术能力，但归根结底，学习能力只是在一定程度上解决问题。3、不要造轮子曾几何时，当我们看着github上那么多优秀的源代码时，我们都在心里暗暗发誓，这辈子一定要写出一个牛逼的框架，开源在网上。如何实现一些复杂情况的告警，比如我们上面提到的故障率、流量波动等？很多追求技术的朋友进入一家公司可能会寻找机会自己做一些事情，但是我之前说过，衡量一项技术真正好不好的标准是它是否能真正解决问题，做出的风险自己造轮子高，周期长，验证和排坑时间长，才能达到更好的效果。举几个例子，在今天的互联网发展中：数据库连接池有dbcp、c3p0、druid；本地缓存有ehcache，中央缓存有redis、tail；基于服务的服务包括dubbo，可以使用跨语言的thrift；分布式任务调度可以考虑schedulex；搜索可以选择es，solr。只要有技术需求，大部分行业都已经有成熟的解决方案，没必要自己专门做一个。因此，我认为造轮子并不容易。如果你一定要造轮子，请想清楚以下问题：你要做的事情是否有类似的解决方案？如果是这样，你自己的一套东西和类似的解决方案有什么区别？假设你不用这套，在现有方案的基础上稍微修改一下，能不能达到目的呢？如果没有，那为什么以前没有？这样的场景在你们公司是不是独一无二的？还是这种场景对应的解决方案根本不可行，所以之前没有人做过？如果你已经把这些问题想清楚了，那就去做吧。4.改善高度观看问题。以前有太多人在我的公众号或者博客下反馈了一个问题：在这家公司，我成天做着增删改查的工作，一点也没有提升自己。对于这种观点，说白了就是四个字——短视。我们看：如果从常人的角度看，那么一棵树只是一棵树，但是如果跳出现在的角度，从更高的角度看，它其实是森林的一部分。你的主管不是因为他是你的主管，所以他就应该比你更有前瞻性，而是因为他看问题的层次比你高，想的远，做的深，所以他就成了你的主管。让这个问题更现实一点：假设你今天负责一个系统，那么你只是了解这个系统的基本原理？或者能理清上下游有多少个系统，各个系统如何调用，如何相互依赖？假设你今天负责一个业务，所以你只是弄清楚了你负责的功能点？或者能不能从最上游开始，到你负责的系统，再到最下游，想的很透彻？今天，与其抱怨机会少，公司没能提升自己的能力，不如想想为什么机会给别人，而不给自己？为什么别人能把同样的小公司增删改查写到BAT，而你还在小公司年复一年地写增删改查？当你真正能够改变自己的思维方式，跳出现在的圈子，站在更高的高度看问题，提升自己的时候，相信总会有大放异彩的一天。同样在阿里巴巴，马老师思考自然、环境保护、人类发展。您的主管会考虑球队未来的发展方向和打法。我们思考的是如何全面落实某个客户的需求。这就是高度，你可能想象不到。马老师想了想，不过你是在对标更高的人，一步步往他们的高度靠。总而言之：眼界决定高度，多看，多想，多好奇，多问为什么，久而久之，自然会上一个台阶。5.学习总结需求和项目回顾是非常重要的内容。但是，我之前见过太多的团队和leader，只关心一个又一个迭代，一个版本又一个版本，只满足于把需求做好，而忽略了总结的重要性。大到项目，小到需求，做完项目后没有总结，我觉得在某种程度上是一种失败。可以总结的点有很多：通过这个项目/需求，你是否彻底了解了某个业务，了解了来龙去脉？;通过这个项目/需求，你是否充分了解了公司某个技术框架/基础组件的使用方法；在整个项目的设计中，有哪些地方没有做好；在整个项目的开发过程中（对于程序员），是否踩过坑，犯过低级错误；整个项目的进度控制、人员安排、上下游协调等方面是否存在缺陷；是否有过值班大升职的经历，是否能熟练使用公司的监控工具是否在遇到突发情况时迅速有效的解决。任何工作都需要个人的提升，但对于不懂得总结的人来说，每个项目/需求中成长的东西都是零散的，时间一长就会遗忘。充分总结之后，我们不会再犯自己犯过的错误，记住清楚业务的来龙去脉，对自己来说是一种提升，分享给别人也是对别人有很大的帮助。失败者失败的原因各不相同，而成功者的方式总是相似的。从宏观上讲，我认为总结是成功者能够成功的重要原因。作者：五月仓颉来源：五月仓颉（ID：gh_6b7a3f664e7d）
