软件架构师应该知道的97件事

来源：互联网发布：mac土豆视频下载编辑：程序博客网时间：2024/05/17 23:00

客户需求重于个人简历：把客户的长远需求摆在自己的短期利益之上，信誉远胜过时髦的编程技巧和流行的范式。
简化根本复杂性，消除偶发复杂性。
关键问题可能不是出在技术上：人才是项目成败与否的基础，帮助团队成员完成项目。对话，尊重他人，给予团队成员充分信任。
以沟通为中心，坚持简明清晰的表达方式和开明的领导风格。
架构决定性能：架构是影响应用性能和可伸缩性的决定因素。
分析客户需求背后的意义：通过询问客户，分析客户要求的功能和需求的真正意义，定位真正的问题，从而提出比客户的建议更好，成本更低的解决方案。
起立发言：让沟通事半功倍。
故障终究会发生：如果不事先设计好防范故障的模型，就无法应对威胁系统安全的意外情况。
我们常常忽略了自己在谈判：跟项目投资人谈判时，绝不能在对方的第一个要求上妥协让步。
量化需求。
一行代码比五百行架构说明更有价值。
不存在放之四海皆准的解决方案：坚持培养和训练“情景意识”（contextual sense）。
提前关注性能问题：尽早反复地展开性能测试可以缩小问题的可疑范围。
架构设计要平衡兼顾多方需求（相关各方的业务需求和项目的技术需求）。
草率提交任务是不负责任的行为。
不要在一棵树上吊死：采用多种表现方式，多种传输方式，通过分解系统的非功能参数，可以为客户提供多样化的解决方案。
业务目标至上：用业务目标驱动项目开发，才能保证软件开发团队的长远利益。
先确保解决方案简单可用，再考虑通用性和复用性：具体情况要具体分析，有针对性地解决方案才有价值。
架构师应该亲力亲为：通过示范领导团队，展示自己的实践能力。
持续集成：持续集成工具会尝试对项目进行构建，然后展开测试。借助它，可以取得更稳定，更符合要求的开发成果。可以提高公司和开发团队的工作效率，改善工作效果。
避免进度调整失败。
取舍的艺术：妄想实现所有需求，只会产生脆弱的，一无是处的架构。
打造坚固的数据库堡垒。
重视不确定性：优良架构能够从整体上降低设计决策的重要性,从而可以建设性地利用不确定性,将系统和进度分割开来。
不要轻易放过不起眼的问题。
让大家学会复用。
架构里没有大写的"I"：杜绝强烈的“自我意识”。
使用“一千英尺高”的视图：合适的视图提供的信息来自恰当的层次，使得判断软件质量更客观。
先尝试后决策：对同一个问题尝试两种或两种以上的解决方案，比直接决策然后动手实现要好，可能是代价最低的选择。
掌握业务领域知识。
程序设计是一种设计。
让开发人员自己做主。
时间改变一切：选择值得投入精力的工作，简单原则，别跟以前的工作过不去。
设立软件架构专业为时尚早。
控制项目规模：抓住真正的需求，分而治之，设置优先级，尽快交付。越复杂的架构越难成功实现。缩小项目规模通常会降低架构的复杂性。
架构师不是演员，是管家。
软件架构的道德责任。
摩天大厦不可伸缩：一次只部署一个组件，设计清晰的组件间接口。尽早发布，递增式部署。尽早部署独立的组件既可增加商业利润，又可以改善架构品质。
混合开发的时代已经来临：组合若干开发工具，挑选合适的编程范式。跳出原有的思维模式，充分挖掘软件的多元化特性。
性能之上。
留意架构图里的空白区域（架构图里未显示的内容）。
学习软件专业的行话：掌握基本的架构模式和设计模式，学会识别不同的模式，并借助它们和同行及开发人员进行交流。四大类架构和设计模式：企业架构模式，应用架构模式，集成模式，设计模式。
具体情景决定一切。
侏儒，精灵，巫师和国王：架构是一个指南，为不同性格的团队成员安排合适的任务，让大家在工作过程中相互学习。
向建筑师学习。
避免重复：复制是魔鬼，重复性的工作拖累开发进度。为了消灭重复，应该重新研究框架，创造更完善的抽象机制。
仔细观察，别试图控制一切：妄想掌控一切只能设计出紧耦合，脆弱的解决方案。先构建出灵活的架构，然后再从实际的系统状态中提取模型。仔细观察，提取模型，然后检查验证。
架构师好比两面神：综合考虑新情况与老经验，在成熟的基础上不断创新，既满足当前的业务需求，又兼顾未来的发展规划。
架构师当聚焦于边界和接口：低耦合，高内聚，接口定义良好。
助力开发团队：确保开发人员拥有他们所需的工具；确保开发人员拥有所需的技能，确保他们能够获得必需的培训；尽可能参与到开发人员的选拔过程中；只要不违背软件设计的总体目标，就让开发人员自己做出决策；保护好开发人员，不要让他们卷入到不那么重要的工作中。
记录决策理由。
挑战假设，尤其是你自己的。
分享知识和经验：如果能帮助周围的人不断改善，他们也会帮助我们发挥出全部的潜力。
模式病：不要让一展设计模式的功力的欲望，遮蔽了务实的真知。应当保持对系统的洞察力，提供切实有效的商业解决方案，使用模式解决适用的问题才是最重要的。
不要滥用架构隐喻：只将之勇于探索性的沟通，不要反让它拖了后腿。
关注应用程序的支持和维护。
有舍才有得：接受一些权衡，往往能产生富有创造性和创新性的结果。
先考虑原则，公理和类比，再考虑个人意见和口味。
从“可行走骨架”开始开发应用：从“可行走骨架”开始，保持系统一直运行可用，增量式地进行培育，使其逐步成长。
数据是核心。
确保简单问题有简单的解。
架构师首先是开发人员：如果是你做的系统设计，你也应该能够编程实现自己给出的设计。
根据投资回报率(ROI)进行决策：将架构决策视为投资，并将相关的回报率也一并考虑在内。在判断每个决策选项是否务实或恰当时，这种方法很有用。
一切软件系统都是遗留系统。
起码要有两个可选的解决方案。
理解变化的影响：不但能够将复杂性降到最低，在解决方案中给出的抽象，应该能够为更高层次提供坚实基础，同时，还应该能足够务实地应付未来的变化。进行小规模的增量渐变；构建可重复运行的测试用例，并经常运行；让测试用例更易编写；跟踪好依赖关系；自动化重复的任务。
应该了解硬件：架构师既要负责连接业务需求和软件解决方案，也要负责连接硬件和软件。
现在走捷径，将来付利息：碰到架构问题或设计缺陷，一定要坚持成本还很低廉的时候就动手。搁置越久，为之付出的利息也将越高。
不要追求“完美“，“足够好“就行。
小心“好主意”。
内容为王。
对商业方，架构师要避免愤世嫉俗：要找到能和业务方建立良好关系的方法。
拉伸关键维度，发现设计中的不足。
架构师要以自己的编程能力为依托：不要在设计里使用自己没有亲自实现过的模式，不要使用自己没有用之写过代码的框架，不要使用自己没有亲自配置过的服务器。
命名要恰如其分：如果无法给出合适的命名，那也就无法继续编程。
稳定的问题才能产生高质量的解决方案：将整体分解为稳定的问题块（内聚性，能够很好地和其他块分隔开）。
天道酬勤。
对决策负责。
弃聪明，求质朴。
精心选择有效技术，绝不轻易抛弃。
客户的客户才是你的客户。
事物发展总会出人意料：设计是一个不断发现的过程，是在不断变化的世界中持续进行探索试验的过程，设计过程必须保持灵活性和连续性。
选择彼此间可协调工作的框架：系统应该由多个相互独立的框架组成，其中每个框架都精专于各自的领域，但同时又非常简洁，包容，和灵活。
着重强调项目的商业价值。
不仅仅只控制代码，也要控制数据：数据库的变化不应该影响构建活动的连续性。要把数据库也作为一个构建单元包含在内，做到一次性构建整个应用程序。
偿还技术债务：“脏但快速”的修复完毕后，记得安排开发人员回头去妥善修复解决，纳入下一个计划发布的版本中。
不要急于求解：不要立即着手去解决摆在面前的问题，而要看看自己是否可以改变问题，想想，如果根本不存在这个问题，系统架构会是怎样的？
打造上手的系统（用户体验，轻巧便利）。
找到并留住富有激情的问题解决者。
学习新语言（业务术语等）。
没有用不过时的解决方案：选择能够满足当前需求的最好解决方案。
用户接受度问题。
清汤的重要启示：软件架构应当不断精炼浓缩，反思各种构想，直至可以确定系统中每个需求的本质。
对最终用户而言，界面就是系统：不仅要让最常用的交互易用，而且要使最终用户能够从中获得回报。
优秀软件不是构建出来的，而是培育出来的：设计尽可能小的系统，帮助成功交付，并推动它向宏伟的远景目标不断演化。