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