bookshelf.png

什么是软件架构师

  • 软件架构师是一位软件专家,他可以进行高级设计选择并决定技术标准,包括软件编码标准,工具和平台。 (来源:维基百科:软件架构师)
  • 软件体系结构是系统的基本组织,由其组件,它们之间的相互关系以及与环境的关系以及确定系统设计和演进的原理来表示。 (来源:软件体系结构手册)

架构师级别

软件架构可以被抽象的分为几个层次

  • 项目级别:最低的架构级别。专注于单个项目。非常详细的底层设计。通常在一个开发团队中进行沟通。
  • 解决方案级别:中级架构。专注于满足业务需求(业务解决方案)。解析需求并进行系统的低层设计。多个开发团队之间的协调。
  • 企业级别:最高的体系结构级别。专注于多种解决方案。高层次的抽象设计,需要解决方案或项目架构师对其进行详细说明。整个组织的沟通。相当于CTO。请参阅链接以了解更多信息。

有时,架构师也被视为不同利益相关者之间的“桥梁”。

  • 水平:在业务和开发人员或不同的开发团队之间架起沟通桥梁。
  • 垂直:在开发人员和管理人员之间架起沟通桥梁。
  • 技术:不同的技术栈或其他产品的集成和融合。

基本工作内容

  • 定义和决策开发技术和平台
  • 定义开发标准,例如编码标准,工具,审查流程,测试方法等。
  • 认识和理解业务需求
  • 根据需求设计系统并做出决策
  • 记录并传达整体架构定义,设计和决策
  • 检查和审查架构与代码,例如,检查定义的模式和编码标准是否正确实施
  • 与其他架构师和利益相关者合作
  • 指导开发人员
  • 询问开发人员,项目进度或遇到的问题,甚至包括心理咨询“心灵鸡汤”灌输。
  • 详细说明并将上级需求转为具体工作内容

应具备的技能

  • 设计
  • 决策
  • 简化
  • 编码
  • 文档
  • 沟通
  • 评估
  • 平衡
  • 指导
  • 市场

1. 设计

系统设计是最重要也是具挑战性的一项技能。我们需要借助理论和实践相结合,完成一个适合当下环境的整体系统架构设计。

  • 学习设计模式:设计模式是架构师开发可维护系统所需的最重要工具之一。使用设计模式,您可以重用设计,以通过可靠的解决方案解决常见问题。

    John Vlissides,Ralph Johnson,Richard Helm和Erich Gamma撰写的《设计模式:可重用的面向对象软件的要素》一书是所有软件开发人员必读的。尽管这些模式已经发布了20多年,但它们仍然是现代软件体系结构的基础。例如,本书描述了模型-视图-控制器(MVC)模式,该模式在许多领域都得到了应用,或者是更新模式的基础,例如模型-视图-视图模型(MVVM)。

  • 深入研究设计模式:如果您已经了解所有基本的GoF模式(Gang of Four,4人组,也就是上面提到的《设计模式》),则可以通过更多的软件设计模式来扩展您的知识,或者更深入地研究您感兴趣的领域。

    学习 Spring 源码中的各种设计模式的巧妙应用;学习现代的微服务,无服务器架构,大型的分布式架构等。保持时代的脚步。

  • 学习质量衡量指标:出于代码质量和非功能性要求定于编码标准。达到系统的可维护,可靠,适应性强,安全,可测试,可扩展,高可用。

    在 Java 项目可以使用 Alibaba Java Coding Guidelines 要求每位开发人员先自测。

  • 了解不同的技术栈:要成为一名更好的架构师,学习新技术栈,从浅到深的学习。不同的(新)技术具有不同的架构设计,值得学习。学习新技术不应只是简单阅读文档(但这也是必须的),而是自己尝试发现其中的痛点和存在的意义。架构师不仅应该具有广泛的知识,而且在某些领域还应该具有深刻的知识。

    好奇并尝试新事物。甚至还去尝试一些之前不喜欢的东西。保持学习

  • 分析框架源码:阅读大型的开源框架源码,尝试了解它如何在框架中应用,为什么要这样做。更深入地研究代码并了解其实现方式。

    不仅可以学习实现方式,设计模式。还包括大型开源的项目管理及可借鉴的工具等。

  • 交互设计: 不仅需要设计软件架构,有时候你还需要了解交互设计,有基本的审美,可以让设计师发挥他们的设计能力,保持对创造的热情,有时候这也有助于你更好的设计软件架构。

2. 决策

架构师必须做出决策并指导项目团队朝正确的方向发展。

  • 专注于你需要专注的 :不同阶段的架构师有不同的职责,专注于你当前的职责,尽早与其他架构师沟通完成决策。

  • 优先级:有时最好做出“错误”的决策而不是没有决策。系统是也是循序渐进的,不一定一开始你就需要考虑到象淘宝一样量级的技术选型与决策。

    使用一些技巧,如:加权最短作业优先(WSJF)模型。在时间紧迫性和风险降低措施对于评估架构决策的优先级至关重要。

  • 能力边界:不要决定能力之外的事情。这很关键,因为如果不考虑的话,它可能会严重破坏您作为架构师的地位。为避免这种情况,请与您的同伴明确您要承担的责任以及角色的一部分。如果架构师不止一个,那么您应该尊重当前部署的架构级别。作为较低级别的架构师,您最好提出有关高层架构的建议,而不是决策。此外建议始终与同伴一起检查关键决策。

  • 评估多个选项:在做决策是,如果发现你没有一个以上的选项可选,那这肯定是有问题的:首先,可能是你的工作做得不好,知识边界过窄;其次,它必然阻碍了你做出正确的决定。此外,还可以与项目成员或利益相关者展开讨论,发现更多的可选项,在讨论中可能会发现你遗漏的一些因素。

3. 简化

“如无必要,勿增实体”,即“简单有效原理”。切勿浪费较多东西去做,用较少的东西,同样可以做好的事情。这就是 奥卡姆剃刀定律

  • 解决方案:简化解决方案可能需要“摇动”现有的解决方案,从不同角度思考,问自己几个问题

    1. 在理想环境中您的解决方案会发生什么?
    2. 竞争对手会怎么做?
    3. 大厂(BTA,GAFA)会怎么做?BAT(Baidu、Alibaba、Tencent),GAFA(Google、Apple、Facebook、Amazon)

    有时候你需要在心里塑造一个不同的人格来判断问题。比如是乔布斯遇到这个问题会怎么做等。多问自己几个这样的问题可以迫使你减少假设。

  • 不忘初心:经过长时间深入的讨论,通常会得出高度复杂的草案。永远不要将这些视为最终结果。停顿一下回到最初,是不是有过多的附加?你可以尝试明天再回头看看这些草案,有时候大脑需要一些时间来处理并提出更好,更优雅,更简单的解决方案。

  • 分而治之:将问题分成小块以简化问题。然后独立解决它们。然后验证小块是否匹配。回到最初的需求查看总体情况。

  • 重构并不是坏事:如果找不到更好的主意,则可以从更复杂的解决方案开始。

    重构并不是坏事。但是在开始重构之前,请记住要进行以下工作:(1)进行足够的自动化测试,以确保系统的正确功能;以及(2)从利益相关者的支持。要了解有关重构的更多信息,建议阅读《重构。改进现有代码的设计》,作者是Martin Fowler。

4. 编码

即使作为企业架构师,你仍然应该了解开发人员的日常工作。不然你可能会遇到:开发人员不接受你的提议;你也无法了解开发人员面临的挑战和问题。

不断去尝试新技术和工具,以了解当今以及未来的开发方式。我们必须了解大量的编程语言,框架,工具,过程和实践。只有对主要趋势有一定的经验和粗略的了解,才能参与对话并引导开发朝正确的方向发展。

5. 文档

架构决策或代码指南文档必不可少。 在开始编码之前通常需要初始项目文档,并且需要不断地完善。 也有一些文档在规范的代码下可自动生成,代码也可以是文档,例如 UML 类图。

  • 整洁的代码:代码是最好的文档。

    《码出高效》,《阿里巴巴Java开发手册》

  • 生成文档:系统正在快速迭代变化,很难更新文档。规范的编码习惯可以直接从源代码自动生成文档。

    可以利用一些工具如 Swagger 、RAML

  • 简明: 简明的 wiki 也是最初文档的好选择。过长的文档不仅需要大量的编写时间,也大大增加后者的学习时间。

    一些大型的开源项目,如: Vue.js 文档写作风格值得学习

6. 沟通

沟通非常重要,而很多架构师都低估它的价值。你对软件架构设计精湛,却无法很好的表达你的思想,这可能会使项目成员偏离你的思想,导致项目失败。

  • 学习演讲:架构师,通常不仅需要参加会议,而且通常需要主持会议。

    如果面对百人演讲会感到不适,可以尝试向面向镜子,面向朋友,慢慢一步步的走出自己的舒适区来学习演讲,不要过分的求速成,要有耐心

  • 沟通需要因人而异:不同的利益相关者有不同的兴趣和看法。需要对他们进行单独处理。表达前也需要再次确认一下自己需要表达内容,目标,动机等。

    开发人员通常对解决方案的细节感兴趣,而管理人员则更喜欢知道哪个选项节省的钱最多。

  • 保持沟通:定期主动的向上级和项目成员汇报项目进度和成果,保持沟通也保持了信任关系。

  • 透明:如果成员过少的沟通,也不参与到决策的过程,那么他们也很难理解和遵循其背后的决策和理由。

  • 总结输出:多做总结并输出写作、运营、品牌。

7. 评估

架构师或首席开发人员,经常会要求估计项目预期,如:多长时间,多少人,多少技能等?当然,如果您打算引入新的工具或框架,则需要为它们提供使用的依据。最初,你应该能够进行粗略的估算,例如几天,几个月或几年。但是要记住,不仅需要考虑开发时间,还有更多其他工作需要考虑,比如需求分析,测试和修复BUG等。因此,你需要了解软件开发的整个“闭环”过程。

  1. 设计实践:项目架构遵循哪些模式?它们是否正确使用?项目预期需求边界是否受控制?是否有清晰的结构?是否高度耦合?
  2. 开发实践:制定并遵循了代码准则?代码如何版本化?部署实践?
  3. 质量保证:测试自动化范围?codeReview如何?
  4. 安全性:有哪些安全概念?存在那些安全隐患?渗透测试或自动安全分析工具是否到位并经常使用?

使用工具对代码进行质量、安全等的分析
SonarQubecodereviewgit stats

8. 平衡

  • 高质量的代价:如果您过度关注架构,则会增加成本并可能降低开发速度。您需要平衡架构和功能需求,应避免过度设计。

  • 解决矛盾的目标 :项目的短期和长期目标通常是矛盾。项目通常倾向于构建最简单的解决方案,而架构师则应具有长远的眼光。通常,简单的解决方案不适合长期解决方案,并且有被以后抛弃的风险(降低成本)。为了避免实现错误的方向,需要考虑两点:

    1. 开发人员和企业需要了解长期愿景及其收益,以适应其解决方案
    2. 负责预算的经理需要参与以了解财务影响。不必直接将100%的愿景图放置在当前,但是也应考虑为后期其他愿景打下基础。
  • 冲突管理:架构师通常是不同团队之间的粘合剂。这可能会发生一些沟通冲突。架构师需要帮助克服冲突,找到平衡的解决方案。

    这时候学习一些商业战略、管理学就显得很重要,平衡上级的预期与项目成员的利益,并获得他们的支持。

9. 指导、答疑

积极主动去询问项目成员遇到的问题与进度。

定期组织交流会,大家互相学习分享近期遇到的问题和学习心得,讨论过去和当前的挑战以及如何解决它们或采用新的方法论和方法。架构师也可以分享,讨论和调整其愿景,开发人员可以共享经验并向同行学习。这样的回合不仅可以为企业带来极大的好处,而且对个人本身也非常有利,因为它有助于建立更强大的网络并传播思想。

10. 市场

您的想法很棒,您已经很好地传达了他们的想法,但仍然没人愿意遵循吗?那么您可能缺乏营销技巧。

  • 包装:了解创投市场,并运用一些工具,搜集与展示数据。

    1. 原型:使用原型去展示你的想法。
    2. 视频:制作视频可以更加生动的演示您的想法或方向。但是不要过度营销:从长远来看,内容为王。如果无法实现你承诺的,从长远来看,这将损害你的声誉。
  • 相信自己:或许你的想法并不被大家认可,但如果你真的对自己的想法深信不疑,则应不断追求并为之奋斗。

    具有长期目标的体系结构决策通常不是最容易的:开发人员不喜欢它们,因为它们的开发更加复杂。经理们不喜欢它们,因为它们在短期内更昂贵。这是您要坚持不懈并进行谈判的工作。

  • 寻找同盟:尝试找到可以支持和说服他人的盟友。

    可以从与同事头脑风暴你的想法开始。如果他们喜欢它,或者至少喜欢它的一部分,那么如果别人提出来,他们很可能会支持您的想法。如果他们不喜欢,问为什么:也许是你忽视了什么细节?还是你的故事不够令人信服?如果你不善于表达讨论,请记住,有时您需要离开舒适区,不断挑战自己。

  • 重复:“研究表明,反复接触某个观点会使人们相信该观点更为普遍。如果你发布的信息足够频繁,则可以更轻松地说服人们。但请注意:应该明智地使用这种策略,因为它可能适得其反,成为糟糕的营销技巧。

  • 学习心理学,统计学: 了解各利益相关者和客户群体心理。

路线图

frontend.png

backend.png

devops.png

内容大多来自 SoftwareArchitect
Developer Readmap
添加了自己的一些理解与本地化

在这里Developer Notes不断完善各阶段技能的一些工具与书籍,也欢迎大家推荐分享自己的观点,一起做更好的架构师。



技术      技术思考

本博客所有文章除特别声明外,均采用 CC BY-SA 3.0协议 。转载请注明出处!