架构师思维

我17年开始从事APP架构师，这是我做技术的梦想职位，感谢宝宝树公司和CTO给我的机会。在成为架构师之前，我主要是负责业务开发，更多是跟着产品需求做开发任务，在平安曾经负责过一个APP开发团队。这两年有同事和陌生网友问我如何成为架构师，有什么书推荐看。我的标准回答是，APP的技术底层原理要比较熟悉，因为要做很多的SDK公共组件，影响面比较大，技术运用准确就显得很重要。对于认真问我这方面问题的人，我还会跟他们补充，做架构师更多是技术思维层面的转变，然后给他们推荐《聊聊架构》这本书。这本书有些人觉得好，有些人觉得太虚，觉得书中内容偏虚的人，我觉得要么还没有准备好成为架构师，要么就是不太明白架构师职能定位的。我甚至认为技术人的两个发展方向——技术专家和技术管理，如果往技术管理方向发展，一定要先做架构师，多数公司的CTO其实可以认为是首席架构师，因为管理职能部分是会被人事、行政部门帮忙分担的，管理属于另外一个职业了，我觉得优秀的公司，管理人的工作相对少些。技术人从事过架构师岗位的锻炼，会让他的思维产生变化，他因此能从更抽象的层面去看待技术，看待业务，看待管理，从而有架构的思维去让技术团队帮助业务部门一起达成业务目标，因此更能胜任技术管理工作。

今天我务虚一点，不谈架构师需要掌握的技术，拿APP架构师来说，APP架构师对APP开发中的各类技术栈都得比较精通，这应该是必须具备的能力。我认为架构师和技术专家的起点都得是资深开发，然后再发展出不同的路线。那架构师和专家的区别在哪里呢？架构师职业特点可以认为是对现有业务软件的升级改造，他的职责是去改造优化软件更好地满足现有业务的发展，架构师的职责是用技术面的广度去选择不同的技术栈改造软件来支撑业务发展；而技术专家则是在某个细分领域深度发展，在业务细化要求上通过深度技术运用帮助业务发展，技术专家是用技术深度去服务业务发展。这样点到为止不知道有没有说明白，不想花大篇幅在这方面，因为不是本文的重点，本文重点是介绍架构师思维意识。

目前不知道对架构师的定位大家是不是能达成一致共识，以我了解看好像各个公司对架构师定位是不一样的，有些软件开发为主，有些偏纯架构设计，有些偏技术攻关，有些只做底层SDK，有些会做业务功能封装。从前面一段，我猜测你们明白我认为真正的架构师是什么样子。真正的架构师，所谓架构架构，架构重构是他的核心职责。我认为架构师的最高阶段可能是首席架构师，也就是CTO。首席架构师会管理一个架构团队，里面会有APP架构师、后端架构师、运维架构师、硬件架构师等，这些细化会有侧重点变化，但是核心是架构重构来让软件满足业务发展的需要，这个根本职责应该是相同的。下面就是我要重点说的架构师的思维意识了。

架构师有自觉地服务业务的意识。软件技术人员要懂业务才能做好技术开发。熟悉业务，应该对公司的每个岗位都适用，现实中技术人员容易认为自己是做技术的，而不是做业务的。即使懂得服务业务，这其中也有要求高低之分，一般互联网公司，软件部门应该是强业务部门，所以对业务理解的要求会高点，那架构师，作为一股技术的中坚力量，只能要求更高，最理想当然是与业务部门同步理解业务，甚至预见业务的发展。做软件架构设计的时候，如果清楚业务，比如一家视频直播公司，在架构早期就要清楚，视频录播直播会是公司的业务重点，两个模块要重点的架构设计好，安排精锐的技术人员去做这部分开发工作。当一个业务需求的来的时候，一般开发工程师可能就埋头开始干了，但是架构师可能会根据这个业务需求和目前的架构，以及未来可能业务发展做个推演，会帮一个小的业务需求丰满起来，体现出威力。我最近被一个同事问到一个技术需求，需求他跟我解释完后大致是这样的：我们找抖音大V做了推广，现在通过他的IDFA,看看通过我们的埋点后台能否查到他是否有帮我们的APP做推广，他说目前埋点没有查到IDFA记录是不是哪有问题。我一听这个需求就感觉不对劲，他问我的是伪需求，如果顺着他的思路就很可能浪费时间做一个错误方向的解决方案，因为做推广不一定需要使用APP，这需要看什么推广，这个需求的要点他没有去深究，就在找解决方案，思路不对，IDFA本身可能获取不到，而且跟推广方要idfa我总感觉怪怪的，要账号就可以吧。在我跟他探讨之后发现他他接到需求是如何知道大V帮我们做了推广的效果，而做这个需求，他是需要深究推广大V推广内容的，是推广的APP下载链接还是推广的使用步骤等，毕竟不同的推广内容跟踪方式不同啊。这是一个例子，强烈服务业务的意识，善于发现业务需求要点和问题点的能力。

架构师有软件研发运行中的职责分工意识。一个公司的首先是创始人发起的，他就像是上帝，需要土地于是有了土地，需要水就有了水，需要男人就有了男人，需要女人就有了女人。他招了这么多人就是为了帮他做业务赚钱的。他需要软件服务业务，所以就有了技术团队，软件架构师的出现，是因为软件组织架构需要架构调整，同时可能伴随软件技术人员的组织架构调整。因此首席架构师要负责软件技术的架构，也会负责技术人员组织架构，他可能会拆分给不同的架构师去负责不同的部分，人的调整是为软件架构调整服务的。比如一个APP，现在一个业务需要很强的音视频处理能力，那可能架构师就会需要一个音视频处理大模块，先从原有的APP中已有的音视频中拆分处理，然后强化这个模块，然后去设计模块可能需要的技术职责分工，甚至细化到技术选型，也可能调用一些技术人员过来，招一些技术人员进来，实在没人可用，可能得亲自动手自给自足，这也是现在多数“架构师”会做的事情——SDK（核心底层模块的）开发，甚至可能是唯一做的事情，这也是部分架构师己被当做一般开发工程师在用的尴尬境地的原因——只负责SDK开发，但是没有架构这部分职能，因为有高级或者首席架构师架构设计好了，只需要一个伪架构师去实现而已。但是架构师主要的职能还是架构——软件架构、技术架构、人员架构。因此真正的架构师有很强的软件分工意识，他清楚实现某个业务，软件如何拆分模块、模块如何分工，每个模块应该负责什么角色，这个角色有什么技术难点，技术选型有哪些优点缺点，如何使用技术人员去实现技术，通过这些架构调整和资源调配来更好的实现软件，最终实现满足业务需要。至于更快更好更高效更强，这是人类永恒的追求，这又是另外一个境界了。

架构师有软件生命周期的发展意识。软件不同的声明周期有它不同的特点，比如在婴儿期——软件孵化期，这个阶段的重点是什么？我觉得应该快速按照业务核心实现一个功能软件原型，这时候强调的是高效迭代，堆出重点业务功能，这时候如果架构师说要做一个性能监控SDK，要做一强大的网络模块，要做个强大埋点系统，那有意无意会分散团队的注意力，浪费大量的时间和资源，甚至导致项目死亡。再比如我们经常会听到某某公司多次出现大量访问导致的宕机，这个阶段的软件处在高速发展的运营和研发并行的周期，显然架构师没有把软件从研发周期顺利向运营周期过度好，没有把软件改造优化支持高并发的架构重组做好，没有拆分更专业的运维团队，没有把软件从研发环境、到测试环境、到生产环境架构设计实现清晰分工明确等。架构师应该要经历过软件运行的生命周期才能做好架构，它要清楚软件在不同阶段的重点。婴儿期强调业务功能实现、运营期强调技术服务及时响应和应急处理、精细化运营期追求各类技术服务的完善，领导行业时期可能需要平台化一些服务，这样的软件生命周期，伴随着大量的软件和人员的架构重组。

就说这么多，大自然本身非常精妙的架构。上帝创造了一切，芸芸众生却能很好的协作起来，去让一个公司，一个国家运转起来。有农民生产粮食，有工厂制造衣服，有的士司机提供打车服务。人类文明的发展导致分工越来来越明确也越来越专业，每个人已经不需要知道其他行业是怎么实现的细节，比如现在的高楼大厦是如何建造的，对我们多数人已经复杂的不可想象，我们只要关心有没有钱买房子就可以了。房地产商提供了一个传入金额、房子面积的方法，你只要选好房子，付上支票调用这个方法他就自动给你返回一套房子。这是何等精妙的架构，人人各司其职，互不影响。当一项新技术出现的时候，比如滴滴打车的出现，它改变了一些人们的出行方式，政府部门会负责架构，梳理，职责分工。让滴滴、司机、出租车公司、乘客都可以在分工变化中收益或者损失减少，又顺应了民心和时代发展潮流。同样，优秀的软件架构师会在分工变化中找到最合适的架构方案，让业务发展，原有架构、未来架构之间找到完美的架构方案。