软件架构师应该知道的件事Word文件下载.docx
- 文档编号:13320269
- 上传时间:2022-10-09
- 格式:DOCX
- 页数:8
- 大小:21.93KB
软件架构师应该知道的件事Word文件下载.docx
《软件架构师应该知道的件事Word文件下载.docx》由会员分享,可在线阅读,更多相关《软件架构师应该知道的件事Word文件下载.docx(8页珍藏版)》请在冰豆网上搜索。
以沟通为中心,坚持简明清晰和开明的风格
架构师不要坐在象牙塔里,命令开发人员实施你的设计和决策,而是应该尽量简化你的设计,透彻地与他们沟通,并且关键在于开明地接受他们的建议并勇于推翻自己的决策
架构决定性能
最好提升性能的方法不是痛苦地做一次次对即将上线的产品做性能测试和提升,而是在架构设计的时候就把性能作为重要因素,从架构底层考虑分布式、缓存、系统交互划分等影响性能的重点。
提前关注性能,是解决性能问题代价最小的方式
分析客户要求背后的真实需求
合同上或UC上只是客户的要求,而并非100%是客户真实的需求,架构师的重要责任就是挖掘隐藏在要求背后的真实需求,这个不但可以最大化满足客户,也往往可以帮助我们避开技术壁垒,当真正抓住客户需求的时候,我们也许能用更为简单的替代方案满足客户
沟通是架构师达成目标的核心技能
常用的沟通技能和准则有以下几点:
·
不要把沟通当做对抗
不要带有情绪与人沟通
表达自己方案之前倾听他人观点
站立发言是扩大沟通影响力的一种好方式
学习业务或技术领域中的行话,降低沟通成本
不要为预防故障引入更多的故障
架构师常常会为识别出的可能故障点加入监控措施,但往往会忽略做些监控措施也是会有故障的,不要试图让你的系统天衣无缝,这往往是使系统更为复杂和脆弱的来源。
先承认是系统总会有缺陷的,只是把这些缺陷设定为容易察觉和维护的点
量化非功能性需求
往往功能性需求容易量化,因为这些是看得见和摸得着的,但像性能好、可扩展性好、高可用性等这些非功能性需求却不好量化,但作为架构师要有意识地去定义和量化这些需求,只有这样才能更好地和其他部门更好沟通,谋求更多资源,也便于系统更有效地验收
一行代码比500行架构说明更有说服力
架构师往往喜欢待在象牙塔里,堆砌大量架构文档,然后希望其他开发人员能乖乖地去实施。
这样做的效果往往是不好的,一方面很难有这样的牛人能洞察所有的细节,在文档里就预测性地解决了所有问题,另一方面也不利于架构师与开发人员的沟通。
比较好的做法是架构师参与具体实施,在实施中验证和改进架构设计,与大家达成一片也便于加深彼此配合的默契程度。
不存在放之四海皆准的解决方案
不存在最好的架构,只有最合适的架构。
不会有一种架构方案,在任何项目里都适用。
虽然我们承认模式的重要性,但在实际项目里要有选择性吸收,根本上要本项目和实际困境出发,不要被既有的模式和经验先入为主,因为没有一种已有方案能完全不修改地适用于你。
架构设计要平衡兼顾多方需求
架构师从某种角度来讲就是一剂胶水,把业务部门的需求、项目进度的需求、测试的需求和开发工程师本身的需求有效地捏合在一起,平衡与兼顾以至达到皆大欢喜。
其他职能的人都只是focus在某一局部,需要架构师这样的人来通盘考虑,因此他的工作是最杂的,绝不是简简单单地拿出一份架构文档就OK了,需要考虑系统安全、易用性、可测性、商业价值、长期规划、发布管理和部署方式,使得各个部门人的需求得到响应
先确保解决方案简单可用,再考虑通用性和复用性
系统的复杂性往往是架构师基于通用性和复用性的设计而引入的,很多具体问题往往不需要通用性和复用性的解决方案。
如果存在多个可实施方案难以取舍,先简单后通用原则可以成为最终的评判标准。
架构师提供具体解决方案时,无需排斥通用和灵活,但是如果过早脱离具体情况,只会迷失在无限的可能性里,被复杂的配置选项、超负荷的参数列表、冗长罗嗦的接口,以及存在缺陷的抽象所淹没。
先简单满足需求,当重复需求再次发生时,通过重构来达到复用是一种不错的方式
架构师应该亲力亲为
架构师干久了往往会脱离技术本身,迷茫在抽象之中,这是很危险可怕的。
架构师要取得其他同事的信任,应该比业务人员更懂业务,比开发人员更懂具体的编码,比测试人员更懂如何有效地测试,就像航班的主驾驶员,虽然不需要亲自操作,但经验丰富,持续地监视着情况,一旦发现异常随时采取行动。
架构师应该项目的交付和质量负有最终的责任。
架构师应该尽可能地参与项目,不能把技术决策和方向上的难题拆分出扔给别人,需要采取更务实的办法,比如亲自动手研究或和其他成员讨论。
持续集成是架构师的重要任务
普通的开发人员会focus在各自负责的小模块,只会对单个模块负责,而架构师需要对整个系统负责,持续集成是一种对整个系统进行有效控制的好方法,架构师有责任让它运行起来。
避免进度调整失误
虽然保障进度是PM的职责,但变更要发生的时候,作为对技术最有发言权的架构师应该站出来,把变更的必要性和风险进行仔细分析,最大限度地支持PM的决策。
取舍的艺术
我们做系统,特别是互联网系统,绝不是做一个变形金刚,而是做一个有缺陷但却满足了现阶段商业需求的系统,因此架构师需要有取舍的艺术,你的架构是能用有限的资源满足最迫切的需求,舍掉那些看是光鲜却无太多用处的东西
打造数据库堡垒
在上层的程序设计中,架构师一般都会推崇先简单实现,然后在逐步重构的敏捷方式,但对于较为稳定的后端数据库,我们需要采取更为谨慎的态度,因为数据库是整个系统的基石,无论是业务设计还是技术设计都得保持它的稳定性,这是整个系统稳定的基础。
我们往往会发现这么一个现象,当程序第一版上线后,数据库里表只会增加不会删除,也不会删除多余的字段,每次数据库变更都会引起所有人的紧张,也会使得本已混乱的数据库设计更为混乱。
重视不确定性
优良的架构能够从整体上降低设计决策的重要性,糟糕的架构则会使得常常突出选择的重要性。
如果出现两个合理地选择,架构师应该停下来,设法找出介于两者之间的、具有更低重要性的决策,了解两者之外还存在其他选择,比决策结果本身更有价值
不要轻易放过不起眼的问题
项目的失败或线上故障往往是由于项目过程中的不起眼问题所引起,比如一些特殊的边界情况,而这些问题绝不能指望开发主力们去发现和解决,因为他们的注意力都会focus在主要矛盾上,作为时刻监控项目的架构师应该担当起发现这些“小bug”的义务。
让大家学会复用
架构师有义务提高开发人员可复用地解决问题的意识,比如以上几种措施:
让大家把自己能复用的代码及时共享给他人
加强复用代码的易用性,避免误用
让大家认识到已有资源好过自己动手
架构文档的抽象程度要适中
架构师写架构文档常常很纠结,写得太高层次的话就太空洞,无切实的指导意义;
写得太具体的话,比如指明到类的各种UML图,就会很约束开发人员。
文档要写到什么程度,关键在于满足他人的需求,比如业务部门想从文档中得知系统各功能的实施可行性,因此你的文档要能体现各主要功能是如何满足的。
测试人员想知道系统内部如何流转和如何对系统进行测试,因此你的文档要体现系统主要模块的运行流程和系统可测试性。
开发人员需要知道系统各自模块的划分和之间的交互规范,因此你的文档要体现模块化设计。
PM需要知道这个项目有哪些风险点,因此你的文档要体现风险点识别和如何规避。
DBA和运维人员需要知道系统的数据量和性能情况,因此需要指明系统如何应对大数据量的情况。
关键一点,架构师不是为了设计而设计,是要想清楚别人为什么要看你的文档,怎样满足别人的需求
先尝试后决策
设计中有很多需要决策的点,很多架构师喜欢在象牙塔里凭借经验做决策,感觉这就是架构师需要干的。
其实,这样的做法往往会让你很被动,不如延迟决策,把需要决策的点抛出来,让大家去尝试,在实践比较中,其实无须决策,正确的选择自然就出来了,这样也更能拉近你和大家的距离,提高大家的积极性和你的权威性
掌握业务领域知识
架构师的角色任务在于理解业务问题、业务目标、业务需求、并设计技术架构来满足它们。
掌握业务领域知识将有利于架构师选择合适的架构模式,更好地制定针对未来的扩展计划。
coding是属于设计范畴
很多人常常把软件开发类比于传统行业,把coding比作是生产过程,因此很多一线开发人员称作自己为代码工人,很多架构师也是这么认为,只是把开发人员当作实现自己设计的生产工具而已。
其实coding相对于传统行业应该属于设计范畴,真正生产过程实际上是由工具来完成的编译、构建和发布过程。
架构师更应该把coding当作设计来看,从纸上的设计到coding后的代码还有很多设计点可挖,同样的输出的背后也许来源于完全不同的coding,其软件成品的价值也是完全不同的。
让开发人员自己做主
架构师虽然需要为系统的设计负责,但无须包揽所有的设计工作,应该给予团队成员足够的自主权,让他们发挥自己的创意和能力,你的工作是确保大家的工作能很好的组合在一起,帮助他人解决棘手困难。
当你发现同事遇到麻烦时,可以主动给出建议,但更可取的做法是创造良好的氛围,让大家主动向你征求意见。
控制项目规模
架构师要试图避免做那种“超大型”系统,因为这种系统往往难以控制,控制项目规模的办法通常有:
抓住真正需求
分而治之
设置优先级
尽快交付原则
架构师不是演员,而是管家
有些架构师误解了证明自己价值的含义,以为是炫耀技术才华,甚至是刁难开发团队,把自己放在高高在上的位子,试图让别人来崇拜你。
其实架构师的职责和管家类似,承担着管理技术资产的责任,要深入了解系统里各个细节,要精打细算,而不是浮在表面做无实文章。
关注性能
高性能往往和代码优美性常常没法兼容,有些架构师往往不在乎性能上的点滴损耗,为了代码更重用或更优美,不惜多查一次数据库,多与外系统交互一次,这种做法会让后期的性能提升很被动,性能压力会逼迫你打破原有的设计,为提升性能把代码搞得支离破碎。
架构师需要珍惜任何一点的性能损耗。
对复杂性要有前瞻意识
在实际的运行环境中,往往简单的系统都有可能变得非常复杂,简单的远程接口可能调不通、稳固的数据库可能down掉、消息顺序可能会错乱、服务器可能会无缘无故地down机,不要假设这些情况不会发生,架构师应该对复杂的情况有前瞻意识,要在假设类似于前面的状态存在的情况下设计软件。
关注边界和接口
任何系统或模块的边界和接口都是与外交互的门面,有交互就暗藏着误解和不恰当的划分,保持接口的顺畅交互是架构师的重要职责。
往往bug发生在模块与模块之间、系统与系统之间,项目的失败也往往因为系统间交互问题,因此架构师需要给予足够的关注
助力开发人员
架构师的完美设计需要开发人员是实现,因此有业务想办法提升开发团队的战斗力,常有以下方式:
寻找或开发工作需要的工具,并附上使用技巧
做定期的分享或提高团队学习气氛,保持团队技术上的先进性
参与开发团队的招聘工作
给予开发人员更多的决策空间,帮助其成长
保护好开发人员,让他们尽可能地免于杂事之中
直接参与开发,分担压力
记录决策的理由
架构师常常需要权衡和决策,但决策过后却没有把决策的过程和理由记录下来,其
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 架构 应该 知道