软件架构师应该知道的97件事读后感(转)
客户需求高于一切 不要为了自己的项目经历上添加光彩而去一味追求时髦而光鲜的方案，而是应该扎根客户需求，脚踏实地地为客户着想，这样才能更体现技术的价值，不至于迷失方向。架构师首先不要把自己当做技术人员，而是业务人员，把实现业务需求作为至上的目标，学会拒绝成本高，性价比不高的技术。 简化根本复杂性 常常为了解决某一局部复杂性引入了更为复杂的框架或产品，使得复杂性不减反增。往往正确的方式是做减法而不是加法，把最根本的复杂源找到，把根铲除。 关键问题可能不是出在技术上 总结失败的项目常常会纠结于选择了错误的技术。其实技术并没有错，而是在使用技术上或是在执行过程中人为的偏差导致。而架构师解决这种人为的问题比较好的方式是沟通，通过有效地沟通把技术贯彻下去 以沟通为中心，坚持简明清晰和开明的风格 架构师不要坐在象牙塔里，命令开发人员实施你的设计和决策，而是应该尽量简化你的设计，透彻地与他们沟通，并且关键在于开明地接受他们的建议并勇于推翻自己的决策 架构决定性能 最好提升性能的方法不是痛苦地做一次次对即将上线的产品做性能测试和提升，而是在架构设计的时候就把性能作为重要因素，从架构底层考虑分布式、缓存、系统交互划分等影响性能的重点。提前关注性能，是解决性能问题代价最小的方式 分析客户要求背后的真实需求 合同上或UC上只是客户的要求，而并非100%是客户真实的需求，架构师的重要责任就是挖掘隐藏在要求背后的真实需求，这个不但可以最大化满足客户，也往往可以帮助我们避开技术壁垒，当真正抓住客户需求的时候，我们也许能用更为简单的替代方案满足客户 沟通是架构师达成目标的核心技能 常用的沟通技能和准则有以下几点： * 不要把沟通当做对抗 * 不要带有情绪与人沟通 * 表达自己方案之前倾听他人观点 * 站立发言是扩大沟通影响力的一种好方式 * 学习业务或技术领域中的行话，降低沟通成本 不要为预防故障引入更多的故障 架构师常常会为识别出的可能故障点加入监控措施，但往往会忽略做些监控措施也是会有故障的，不要试图让你的系统天衣无缝，这往往是使系统更为复杂和脆弱的来源。先承认是系统总会有缺陷的，只是把这些缺陷设定为容易察觉和维护的点 量化非功能性需求 往往功能性需求容易量化，因为这些是看得见和摸得着的，但像性能好、可扩展性好、高可用性等这些非功能性需求却不好量化，但作为架构师要有意识地去定义和量化这些需求，只有这样才能更好地和其他部门更好沟通，谋求更多资源，也便于系统更有效地验收 一行代码比500行架构说明更有说服力 架构师往往喜欢待在象牙塔里，堆砌大量架构文档，然后希望其他开发人员能乖乖地去实施。这样做的效果往往是不好的，一方面很难有这样的牛人能洞察所有的细节，在文档里就预测性地解决了所有问题，另一方面也不利于架构师与开发人员的沟通。比较好的做法是架构师参与具体实施，在实施中验证和改进架构设计，与大家达成一片也便于加深彼此配合的默契程度。 不存在放之四海皆准的解决方案 不存在最好的架构，只有最合适的架构。不会有一种架构方案，在任何项目里都适用。虽然我们承认模式的重要性，但在实际项目里要有选择性吸收，根本上要本项目和实际困境出发，不要被既有的模式和经验先入为主，因为没有一种已有方案能完全不修改地适用于你。 架构设计要平衡兼顾多方需求 架构师从某种角度来讲就是一剂胶水，把业务部门的需求、项目进度的需求、测试的需求和开发工程师本身的需求有效地捏合在一起，平衡与兼顾以至达到皆大欢喜。其他职能的人都只是focus在某一局部，需要架构师这样的人来通盘考虑，因此他的工作是最杂的，绝不是简简单单地拿出一份架构文档就OK了，需要考虑系统安全、易用性、可测性、商业价值、长期规划、发布管理和部署方式，使得各个部门人的需求得到响应。 先确保解决方案简单可用，再考虑通用性和复用性 系统的复杂性往往是架构师基于通用性和复用性的设计而引入的，很多具体问题往往不需要通用性和复用性的解决方案。如果存在多个可实施方案难以取舍，先简单后通用原则可以成为最终的评判标准。架构师提供具体解决方案时，无需排斥通用和灵活，但是如果过早脱离具体情况，只会迷失在无限的可能性里，被复杂的配置选项、超负荷的参数列表、冗长罗嗦的接口，以及存在缺陷的抽象所淹没。先简单满足需求，当重复需求再次发生时，通过重构来达到复用是一种不错的方式 架构师应该亲力亲为 架构师干久了往往会脱离技术本身，迷茫在抽象之中，这是很危险可怕的。架构师要取得其他同事的信任，应该比业务人员更懂业务，比开发人员更懂具体的编码，比测试人员更懂如何有效地测试，就像航班的主驾驶员，虽然不需要亲自操作，但经验丰富，持续地监视着情况，一旦发现异常随时采取行动。架构师应该项目的交付和质量负有最终的责任。架构师应该尽可能地参与项目，不能把技术决策和方向上的难题拆分出扔给别人，需要采取更务实的办法，比如亲自动手研究或和其他成员讨论。 持续集成是架构师的重要任务 普通的开发人员会focus在各自负责的小模块，只会对单个模块负责，而架构师需要对整个系统负责，持续集成是一种对整个系统进行有效控制的好方法，架构师有责任让它运行起来。 避免进度调整失误 虽然保障进度是PM的职责，但变更要发生的时候，作为对技术最有发言权的'架构师应该站出来，把变更的必要性和风险进行仔细分析，最大限度地支持PM的决策。 取舍的艺术 我们做系统，特别是互联网系统，绝不是做一个变形金刚，而是做一个有缺陷但却满足了现阶段商业需求的系统，因此架构师需要有取舍的艺术，你的架构是能用有限的资源满足最迫切的需求，舍掉那些看是光鲜却无太多用处的东西 打造数据库堡垒 在上层的程序设计中，架构师一般都会推崇先简单实现，然后在逐步重构的敏捷方式，但对于较为稳定的后端数据库，我们需要采取更为谨慎的态度，因为数据库是整个系统的基石，无论是业务设计还是技术设计都得保持它的稳定性，这是整个系统稳定的基础。我们往往会发现这么一个现象，当程序第一版上线后，数据库里表只会增加不会删除，也不会删除多余的字段，每次数据库变更都会引起所有人的紧张，也会使得本已混乱的数据库设计更为混乱。 重视不确定性 优良的架构能够从整体上降低设计决策的重要性，糟糕的架构则会使得常常突出选择的重要性。如果出现两个合理地选择，架构师应该停下来，设法找出介于两者之间的、具有更低重要性的决策，了解两者之外还存在其他选择，比决策结果本身更有价值 不要轻易放过不起眼的问题 项目的失败或线上故障往往是由于项目过程中的不起眼问题所引起，比如一些特殊的边界情况，而这些问题绝不能指望开发主力们去发现和解决，因为他们的注意力都会focus在主要矛盾上，作为时刻监控项目的架构师应该担当起发现这些“小bug”的义务。 让大家学会复用 架构师有义务提高开发人员可复用地解决问题的意识，比如以上几种措施： * 让大家把自己能复用的代码及时共享给他人 * 加强复用代码的易用性，避免误用 * 让大家认识到已有资源好过自己动手 架构文档的抽象程度要适中 架构师写架构文档常常很纠结，写得太高层次的话就太空洞，无切实的指导意义；写得太具体的话，比如指明到类的各种UML图，就会很约束开发人员。文档要写到什么程度，关键在于满足他人的需求，比如业务部门想从文档中得知系统各功能的实施可行性，因此你的文档要能体现各主要功能是如何满足的。测试人员想知道系统内部如何流转和如何对系统进行测试，因此你的文档要体现系统主要模块的运行流程和系统可测试性。开发人员需要知道系统各自模块的划分和之间的交互规范，因此你的文档要体现模块化设计。PM需要知道这个项目有哪些风险点，因此你的文档要体现风险点识别和如何规避。DBA和运维人员需要知道系统的数据量和性能情况，因此需要指明系统如何应对大数据量的情况。关键一点，架构师不是为了设计而设计，是要想清楚别人为什么要看你的文档，怎样满足别人的需求 先尝试后决策 设计中有很多需要决策的点，很多架构师喜欢在象牙塔里凭借经验做决策，感觉这就是架构师需要干的。其实，这样的做法往往会让你很被动，不如延迟决策，把需要决策的点抛出来，让大家去尝试，在实践比较中，其实无须决策，正确的选择自然就出来了，这样也更能拉近你和大家的距离，提高大家的积极性和你的权威性 掌握业务领域知识 架构师的角色任务在于理解业务问题、业务目标、业务需求、并设计技术架构来满足它们。掌握业务领域知识将有利于架构师选择合适的架构模式，更好地制定针对【软件架构师应该知道的97件事读后感(转)】相关文章：
真正的男人应该知道的20件事01-18
面试前应该知道的10件事01-01
关于动力，你应该知道的六件事01-18
女生应该偷偷知道的13件事 -资料01-01
应该知道的知识10-25
做交互应该知道的视觉几件事 -电脑资料01-01
软件架构师岗位职责范文01-17
软件架构师个人简历模板02-10
软件架构师的沟通修炼 -管理资料01-01