第17章 未来的软件架构师在哪里

敏捷和软件技艺是我们努力改进和推动软件行业向前的两个非常好的例子。我们花了很多时间谈论编写代码、自动化测试、自动化部署、工具、各种技术，以及所有相关的流程。这很有意义，因为最终目标是通过软件让人们获益，而可用的软件是关键。但我们不应该忘记，在软件开发的流程中某些层面是很少有人真正有经验的。想想你将如何回答下列问题。

(1) 你上次写代码是什么时候？

❑ 今天早些时候就写过，我是软件开发者，所以这是我工作的一部分。

(2) 你上次重构是什么时候？

❑ 我一直注意让自己的代码尽可能好，这包括必要的重构。提取方法、重命名、上升、下降……这些我都知道。

(3) 你上次测试你的代码是什么时候？

❑ 过去，我们会在编写产品代码的过程当中或之后编写自动化测试，来进行持续的测试。单元测试、集成测试和验收测试我们都会用到。

(4) 你上次设计东西是什么时候？

❑ 我一直在做，作为软件开发者，这是我工作的一部分。在编码之前，我需要思考它会如何工作，不管是画草图还是使用TDD。

(5) 你上次从零开始设计一个软件系统是什么时候？我的意思是，承接一系列明确的需求，真正从无到有的创建？

❑ 好吧，在我目前的项目没有太多机会，但在业余时间我会为开源项目工作。只是我自己用的。

(6) 你上次从零开始设计一个会由一个团队来实现的软件系统是什么时候？

❑ 嗯，那不是我做的。

面对现实吧，无论预先设计还是演化设计，也不管是单打独斗还是集团作战，大多数软件开发者都不会频繁地在一张白纸上从无到有地设计软件。

指导、辅导和师徒关系

在大多数软件开发项目中，指导和辅导是一项被忽视的活动，很多团队成员没有得到所需的支持。技术领导力就是要引导整个项目，有时候个人需要协助。除此之外，指导和辅导提供了一种方式来增强人们的技能，帮助他们完善自己的职业生涯。这种协助有时候是技术性的，有时候是软技能。从技术的角度来看，为什么承担软件架构角色的人不应该帮着指导和辅导呢？我认识的大多数架构师正是因为他们在一个或多个技术领域有大量的经验才当上架构师的。既然是这样，为什么那些架构师不应该通过分享一些自己的经验来帮助别人？学徒模式正是过去建造大师传承技艺的方式。

我们正在失去技术导师

可悲的是，在我们的行业里许多开发者为了在企业晋升机制中有所发展，被迫转向非技术的管理岗位。讽刺的是，被迫离开技术岗位的往往是最优秀和最资深的技术人员，而软件团队中则失去了最有价值的技术领导、架构师和导师。今天的开发者还会在将来继续重蹈覆辙。

软件团队需要休息

许多团队失去了最资深的技术人员，留在团队中的人本来就已经在尽力平衡所有常规的项目限制和IT行业风潮（敏捷、技艺、云、富互联网UI、函数式编程，等等）带来的压力，而这又给他们增加了更多的工作量。很多团队意识到他们应该努力提高，但却没有时间或缺乏动力。

为了提高，软件开发团队需要一些时间远离日常工作，进行思考，但他们也需要保持对软件开发流程各个方面的关注。行业的炒作确实很容易迷惑人，但应该自问这是否比确保能良好务实地落地更重要。

编码经验很容易积累，有很多方式来练习这项技能。然而，从头开始设计一些将会由团队来实现的东西，就不是很多团队都会教授或实践的事情了。拜典型的企业晋升机制所赐，很多技术导师都消失了，让开发者上哪儿去获得这种经验？未来的软件架构师从哪里来？