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

1、开发人员应该解决问题，而不是解迷取乐。

　　2、关键问题可能不是出在技术上：

• 不要把对话当成对抗
• 不要带成情绪与人沟通
• 尝试通过沟通设定共同目标

　　3、以沟通为中心，坚持简明清晰的表达方式和开明的领导风格。

• 让开发人员参与架构的制订过程，这样他们才会买你的帐！

　　4、架构才是影响应用性能和可伸缩性的决定因素，性能参数是无法简单地通过更换软件，或者“调优”底层软件架构来改善的。

　　5、分析客户需求背后的意义

• 架构师可以通过询问客户，分析客户要求的功能和需求的真正意义，定位真正的问题，从而提出比客户的建议更好、成本更底的解决方案。

　　6、让沟通事半功倍，起立发言是简单、有效的方法！

　　7、故障终究会发生。

　　8、量化需求

• 比如：必须在1500毫秒响应用户的输入。在正常负载（定义如下....）的情况下，平均响应时间必须控制在750~1250毫秒之间。由于用户无法识别500毫秒以内的响应，所以我们必须将响应时间降低到这个范围之下。

　　9、一行代码比五百行架构说明更有价值

• 如果你亲自参与开发，应该珍视自己花在写代码上的时间，千万别听信这会分散架构师精力的说法。参与项目所付出的努力，既能拓展你的宏观视野，也能丰富你的微观视界。

　　10、提前关注性能问题。

　　11、草率提交任务是不负责任的行为。

　　12、业务目标至上、掌握业务领域知识

• 架构师必须通过沟通协调，即保护软件架构，又坚持业务目标，即允许开发人员制定微观（技术）决策，又设法避免他们参与制定业务决策。如果技术决策脱离了业务目标目标和现实条件的约束，则无异于用宝贵的稀缺资源进行高风险的投机。

　　13、先确保解决方案简单可用，再考虑通用性和复用性。

• 许多用来实现基础设施的代码，包括组件框架、类库、基础服务，普遍存在一个问题，它们的设计一味强调通用性而不考虑具体应用，导致出现许多令人困惑的可选项和不确定因素，这些功能常常不是因为被闲置，就是被误用，甚至毫无价值。

　　14、架构师应该亲力亲为

• 对技术缺乏全面理解的架构师，充其量只是个项目经理。
• 架构师完全可以要求团队成员的帮助，让团队成员充分参与制订解决方案，同时引导讨论方向，找出正确的方案。
• 架构师应该尽早参与项目，与团队成员并肩工作，而不是坐在象牙塔里发号施令。

　　15、持续集成

• 尽早构建，经常构建。

　　16、避免进度调整失误

• 加快进度不一定会降低成本，要考虑交付质量和后期造成的影响，可以尝试去掉一些不重要的功能，留待后续版本发布。

　　17、取舍的艺术

• 世界上不存十全十美的设计，既具有高性能，又具有高可用性；既高度安全，又高度抽象；

　　18、不要轻易放过不起眼的问题

• 自已的盲点自己难以查觉，忠言虽然逆耳，却是你最宝贵的财富。
• 组织团队一起来想办法管理风险。

　　19、让大家学会复用

• 大家知道它们的存在
• 大家知道如何使用它们
• 大家认识到利用已有的资源好过自己动手

　　20、架构里没有大写的"I"

• 自我反省，做人问题。
• 重视团队合作，架构属于团队，不是你一个人的。你负责导航，大家一起划桨。双方缺一不可，但相比之下，你更离不开他们的帮助。
• 做技术的，保持谦虚是最基本的素质！

　　21、先尝试后决策

• 尽量推迟决定的时间，最后即便不做决策，决策也会自己呈现。
• 对同一个问题尝试两种或两种以上的解决方案，比直接决策然后动手实现的工作量要大。

　　22、程序设计是一种设计

• 把编写代码看成设计行为，而不是生产行为。

　　23、控制项目规模

• 抓住真正的需求
• 分而治之
• 设置优先级
• 尽快交付

　　24、架构师不是演员，是管家。

• 扎实掌握技术和业务领域知识，以严谨的领导风格赢得团队的尊重。

　　25、混合开发的时代已经来临

　　26、性能至上

• 尤其目前的互联网行业

　　27、学习软件专业的行话

• 比如架构和设计模式可以分成四大类，企业架构模式、应用架构模式、集成模式和设计模式。

　　28、具体情境决定一切

• 架构决策只有在情境需要时，才能牺牲尽量简单的原则。

　　29、侏儒、精灵、巫师和国王

• 软件架构师好比国王，应该熟悉各种人的性格特点，招聘不同性格的人加入自己的团队，英明的国王知道怎样用目标来激励不同的种族，率领大家并肩作战完成任务。

　　30、避免重复

• 复制是魔鬼
• 重复性的工作拖累开发进度

　　31、仔细观察，别试图控制一切

　　32、架构师当聚焦于边界和接口

• 低耦合，高内聚
• 定义系统边界

　　33、助力开发团队

• 确保开发人员拥有他们所需的工具
• 确保开发人员拥有他们所需的技能
• 只要不违背软件设计的总体目标，就让开发人员自己做出决策。
• 保护好开发人员，不要让他们卷入到不那么重要的工作中。

　　34、记录决策理由

• 不要为了写文档而写。
• 懂得《取舍的艺术》，定义软件架构，就是要在质量属性、成本、时间以及其它各种因素之间，做出正确的权衡。

　　35、分享知识和经验

　　36、模式病

• 使用模式解决适用的问题才是最重要的，禁止在项目中硬塞不必要的模式。

　　37、关注应用程序的支持和维护

• 应用程序超过80%的生命周期都是在维护上
• 理解开发人员和支持人员确实具有不同的技能
• 在项目中尽可能早地引入支持负责人
• 将支持负责人作为团队的核心成员之一
• 让支持负责人参与规划应用程序的支持

　　38、有舍才有得

• 接受某种约束或放弃某个特性，可带来更好的架构，这种架构在构建和运维上都会更加简单，而且成本底。

　　39、先考虑原则、公理和类比，再考虑个人意见和口味。

　　40、数据是核心

• IDE、操作系统、软件等都是工具。

　　41、不仅仅控制代码，也要控制数据。

• 源代码控制和持续集成，是管理应用程序构建过程和部署过程的优秀工具。数据方案和数据内容通常会随着源代码变化而变化，它们也是这一过程的重要组成部分，因此也需要对之进行类似的控制。
• 灵活运用“数据库脚本”解决问题。

　　42、确保简单问题有简单的解

• 对于简单的问题，不要采用复杂的解决方案。软件设计者都是聪明人，但是出于炫技心理，很容易陷入“杀鸡用牛刀”的误区。
• 对应第一条“开发人员应该解决问题，而不是解迷取乐。”

　　43、架构师首先是开发人员

• 作为架构师，主要目标应该是创建可行、可维护的解决方案，当然，也一定要能解决当前的问题。

　　44、根据投资回报率(ROI)进行决策

　　45、一切软件系统都是遗留系统

• 即使系统十分前沿，采用了最新的技术开发而成，但对于接手的下一个而言，它也会是遗留系统。
• 设计优化的架构基础，考虑如下几个问题：清晰性、可测性、正确性、可跟踪
• 可以参考一些优秀的开源项目

　　46、起码要有两个可选的解决方案

　　47、理解变化影响

• 优秀的架构师能够深刻理解变化带来的影响，这种影响不仅限于彼此隔离的软件模块之间，而且包括人与人之间，以及系统与系统之间。
• 变化有多种不同表现形式：功能需求的变化、可扩展性需求的演进、系统的接口被修改、团队人员流动等。
• 常用方法减轻变化的影响：运行小规模的增量渐变、构建可重复运行的测试用例、让测试用例更易编写、跟踪好依赖关系、系统性的行动，根据反馈信息作出进一步反应、自动化重复的任务。

　　48、你不能不了解硬件

• 学习硬件知识
• 和基础设施架构师紧密合作

　　49、现在走捷径，将来付利息。

　　50、不追求“完美”，“足够好”就行

• 在设计和实现上追求完美，会导致过度设计和模糊混乱的解决方案，最终使系统难以维护。应用程序开发不是选美大赛，因此，停止吹毛求疵的做法，不要再浪费时间追求尽善尽美。

　　51、小心“好主意”

• 那种诱人的、不用想都知道的、外表无辜、以为不可能会产生伤害的那种“好”主意。通常在项目进展到一半而似乎一切看起来都挻好——形势和进度都在循序渐进，初步测试进展顺利，落地日期看起来可靠无误——的时候，项目团队中有人会冒出这些想法。务必小心那些“好主意”，它可能会杀死你的项目。

　　52、内容为王

• 很多系统的成功取决于其内容的建设。

　　53、对商业方，架构师要避免愤世嫉俗。

　　54、架构师要以自己的编程能力为依托

• 对应“架构师首先是开发人员”

　　55、稳定的问题才能产生高质量的解决方案

• 只要问题是稳定的，你就可以创建出一个拥有稳定设计的系统。稳定的设计可以让你集中精力，打造出高质量的应用程序。

　　56、天道酬勤

　　57、弃聪明，求质朴。

　　58、对决策负责

• 重要的架构决策应该以书面形式记录下来，它们必须经过校核证实，并可被追溯。
• 必须和执行该决策及会直接或间接受其影响的人进行过沟通，达成共识。

　　59、精心选择有效技术，绝不轻易抛弃。

　　60、客户的客户才是你的客户！

　　61、事物发展总会出人意料

• 设计是一个不断发现的过程，发现问题并解决问题。
• 没有永不过期的解决方案。

　　62、着重强调项目的商业价值

• 形成价值陈述
• 建立量化的度量标准
• 回过头来关联传统商业的衡量方式
• 知道该在哪里停止
• 寻找恰当的时机

　　63、偿还技术债务

• 花合适时间“一次做对”！
• 取巧走“捷径”，争取尽快推出修改后以产品。

　　64、打造上手的系统

• 用户体验很重要
• 对最终用户而言，界面就是系统！

　　65、找到并留住富有激情的问题解决者

• 我们所要找的，是那种具备解决问题的能力和激情的开发人员，都善于攻克各种难题的人才。
• 提防批评过度，它可能会扼杀开发人员的创造力，降底生产力。
• 好的开发人员都非常聪明，他们知道自己并非一无是处，如果你对其工作吹毛求疵，将会降低他们对你的尊重！
• 以正确的方式经营开发团队，其重要性不言而喻。

　　66、学习新语言

• 想要理解客户或者想让客户理解你的语言，必须学习客户所在行业领域的语言，这样才能做到有效沟通。

　　67、优秀软件不是构建出来的，而是培育起来的。

• 设计尽可能小的系统，帮助成功交付，并推动它向宏伟的远景目标不断演化。注意，不要把这种演化式方法和削减需求、规范混乱和生产废品这样的做法混淆在一起。