软件架构师应该知道的97件事读后感(转)(精)

1、软件架构师应该知道的97 件事读后感 (转 客户需求高于一切不要为了自己的项目经历上添加光彩而去一味追求时髦而光鲜的方案 ,而是应该扎根客户需求 ,脚踏实地地为客户着想 ,这样才能更体现技术的价值 ,不至于迷失方向 ,软件架构师应该知道的 97 件事读后感 (转。架构师首先不要把自己当做技术人员 ,而是业务人员 ,把实现业务需求作为至上的目标 ,学会拒绝成本高 ,性价比不高的技术。简化根本复杂性常常为了解决某一局部复杂性引入了更为复杂的框架或产品 ,使得复杂性不减反增。往往正确的方式是做减法而不是加法 ,把最根本的复杂源找到 ,把根铲除。关键问题可能不是出在技术上总结失败的项目常常会纠结于选择

2、了错误的技术。其实技术并没有错 ,而是在使用技术上或是在执行过程中人为的偏差导致。而架构师解决这种人为的问题比较好的方式是沟通 ,通过有效地沟通把技术贯彻下去以沟通为中心 ,坚持简明清晰和开明的风格架构师不要坐在象牙塔里 ,命令开发人员实施你的设计和决策 ,而是应该尽量简化你的设计 ,透彻地与他们沟通 ,并且关键在于开明地接受他们的建议并勇于推翻自己的决策架构决定性能最好提升性能的方法不是痛苦地做一次次对即将上线的产品做性能测试和提升 , 而是在架构设计的时候就把性能作为重要因素 ,从架构底层考虑分布式、缓存、系统交互划分等影响性能的重点。提前关注性能,是解决性能问题代价最小的方式分析客户要求

3、背后的真实需求合同上或 uc 上只是客户的要求 ,而并非 100%是客户真实的需求 ,架构师的重要责任就是挖掘隐藏在要求背后的真实需求 ,这个不但可以最大化满足客户 ,也往往可以帮助我们避开技术壁垒 ,当真正抓住客户需求的时候 ,我们也许能用更为简单的替代方案满足客户沟通是架构师达成目标的核心技能常用的沟通技能和准则有以下几点:* 不要把沟通当做对抗* 不要带有情绪与人沟通* 表达自己方案之前倾听他人观点* 站立发言是扩大沟通影响力的一种好方式* 学习业务或技术领域中的行话 ,降低沟通成本不要为预防故障引入更多的故障架构师常常会为识别出的可能故障点加入监控措施 ,但往往会忽略做些监控措施也是会

4、有故障的 ,不要试图让你的系统天衣无缝 ,这往往是使系统更为复杂和脆弱的来源。先承认是系统总会有缺陷的 ,只是把这些缺陷设定为容易察觉和维护的点量化非功能性需求往往功能性需求容易量化 ,因为这些是看得见和摸得着的 ,但像性能好、可扩展性好、高可用性等这些非功能性需求却不好量化 ,但作为架构师要有意识地去定义和量化这些需求 ,只有这样才能更好地和其他部门更好沟通 ,谋求更多资源 ,也便于系统更有效地验收一行代码比 500 行架构说明更有说服力架构师往往喜欢待在象牙塔里 ,堆砌大量架构文档 ,然后希望其他开发人员能乖乖地去实施。这样做的效果往往是不好的 ,一方面很难有这样的牛人能洞察所有的细节 ,

5、在文档里就预测性地解决了所有问题 ,另一方面也不利于架构师与开发人员的沟通。比较好的做法是架构师参与具体实施 ,在实施中验证和改进架构设计 ,与大家达成一片也便于加深彼此配合的默契程度。不存在放之四海皆准的解决方案不存在最好的架构 ,只有最合适的架构。不会有一种架构方案 ,在任何项目里都适用。虽然我们承认模式的重要性 ,但在实际项目里要有选择性吸收 ,根本上要本项目和实际困境出发 ,不要被既有的模式和经验先入为主 ,因为没有一种已有方案能完全不修改地适用于你。架构设计要平衡兼顾多方需求架构师从某种角度来讲就是一剂胶水 ,把业务部门的需求、项目进度的需求、测试的需求和开发工程师本身的需求有效地捏

6、合在一起 ,平衡与兼顾以至达到皆大欢喜。其他职能的人都只是 focus 在某一局部 ,需要架构师这样的人来通盘考虑 ,因此他的工作是最杂的 ,绝不是简简单单地拿出一份架构文档就 ok 了,需要考虑系统安全、易用性、可测性、商业价值、长期规划、发布管理和部署方式 ,使得各个部门人的需求得到响应。先确保解决方案简单可用,再考虑通用性和复用性系统的复杂性往往是架构师基于通用性和复用性的设计而引入的,很多具体问题往往不需要通用性和复用性的解决方案。如果存在多个可实施方案难以取舍,先简单后通用原则可以成为最终的评判标准。架构师提供具体解决方案时 ,无需排斥通用和灵活 ,但是如果过早脱离具体情况 ,只会迷

7、失在无限的可能性里 ,被复杂的配置选项、超负荷的参数列表、冗长罗嗦的接口 ,以及存在缺陷的抽象所淹没。先简单满足需求 ,当重复需求再次发生时 ,通过重构来达到复用是一种不错的方式架构师应该亲力亲为架构师干久了往往会脱离技术本身 ,迷茫在抽象之中 ,这是很危险可怕的。架构师要取得其他同事的信任 ,应该比业务人员更懂业务 ,比开发人员更懂具体的编码 ,比测试人员更懂如何有效地测试 ,就像航班的主驾驶员 ,虽然不需要亲自操作 ,但经验丰富 ,持续地监视着情况 ,一旦发现异常随时采取行动。架构师应该项目的交付和质量负有最终的责任。架构师应该尽可能地参与项目 ,不能把技术决策和方向上的难题拆分出扔给别人

8、 ,需要采取更务实的办法 ,比如亲自动手研究或和其他成员讨论。持续集成是架构师的重要任务普通的开发人员会 focus 在各自负责的小模块 ,只会对单个模块负责 ,而架构师需要对整个系统负责 ,持续集成是一种对整个系统进行有效控制的好方法 ,架构师有责任让它运行起来。避免进度调整失误虽然保障进度是 pm 的职责 ,但变更要发生的时候 ,作为对技术最有发言权的架构师应该站出来 ,把变更的必要性和风险进行仔细分析 ,最大限度地支持 pm 的决策。取舍的艺术打造数据库堡垒在上层的程序设计中 ,架构师一般都会推崇先简单实现 ,然后在逐步重构的敏捷方式 ,但对于较为稳定的后端数据库 ,我们需要采取更为谨慎

9、的态度 ,因为数据库是整个系统的基石 ,无论是业务设计还是技术设计都得保持它的稳定性 ,这是整个系统稳定的基础。我们往往会发现这么一个现象 ,当程序第一版上线后 ,数据库里表只会增加不会删除 ,也不会删除多余的字段 ,每次数据库变更都会引起所有人的紧张 ,也会使得本已混乱的数据库设计更为混乱。重视不确定性优良的架构能够从整体上降低设计决策的重要性 ,糟糕的架构则会使得常常突出选择的重要性。如果出现两个合理地选择 ,架构师应该停下来 ,设法找出介于两者之间的、具有更低重要性的决策 ,了解两者之外还存在其他选择 ,比决策结果本身更有价值不要轻易放过不起眼的问题项目的失败或线上故障往往是由于项目过程

10、中的不起眼问题所引起 ,比如一些特殊的边界情况 ,而这些问题绝不能指望开发主力们去发现和解决 ,因为他们的注意力都会 focus 在主要矛盾上 ,作为时刻监控项目的架构师应该担当起发现这些 “小bug”的义务。让大家学会复用架构师有义务提高开发人员可复用地解决问题的意识,比如以上几种措施 :* 让大家把自己能复用的代码及时共享给他人* 加强复用代码的易用性 ,避免误用* 让大家认识到已有资源好过自己动手架构文档的抽象程度要适中架构师写架构文档常常很纠结 ,写得太高层次的话就太空洞 ,无切实的指导意义 ; 写得太具体的话 ,比如指明到类的各种 uml 图 ,就会很约束开发人员。文档要写到什么程度

11、 ,关键在于满足他人的需求 ,比如业务部门想从文档中得知系统各功能的实施可行性 ,因此你的文档要能体现各主要功能是如何满足的。测试人员想知道系统内部如何流转和如何对系统进行测试 ,因此你的文档要体现系统主要模块的运行流程和系统可测试性。开发人员需要知道系统各自模块的划分和之间的交互规范 ,因此你的文档要体现模块化设计。 pm 需要知道这个项目有哪些风险点 ,因此你的文档要体现风险点识别和如何规避。 dba和运维人员需要知道系统的数据量和性能情况 ,因此需要指明系统如何应对大数据量的情况。关键一点 ,架构师不是为了设计而设计 , 是要想清楚别人为什么要看你的文档 ,怎样满足别人的需求先尝试后决策

12、设计中有很多需要决策的点 ,很多架构师喜欢在象牙塔里凭借经验做决策 ,感觉这就是架构师需要干的。其实 ,这样的做法往往会让你很被动 ,不如延迟决策 ,把需要决策的点抛出来 ,让大家去尝试 ,在实践比较中 ,其实无须决策 ,正确的选择自然就出来了 ,这样也更能拉近你和大家的距离 ,提高大家的积极性和你的权威性掌握业务领域知识架构师的角色任务在于理解业务问题、业务目标、业务需求、并设计技术架构来满足它们 ,读后感软件架构师应该知道的 97 件事读后感 (转。掌握业务领域知识将有利于架构师选择合适的架构模式 ,更好地制定针对未来的扩展计划。coding 是属于设计范畴很多人常常把软件开发类比于传统行

13、业 ,把 coding 比作是生产过程 ,因此很多一线开发人员称作自己为代码工人 ,很多架构师也是这么认为 ,只是把开发人员当作实现自己设计的生产工具而已。其实 coding 相对于传统行业应该属于设计范畴 ,真正生产过程实际上是由工具来完成的编译、构建和发布过程。架构师更应该把 coding 当作设计来看 ,从纸上的设计到 coding 后的代码还有很多设计点可挖 ,同样的输出的背后也许来源于完全不同的 coding,其软件成品的价值也是完全不同的。让开发人员自己做主架构师虽然需要为系统的设计负责 ,但无须包揽所有的设计工作 ,应该给予团队成员足够的自主权 ,让他们发挥自己的创意和能力 ,你

14、的工作是确保大家的工作能很好的组合在一起 ,帮助他人解决棘手困难。当你发现同事遇到麻烦时 ,可以主动给出建议 ,但更可取的做法是创造良好的氛围 ,让大家主动向你征求意见。控制项目规模架构师要试图避免做那种 “超大型 ”系统 ,因为这种系统往往难以控制 ,控制项目规模的办法通常有 :* 抓住真正需求* 分而治之* 设置优先级* 尽快交付原则架构师不是演员，而是管家有些架构师误解了证明自己价值的含义，以为是炫耀技术才华，甚至是刁难开发团队， 把自己放在高高在上的位子，试图让别人来崇拜你。其实架构师的职责和管家类似，承担着 管理技术资产的责任，要深入了解系统里各个细节，要精打细算，而不是浮在表面做无

15、实文 章。 关注性能 高性能往往和代码优美性常常没法兼容，有些架构师往往不在乎性能上的点滴损耗，为了代码更重用或更优美，不惜多查一次数据库，多与外系统交互一次，这种做法会让后期的 性能提升很被动，性能压力会逼迫你打破原有的设计，为提升性能把代码搞得支离破碎。架构师需要珍惜任何一点的性能损耗。对复杂性要有前瞻意识关注边界和接口任何系统或模块的边界和接口都是与外交互的门面，有交互就暗藏着误解和不恰当的划分，保持接口的顺畅交互是架构师的重要职责。往往bug发生在模块与模块之间、系统与系统之间，项目的失败也往往因为系统间交互问题，因此架构师需要给予足够的关注助力开发人员 架构师的完美设计需要开发人员是

16、实现，因此有业务想办法提升开发团队的战斗力，常有以下方式： *寻找或开发工作需要的工具，并附上使用技巧做定期的分享或提高团队学习气氛，保持团队技术上的先进性参与开发团队的招聘工作给予开发人员更多的决策空间，帮助其成长 保护好开发人员，让他们尽可能地免于杂事之中 直接参与开发，分担压力 记录决策的理由 架构师常常需要权衡和决策，但决策过后却没有把决策的过程和理由记录下来，其实这 是在浪费很大的一笔财富。质疑假设 架构师往往需要假设一种情境，然后在这种情境下给出方案和做出决策，很多人包括自 己从来都是纠结于这个方案的优劣，并不断改进，但却忽视了这种假设的情境是否成立，而 这个可能是万恶之源。关注系

17、统的支持和维护架构师通常是由开发人员成长而来，因此天然地把注意力放在功能开发上，常常忽视系 统的支持和维护方面，给支持人员和维护人员造成不便。架构师需要清晰知道一个系统生命 周期 80%在于维护上面，而系统的价值需要支持人员去不断传递给客户，他们的需求需要得 到重视。有以下几点需要注意：*清晰性 可测性 正确性 可跟踪性 不要急于求解 很多架构师都有解决难题的欲望，一遇到问题，就立马陷入解决问题的泥潭中。而更可 取的是审视问题本身，看是否可以改变问题，或是干脆绕开问题，很多时候技术上的难题在通过业务上的优化是可以避免的。我们不要立足点设为解决特定问题，而是应该立足于客户需求 优秀软件是培育出来

18、的 原则大于个人口味 很多架构师都有着丰富的经验和个人风格，以至于在平常工作中常以个人口味作为决策 的依据，对于普通的开发人员也许是可行的，我们鼓励大家有个人特色，但架构师更应该依据原则办事，需要维护和遵守一套大家公认的原则，以此作为判断是非的工具从“可行走骨架 ”开始 敏捷管理崇尚尽早集成，在架构设计这一块，这个原则也行之有效。架构师在开始阶段无需陷入某些难题或细节里，应该尽快地把各个核心模块串接起来，并能发动开发人员使其简单地运转起来，骨架一旦就绪，再进入健身环节。这样做的好处，一方面可以尽早消除大家之间的误解，也可以带来正朝着正确方向前进的信心 数据是核心 数据为王是大家深知的道理，只要

19、这个系统拥有有价值的数据，那么这个系统就有生命力。架构设计中，数据无小事，任何数据只要是存在于系统中，就需要给予足够的重视，也 许是个废弃的字段，但它也许会有一天被人错误的引用到，或是时不时地遭到别人的询问是 干嘛用的。 根据投资回报率进行决策 很多架构师认为计算和分配资源是 pm 要做的事情， 与自己无关， 自己要做的是设计最优 的系统。其实，这个最优不光是技术上的最优，往往在实际项目中大家所关注的是投资回报率最优，老板想用最少的投资获取符合需求的产品，pm 想用最少的人力发布项目，开发人员想用少的代码完成功能等等，作为架构师应该把投入产出比作为决策的一个重要因素 起码有两个可选解决方案 一个经验丰富的架构师会对一些关键的问题给出多个解决方案，并能分析其优缺点，并 最后一般取舍之后做出选择，这是一种令人信服的说明问题和解决问题的方式。 不能不了解硬件 软件架构师常常无法正确考虑硬件因素，有多种原因，但大多和缺乏硬件的了解脱离不 了干系。最好的解决办法是加强与基础设施架构师合作，共同对架构和设计进行评估架构无小事 很多系统建设初期的琐碎事情在架构师看来是些小事情