谈谈这几天参加QCon后的感想。

稍作总结

从架构分组的上一篇文章：有关“架构师”到现在已经一年有余，这一年写的文章很少。固然有一些客观的不可抗力原因，但是还有一些需要反思。

为什么写的文章变少？

  1. 没有时间写
  2. 没有内容可写 -> 没有投入更多的时间钻研技术

时间投入到哪里了？

  1. 与编程无关的其他低投入，高刺激的事情上
  2. 陪伴身边的人

为什么编程对自己的刺激感下降 -> 缺乏成就感

归功于最近的QCon上受到的启发，终于愿意坐下来，回顾这一年多的经历，谈谈自己的感想。

从技术开发转型架构师的误区

过于追求技术的深度

之前那篇有关“架构师”隐隐有些危险的趋势。 架构师在大家的印象中是技术上很有深度的，所以我从转型架构师之后，陷入的第一个误区就是过于追求技术的深度。时时抱着Dubbo，RocketMQ，Spring甚至JDK的源码硬啃。时时有所收获，但是投入的大量时间和精力让我在大量的未知中渐渐迷失。

追逐潮流

2017年是Spring Boot和Spring Cloud相关技术飞速发展的一年，我投入了大量的时间调研和使用相关的产品，跟踪最新的发布进展和新增特性，试图推行并取代以往的Dubbo，并且遇到了重重困难。等我终于意识到，工具/框架是手段而不是目的，那些沉没成本已经找不回来了。

脱离业务

也许与我们公司重线下的业务场景有关，有很多时候，开发要直面一线的业务员，解答他们使用过程中遇到的各种问题。因为保受打扰的工作环境十分让人不适，所以自然而然，借着架构师这个与业务听起来没有瓜葛的岗位，我在很长的时间里面，都不再与业务方有业务实现上的沟通，沉浸在上面两点中。脱离业务方也直接导致自己的工作在业务方没有任何直接的体现，看不到自己打造的东西得到别人的期盼或者认可，乐趣自然而然的缺失了。

脱离团队

因为从业务的脱离，自然而然的，与各个业务团队也慢慢脱离。当自己是业务开发的时候，业务跟各方都有接触，所以大家都相互了解和认识，有问题大家都会坐一起讨论，有疑问别人会来寻求解答，这种愉快的协作氛围，随着团队成员的更迭慢慢淡去。

无法推动

各个业务团队在项目DeadLine第一的业务氛围下，对于架构组尝试推动的一些新的技术或者标准都反响冷淡，让我在跟众多团队中的协作也开始身心俱疲。

破局

让我醍醐灌顶的，在QCon上的众多大牛演讲中提到的优良的经过工程实践的架构理念功不可没， 更归功于安姐和她的书。

团队目标的制定

相对于我们采用的KPI体系，硅谷普遍采用OKR的方式更显科学。整个公司的利益是最先需要被考虑的，然后逐步分发到各个业务团队。架构组的目标不应该是从自身的角度出发，产出多少的中间件，得到多少的技术提升，而是在对整个公司业务的推动力。

标准化的重要

在以往推送的各个标准中，我总是最嗤之以鼻的，认为多样性和灵活才是最酷的。但是在QCon上各大团队的工程实践和安姐的切身经历，都说明了标准的重要性。在敏捷开发和持续交付，质量跟踪，运维难度上，标准的开发和项目体系能够带来数不清的好处。

沟通和协作

一个人能实现的东西是很有限的，一个团队总要依托于其他多个团队。 沟通力此时显得尤为重要。将当前做的事，需要得到的配合准确地传达给整个团队，不管对自己还是对整个团队都是有益的。