论架构师的职责

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