论架构师的职责

好久之前（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。

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