一、背景

最近读了一篇非常不错的文章《我对技术架构的理解与架构师角色思考》。
非常推荐大家也读读。
下面简单记录下对此文的一些感想。

二、读后感

2.1 概况

1 文中【架构师角色】这一块讲得非常透彻。
架构师需要大量的实践和知识的积累，身边的架构师都计算机底层原理了解的都很透彻，都有多年的编程经验。
文章提到“用新的方法解决新的问题”这一点完全认可，其实我们这个行业除了极个别场景，大多数新的问题都可以用旧的方法来解决。
比如分布式架构，本质上就是化整为零，分而治之的思想。领域驱动设计本质上就是加了领域这个中间层，依然是“计算机科学的任何问题都是可以通过增加一个间接的中间层来解决的”。
很多项目管理，技术成长等都逃不过 PDCA 循环，都是不断计划、执行、复盘、纠正等。
我们更应该了解不同方法背后的本质原理，找到问题的共性，通过经典的方法或者经典思想的变通来快速解决问题。
虽然归纳演绎的确是解决问题的好办法，但是很多人会犯教条主义的错误，大家在解决问题时还应该因地制宜，以终为始，适当进行变通。

2 文中【架构师能力】这一块讲到：阿里不缺解决问题的同学，而缺定义问题的同学。这一块的确发人深省。
这一块应试教育要背点锅。大多数人习惯于给题目来解题，并不擅长发现问题、提出并定义问题。
我们还是应该在遇到问题时主动养成寻根究底的思维习惯，这是新的问题还是旧的问题，当前解决办法是治标还是治本的方案，当前暴露出来的问题未来会有什么影响等。
现在越发觉得想往架构师转变不能只扫门前雪，要拥有更宏观的视角。

3 【架构师的挑战】总结的很全面，全局视角、技术广度、持续学习、业务理解、追求结果。
身边见过的架构师他们的确可以理清楚系统和业务架构，能够解决各种技术问题，能够持续学习，能够结果导向而不仅追求技术本身。

2.2 感悟

挺希望自己以后可以转型成为架构师，做一些更有价值的事情。
现在发现这篇文章写得确实不错，也指明了方向，但越来越发现当程序员往架构师方向走的时候，已经不再可以单纯通过几本书、几套视频非常明确地引导你往前走，更多地需要自己去摸索和思考。对于喜欢通过看书、看视频，习惯于通过别人指导、习惯于有标准答案的才能清楚该怎么做的很多人来说非常不适应，甚至迷茫。
尤其现在很多公司业务节奏非常紧，有些同学甚至连双休都无法保障，如何在兼顾业务节奏的同时持续学习，能够带来足够的成长是一个非常重要的问题。
我认为应该有自己的底线和技术追求，否则很容易得过且过，干了几年但是成长并不够快。在编码过程中多一些思考和设计，在每个项目结束后都总结下项目中好的不好的方面，学习同事方案设计的好的地方。此外工作之余巩固专业基础，多读一些经典的图书，在这个过程中不再追求记住内容，而是重点思考为什么这么设计，重点理解背后的依据。可以选取某个技术深挖，然后再触类旁通。一个技术学深之后就和别人比起来有一定的优势，自己也会有成就感，因为有些原理都是相通的，再学其他的也会很容易。
总之还有很长的路要走，对照着文章的一些能力要求，继续努力。

三、其他

附上一个朋友梳理的思维导图