`
agileai
  • 浏览: 61023 次
  • 性别: Icon_minigender_1
  • 来自: 沈阳
社区版块
存档分类
最新评论

论架构师的自我修养

阅读更多

    架构师,当然是脑力劳动者,但是,同样是脑力劳动也存在重大的差别。有一类脑力劳动的成果,是比较容易被评价的。或者能够判断其对错:比如考试的分数;或者能够比较其高下:比如两个人下棋分出输赢;或者能够交由市场来判断:比如某种UI/UE设计,我们可以通过数据统计,了解其受用户欢迎的程度。

    但是,架构设计只是软件开发过程中的一个环节,而在这个多人协作的场景中,我们很难单独评价架构的优劣。由于硬件、软件、部署、人员、测试、用户、市场等众多的差别,即使是非常相近的两个系统,我们也很难判断两个架构孰优孰劣。比如:eBay的架构与Taobao的架构哪个更加优秀?在交付拖延的时候,我们可以将问题归咎于开发团队的效率低下。在出现质量问题的时候,我们可以将问题归咎于测试团队的疏忽大意。在负载撑不住的时候,我们可以将问题归咎于运维团队不够专业,甚至是竞争对手的DDoS攻击。那么,在出现什么样的问题的时候,我们可以将责任归咎于架构呢?

    所以,现状就是:架构师是一个很难做好的职业。但是,从某种意义上来说,又是一个非常容易混的职业。(当然,混是另一种需要持续修炼的高端技能。)因此,架构师也是特别需要强调自我修养与职业道德的职业。

    什么是架构?什么是架构师?

    对于架构的定义,有很多种,我比较同意的一种定义是:“架构是一组关键决策”。这样的决策包括但不限于:使用什么操作系统、语言、框架与类库;是否在架构中使用某种全新的技术方案;优先考虑或满足哪一方面的需求以及如何在技术上实现这一点;更进一步的,面对一个不断发展的系统,哪些部分需要优先重构or优化、哪些决策需要重新考虑甚至修改;再进一步,某些前瞻性的考虑,也是架构决策的一部分,等到问题发生再来解决,同样是架构方面考虑不周。

    能够做出这些决策的,就是架构师。或者说,在一个团队中,实际的最终决策者,就是事实上的架构师。无论他被赋予什么样的头衔。在一个团队中,我们总能找到这样的角色(无论他做得是不是称职),而一个优秀的架构师,就是通常能够做出“较多”正确决策的人。

    架构师的工作是什么?

    仅仅做出决策是不够的,我们可以从时间线上来观察:在做出决策之前,架构师需要足够了解自己的“可选项”,无论是用户的实际需求,还是最新出现的技术和框架,并且都得要有足够深入的理解(否则就是在拍脑袋做决策)。这时,架构师的角色,是一个“研究者”。

    在综合各项因素,甚至是相互矛盾的各种需求之后,在考虑到团队的实际能力与交付压力之后,在平衡了先进性与可靠性、扩展性与稳定性、重要性与紧迫性之后,架构师做出了一组决策。这时,架构师的角色,是一个“设计师”。

    为了确保自己架构设计能够被正确地实施和贯彻,架构师需要与研发团队密切配合,或者说服、或者引导、或者辅导、或者鼓动、甚至需要某种“强有力的推进手段”,这对于架构师的「硬实力」与「软实力」都提出了很高的要求。这时,架构师的角色,是一个“Top Coder”。

    在某些大公司,架构师还需做很多的文档工作,这些文档并不是交付给开发团队的说明性文档。而是某种向上级证明某某方案可行,某某架构有效的证明性文档。这时,架构师的角色,是一个“说服者”。

    从上面的描述,我们也可以发现,架构师像是一个千面人:需要与上下前后左右的不同角色打交道;多面手:需要了解甚至掌握诸多不同的知识和技能。要想做好这个工作,提升自我修养是根本之道!

    什么是架构师的自我修养?

    1. 以理解用户为荣,以想当然尔为耻 

    架构师不是产品经理,不是市场人员,不是客服人员。但是,如果只懂技术,只考虑技术,不能深入的理解用户的需求(强调一下,用户的真实需求!),就会做出“纯粹追求技术先进性”的想当然尔的架构出来。 

    2. 以脚踏实地为荣,以夸夸其谈为耻

    架构师当然需要很强的表达能力,甚至还需要有忽悠能力。但是,无论是表达还是忽悠,都必须以“实力为基础”。如果不能脚踏实地,积累实力,只会夸夸其谈。那就相当可耻了。 

    3. 以身先士卒为荣,以指手画脚为耻

    还是那个经典的台词“兄弟们跟我上”与“弟兄们给我上”的区别。如果对于一些困难的问题,架构师自己都搞不定,却摆出一副胸有成竹的表情:“这不是很简单的吗?你到网上搜一下嘛,资料大把大把的。”这种做派,就很令人不齿。 

    4. 以实践检验为荣,以道听途说为耻

    如果某种技术,架构师自己都没有做过评测,没有看过框架代码,没有在过去的实践中应用过。却因为一篇文章,一个讲座,甚至某个大公司曾经用过这样的证据,就将一种技术引入到项目之中。这样的决策,很少有不失败的。 

    5. 以先见之明为荣,以后知后觉为耻

    “过度设计”当然是一个贬义词,但是架构师一定要有前瞻能力。不能等到火烧起来了,再去救火。虽然在企业里,的确存在“救火英雄升迁快”的现象。但是,一个优秀的架构师,应该以“消除隐患于无形”为荣。 

    6. 以兼容并包为荣,以独断专行为耻

    在架构领域,很少有唯一解、最优解。大多数时候,我们只能在多个各有优劣的方案中,反复权衡,考虑取舍。这时,开阔的视野、开放的心胸,就显得尤为重要。如果一味的独断专行,听不进团队里其他同事的意见(尤其是那些学习了乔布斯的架构师),就会非常危险。 

    7. 以主动学习为荣,以固步自封为耻 

    技术的进步实在太快,曾经有一种夸张的说法:“平均每天诞生一种革命性的、颠覆性的技术”。虽然有很多新技术,都在如此宣称,作为架构师,却必须不断地主动学习,了解,甚至在某些领域做一些初步的尝试。这样的过程,在架构师的整个职业生涯中,都无法停止。一旦产生了“固步自封”的念头,这个架构师也就“不过尔尔”了。 

    8. 以勇猛精进为荣,以疏忽懈怠为耻

    架构师是一份困难的工作,更加重要的是:随着架构设计的完成,架构师的工作,才刚刚开始。接下来的任务,会非常琐碎,也许会更加困难。这份工作的主题是:“架构看护”尽可能保护架构,不会随着时间的推移,随着特性的增加,渐渐变得腐化。很多最初设计得相当优秀的架构,到最后变得不堪入目。说到底,还是要怪架构师没有能够坚持自己当初的决策。

    如何提升架构师的自我修养?

    在《中庸》里,子曰:“好学近乎知,力行近乎仁,知耻近乎勇。知斯三者,则知所以修身;知所以修身,则知所以治人;知所以治人,则知所以治天下国家矣。”

    简单的翻译解释下:好学就能显得有智慧(至少能有知识),力行就能不脱离群众(因不忘本而能具备仁慈之心),知耻就能守底线(有所为有所不为之勇)。能做到这三点,就算是懂得如何提升自己的修养了。懂得如何提升修养,才能懂得如何驾驭团队。懂得如何驾驭团队,才能创作出真正伟大的,甚至风行全球的软件产品来。

    这就是我理解的架构师的中庸之道,与诸位共勉吧。

    作者简介:华为开源专家,目前主要的工作是华为的内源社区平台建设。1997年毕业于华东师范大学,曾任盛大创新院的高级研究员、印客网的技术总监。多年来一直在编程的第一线,并以Coding为最大的乐趣。

    本文来自《程序员》电子刊10月B架构专题文章。

分享到:
评论

相关推荐

    人工智能训练师:让机器“通人性”.pdf

    随着人工智能技术的发展,特别是在无监督自我学习算法的兴起下,人工智能训练师的工作重点也逐渐从数据标注向更高级的技能转变。他们需要不断学习和提升自身的综合素质,以适应新产业、新业态、新模式的发展变化趋势...

    软件工程的职业发展与前景.pptx

    - **软件架构设计**:由软件架构师完成,涉及整个系统的组织结构和交互方式的设计,确保软件具有良好的扩展性和可维护性。 - **组件设计**:根据需求细化为各个具体模块或组件的设计,为后续的编码工作提供详细的...

    软件工程与软件质量评估方法.pptx

    - **软件架构师**:负责软件的整体架构设计,确保系统的可扩展性和可维护性。 - **软件开发工程师**:根据设计文档完成代码编写,并进行初步的测试。 - **质量保障工程师**:负责软件质量的监控和改进,确保软件产品...

    腾讯交互设计.ppt

    2. **结构图法**则利用图形工具描绘出产品的层次结构,帮助设计师和团队理解产品组件之间的关系,以便于设计出更合理的导航和信息架构。 3. **任务走查法**则是通过模拟用户完成特定任务的过程,检查产品设计中可能...

    产品经理深入浅出第14课-互联网产品的用户体验设计(UED)(上).pdf

    而UDC(User-Centered Design)是以用户为中心的设计方法论,强调在设计过程中始终将用户体验放在首位,这是一种设计哲学。HCI(Human-Computer Interaction)关注人与计算机之间的交互方式,而GUI(Graphical User ...

    软件工程与软件用户体验设计.pptx

    - **用户旅程地图**:为用户体验过程中的关键阶段创建详细的地图,帮助设计师更好地理解用户在整个过程中的感受和行为。 - **用户体验设计流程**:包括用户研究、用户分析、原型设计等步骤,以深入了解用户需求和...

    UML建模技巧与实践.pptx

    - **优化设计过程**: 通过可视化工具,设计师可以直观地调整和完善设计方案。 - **增加灵活性**: 支持多种设计模式,便于应对未来的变化和扩展。 - **提高质量**: 有助于确保系统的各个部分按照预期的方式工作。 - *...

    从零开始学习软件工程.pptx

    - **方法论**:敏捷开发、瀑布模型、迭代开发等方法被广泛应用。 - **质量保证与评估**: - **功能完整性**:确保软件能够按照预定的要求正常运作。 - **性能可靠性**:软件在不同环境下的稳定性和响应速度。 -...

    软件工程中的问题解决技巧.pptx

    - **解决方法**:采用敏捷开发方法论、加强团队沟通与协作、使用版本控制工具等。 **1.6 常见的软件开发模型** - **瀑布模型**:线性顺序的开发过程,每个阶段必须完成才能进入下一个阶段。 - **敏捷开发**:强调...

    软件工程中的可视化与数据可视化.pptx

    - **统一建模语言(UML)**:一种用于软件开发的标准建模语言,可以清晰地展示系统架构、类之间的关系等。 - **流程图**:用来描述算法或流程的图形表示,帮助团队成员理解业务逻辑。 - **时序图**:显示对象间的...

    软件工程的企业应用与管理.pptx

    - **设计工具**:如UML建模工具、原型设计工具等,这些工具可以帮助设计师更好地表达设计意图,并提高设计的准确性和效率。 **设计原则**: - **提高模块独立性**:确保每个模块具有高内聚(紧密相关)和低耦合...

Global site tag (gtag.js) - Google Analytics