成为架构师的一些关键思考和经验

  如何更高效的学习?

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

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

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

  说说自己提升学习效率的心得,其实非常简单:体系化的学习

  我曾经很喜欢看一些博客或者是一些 “看起来” 比较通俗易懂的文章,每天在微博微信里刷到什么技术文章就 mark 下来,基本上几分钟就能读完。可一段时间下来,虽然读了不少东西,但是还是有种在原地打转的状态,并没有感受到有什么实际的提高。

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

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

  你是怎么知道这些的?

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

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

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

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

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

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

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

  架构师应不应该写代码?

  似乎隔三差五就能看到一些关于架构师应不应该写代码的文章。我是属于写代码派,因为我本身就喜欢写代码。但是,当工作职责发生变化之后,如何保持写代码和其它工作之间的平衡就成了问题。

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

  但作为架构师,参与写代码还是会有一些不大不小的收益。

  一般来说合格的程序员对于明确分配的任务会完成的很好,但是大部分情况下 “架构” 这个词意味着架构师并不会涉及太多细节,架构图和代码实现之间总还是有些距离,你无法保证所有人都会正确的理解你的设计,或者是程序员写代码时遇到障碍时会立刻想出足够优雅的解决方案。

  大部分烂代码并不是架构师的设计问题,如果程序员没能很好的理解设计或者是经验不足,往往会做出一些非常匪夷所思的东西。比如我见过刚毕业的程序员为了防止模块耦合而将耦合的代码又拷贝了一份,或者为了 “优化性能” 而尽量把所有逻辑写在一个函数里。

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

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

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

  实践:开会是个技术活吗?

  我觉得应该没有人喜欢开会。但是会议邀请就这么一个个的跳了出来:开发需求要跟产品开会、项目方案要跟技术开会、新人转正要去开评审会、别的公司来了几个大牛正在开分享会、出了故障要开总结会、小组有周会、部门有周会,大项目每周开两次碰头会不过分吧?小项目启动的时候开个会不过分吧?调试的时候发现有个坑大家赶紧讨论讨论吧?

  有时候参加的会议整场下来跟我毛关系都没有,全程神游俩钟头,最后突然有人一拍桌子:” 还有问题没?好,散了!“

  也有可能有个什么会没叫你,过了俩礼拜突然收到封邮件催开发进度,” 当时那个会你没参加,大家都说应该是你们做……你没看会议纪要吗?“

  吐槽了这么多,但我还是认为开会是个技术活,对于架构师来说尤其如此。

  大多数技术人员开会并不是那种新闻里的工作汇报或者长者们的会议,他们真的需要通过开会讨论一个具体方案,或者解决什么具体问题。可惜的是我参加过很多会议,大多数的会议都是在毫无意义的交流中浪费时间:几方人坐在一个屋里互相说一些对方理解不了的话,最后得出一个” 我们会后再捋一捋 “之类的结论。

  这并不是会议才有的问题,在程序员日常的沟通中,也有很多人并不懂得如何交流,比如偶尔会收到一些写的非常认真的邮件,打开之后是密密麻麻的一屏幕文字,但是从第一句开始就不知道他在说什么,后面的东西连看的动力都没有了。

  大多数时候,沟通的核心不是你说了什么,而是你想要让对方了解什么、让他做什么。良好的沟通能在工作中显著提升效率,但很多人忽略了这个事情。

  想要恰到好处的进行沟通是一件不那么轻松的事情,但是简单来说有几条原则:

  确保各方对背景的理解一致,比如开会之前先简单通过邮件交流一下,对新加入会议的人花个 30 秒钟做个前情提要,或者在讨论过程中让对方说一下他的理解。

  去掉对方不能 / 不需要理解的内容,比如跟产品说 “这个队列在高并发下因为锁的实现有问题导致 CPU 性能瓶颈” 不如改成 “我们发现了性能问题,持续 10 分钟了,10 万用户收不到运营发的无节操广告,大概 5 分钟后扩容解决”。

  确保在对方失去注意力前尽快说出重点,比如排查问题的总结邮件,如果第一段是这样:“某某框架内部使用的是 xxx 技术,这个技术的架构是这样:blabla”,那么对方可能完全不知道你在讲什么。可以换成这样:“我发现了某某框架的 bug,需要尽快升级,否则在 xxx 情况下有可能会出现 yyy 问题,具体排查过程如下:blabla”。

  不要说没有意义的内容浪费其他人的时间,比如” 这需求做不了 “或者” 这里不可能出 bug “,没有人想听到这些废话。

  为什么别人的代码如此的糟糕

  很多程序员解决问题的能力很强,说要解决一个什么问题,下午就能写出几百行代码把功能实现了。但是做出来的东西有种少考虑了什么东西的感觉,我花了挺久去想一个词去形容 “这个东西”,最后想出了个勉强可以表达的词:程序的生命力。

  大部分程序都能实现功能,但是如果把 “时间” 这个也作为一个考虑的维度的话,就会意识到一个合格的项目需要考虑更多的东西:更通用的使用方式、易于理解的文档、简单而易于扩展的设计,等等。而想要毁掉程序的生命力也很简单:做的更复杂,更定制化,让更少的人参与。

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

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

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

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

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

  一小部分人立刻能给出优化后的版本,甚至我连续问几次之后,他能给出好几个优化后的版本;另小一部分人会斩钉截铁的说优化不了了,就这样了。但是大部分人会犹犹豫豫的说出一些完全不着调的回答。

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

  “你要解决什么问题?”

  “还有更好的办法吗?”

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

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

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

  “你解决的是什么问题?“

  ” 还有更好的办法吗?“

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

  成为架构师最困难的门槛是什么?

  跟一些程序员交流的过程中,有不少人问我要怎么成为一名牛逼的架构师。

  我最近几年面试的人挺多,发现一个有意思的现象:很多人自称架构师的人跟你讲一个架构时简直滔滔不绝,各种技术名词像是说相声一样从他嘴里说出来,三句话不离高并发大数据,但是稍微追问一下,就会发现很多基本概念的缺失,例如自称精通高并发的人说不清楚他所谓的高并发系统的瓶颈在哪里,自称精通架构设计的人说不明白他的系统怎么保证高可用,自称超大数据量的系统实际上只有不到 100 万条数据,等等。

  架构师虽然听起来很高大上,但本质上仍然是工程师,不是科学家,也不是忽悠人的江湖骗子。学习再多,也需要实践落地。设计架构方案更多的是在做一些抽象和权衡:把复杂的需求抽象成简单的模型,从功能、性能、可用性、研发成本等等方面规划如何构建一个系统,这些内容需要更多的实践练习。

  所以我认为在架构师(和其它很多)的工作中最重要的部分是实践,夸夸其谈很容易,与其拽一些技术名词,不如把你正在做的系统真正的做好。

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

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

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

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

时间: 2024-11-03 03:25:28

成为架构师的一些关键思考和经验的相关文章

CSDN日报20170509 ——《互联网时代架构师的职责与思考》

[程序人生]互联网时代架构师的职责与思考 作者:木小鱼 在当下的互联网时代,架构师是互联网行业的热点关键词,人云亦云者居多,那互联网架构师到底是做什么的,如何来评价互联网架构师的优劣呢? 点击阅读全文 [Android]手把手教你构建 Android WebView 的缓存机制 & 资源预加载方案 作者:Carson_Ho 由于H5具备 开发周期短.灵活性好 的特点,所以现在 Android App大多嵌入了 Android Webview 组件进行 Hybrid 开发,但我知道你一定在烦恼 A

全栈软件工程师和系统架构师的异同

看完后.发现.不用怕....因为程序员不会看完.只有"架构师"才有耐心看这么长的. 一 每个好架构师都是一位出色的程序员(卓越的程序员) 架构师,听起来是如此神秘的一个称号.尤其是在开发领域刚入门不久的菜鸟级程序员眼中,架构师都是高手,都是牛人,都是如此高高在上的存在. 不过,在搞了四.五年编程之后,程序员们往往早已失去了当年对这些"高级"职位的神秘感,甚至会对自己所在项目的架构师抱怨不已,背后里称他们是一群水王.所以有江南白衣曾撰文述说:"国内的架构师到

普通程序员,三年成为年薪70w架构师,只因做到了这些

每个程序员.或者说每个工作者都应该有自己的职业规划,如果你不是富二代,不是官二代,也没有职业规划,希望你可以思考一下自己的将来.今天给大家分享的是一篇来自阿里Java架构师对普通程序员的职业建议,希望对你有启发. 程序员的三个阶段 第一阶段---三年 我认为三年对于程序员来说是第一个门槛,这个阶段将会淘汰掉一批不适合写代码的人.这一阶段,我们走出校园,迈入社会,成为一名程序员,正式从书本上的内容迈向真正的企业级开发.我们知道如何团队协作.如何使用项目管理工具.项目版本如何控制.我们写的代码如何测

7年iOS开发,自述通往架构师的修炼之路【精华篇】

前言: 本篇文章仅供大家参考学习以及在成为架构师的道路上应该掌握的知识点和经验.相信你在看完这篇文章后,你有一个明确的目标以及一个通往架构师路上正确的方向. 导读: 1.架构师应不应该写代码 2.为什么别人的系统总是那么烂 3.成为架构师最困难的门槛是什么? 4.如何更高效的学习? 5.面对目前流行的技术不知如何下手? 6.一家公司待久了,过得很安逸,但跳槽时面试碰壁? 7.觉得现在的技术基础感觉到很扎实,但就是自己的技术提升不上? 8.觉得自己很牛B,一般需求都能搞定,但是所学的知识点没有系统

阿里P7架构师:通往架构师路上的经验总结

困扰架构师日常问题 架构师应不应该写代码为什么别人的系统总是那么烂成为架构师最困难的门槛是什么?如何更高效的学习?面对目前流行的技术不知如何下手?一家公司待久了,过得很安逸,但跳槽时面试碰壁?觉得现在的技术基础感觉到很扎实,但就是自己的技术提升不上?觉得自己很牛B,一般需求都能搞定,但是所学的知识点没有系统化,很难在技术领域继续突破?现在觉得自己技术还可以,但就是薪资涨不上去? 以上这几点,做为开发人员的你们,有遇到过么?有为自己想过么?有细心仔细的去解决过这些问题么?有深刻的想过么?虽然这几个

资深大牛分享:一个合格的Java程序员如何成长为优秀的架构师

踽踽独行上下求索总是痛苦,如果有良师益友陪伴点拨必能事半功倍.从新手码农到高级架构师,要经过几步?要多努力,才能成为为人倚重的技术专家?本文将为你带来一张程序员发展路径图,但你需要知道的是,天下没有普适的道理,具体问题还需具体分析,实践才能出真知.资深大牛分享:一个合格的Java程序员如何成长为优秀的架构师如果大家如果在自学遇到困难,想找一个java的学习环境,可以加入我们的java学习圈,点击我加入吧,会节约很多时间,减少很多在学习中遇到的难题. 我认为,架构师的内功主要包含三部分:判断力.执

三年成为年薪70w架构师,只因做到了这些。果然不是一般人

每个程序员.或者说每个工作者都应该有自己的职业规划,如果你不是富二代,不是官二代,也没有职业规划,希望你可以思考一下自己的将来.今天给大家分享的是一篇来自阿里Java架构师对普通程序员的职业建议,希望对你有启发. 普通程序员,三年成为年薪70w架构师,只因做到了这些 程序员的三个阶段 第一阶段---三年 我认为三年对于程序员来说是第一个门槛,这个阶段将会淘汰掉一批不适合写代码的人.这一阶段,我们走出校园,迈入社会,成为一名程序员,正式从书本上的内容迈向真正的企业级开发.我们知道如何团队协作.如何

一名资深架构师规划Java程序员五年职业生涯指南

每个程序员.或者说每个工作者都应该有自己的职业规划,如果你不是富二代,不是官二代,也没有职业规划,希望你可以思考一下自己的将来.今天我给大家分享的是一篇来自阿里大牛对五年工作经验程序员的职业建议,希望对你们有启发. 第一阶段: Java程序员 Java初级程序员 第一阶段我认为对于程序员来说是第一个门槛,这个阶段将会淘汰掉一批不适合写代码的人.这一阶段,我们走出校园,迈入社会,成为一名程序员,正式从书本上的内容迈向真正的企业级开发. 第二阶段: Java中级程序员 企业标准程序员 第二阶段—又是

为什么你总成为不了架构师?

背景: 今天接到一个哥们儿的电话,说,非常郁闷,想和我聊聊. 我问,有啥郁闷的事情啊,说来听听. 他说,近期非常郁闷,我本来今年的计划是成为一个架构师,可是,不管怎样努力,都不知道为什么,感觉希望非常渺茫... 这哥们儿事实上是一个非常努力的家伙,以前是我Team里技术最好的程序猿,对一个技术不钻明确不罢休的那种程序猿. 我给他电话里说了说我一直想说,但一直都没有时间说的话,那就是:为什么你总是成为不了架构师? 一.什么是架构师? 事实上架构师的概念并非从程序开发专业一诞生就有的职位概念,架构师