第24章 职业发展之路
成为一名架构师需要花费更多的时间和精力，但基于本书中概述的许多因素，成为一名架构师后管理职业化之路同样棘手。 尽管我们无法为您提供具体的职业发展路径，但我们可以为您指出一些我们认为行之有效的做法。
架构师必须在整个职业生涯中持续学习。技术世界的变化令人眼花缭乱。尼尔（Neal）的一位前同事是Clipper方面享誉全球的专家。他感叹自己不能吸收大量（现在无用的）Clipper知识，而用其他东西代替。他还推测（这仍然是一个悬而未决的问题）：历史上有没有一个小组像软件开发人员的在一生不断的学习和放弃如此多的知识？
每个架构师都应密切注意技术和业务方面的相关资源，并将其添加到他们的个人知识库中。不幸的是，资源来得太快了，这就是为什么我们在本书中没有列出任何东西。和同事或专家讨论他们使用什么资源保持最新状态是寻找活跃于特定兴趣领域的最新的资讯，网站和群组的一种好方法。架构师还应该花点时间来维持使用这些资源的广度。
20分钟规则
如图2-6所示，架构师技术广度是比深度更重要。但是，保持广度需要时间和精力，架构师应该在自己的工作中建立一些东西。但是，世界上有谁有时间实际去各种网站阅读文章，观看演示文稿以及收听播客呢？答案是……不是很多。开发人员和架构师都在平衡工作和生活，与家人共度时光，与孩子共处，为个人的兴趣和爱好花时间，努力发展事业，同时又努力保持平衡最新趋势和流行的技术。
我们用来维持这种平衡的一种方法是我们称之为20分钟规则。这个想法如图24-1所示，投入学习至少一种新的东西或深入到一个特定的主题，每天20分钟，你的职业生涯作为一个架构师。图24-1举例说明了每天要花费20分钟的某些类型的资源，例如InfoQ，DZone Refcardz和ThoughtWorks
Technology Radar。花至少需要20分钟的时间，向Google提供一些不熟悉的流行词（第2章：“您不知道的事” ），以了解一些有关它们的知识，并将这些知识推广为“您不知道的事情” 。” 或者，也许需要花20分钟深入研究某个特定主题，以获取更多有关该主题的知识。该技术的重点是能够腾出一些时间来发展作为架构师的职业并不断获得技术广度。
图24-1。20分钟规则
许多架构师拥有这个概念，计划在工作后的午餐或晚上花费20分钟。我们所经验的是 ，这个很难起到作用。午餐时间越来越短，越来越多的是上班时间，而不是休息和吃饭的时间。晚上甚至更糟-一切情况都在发生变化，制定了计划，家庭时间变得更加重要，而且20分钟的规定永远不会发生。
我们强烈建议您在早晨开始时首先利用20分钟规则。但是，此建议也有一个警告。比如，架构师早上起来工作后要做的第一件事是什么？好吧，架构师要做的第一件事就是喝上一杯很棒的咖啡或茶。好的，在这种情况下，每个架构师在获得必要的咖啡或茶之后要做的第二件事是-查看电子邮件。一旦架构师检查了电子邮件，便会发生转移，写出电子邮件回复，这一天结束了。因此，我们强烈建议您在早上喝咖啡或茶后，然后检查电子邮件之前，首先调用20分钟规则。
开发个人技术雷达
在90年代的大部分时间和20年代初期，尼尔是一家小型培训和咨询公司的CTO。 在那时，主要平台是Clipper，它是一个快速应用程序开发工具，用于在dBASE文件之上构建DOS应用程序。直到一天，它消失了。该公司已经注意到Windows的兴起，但是商业市场仍然是DOS…直到突然之间就没有了。那堂课给人留下了持久的印象：无视技术的发展，后果后严重。
它还教导了我们有关技术泡沫的重要课程。当大量投资于技术时，开发人员生活在模因泡沫中，该泡沫也充当回声室。供应商创建的气泡特别危险，因为开发人员从未听过气泡内部的诚实评估。但是，活在泡泡中最大危险在于它开始崩溃时，开发人员从内部不会注意到，直到为时已晚。
他们缺乏的是技术雷达：一份评估现有技术和新生技术的风险和回报的活文档。雷达概念来自ThoughtWorks。首先，我们将描述这个概念的产生方式，然后介绍如何使用它来创建个人雷达。
ThoughtWorks技术雷达
ThoughtWorks技术顾问委员会（TAB）是一组高级技术 ThoughtWorks内部的领导者是为协助CTO Rebecca Parsons博士而创建的，他为公司及其客户确定技术方向和策略。该小组每年会面两次。面对面会议的成果之一是技术雷达。随着时间的流逝，它逐渐发展成为半年两次的技术雷达。
TAB逐渐适应了每年两次的雷达生产节奏。然后，经常发生意外的副作用。在尼尔参加的一些会议上，与会人员将他找出来，并感谢他帮助生产雷达，并说他们的公司已经开始生产自己的雷达版本。
尼尔还意识到，这是遍及世界各地会议发言人小组的一个普遍问题的答案：“您（发言人）如何跟上技术发展？您如何确定接下来要追求的目标？” 答案当然是它们都具有某种形式的内部雷达。
组成部分
ThoughtWorks雷达由四个象限组成，这些象限试图涵盖大多数软件开发领域：
工具类
软件开发领域中的工具，从IDE等开发人员工具到企业级集成工具，应有尽有
语言和框架
计算机语言，库和框架，通常是开源的
技巧
任何有助于整体软件开发的实践；这可能包括软件开发流程，工程实践和建议
平台类
技术平台，包括数据库，云供应商和运营系统
圆环
雷达有四个环，在此从外到内列出：
暂缓
暂缓环的最初意图是“暂时暂缓”，以表示那些太新而无法进行合理评估的技术，这些技术引起了很多轰动，但尚未得到证实。保持环已演变为“不要使用此技术开始任何新的事物”。在现有项目上使用它没有什么害处，但是开发人员应该考虑将其用于新开发。
评估
评估环表明，一项技术值得探索，其目的是了解它如何影响组织。架构师应该投入一些精力（例如开发高峰，研究项目和会议），以查看是否会对组织产生影响。例如，许多大公司在制定移动策略时显然都经历了这一阶段。
试验
试用环用于值得追求的技术；重要的是要了解如何建立这种能力。现在是时候尝试一个低风险的项目，以便架构师和开发人员可以真正理解该技术。
采纳
对于采用环中的技术，ThoughtWorks强烈认为业界应采用这些技术。
图24-2中显示了Radar的示例视图。
图24-2。ThoughtWorks技术雷达示例
在图24-2中，每个光点表示一种不同的技术或方法，并带有简短的文字说明。虽然ThoughtWorks使用雷达来广播他们对软件世界的看法，但许多开发人员和架构师也将其用作构建其技术评估过程的一种方式。架构师可以使用“开放源代码可视化”中描述的工具来构建ThoughtWorks使用的相同视觉效果，以此来组织他们对投入时间的思考。
将雷达用于个人用途时，建议将象限的含义更改为以下含义：
暂缓
架构师不仅可以包括要避免的技术，还可以包括他们试图打破的习惯。例如，.NET世界的架构师可能习惯于在论坛上阅读有关团队内部的最新新闻或八卦。在娱乐时，它可能是低价值的信息流。将其搁置提醒架构师避免出现问题。
评估
架构师应将评估用于他们听说过的好东西但还没有时间进行自我评估的有前途的技术-请参阅“使用社交媒体”。这枚戒指构成了将来在某些时候进行更认真研究的舞台。
试验
该试验环表示活跃的研究和开发，例如作为较大的代码库中执行尖峰实验架构师。这枚戒指代表着值得花时间去深入了解的技术，以便架构师可以进行有效的权衡分析。
采纳
在采用环表示新事物的架构师是最兴奋和最佳实践，解决特殊的问题。
对技术组合采取自由放任的态度是危险的。大多数技术人员或多或少地根据技术的优劣或您的雇主的意愿来临时选择技术。创建技术雷达可以帮助架构师形式化他们对技术的思考，并平衡相反的决策标准（例如“更酷”的技术因素，获得新工作的可能性相对较小，而拥有庞大的工作市场却没有那么有趣的工作）。架构师应将其技术组合视为财务组合：在许多方面，它们是同一回事。理财规划师告诉人们有关其投资组合的什么信息多样化！
架构师应选择一些需求广泛的技术或技能，并跟踪需求。但是他们可能还想尝试一些技术诀窍，例如开源或移动开发。有趣的是，开发人员通过在深夜从事开源项目而使自己摆脱了小隔间的麻烦，这些开源项目变得很受欢迎，可购买，并最终成为了职业目的地。这是关注广度而不是深度的另一个原因。
架构师应该留出时间来扩大他们的技术范围，而建造雷达可以提供良好的支撑。但是，锻炼比结果更重要。创建可视化文件为思考这些事情提供了借口，对于忙碌的架构师而言，找到借口在忙碌的工作中节省时间是这种思考发生的唯一方法。
开源可视化
根据大众的需求，ThoughtWorks在2016年11月发布了一个工具，以帮助技术人员构建自己的雷达可视化。当ThoughtWorks为公司执行此练习时，他们会在电子表格中捕获会议的输出，每个象限都有一个页面。ThoughtWorks的“构建自己的雷达”工具使用Google电子表格作为输入，并使用HTML 5画布生成雷达可视化。因此，尽管练习的重要部分是它产生的对话，但它也可以产生有用的可视化效果。
使用社交媒体
架构师在哪里可以找到新技术来放置雷达评估环？ 在安德鲁·迈克菲（Andrew McAfee）的《企业2.0》（哈佛商业评论出版社）一书中，他对社交媒体和社交网络进行了有趣的观察。 思考关于人与人之间的关系网络，存在三种类别，如图24-3所示。
图24-3。人际关系的社交圈
在图24-3中，强链接表示家庭成员，同事和一个人定期联系的其他人。一个石蕊试纸测试了这些联系之间的紧密程度：他们可以告诉您，上周联系至少一天的人在他们的紧密联系中吃过什么。薄弱的环节是偶然的熟人，远方的亲戚和其他每年只见过几次的人。在社交媒体出现之前，很难跟上这一群人。最后，潜在链接代表您尚未认识的人。
McAfee关于这些连接的最有趣的观察结果是，某人的下一份工作更有可能来自薄弱的环节，而不是强大的环节。紧密联系的人知道紧密联系的组中的所有内容，这些人一直在彼此见面。另一方面，弱链接会从他人的正常经验（包括新工作机会）中提供建议。
利用社交网络的特征，架构师可以利用社交媒体来提高其技术广度。专业人士使用Twitter之类的社交媒体，架构师应该找到技术专家，并尊重他们的建议，并在社交媒体上关注他们。这使架构师可以在有趣的新技术上建立人际网络，以评估并跟上技术领域的快速变化。
分词建议
我们如何获得优秀的设计师？当然，伟大的设计师设计。
弗雷德·布鲁克斯
那我们应该怎么办 获得优秀的架构师，如果他们在职业生涯中仅获得少于六次的架构师机会？
泰德·纽亚德
实践是一种行之有效的方法，可以提高技能并在生活中的任何方面（包括架构）变得更好。我们鼓励新老架构师保持磨练自己的技能，无论是针对个人技术范围还是针对架构设计的工艺。为此，请在配套网站上查看该书的体系结构选项。 我们以此处的示例为原型进行建模，我们鼓励架构师使用它们来练习架构方面的技能。
关于kata的一个常见问题：某处是否有答案指南？不幸的是这样关键答案不存在。引用作者尼尔的一句话：
在架构中没有正确或错误的答案，只有权衡取舍。
什么时候我们开始在现场培训课程中使用架构katas练习，我们最初保留了学生制作的图纸，目的是创建答案库。但是，我们很快就放弃了，因为我们意识到我们的工件不完整。换句话说，团队已经捕获了拓扑并在课堂上解释了他们的决策，但是没有时间创建架构决策记录。尽管他们实现解决方案的方式很有趣，但其原因却更加有趣，因为它包含了他们在做出决定时所考虑的权衡。只保留故事的一半。因此，我们最后的建议是：永远学习，始终练习并去做一些架构设计！
原文 ：https://www.jianshu.com/p/70cd10b3bed5
全书翻译目录：https://www.jianshu.com/p/05711d172dfa
声明：本资料仅供学习交流严禁使用于任何商业用途！请购买正版图书：https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/cover.html
资料整理和翻译：杨传池Chris IT老兵，人生三大爱好（爱好喝茶，喝酒和喜欢做梦）
10+年的软件研发和项目管理经验；
7+年大型房产信息化、数字化咨询经验；
50+人以上研发团队管理，擅长团队管理和人才梯队建设；
熟悉研发管理、工程构建、体系建设、DevOps和领域建模，掌握IT研发价值链和工具链。
