从“菜鸟”码农到“资深”架构师，我到底经历了什么？

不念不忘少年蓝@ 2022-12-31 06:18 128阅读 0赞

工作了挺久，发现有个挺有意思的现象，从程序员、高级程序员，到现在挂着架构师、专家之类的头衔，伴随着技术和能力的提高，想不明白的事情反而越来越多了。

”

这些疑问有些来自于跟小伙伴的交流，有些是我的自问自答，有些到现在也想不清楚，这篇文章就来写一写这些问题。

![4ffce448e8d029c51ce6f0cf51ca1799.png][]

如何更高效的学习？

很多新人程序员一开始在学习上找不到方向，但我想在渡过了一段时间的新手期之后，这类问题大多都会变得不再那么明显，工作的方向也会逐渐变得清晰起来。

但是没过多久，能了解到的资料就开始超过每天学习的能力，像是买了没看的书、收藏没读的贴、Mark 了之后再也没有关注过的文章越积越多，更别提每天面对各种技术分享或者微博里的新鲜玩意了。

大多数人每天能留给自己学习的时间有限，这个阶段如何提升学习效率就成了要解决的重点。

说说自己提升学习效率的心得，非常简单：体系化的学习。

我曾经很喜欢看一些博客或者是一些“看起来”比较通俗易懂的文章，每天在微博微信里刷到什么技术文章就 Mark 下来，基本上几分钟就能读完。

可一段时间下来，虽然读了不少东西，但是还是有种在原地打转的状态，并没有感受到有什么实际的提高。

最后实在忍不住，抱着厚书硬啃了一遍，突然有种豁然开朗的感觉：读书时自己学到的是一张完整的知识网络，每个知识点和其它内容相互联系和区别。这种全方位的理解比起一篇篇独立的文章，不知要高到哪里去了。

而读了一段时间书之后，渐渐原本不在一个体系之内的知识也会慢慢联系起来，比如说后端服务的开发，简单梳理一下，就成了这样：

![8d379e35438b8ff33b4f5093c7e82be5.png][]

在重复了几次痛苦的学习-梳理过程后，再去看一些独立的文章或者资料往往会事半功倍，因为能在体系内找到相对应的知识，甚至有时候一本书里一页只需要看一句话，点破那层窗户纸，就可以掌握新的知识。

你是怎么知道这些的?

工作中总是会遇到各种各样的问题，有几次把问题处理过程总结了一下，发了出来，之后就像滚雪球一样，有越来越多的小伙伴来咨询问题。

比如说：前一阵帮忙排查一个性能问题，系统压力稍微一大就会频繁 FullGC，压力降低之后又恢复了。

某个小伙伴接入代码质量检查系统之后发现每次构建会报一个莫名其妙的错误，打不了包。

某次代码有 Bug，小伙伴跑来来问我 git 怎么才能回滚代码。

每次查完这种问题的时候，一些刚毕业没多久小伙伴们就会用一种崇拜的眼神看着我，然后大多会问：“你是怎么知道这些的?”

实际上，虽然我一直在不断的学习，但是面对工作中无穷无尽的新问题，大部分问题还是会命中我没有掌握的那部分区域。每次有人问到我不了解的知识时我都会非常开心：还有什么比带着问题学习更有效率的学习方法呢?

而且幸运的是，在建立了自己的知识体系的基础上，学习新的知识通常都能很快的上手，解决一个问题往往只需要多了解一个知识点而已。

举个例子，频繁 FullGC 的问题，以前查过很多次 GC 的问题，大多数是 Java 程序或 JVM 内存泄露问题，而这次内存没有泄露，GC 吞吐量也正常，那么我只需要查一下如何查看一段时间内创建的最多的对象的方法就可以了。

回到刚才的问题，小伙伴们问我：“你是怎么学到这些的知识的?”

答案是：在你问我问题之后现学的。

架构师应不应该写代码?

![72d58d9d24831f55c2ddb153ad996eb5.png][]

似乎隔三差五就能看到一些关于架构师应不应该写代码的文章。我是属于写代码派，因为我本身就喜欢写代码。

但是，当工作职责发生变化之后，如何保持写代码和其它工作之间的平衡就成了问题。

从个体效率上来看，我自己亲自写代码，和很多人相比没有什么绝对优势，甚至有些人码代码的速度比我还快一些。

但作为架构师，参与写代码还是会有一些不大不小的收益。一般来说合格的程序员对于明确分配的任务会完成的很好，但是大部分情况下“架构”这个词意味着架构师并不会涉及太多细节。

架构图和代码实现之间总还是有些距离，你无法保证所有人都会正确的理解你的设计，或者是程序员写代码时遇到障碍时会立刻想出足够优雅的解决方案。

之前写过一篇关于烂代码的文章，大部分烂代码并不是架构师的设计问题，如果程序员没能很好的理解设计或者是经验不足，往往会做出一些非常匪夷所思的东西。

![356bfa0bcdedabcb6ad7f1f7ecebc1e2.png][]

比如我见过刚毕业的程序员为了防止模块耦合而将耦合的代码又拷贝了一份，或者为了“优化性能”而尽量把所有逻辑写在一个函数里。

如果不能及时发现并改正这些问题，那么这些地方就会变成“正确的错误代码”，或者“不是我写的”代码，或者“我靠我也看过那段代码”之类足以被挂上耻辱柱的玩意。

这种问题算是架构师的责任吗？作为一个视名声如命的架构师，我认为是的。

在我看来，写代码的架构师更像是在做后勤保障的工作：在代码中第一时间发现可能存在的问题，向其他人提出警告；或是给予其他人改进的意见，必要的时候给其他人演示一下正确的姿势。

大部分情况下我作为架构师并不需要揽下“核心模块”开发这种工作，毕竟我能调配的时间太零散了，效率难以保证，很多人在专注的情况下比我做的好很多，我只需要保持大局观，需要时适度参与就可以了。

总的来说，架构师和程序员在某些方面上有点像产品经理和用户的关系，大部分程序员并不会主动告诉你他们想要什么、哪里需要优化，甚至自己也不知道这些。想要做出好的产品，捷径之一就是跟用户做同样的事情。

为什么别人的系统总是那么烂？

很多程序员解决问题的能力很强，说要解决一个什么问题，下午就能写出几百行代码把功能实现了。

但是做出来的东西有种少考虑了什么东西的感觉，我花了挺久去想一个词去形容“这个东西”，最后想出了个勉强可以表达的词：程序的生命力。

大部分程序都能实现功能，但是如果把“时间”也作为一个考虑的维度的话，就会意识到一个合格的项目需要考虑更多的东西：更通用的使用方式、易于理解的文档、简单而易于扩展的设计，等等。

而想要毁掉程序的生命力也很简单：做的更复杂，更定制化，让更少的人参与。

我跟很多程序员提过程序的生命力，比如说要让自己写的工具的操作方式跟其它 Linux 命令类似，或者要用一些更容易理解但不是性能最优的设计方式，又或者要他去参考现在业界主流的做法，很多人认为提这种需求的意义不大，我觉得这里还是举个例子吧。

很多公司应该都会有一些遗留系统，它们庞大、笨重、难用、几乎无法维护，所有人都在抱怨这些系统，并且每天都在想方设法换掉那些遗留系统。

但是一段时间过去之后，又会发现身边的新人又开始吐槽当时替代遗留系统的那个系统了。

“大多数系统当初都很好使，功能当时够用，扩展性看起来也可以，但是这些系统都是开发的人离职之后变坏的。”

还有更好的办法吗?

成为技术专家之后的工作可以说是痛并快乐着，会有很多人找你咨询问题，另一方面，会有太多人找你咨询问题。

甚至有一段时间，我每天的工作就是解答问题，小到工具使用，中到疑难 Bug，大到架构设计，从早上到晚上基本都是在给各种各样的小伙伴提供咨询服务。

我很快发现有些地方不对头：有些问题实在是太简单了，以至于我甚至都不用思考就可以给出答案，为什么会有这种问题？

后来我在每次回答之前先问一句：

“你还有更好的办法吗？”

一小部分人立刻能给出优化后的版本，甚至我连续问几次之后，他能给出好几个优化后的版本；另小一部分人会斩钉截铁的说优化不了了，就这样了。

但是大部分人会犹犹豫豫的说出一些完全不着调的回答。

后来我改成在每次回答之前先问两句：

“你要解决什么问题？”

“还有更好的办法吗？”

效果好了很多，很多小伙伴发现要解决的问题并不复杂，只是做法跑偏了。

再后来我改成了在每次回答之前先问三句：

“他们要你解决什么问题？”

“你解决的是什么问题？”

“还有更好的办法吗？”

现在第三句已经很少问到了。

我和大牛之间有多少距离?

跟很多人一样，刚毕业时我觉得作为程序员，只要努力，加上少许天赋便可以获得一些成绩。

工作一段时间后，对自己和其他人的认识也越来越清晰，逐渐的发现程序员之间的差距或许比人和猴子之间的差距还大，接受这个事实让我郁闷了很久。

再过一段时间，发现自己已经能够客观的评价自己的能力，也意识到了距离并不是那么重要，只要想办法跑的更快，就足够了。

[4ffce448e8d029c51ce6f0cf51ca1799.png]: /images/20221120/c6379f8c17b04064bc4b424acd779d27.png
[8d379e35438b8ff33b4f5093c7e82be5.png]: /images/20221120/5190c47468e74c70a90b5990fdf85596.png
[72d58d9d24831f55c2ddb153ad996eb5.png]: /images/20221120/b536081fc8c44fd1af7fafed5ab07bb1.png
[356bfa0bcdedabcb6ad7f1f7ecebc1e2.png]: /images/20221120/3a9efc1f63944ca7b1b265d0c471d8fe.png