登山sequence_登山指南

登山sequence

是的，我碰巧涉及架构，软件设计和技术。 是的，我受“软件架构师”一词的称呼。 不过，我不太喜欢。 恕我直言，这是一个被广泛滥用的角色。 许多人想到“象牙塔建筑师”，坐在他们的房间里，设计他们梦of以求的建筑，然后将这些建筑命令给开发团队。 那根本行不通。

ah…我们不需要建筑师

西蒙·布朗（Simon Brown）在他的《面向开发人员的软件体系结构》一书中说，为了知道您是否以正确的方式进行软件体系结构，您应该能够积极回答以下问题：

• 您的软件系统是否具有定义明确的结构？
• 团队中的每个人都以一致的方式实现功能吗？
• 整个代码库的质量水平是否一致？
• 对于整个团队如何构建软件是否有共同的愿景？
• 团队中的每个人都有必要的技术指导吗？
• 是否有适当的技术领导能力？

软件架构很重要！ 但是，这不应该是一个人为另一个人决定的事情，也不应该是一个更好的选择 。 仅仅需要一个关心质量，一致性的人，指出潜在问题，将关键方面进行讨论并提醒团队尊重既定准则的人。
软件架构师或技术负责人（IMHO可以更好地定义角色）必须与团队合作，成为受人尊敬且有价值的成员 。 因此，他需要保持高度的沟通能力和良好的社交能力。 我发现这些是最难的部分，而且通常比技术技能更重要。

软件架构师必须与团队合作，成为受人尊敬且有价值的成员。

团队内做出的决定将得到所有人的支持。 自上而下的决策正在执行（如果有的话）。

Architectus Reloadus与Architectus Oryzus

马丁·福勒（Martin Fowler）确实使我对建筑师的角色印象深刻。 我只是偶然发现了他的文章“谁需要建筑师” 。 马丁确定了两种类型的建筑师。

架构师会重新制定所有重要的决定，因为他认为团队没有必要的技能来做到这一点。 在他看来，所有这些都需要预先制定，其他所有人都有计划要遵循。

Architectus Reloadus。 图片来源：cyberpunkreview.com

然后是Architecty oryzus ，需要非常了解项目中当前正在发生什么。 他需要预见即将发生的问题，并在它们成为严重问题之前加以解决。

当我看到这样的架构师时，工作中最引人注目的部分就是紧密的协作。 早上，架构师与开发人员进行编程，试图获取一些常见的锁定代码。 下午，架构师参加了需求会议，以非技术的方式帮助需求者解释其某些想法的技术后果。 谁需要M. Fowler的建筑师

这恰好反映了我的愿景。 我喜欢在团队中工作，生活在多变的环境中。 您必须经历出现的那种问题。 这是极有价值的反馈，需要收集，分析，改进然后再带回下一个项目，其他团队才能从中受益。 他们的重点是成为一名导师 ，以提高团队的水平和能力，以自行处理复杂的情况。 因为您想要的最后一件事就是成为瓶颈。 不过，很难落入“ archycturs oryzus”的角色，因为它通常很诱人，并且是两者中较容易的一个。

建筑师需要成为高级编码员

作为一名架构师或技术负责人， 我确实以多种技术编写了很多代码 。 上周，我帮助一个团队成员在基于.Net的Web应用程序中实现了一些棘手的用户故事，并讨论了另一种可能的方法，即如何在Windows WPF应用程序中最佳地实现应用程序的跨领域功能。 然后，我修复了其中一个Java REST服务应用程序中的一些关键的，无法预料的问题，该问题公开了用于向Android和iOS应用程序发送推送通知的通用终结点。 软件架构师需要成为高级编码人员！

指导，如登山。 指南是一个经验丰富且技能娴熟的团队成员，可以教其他团队成员更好地自我维护，但始终会为您提供真正棘手的东西。 谁需要M. Fowler的建筑师

结论

不要成为象牙塔建筑师。 那行不通。 优秀的架构师是值得尊重的技术和团队领导。 他们为球队服务，指导他们。 那里有困难的部分，以确保团队可以专注于既定目标。

一些文献：

• 开发人员软件架构，Simon Brown
• 马丁·福勒（Martin Fowler）–谁需要建筑师
• 您最重要的技能：移情

翻译自: https://www.javacodegeeks.com/2015/06/guide-as-in-mountaineering.html

登山sequence