架构师应该知道的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、优秀软件不是构建出来的，而是培育起来的。
设计尽可能小的系统，帮助成功交付，并推动它向宏伟的远景目标不断演化。注意，不要把这种演化式方法和削减需求、规范混乱和生产废品这样的做法混淆在一起。