一个思惟习惯，让你成为架构师

  程序员的迷茫不只仅是面对技术繁杂的无力感，更重要的是由于长期埋没于软件 世界的浩大的分工体系中，没法看清从业务到软件架构的价值链条，没法清楚定位自 己在分工体系的位置，处理很差自身与技术、业务的关系所致。

  不少程序员打心底不喜欢业务，这一点我曾经也经历过，我更宁愿从事框架工 具、技术组件研究的相关事情。我有个朋友常常吐槽我说：”大家每天加班加点写了 那么多代码，而后呢？有改变什么吗？还不是写出了一堆垃圾。”仔细想一想不少时候 业务在咱们脑海中存留的只是逻辑和流程，咱们丢失的是对业务场景的感觉，对用 户痛点的体会，对业务发展的思考。这些都是与价值紧密相关的部分。咱们很天然的 用战术的勤快掩盖战略的懒惰！那么这样的后果就是咱们把本身限死在流水线的工位 上，阉割了本身可以发现业务价值的能力，而过多关注新技术对职场竞争力的价值。 这也就是咱们面对繁杂技术，而产生技术学习焦虑症的根本缘由。

那么什么是业务呢？

  就是指某种有目的的工做或工做项目，业务的目的就是解 决人类社会与吃喝住行息息相关的领域问题，包括物质的需求和精神的需求，使开展 业务活动的主体和受众都能获得利益。通俗的讲业务就是用户的痛点，是业务提供方 （好比公司）的盈利点。而技术则是解决问题的工具和手段。好比为了解决用户随时随 地购物的业务问题时，程序员利用 web 技术构建电子商务 App，而当需求升级为帮 助用户快速选购商品时，程序员会利用数据算法等技术手段构建推荐引擎。 技术若是 脱离了业务，那么技术应用就没法很好的落地，技术的研究也将失去场景和方向。而 业务脱离了技术，那么业务的开展就变得极其昂贵和低效。
  因此回过头来咱们想一想本身没日没夜写了那么多的代码从而构建起来的软件系 统，它的价值何在呢？说白了就是为了解决业务问题，因此当你所从事的工做内容并 不能为解决业务问题带来多大帮助的时候，你应该要及时作出调整。那么软件系统又 是如何体现它自身的价值呢？在我看来有以下几个方面的体现：

业务领域与功能：好比支付宝立足支付领域而推出的转帐、收款功能等，好比人 工智能自动驾驶系统等。

服务能力：这就比如火车站购票窗口，评判它的服务能力的标准就是它可以同时 处理多少用户的购票业务，能不能在指定时间内完成购票业务，能不能 7*8 小时持续 工做。对应到软件系统领域，则表现为如下三个方面：

• 系统正确性 ( 程序可以正确表述业务流程，没有 Bug)
• 可用性（能够 7 ＊ 24 小时＊ 365 不间歇工做）
• 大规模（高并发，高吞吐量）

  互联网公司正是借助大规模的软件系统承载着繁多的业务功能，使其拥有巨大的 服务能力并借助互联网技术突破了空间限制，高效低廉解决了业务问题，创造了丰厚 的利润，这是人肉所不可比拟的。

  理解了这一层面的概念，你就能够清楚这个价值链条：公司依靠软件系统提供业 务服务而创造价值，程序员则是经过构建并持续演进软件系统服务能力以及业务功能 以支撑公司业务发展从而创造价值。

  有了这个价值链条，咱们就能够反思本身的工做学习对软件系统的服务能力提高 起到了多大的推进做用？能够反思本身的工做学习是否切实在解决领域的业务问题， 仍是只是作一些意义不大的重复性工做。

什么是架构？

  在我看来软件架构就是将人员、技术等资源组织起来以解决业务问题，支撑业务 增加的一种活动。可能比较抽象，我想咱们能够从架构师的一些具体工做任务来理解 这句话含义：

  组织业务：架构师经过探索和研究业务领域的知识，构建自身看待业务的”世界 观”。他会基于这种认识拆分业务生命周期，确立业务边界，构建出了一套解决特定 业务问题的领域模型，而且确认模型之间、领域之间的关系与协做方式，完成了对业 务领域内的要素的组织工做。

  组织技术：为了能在计算机世界中运做人类社会的业务模型，架构师须要选用计 算机世界中合适的框架、中间件、编程语言、网络协议等技术工具依据以前设计方 案组织起来造成一套软件系统方案，在我看来软件系统就像是一种技术组织，即技 术组件、技术手段依据某种逻辑被组织起来了，这些技术工具被肯定了职责，有了明 确分工，并以实现业务功能为目标集合在了一块儿。好比 RPC 框架或消息队列被用 于内部系统之间的通讯服务就如同信使通常，而数据库则负责记录结果，它更像是 一名书记员。

  组织人员：为了可以实现利用软件系统解决业务问题的目标，架构师还须要关注 软件系统的构建过程，他以实现软件系统为号召，从公司组织中汇集一批软件工程 师，并将这些人员按不一样工种、不一样职责、不一样系统进行组织，肯定这些人员之间的 协做方式，并关注这个组织系统是否运做良比如如沟通是否顺畅、产出是否达到要 求、可否按时间完成等。

  组织全局，对外输出：架构师的首要目标是解决业务问题，推进业务增加。因此 他很是关心软件的运行情况。由于只有在软件系统运行起来后，才能对外提供服务， 才能在用户访问的过程当中，解决业务问题。架构师须要关注运行过程当中产生的数据比 如业务成功率，系统运行资源占用数据、用户反馈信息、业务增加状况等，这些信息 将会帮助架构师制定下一步架构目标和方向。
  因此软件架构不只仅只是选用什么框架、选用什么技术组件这么简单。它贯穿了 对人的组织、对技术的组织、对业务的组织，并将这三种组织以解决业务问题这一目 标有机的结合在了一块儿。
  不少面试的候选人在被问及他所开发的系统采用什么架构的问题时，只会罗列出 一些技术组件、技术框架等技术要素，这样看来其根本没有理清架构的深层含义。也 有一些架构师只专一对底层技术的研究，觉得打造一个卓越的系统是很是牛逼的事 情，但是他忽略了软件系统的价值是以解决业务问题的能力、支撑业务增加的能力为 衡量标准，因此最后生产出了不少对组织，对业务没有帮助的系统。

成本与收益

  正如以前所说软件系统只有在运行的时候才能创造价值，也就是说软件系统可否 7*24 小时＊ 365 天稳定的工做关系到公司的收益水平。因此开发团队对生产环境的 发布老是当心翼翼，对解决生产环境的问题老是加班加点。而软件系统的成本则体现 在软件构建过程，这时候咱们就能理解那些工程技术如项目管理、敏捷开发、 单元测 试、持续集成、持续构建，版本管理等的价值了，他们有的是保证软件系统正确性， 有的是为了下降沟通成本，有的是为了提高开发效率等但总的来讲就是为了下降软件 的构建成本。因此在提高系统服务能力，创造更多业务收益的同时，下降构建成本也 是一种提高收益的有效手段。

  做为一名软件工程师而言，咱们每每处在软件构建过程体系中的某个环节，咱们 能够基于成本与收益的关系去思考本身每一项技能的价值，学习新的有价值的技能， 甚至在工做中基于成本与收益的考量选择合适的技术。好比在逻辑不大发生变化的地 方，没有必要去作过多的设计，应用各类花俏的设计模式等浪费时间。这样咱们才能 成为技术的主人。

架构目标须要适应业务的发展

  架构的目标就是为了支撑业务增加，就是提高软件系统的服务能力。但是话虽然说 如此，但真实却要作不少取舍。好比对初创团队而言，其产品是否解决业务问题这一 设想还没获得确认，就当即去构造一个高性能、高可用的分布式系统，这样的架构目 标远超出业务发展的需求，最后的结果就是浪费大量人力物力，却得不到任何转机。 架构师须要审时度势，仔细衡量正确性、大规模、可用性三者的关系，好比今年业务 蓬勃发展日均订单 300 万，基于对将来的可能预测，明年可能有 3000 万的订单，那 么架构师应该要着重考虑大规模和可用性。并且每一点提高的程度，也须要架构师衡 量把握，好比可用性要达到 2 个 9 仍是 3 个 9。
  回顾本身以往的工做不少时候就是由于没有确立架构目标致使浪费了组织不少资 源，好比在以前的创业团队中，因为本人有必定的代码洁癖，常常会花费不少时间和 同事计较代码质量，这样本能够更快上线的功能却须要被延迟，当时过分追求正确性 的行为是与创业团队快速验证想法的业务需求不匹配的。

从价值出发－找寻学习与工做的新思路

  向前一步，为更大的价值负责：不要由于本身是开发人员就不去关注软件运维， 不要由于只是测试就不关注软件开发，由于你关注的越多你越能看清全局的价值目 标。若是只关注一亩三分地，那么注定这辈子只能困守在这一亩三分地里，成为一名 流水线上焦虑至死的码农。试着转变思惟，从架构师的角度思考价值问题，看看可否 将技术贯穿到业务、到用户、到最终的价值去。以前个人朋友说过要把产品经理踢到 运营位置去，把程序员踢到产品经理位置去，这样才是正确作事方式。这句话也是类 似的意思，向前一步才能懂得怎么作的更好。
  像架构师同样思考，用价值找寻重心：人的迷茫是由于找不到重心，而价值的意 义在于引导咱们思考作哪些事情才能实现价值，先作哪些事情会比后作哪些事情更能 创造收益。像架构师那样全局性思考，把遇到问题进行拆分，把学习到的事物串联起 来，努力构成完整的价值链条。

 结尾处验证一下知识变现