比代码更难的东西！读完这些思维习惯，人们就成了建筑师
这是一篇深刻的好文章，希望大家会喜欢。思维习惯让你成为建筑师
程序员的困惑不仅是复杂技术的无能为力造成的，也是因为他们长期被埋在软件世界的巨大分工体系中，无法清晰地看到从业务到软件架构的价值链，无法在分工体系中清晰地定位自己，无法处理好自己与技术和业务的关系。
许多程序员从心底里不喜欢商业，这是我以前经历过的。我更喜欢研究框架工具和技术组件。我的一个朋友经常对我说:“你每天加班，写了那么多代码，然后呢？有什么变化吗？不是写一堆垃圾。”
仔细考虑一下。大多数时候，业务只在我们的头脑中留下逻辑和过程。我们失去的是对业务场景的感觉、对用户痛点的体验以及对业务发展的思考。这些都与价值密切相关。我们自然会用战术上的勤奋来掩盖战略上的懒惰！
结果是，我们把自己局限在装配线工位，阉割了我们发现商业价值的能力，并且过于关注新技术对工作场所竞争力的价值。这是我们面对复杂技术时产生技术学习焦虑的根本原因。
那么什么是商业？商业是指某种有目的的工作或工作项目，商业的目的是解决人类社会中与饮食、住房、交通等领域密切相关的问题，包括物质需求和精神需求，从而使开展商业活动的主体和受众都能获得利益。一般来说，业务是用户的痛点，也是业务提供商(如公司)的利润点。
技术是解决问题的工具和手段。例如，为了解决用户可以随时随地购物的业务问题，程序员使用网络技术来构建电子商务应用，当需求升级以帮助用户快速购买商品时，程序员将使用数据算法和其他技术手段来构建推荐引擎。如果技术脱离了业务，技术的应用就不能很好地落地，技术的研究也就失去了它的场景和方向。然而，如果业务与技术分离，它将变得极其昂贵和低效。
因此，当我们回顾过去时，我们通过日以继夜地编写如此多的代码而构建的软件系统的价值是什么？说白了，这是为了解决商业问题。因此，当你从事的工作对解决业务问题没有太大帮助时，你应该及时做出调整。那么软件系统是如何体现其自身价值的呢？在我看来，有以下几个方面:
业务领域和功能:如支付宝基于支付领域的转账和收款功能，如人工智能自动驾驶系统。服务能力:这就像火车站的购票窗口。判断其服务能力的标准是它可以同时
有多少用户可以办理购票业务，能否在规定时间内完成购票业务，能否连续工作7*8小时。
与软件系统领域相对应，它表现在以下三个方面:系统正确性(程序能够正确表达业务流程而没有缺陷)
可用性(可连续工作7 * 24小时* 365分钟)
大规模(高并发、高吞吐量)
借助大规模的软件系统，互联网公司承载了广泛的业务功能，使其具备了强大的服务能力，并借助互联网技术突破了空之间的限制，高效、廉价地解决了业务问题，创造了无与伦比的巨大利润。
通过在这个层面上理解这个概念，您可以清楚地理解这个价值链:公司依靠软件系统提供业务服务来创造价值，而程序员通过构建和不断发展软件系统服务能力和业务功能来支持公司的业务发展来创造价值。
有了这个价值链，我们可以反思我们的工作和研究在多大程度上提升了软件系统的服务能力。你可以反思你的工作和学习是否实际上是在解决该领域的商业问题，或者只是做一些毫无意义的重复性工作。
什么是建筑？
在我看来，软件架构是一种组织人员、技术和其他资源来解决业务问题和支持业务增长的活动。也许是抽象的，我想我们可以从建筑师的一些具体任务中理解这句话的含义:
组织商业:建筑师通过探索和研究商业领域的知识来建立他们自己的商业“世界观”。基于这种理解，他将划分业务生命周期，建立业务边界，建立一套解决具体业务问题的领域模型，并确定模型和领域之间的关系和合作模式，完成业务领域中元素的组织。
组织技术:为了在计算机世界中运行人类社会的商业模式，架构师需要在计算机世界中选择合适的框架、中间件、编程语言、网络协议和其他技术工具，按照之前的设计方案组织并形成软件系统方案。在我看来，软件系统就像一种技术组织，即按照一定的逻辑来组织技术组件和技术手段，这些技术工具都有明确的职责、明确的分工和实现业务功能的目标。
例如，rpc框架或消息队列用于内部系统之间的通信服务，就像messenger一样，而数据库负责记录结果，这更像是一个职员。
组织人员:为了实现用软件系统解决业务问题的目标，架构师还需要关注软件系统的构建过程。在实现软件系统的号召下，他从公司组织中聚集了一批软件工程师，根据不同的工作类型、不同的职责和不同的系统来组织这些人员，确定这些人员之间的合作模式，并关注组织系统是否运行良好，如沟通是否顺畅、输出是否满足要求、能否按时完成等。
组织整个情况并将其输出到外部世界:架构师的主要目标是解决业务问题并促进业务增长。所以他非常关心软件的运行状态。因为只有在软件系统运行后，才能提供外部服务，解决用户访问过程中的业务问题。架构师需要关注运营过程中产生的数据比率，如业务成功率、系统运营资源占用数据、用户反馈信息、业务增长等。，这将帮助建筑师制定下一个建筑目标和方向。
因此，软件架构不仅仅是选择什么框架和技术组件那么简单。它贯穿于人、技术和业务的组织之中，并将这三个组织与解决业务问题的目标有机地结合在一起。
当被问及他开发的系统架构时，许多候选人只列出了一些技术组件、技术框架和其他技术元素，因此他们似乎根本没有阐明架构的深层含义。
也有一些架构师只关注底层技术的研究，认为构建一个优秀的系统是一件伟大的事情。然而，他忽略了软件系统的价值是由解决业务问题和支持业务增长的能力来衡量的，所以最终产生了许多对组织和业务没有帮助的系统。
成本和收益
如前所述，软件系统只有在运行时才能创造价值，也就是说，软件系统能否稳定地工作7*24小时* 365天，与公司的收入水平有关。因此，开发团队总是小心生产环境的发布，并且总是加班加点地解决生产环境的问题。
软件系统的成本反映在软件建设的过程中。此时，我们可以理解工程技术的价值，如项目管理、敏捷开发、单元测试、持续集成、持续构建、版本管理等。有些是为了保证软件系统的正确性，有些是为了降低通信成本，有些是为了提高开发效率等等。但一般来说，他们是为了降低软件建设成本。因此，在提高系统服务能力和创造更多业务效益的同时，降低建设成本也是提高效益的有效手段。
作为一名软件工程师，我们经常处于软件构建过程系统的某个阶段。我们可以根据成本和效益的关系思考每项技能的价值，学习新的有价值的技能，甚至在工作中根据成本和效益的考虑选择合适的技术。例如，没有必要做太多的设计，在逻辑没有太大变化的地方使用各种花哨的设计模式来浪费时间。只有这样，我们才能成为技术大师。
架构目标需要适应业务的发展
架构的目标是支持业务增长，即提高软件系统的服务能力。但即便如此，现实中仍有许多取舍。例如，对于一个创业团队来说，如果其产品解决业务问题的想法没有被证实，它将立即构建一个具有高性能和高可用性的分布式系统。这样的架构目标远远超出了业务发展的需要，最终的结果是浪费了大量的人力和物力资源而没有任何改进。
架构师需要评估情况，并仔细权衡正确性、规模和可用性之间的关系。例如，今年的生意蒸蒸日上，平均每天订单300万。根据对未来可能的预测，明年可能会有3000万份订单，因此建筑师应该关注规模和可用性。此外，架构师需要掌握每一个改进的程度，例如，可用性应该达到两个9还是三个9。
回顾我过去的工作，组织的许多资源都被浪费了，因为我没有建立架构目标。例如，在前一个启动团队中，因为我有一定的代码清洁度，所以我经常花费大量的时间同时考虑代码质量，这样可以更快启动的功能就需要延迟。当时，过分追求正确性与创业团队快速验证想法的业务需求不匹配。
从价值出发——寻找学习和工作的新思路
向前迈出一步，为更大的价值负责:不要仅仅因为你是一个开发人员就关注软件的运行和维护，也不要仅仅因为你只关注测试就关注软件开发，因为你关注得越多，你就能更好地看到全球价值目标。如果我们只关注一亩三分地，我们注定会在生活中被困在这一亩三分地上，成为一个在流水线上渴望死亡的代码农民。
试着改变你的想法，从架构师的角度考虑价值，看看你能否将技术应用到业务、用户和最终价值中。我的朋友以前说过，我们应该把产品经理踢到操作的位置，把程序员踢到产品经理的位置，这是正确的做法。这个句子也有类似于类的意思。只有向前迈出一步，你才能知道如何做得更好。
像建筑师一样思考，找到有价值的重心:人们困惑是因为他们找不到重心，而价值的意义是引导我们思考我们能做什么来实现价值，我们能先做的比我们以后能做的创造更多的利益。像建筑师一样全球化思考，把遇到的问题分开，把学到的东西串联起来，努力形成一个完整的价值链。
文章来源：www.atolchina.com