架构师成长之路: 架构师初体验

Posted 2023-02-20 玄道公子

​ 说起架构师，给人的印象就是高高在上，在象牙塔的顶端，一点都不接地气。 作为一个工程师，笔者之前对架构师也有类似的看法，感觉他们又不干实事，就是画画框图，写写PPT就完事儿了。

​ 万万没想到有这么一天，笔者自己也即将踏入架构师们的世界。对笔者来说，架构师的世界一切都充满了新鲜感，同样的作为一个工程师对一切新鲜的事物都充满了好奇，都想去把它弄的明明白白，清清楚楚的。

​ 在这之前，笔者虽然读了一些软件架构方面的书籍，但是并没有从事过架构师这个职业或者说角色。笔者认为，作为一个架构师就是要理解好需求，设计好软件的架构，分好模块，产出文档，然后就结束了，接下来就是工程师们的事情了。

​ 带着这样的认知，笔者来到了新公司，以架构师的身份加入到了一个新的团队。 两周下来，和前面进来的其他架构师同事聊了很多， 他们也跟笔者讲了不少东西，当然基本都是当前项目相关的东西，并没有涉及到架构设计之类的技术话题。通过这些接触以及笔者的观察，虽然时间还不长，但是也有了不少收获。笔者不清楚其他公司的情况，只是就笔者目前所在公司所得到的启发。

​ 其一、 架构师并不是孤立存在的，一般来说稍微复杂一些的应用软件或者软件系统都可能不止一个架构师，很可能是一个架构师团队，只有这样才能覆盖到一个复杂软件系统的方方面面。

​ 其二、 架构师这个角色，并不只是使用UML，C4模型、4+1视图等撰写出架构设计文档就结束当前项目的工作了。 相反，当架构设计出来之后，一切才刚刚开始。 架构师除了要设计架构之外，还需要确保软件架构能够被正确的实现。 比如笔者所在的汽车电子电气软件开发行业，一个功能需求，往往需要多个组的团队，甚至是多个公司的团队来协作完成。 因此架构师还需要具备的一个能力就是交流的能力，因为在实际的开发过程中，每个团队可能都想自己这边负责的越少越好，所以，架构师就有必要协调好团队之间的分工合作。 听笔者工作的架构师同事说，有时候一个feature，可能在几个团队之间像踢皮球一样踢来踢去，这个时候他就得一遍一遍的去游说这些团队，直到能够“和谐”的完成这个feature为止。

​ 其三、 这一点笔者之前在一些架构设计的书籍上也看到过，不过经过这两周的观察，更深刻的明确到了这一点， 那就是软件架构并不是大型的预先设计，它和软件开发一样，也都是不断的迭代，一步一步的演化出来的，并不能一蹴而就。 就拿笔者所在的团队目前的项目来说，不少需求都是陆陆续续的加上来的，这样的话如果有新的需求来了，而这个需求的实现，有需要一些其他的技术方案，那么这个时候架构师需要参与方案的评估，需要根据功能需求和约束条件来权衡选择合适的技术方案。又比如，一个技术方案在开发实现的过程中，有些意想不到的的并发性(这里的并发不是并发访问，而是像并发症一样的概念)问题或者之前某些没有考虑到的地方爆发出了新问题，发现了新隐患等等，这些可能都会导致重新评估技术方案，也都会需要架构师参与进来主导多团队共同改进方案或许验证新方案。

当然笔者在目前的团队当中也发现了不少问题，比如目前的团队当中架构师组基本上都是各个部分的专家转变而来，比如BSP啊，系统啊等等。 又比如，整个软件团队(架构师，软件开发，集成，测试等)的分工并不那么明确。 特别是软件开发团队，给笔者的感觉除了分工有些混乱之外，还有整体的软件开发能力偏弱的问题。 虽然是新建团队，但这原因并不能掩盖工程师水平偏弱的问题。 还比如，软件团队在文档这一块也是比较混乱， 笔者翻来覆去的查看团队的文档仓库，发现不少问题：

• 文档混乱，目录多且杂， 还存在不少重复，比如在不同的目录下存放了相同的文档
• 文档虽多，但是说实话，并不能起到文档的作用，比如，笔者翻看了很多模块的HLD(High Level Design)和DD(Detail Design)发现虽然这些文档里面画了不少use case图，BB(Black box, 就是把模块当做黑盒子，设计与外部的交互)，与之相对应的就是WB(White Box，软件的白盒子，就是设计内部结构)。 还有时序图，状态图。 但真的是看的笔者一脸懵逼， 完全不知所云，错乱的use case， 杂乱的wb， 奇奇怪怪的状态图等等。虽然有这么多文档，但神奇的是，笔者居然没有找到接口文档，一个模块(比如是一个Media 的service)，对外要提供哪些接口，有哪些广播事件(或信号), 这些一个都没有。 尽是些花里胡哨没用的东西。 笔者深深的体会到， 软件开发其实不一定需要那么“重”的文档， 如果是模块级别的，可能只需要轻量级的 接口文档，详细设计文档就够了，当然笔者这里说的详细设计和上面说的DD的内容还不一样，笔者以为的详细设计应该是设计 模块内部的各个子模块，明确每个子模块的职责，以及子模块之间的协作关系， 就类似于C4模型中的 组件图一样
• 需求管理不清晰， 笔者东拼西凑了良久， 也没能看到整个系统的“全貌”，因为这里没有一个完整需求文档，不管是产品需求、系统需求，还是软件需求，一个全的都没有，都是这里一点，那里一点。经过笔者在实际的代码和 运行平台上摸索了一圈之后发现，平台上有的一些东西，根本就没有相对应得文档。
• 软件架构的文档，与实际情况不匹配， 很多平台上的东西在软件架构文档里面都没有。 更麻烦的是，因为这些种种文档的缺失，或者不“称职”的文档，导致笔者根本无法确认平台上的各个模块对应的职责是什么，要完成什么样的功能。

洋洋洒洒写了一大篇， 以纪念笔者架构师之路的起航。 笔者并没有想从现有团队上学到多少东西，而是想实践笔者所思所学。 笔者的架构师之路既是一条成长之路，也是一条历练之路。

加油吧，想要成为架构师的朋友们。 虽然目前架构师的名声或许并没有那么好， 但是只要咱们脚踏实地，小步快跑，不断迭代，不断演进，笔者相信咱们总会在这条路上留下属于咱们自己的架构传说。