主题：303-Dylan Beattie：怎样成为一名架构师？ -- 万年看客

你有一个前端团队，前端团队正在构建插入 API 服务器的代码，那么一开始就要告诉他们：“我们要伪造一些 API 响应，好让你们开始工作。”另一边你再告诉其他后端开发团队：“我将帮助你们构建API 的测试套件文档，然后你可以去构建满足这些要求的客户端。”如何向团队传达你的设计？你创建数据，你创建测试，然后你让他们去构建实际的代码。然后你可以将这两部分相互嵌合。作为一个架构师，你要在这里查看系统中发生的情况并查看流量。你是否看到了你期望看到的数据结构？延迟、吞吐量和流量是否符合你的期望？经常被提起的问题之一是架构师是否应该仍然亲手编码？是的，绝对的。因为如果你停止编码，你就会丧失在码农眼中的信誉。但是不要在你正在开发的系统里编码。你有一个改进架构的好主意，那么迟早你会屈服于诱惑：“我懒得更新图表，懒得开会安排别人去实施，我自己动手好了。”一开始你的团队会大感意外：“你到底做了什么？”你说：“你们看现在架构好多了。”第一次出这种事，他们会说“挺好挺好”，第二次他们就会直接把工作推给你，这一来你就成了瓶颈。“你这么喜欢修改，那你就自己修改好了。”但是另一方面，你又必须保持控制权，写代码的手不能停，一旦停下来你的技艺就会钝化，就会跟不上软件构建的最新进度。亲手写代码是与团队建立可信度和良好工作关系的好方法。我发现架构师写代码的最好方式是构建监控系统。你可以在团队中挑选几个人，吩咐他们：“我想了解你们的API正在做什么，我想在办公室墙上的大屏幕上显示流量。咱们几个一起来构建这个东西。”这样你既可以作为程序员充分了解该系统的工作原理，同时又不必对你正在构建的面向客户的系统当中实际投入的任何东西负责。你亲手构建的东西只会在墙上运行，不过这足以让你产生主人翁意识：“你们看，我的代码也正在运行。”其次，这样做还让你有机会与人们合作，向他们学习，分享建议和智慧。大多数架构师在开始专门从事架构之前都是非常优秀的开发人员。你的经验与技能很有价值，但是依然要避免成为瓶颈。

很多时候情，特别是当你决定要使用现成的服务，或者将软件的某些部分托管在某处，或者与支付提供商集成的时候，作为业务决策这些都很有意义，因为这样做很有效。但对于团队中的开发人员来说，这种体验通常很糟糕，因为他们往往要应对讨厌的api， 签名的xml，加密签名以及奇怪的沙箱之类的东西。开发人员的眼里没有商业价值。几年前我遇到过一个真实的案例。我们将一大堆东西从内部系统移植到 Microsoft Dynamics。Dynamics 作为 开发工具有一些有趣的功能，但是也有很多方面难以处理，团队感到有点受压迫。然后有一天开会的时候我说：“你们还记不记得去年每个星期一早上都得有人花两个小时从数据库中提取邮件列表，以便营销团队可以发送每周简讯？”他们都说：“是啊。”我又问道：“你们有没有注意到我们不再这样做了？”他们都说：“诶，是啊。”当业务问题得到解决时，开发人员很少看到解决方案。作为架构师，你的工作就是替他们去看：“还记得我们曾经不得不做过哪些恶心人的事吗？如今我们用不着再这么干了。这就是为什么。”传达这些决策正在创造的价值，与团队中的其他开发人员配对，构建Dashboard，构建监控系统，查看网络流量，不要让自己成为瓶颈，所有这些都是你可以用来构建高功能团队的协作模式，从而允许响应变化的行为得以发生，而不是一味遵循计划。你当然有计划，但是你并没有与计划绑定。如果计划出了错，你就得制定一个更好的计划。

有一幅经典的 xkcd 漫画，题目是“如何编写好的代码”。我们做事求快还是求对？如果你做得快，软件能运行吗？不，不，不，勉强能运行，但是代码好像糊成一堆的意大利面，不如重新开始。如果你做得对，代码写得很好，那就完了吗？没完，因为客户要求已经改变了。你知道如何获得好的代码？当优秀的开发人员查看代码，表示“这东西还能改进”，而且确实实现承诺的时候，好的代码就会发生。我们在此类活动中讨论的几乎所有内容都是关于如何构建更好的系统——框架、单元测试、集成测试、架构等等。架构师的努力方向是鼓舞开发人员的信心，让他们可以尝试他们的改进设想。架构是修改起来代价昂贵的东西。如果架构师的工作做得好，改变的代价就更便宜。有人可以打开一段代码，然后表示：“我想我可以重构它，让它运行得更好。良好的架构让人们能够做到这一点，让整个团队多年来一直做到这一点。就像我说的那样，验证很难。你得等上五年才能看到你架构的软件是否运行正常。如果不太正常，不妨轻轻地导引一点点。但是归根结底，架构师的存在是为了让优秀的开发人员能够查看一段代码，改进并且交付，同时很清楚他们这样做的时候没有破坏别的什么东西。谢谢。