论架构师的职责

原创
2016/01/31 20:52
阅读数 670

很久以前(4,5年前)当核心码农,只需保质保量完成既定任务。技术选型开会的时候随便yy,反正最后拍板背书的人不是我。完成特定的任务,想算法,做优化,实实在在的产出,很有成就感。 

而最近这几年,开始渐渐提升自己,从架构师,技术经理,到技术负责人。现在开会不敢乱说,技术也不敢乱选。因为要给设计做最终拍板,确定最终的技术架构体系。所以会经常焦虑自己做的设计是不是有坑,是不是太low等等。 

同时在公司有限的资源内,还得决定哪些先做哪些缓一缓。以前我只需要把待做的1234抛出去,具体做啥上头说了算,你说做1我就做1,不用过脑子。现在经常1234都要做,手头的资源只够做2个,优先级还得自己协调,光想这个优先级就头大。

因此在此开贴,抛砖引玉,谈谈自己对架构师职责的理解。

首先,我们应该明确,不同公司对架构师的定位不尽相同,而且也和架构师在一个项目中切入的时间点有很大关系。经历过几家公司的架构师职位,有的是以技术选型,设计阶段给技术团队提供咨询为主;有的则是系统调优,代码重构,性能优化为重;而还有些公司,CTO的设想是,产品经理提产品需求,架构师提重构和优化需求,并且作为顾问参与到所有项目的设计阶段。

在我看来,架构师对公司核心业务,组件化,耦合,解耦的理解程度如何,对新技术保持浓厚兴趣和探索,决定了一个公司在技术演进发展道路上是否会一路坦途。同时,架构师应该深刻理解,架构是被业务推动而发展的。


优秀的架构师在作业时,因为长期经验使然,会自然不自然的留下平滑升级的余地。而不会在这个时间点就引入过多架构问题;在构架之前都需要用采取类似伪代码的形式把问题勾画一遍,这样能让各种关键细节问题浮现出来,然后再去讨论, 否则就是空谈。

架构师不会关注细节,但是架构师需要知道有bug或者性能问题(有人告知或者线上表现观察出来),然后别人用的时候给出建议。具体为什么有bug,如何做算法优化,架构师可以不用太深究。架构师关心的是更high level的大模块之间的关系。当然也有公司要求架构师切实可行的钻研进去,做好各种优化和调优工作,颇有点救火队员的角色扮演。这种情况的出现,显然是前期项目协调和产出产生了较严重的问题所致。 

当然自己做实现也有个抽象和分层的问题,我觉得这个问题在不同层次上是同构的。网站级别的架构和模块内部的架构,道理和方法是一样的。 

不过我想说的重点就是,要抵制那些过度微观的工程倾向,从来不做API评审,但是code review 抓的很紧,这就属于本末倒置,code review本来就是一个微观的东西,你写的东西leader评价再好,格式再优美,higher level上是一坨就不行。 

我认为在各个层面上,能控制界面层就很好了,内部实现是实现的问题,这个在上一层可以系统的解决,比方引入稳定性和性能反馈,你做个变更我看下好了还是坏了,到变更这个层次,结论就很强了。

大体上,宏观指标好的,也更可能是fixable的,反过来,不fixable,但是宏观指标好,你也没必要去深究,最多这块重写。


最后,一个现实问题,架构师应不应该参与编码呢?架构师如果完全不做编码,时间长了以后自己的知识如何持续更新,与时俱进才是最大的问题,而且我觉得这基本上是无解的。更坏的情况是,有些架构师自己的知识懒得更新,所有新的事物,一律要别人往他知道的东西上套。这时候谁还服你,只能是you can you up。

所以,我不认为脱离编码去搞架构是一件好事。也不认为脱离业务去搞技术框架是一件好事,最好还是一边干,一边搞这些东西。建议适当编码,目前我每周仍抽出时间看看代码偶尔也编码,实际工作中,可以进行业务和非业务核心层的编写。


展开阅读全文
打赏
2
26 收藏
分享
加载中
我们公司只要求会吹牛逼,不懂技术也没有关系
2019/10/03 18:47
回复
举报
赞\(≧▽≦)/赞
2016/02/01 22:16
回复
举报
深有同感
2016/02/01 00:07
回复
举报
更多评论
打赏
3 评论
26 收藏
2
分享
返回顶部
顶部