前端架构师的职责
没有文档的代码 = 放弃治疗
作为前端架构师, 首先要解决的问题就是让日益膨胀的代码可控,因此你需要 梳理代码, 建立架构, 组织文档, 管理架构的更新和维护, 评审技术方案对架构的影响, 核心模块的方案设计, 重点项目的方案设计, CodeReview 等.
架构师和资深开发在工作职责上有着明确的界限, 在一个没有架构师的团队, 每一个资深开发或多或少都承担了一部分架构的工作, 但都是破碎的, 不成体系而且不统一, 从某种意义上讲, 这种隐晦的架构还不如没有架构. 所以确立一名架构师, 从管理上也是将混乱统一的唯一途径, 在团队还小的时候, TL 可能会默认承担架构师的角色, 但团队规模增长到一定程度, TL会变得力不从心起来, 将工作分给专业的人, 永远都是工程上自然而然的结果.
相比实际的 coding, 用一段代码解决某个问题, 实现某个需求, 架构要复杂和烧脑的多, 本质上工程的问题, 只能用架构解, 而没法用代码解, 所以没有架构, 谈不上工程化. 因此架构师的第一要务, 是梳理代码确立架构
把前端架构立起来
在立起来之前, 我们首先要明确, 树立前端架构的作用, 当你担负起架构师的职责, 你可能首先面对的就是代码, 各种老代码, 我们着手去树立前端架构, 本质上就是要将代码隔离在各自的区域之内, 为接下来的工作打下基础.
因此第一步, 我们先要找出所有属于你团队的代码, 大到 git 仓库, 小到某段逻辑, 事无巨细, 我们把这个工作可以称为 "技术资产盘点".
等盘点清楚了技术资产, 就是第二步, 编写资产白皮书, 以文件为单位把所有的技术资产说清楚, 每个文件都是干嘛的, 资产白皮书非常重要, 这个将是你日后架构维护工作的核心.
第三步, 手上有料, 事情就好办了, 文件已经说明了解决的问题, 按照问题域和技术域, 对文件进行归类, 最后得到的就是现状, 99%的情况下, 现状都应该让你沮丧, 因为看起来就是一坨 shit. 但是这就是你要面对的 "shit 架构".
接下来考验架构设计能力的时候到了, 把 "shit 架构" 画成你心中的架构, 两者之间的路线图, 结合现状, 结合业务, 结合团队, 做出迁移的方案, 这些都做完, 你就成功的把前端架构给立起来了, 这个过程中你可能不需要写多少代码, 你要完成的都将是新架构中的核心功能的代码.
前端架构就是你的孩子, 你要保护他
如今你眼前的架构看起来应该不错了, 作为架构师你的职责就是保护他, 在你没有想到什么金钟罩之类的秘籍之前, 你只能用你的肉体了, 自己设计技术方案, 或者参与技术方案的评审, 在 CodeReview 中找出任何可能污染架构的代码, 总之你的核心工作是, 确保代码和架构设计之间的联系的真实性, 这部分工作往往体现在你如何高效的维护文档和 CodeReview, 这里有个小提示, 你的架构设计的越棒, 这部分工作就越轻松, 如果这部分工作让你疲惫不堪, 那你可能需要重新审视你的架构设计了. 另一部分来自于外部, 毕竟 CodeReview 是最后的保障手段, 但真正的防御应该是在设计之初, 任何对架构的修改, 在设计阶段就应该被你的火眼金睛察觉到那些不好的味道, 然后通过修改, 隔离等各种方式防止对架构的破坏和污染.
总之, 保护好你的架构, 无论他有多烂, 总比没有强, 等你的架构变得健壮而灵活, 带给团队的收益将远超你的想象.
作者：柳郎中
链接：https://www.jianshu.com/p/42775438004d
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。