架构师究竟要不要写代码？

Talk is cheap, show me the code！ 可是在互联网企业中，身处技术要职的架构师到底需不须要写代码？

在咱们的专业领域中有一种广泛存在的误解：架构师的工做不须要写代码。

就目前看来这彷佛没什么问题。毕竟，写代码是开发人员的工做。架构师就应该在更重要的任务上忙碌。

可是，让架构师远离写代码会限制开发团队的潜力。当需求和业务须要发生变化时，也可能致使架构混乱。

因此对于业界的误解，今天我想要为架构师正名，接下来，就让咱们来看看为何让你的软件架构师参与写代码的工做是一件好事。不过，在此以前，咱们首先来看看架构师的平常工做。

01

架构师的工做是什么？

01

这是一个很常见的问题。许多开发人员、产品经理、甚至连有些架构师都不肯定架构师的工做是什么。通常的定义说他们须要作出高层决策并规定标准。 可是这种说法很模糊。让咱们来深刻看看。

架构师应该承担的工做

理想状况下，架构师须要建立一个技术愿景，经过该愿景咱们能够得到可维护又可靠的产品。架构师须要协调不一样的团队，共同构建一个相互依存的软件生态系统。此外，他们还须要分享高层的集成决策，传达应用程序和组件之间协同工做的方式。除此以外，他们还须要根据常见的软件问题审查并规定工具和框架，并经过向利益相关者和领导层传达最终产品的目标和愿景，将全部这些联系在一块儿。

因此架构师的工做听起来很伟大。你可能想知道为何我把如此之多的工做都推给了忙忙碌碌的架构师。为了理解这一点，让咱们来看看我刚描述的状况与现实生活的对比。

现实

现实状况看起来因公司而异。事实上，有些公司确实让他们的架构师在履行其余全部职责的同时也担负了编程的任务。可是这些公司不是这篇文章的讨论对象。我想重点讨论曾经与我合做过的不参与编程工做的架构师在公司里究竟作了哪些工做。

首先，这位不参与编程的架构师将大部分时间都花在了开会上。他还为这些会议准备大量 PPT 和 Visio 的资料。实际上，这是“PPT 架构师”一词的来源。除此以外，他编写了设计文档，将本身对软件设计的见解写成一本 50 页的书，与开发人员共享。（惋惜这个前期设计已通过了批准的日子）。后来，他还审查其余设计文档，签署设计选择，并重复全部这些工做，直到他忘记了 IDE 应该是什么样子。

02

若是架构师不参与编程会怎么样？

若是看不到产品的平常开发过程，那么人们可能会认为一切都很顺利。 时间线看起来还不错。功能也在持续增长。咱们正在朝着咱们的目标前进。

首先，库和工具没法解决问题时，架构师有可能并不知情。可能有一些架构师规定的工具在理想状况下能够正常运行，可是在复杂且常见的用例中这些工具可能会带来不少困难。 或者偏偏相反，他们推荐了一种适用于复杂场景的工具，可是对于开发人员遇到的简单平常问题则过于苛刻。

除非架构师使用他们本身推荐的工具，不然就没法真正意识到他们的选择产生的影响。

设计没法知足不断变化的需求

在考虑软件开发的时候，咱们不能假设一个静态的世界。架构师作的提早设计并不能考虑到全部的可变因素和极端状况。在软件编写工做完成以前，咱们没法发现其中的细微差异。

总之，架构和设计决策常常须要作出改变。

你可能会说这不是问题。架构师能够回去从新设计系统。然而，实际状况却并不是如此。开发人员注意到有些事情不太对劲。这些事情变得愈来愈困难。而他们能够作的有：他们能够向架构师汇报这个问题，可是架构师不在其中没法真正掌握状况；他们能够自行从新设计系统；或者他们也能够尽量地想办法弥补问题，而后继续前进。 若是架构师可以与开发团队近距离相处，并担任编程的工做，那么他们就能够看到变化即将到来，并实时修改设计。他也能够预先作最小的设计，并与团队合做，随着时间的推移改进系统的架构。

开发人员备受打击

若是设计只能自上而下地传达，并且架构师又不在身边，那么开发团队也会在各个方面遭受困苦。首先，正如我上面提到的，状况会发生变化。

若是架构师不在身边共同讨论，那么这些变化会致使延迟。

其次，许多开发人员都不喜欢刻板的编程，他们但愿可以创造设计并作出决策。 若是设计过于精细，那么创造过程就会消失。

最后，当开发团队注意到实际状况与架构图上的不一致时，他们会责怪计划。并且他们会以为架构师没有搞明白情况。不管这是实情仍是他们的想象，编写软件过程当中的障碍均可以视做架构师的失职。

03

解决方案

在咱们注意一些陷阱的前提下，若是架构师参与写代码的工做，那么咱们能够得到哪些好处呢？

尊重架构师

我曾经见过一些开发人员忽略了对架构师的尊重。毕竟，架构师不参与写代码的工做。他们不知道如何平衡可读性、设计和可维护性。

所以，若是架构师参与写代码的工做，那么他们就能够告诉开发团队他们在并肩做战。他们了解实际状况。并且若是有必要他们也愿意携手同行。

此外，架构师还能够更频繁地分享设计看法。一般，开发人员看不到架构模式的需求，由于他们历来没见过可让他们的日子更好过的模式。架构师能够经过传达设计中重要部分的架构来解决这个问题。或者他们能够帮助团队将代码中的混乱部分重构成优雅的东西。

更好地理解设计

若是架构师参与写代码的工做，那么他们就有机会向开发人员传达更具影响力的设计思想和原则。看到白板上画出来的适配器模式是一回事，而在 IDE 中亲眼看到一个适配器模式是另外一回事。

此外，架构师应该鼓励开发人员多多思考设计。做为导师，你能够教导开发人员处理意外的变化，并找到解决问题的模式和设计。你应该公开讨论解决方案的优缺点，提出问题和讨论，并开展设计合做。

另外一种方法是利用原型。若是架构师将他们的一些架构设计原型化，那么就能够部分地看到该原型在实际生活中的运做方式，并为团队提供须要构建的东西。

实时设计更新

参与写代码工做的架构师能够实时地评估备选方案。过分架构的解决方案须要花费太多实现的时间，架构师能够为团队提供有关开源或购买库的信息。

让架构师与团队在一块儿能够确保根据不断变化的需求调整架构。此外，过分提早设计的工做压力也会减小。

若是架构师每周均可以参与一点写代码的工做，那么他们就能够及时地注意到代码偏离了愿景，从而能够及时地调整方向。此外，架构师还能够更好地处理正在建立的技术债务。并且他们可以指导团队什么时候增长技术债务，什么时候不能增长技术债务。

最终产品的架构全部权

若是架构师参与最前线的写代码工做，那么他们就会拥有更多产品的主动权。能够更好地了解他们的解决方案为企业带来的成本。若是他们可以亲手实现本身的解决方案，那么他们就会很快意识到哪些设计决策很是重要，而哪些设计决策无关紧要。

例如，一般架构师须要针对可能发生的每种状况进行规划。

可是在项目开始时，一般很难知道哪些问题是真实的，哪些是想象的。 或者至少哪些状况不太可能出现。若是最终咱们只有 100 个客户，那么就没有必要创造一个冗余且规模巨大的迷宫。 咱们应该专心提供价值。

04

潜在问题

有关为何架构师不该该参与写代码的工做，支持者们有如下几点理由：

• 他们会忽略长期愿景或更大的问题。

• 理解本来不须要了解的应用程序的细节。

架构师参与写代码的工做等于鼓励团队不配置架构师。

我彻底明白。大家但愿确保架构师只承担本身的职责，即制定长期和高层决策。可是，咱们并非要求架构师花费全部时间来编写代码。相反，咱们只是他们花费少许时间来帮助他们设计的应用程序变成现实。

至于不配置架构师的观点，我在别的地方看到过这样的例子。咱们经常会遇到有的架构师很喜欢写代码，却不肯意将最基本部分以外的东西交给其余开发人员。这种架构师须要信任开发团队来编写代码。随着时间的推移，开发人员应该可以承担愈来愈复杂的工做。

05

人人受益

最后我认为，让软件架构师参与写代码的工做有益于整个团队和最终产品。同时也能够鼓励分享设计理念和快速反馈，能够帮助团队中每一个人的成长。

因此让你的架构师参与写代码的工做吧。让开发人员参与设计的工做吧。增强团队合做才能提供最佳解决方案。

做者：Sylvia Fronczak

来源：

mp.weixin.qq.com/s/m_0Y9_cJX…

原文:

dzone.com/articles/sh…