2、简化根本复杂性，消除偶发复杂性：
根本复杂性是问题本身就很复杂，所以它是无法避免的。偶发复杂性是在解决根本复杂性的过程中衍生的，即解决方案本身带来的新问题。如为了解决某个问题而设计的一个软件框架，设计该框架本身，就是引入的偶发复杂性。所以，如果原本问题比较简单，但设计或引入一个太过灵活的框架，可能得不偿失。(避免过度设计)
3、关键问题可能不是出在技术上：
简单的项目也可能会出现问题，这并不是因为我们选错了某种语言或者系统，根本原因还是在于人。所以，要帮助团队完成项目，多与项目成员沟通，及时改正团队成员不正确的工作方式。
4、以沟通为中心，坚持简明清晰的表达方式和开明的领导风格：
5、架构决定性能：
如果性能有问题，尽量“调优”架构来解决问题，如果无法带来理想的性能和可伸缩特性，则应重新设计架构的内在逻辑和部署策略。
6、分析客户需求背后的意义：
分析客户提的需求，为什么提这样的需求。即要知道客户要求的功能和需求的真正意义，这样或许我们可以在达到客户目的的情况下，采取成本更低的解决方案。
7、起立发言：
在多人场合发表意见时，起立发言非常重要，尤其是其他人坐着的时候。站立时，无形中增添了一种权威和自信，容易控制了场面。听众不会轻易打断你的发言。站立时可以更好的利用肢体语言，且在十人以上的场合，起立发言方便与每位听众保持视线接触。眼神交流和肢体语言等表达在沟通中的作用不可小觎。起立发言也更容易控制语气、语调、语速和嗓门，让声音传播的更远。讲到重点时，注意语速的减缓，发声技巧也能改善沟通效果。
8、故障终究会发生：
为了防止A程序出错，增加了监控程序B，但监控程序B本身就可能会出错。所以故障及错误是无法避免的，即要做好错误的防范措施。
9、我们常常忽略了自己在谈判：
项目投资人为了削减预算，可能会去掉一些“东西”。当投资人问“我们真的需要这东西吗？”很多工程师把自己摆在了工程师的位置，会回答一些不使用这些东西的替代方案，但往往这些替代方案是极差的。在投资人看来，有其它方案可选，他不关心是什么方案，他往往会让你去掉这些“东西”。我们这时应该把自己放到谈判者的角度上，说明不使用该方案的坏处，以及使用该方案的好处。让投资人清楚的认识到该方案的重要性。
10、量化需求：
11、一行代码比五百行架构说明更有价值：
要牢记我们的目标是可工作的代码，设计只是手段。很多架构师往往被抽象的架构所吸引，沉迷于设计过程。没有天生完美的设计，设计都是在实现过程中逐步完善的。如果有机会亲自开发，珍惜这个机会。
12、不存在放之四海皆准的解决方案：
没有通用的解决方案，遇到的问题也是千差万别，架构师需要运用情境意识来解决问题（类似于常识）。情境意识需要培养和训练，架构师要不断的积累案例和经验才能建立足够的情境意识。要解决系统层次的问题，通常需要十年的磨练。
14、架构设计要平衡兼顾多方需求：
软件架构不仅包含系统建模、定义接口、划分功能模块、套用模式、性能优化等，还包括系统的安全性、易用性、产品支持、发布管理、部署方式等其它部门关心的问题。
15、草率提交任务是不负责的行为：
16、不要在一棵树上吊死：
没有什么架构、策略、观点能解决所有的业务问题，我们要承认世界是混乱的，解决方案也是多样的、不一致的。
17、业务目标至上：
架构师必须成为业务部门和技术部门之间沟通的桥梁，兼顾双方的利益，用业务目标来驱动项目开发。架构师要评估项目商业价值，以高的投资回报率作为目录，避免作出错误的技术决策。要谨慎的站在业务团队一边，用业务目标驱动项目开发，才能保证软件开发团队的长远利益。在软件形成产品过程中，需要持续的根据反馈制定决策，软件开发人员可以制定微观技术决策，业务决策由业务部门来制定。
18、先确保解决方案简单可用，再考虑通用性和利用性：
19、架构师应该亲力亲为：
20、持续集成：
源码的提交或变更触发工具对项目进行自动构建、自动测试，反馈结果。早集成，频繁的集成可以帮助项目在早期发现项目风险和质量问题，如果到后期才发现这些问题，解决问题代价很大，很有可能导致项目延期或者项目失败。
21、避免进度调整失误：
22、取舍的艺术：
世上不存在十全十美的设计——即高性能又高可用性，即高安全又高抽象。架构权衡分析方法(ArchitectureTradeoffAnalysisMethod,ATAM)、成本收益分析方法(CostBenefitAnalysisMethod,CBAM)都是帮助架构师做出取舍的工具。
23、打造数据库堡垒：
不管业务如何发展、人员如何变动，数据总是不变的，且会永远保存下来，所以创建牢固的数据模型要从第一天开始。数据库的出错是灾难性的，一旦数据被破坏，即使后面修复了数据层的设计问题，丢失的数据也无法恢复了。要充分发挥关系型数据库的作用，让它成为应用的一部分，从开始构建数据库时，就要深刻地理解业务需求。虽然普通开发方法中敏捷被证明是非常好的方法，但对数据库的设计还是要保守，开始之前要认真设计。
24、重视不确定性：
在设计过程中，面对多种可能方案举棋不定时，要仔细考虑采用哪一种方案，或者推迟决定，当收集到更多的信息时，再做出后续的更好的选择。但也不能太迟，要赶在这些信息失效前利用它们。如果对着代码反复琢磨但仍无法决定采用哪种实现方式时，实现时设法利用分离或封装将决策和最终依赖于决策的代码隔离开，这样在决策变更时可以尽量降低成本。优秀的架构会把这个变更成本降的尽量低。
25、不要轻易放过不起眼的问题：
26、让大家学会复用：
让大家知道你的框架、库或设计，然后让大家知道它如何使用。一般有经验的人都喜欢寻找已有的解决方案。
27、架构里没有大写的"I"：
架构师不能自负，别人批评我们的设计时，要学会接受与学习。要避免认为自己比客户更懂需求或把开发人员当作资源，要与客户密切合作，驱动架构的是需求，不是架构师，你的任务是竭尽所能满足需求。要重视团队合作，架构是属于团队的，经常检查自己的工作以及反省自己，要杜绝“自我意识”引发的一些常见问题。
此后转自豆瓣：
28、使用“一千英尺高”的视图
30.掌握业务领域知识
31.程序设计是一种设计
代码即文档，写代码即是设计行为，而非生产行为。
32.让开发人员自己作主
应该给自己的团队足够的自主权，让他们发挥自己的创意和能力。不要过于拘泥于细节，要为开发人员创造一个良好的开发体验，如自己设计的API是否易于理解及使用，如果经常被误用，应该怎么修改。而且要创造一个良好的氛围，让大家主动起来，如果遇到什么问题，及时的向你征求意见。
让结果说话，认真执行KISS原则。现在的设计，可能会被两三年之后的自己所否定，同样，以前的设计也容易被自己否定，所以不要跟以前的工作过不去。
34.设计软件架构专业为时尚早
软件开发仍处于相对初级的尝试阶段
35.控制项目规模
尽量控制和缩小项目规模，提高项目成功机会。
a)抓住真正需求
b)分而治之
c)设置优先级
d)尽快交付
36.架构师不是演员是管家
炫耀和作秀放到市场营销上去，而不是设计中，架构师应该把自己看成管家，承担着管理他人资产的责任，为客户利益着想。
37.软件架构的道德责任
38.摩天大厦不可申缩
软件相对建筑，扩展新功能要简单的多，而且产品发布越早，公司的净收益就会越高，所以，应用软件只要具备了用户要求的关键功能就可以发布了。提早发布，还能持续改善软件架构的品质。
39.混合开发的时代已经来临
混合编程是指在同一套软件系统中同时采用多种核心编程语言。把若干强大的工具组合起来，形成更巧妙的解决方案。
59.先考虑原则、公理和类比，再考虑个人意见和口味
60.从“可行走骨架”开始开发应用
63.架构师首先是开发人员
65.一切软件系统都是遗留系统
66.起码要有两个可选的解决方案
67.理解变化的影响
68.你不能不了解硬件
70.不要追求“完美”，“足够好”就行
72.内容为王
73.对商业方，架构师要避免愤世嫉俗
74.拉伸关键维度，发现设计中的不足
75.架构师要以自己的编程能力为依托
76.命名要恰如其分
77.稳定的问题才能产生高质量的解决方案
78.天道酬勤
79.对决策负责
很多失败的项目，究其根本原因，是因为做出了不当的决策，或无法执行正确的架构决策。做出有效决策的方法：
a)对决策过程有充分的认识（决策以书面形式记录下来了，与决策执行人沟通过）
b)定期对架构决策进行复审，检查决策的实际效果和预期结果。
c)要贯彻架构决策，架构师不仅要参与设计阶段，后续仍然要持续跟进。
d)可以将一些决策交给问题域专家。
80.弃聪明，求质朴
小聪明会诱导我们在软件开发中使用奇技淫巧。聪明的设计僵硬难改，细节会对全局产生太多的牵扯。质朴的方案中，每个组件只做一件事，组件耗时少，易于创建，以后维护也更容易。
81.精心选择有效技术，绝不轻易抛弃
软件架构师工作很大的一部分，是要选择用以攻克难题的合适技术。精心选择熟悉的武器，不到万不得已，不要轻易排序它们。选择新技术虽然有风险，但其价值在于往往能为你带来质的飞跃。不过仍然要谨慎选择。
82.客户的客户才是你的客户！
想象你的客户并不是你的客户，而你客户的客户才是你的客户，这样你的客户的客户赢了，你的客户也就赢了。例如，你为某个机械开发一个网站，你要想到使用这个网站的最终用户！如果你的客户有意无意的忽视他们的客户所看重的重要事项，这个时候你就需要考虑与你的客户沟通、甚至放弃这个项目。
83.事物发展总会出人意料
设计是一个不断发现的过程，不要开始试图把设计做的很完美。在开发过程中，可能不断有一些微小的变化，这些变化积累起来就需要对设计进行一次大的变更，如果还是试图维持住已经走样的设计，就会越破坏原设计。
84.选择彼此间可协调工作的框架
85.着重强调项目的商业价值
a)形成价值陈述。即你的决策摘要，用以说明组织的业务为何要采用特定的软件架构。重点要放在该架构如何提高生产力、改进业务效率等。不要强项这种技术如何高明。
b)建立量化的度量标准。量化越具体，项目也将越具有说服力，越能让人相信好的架构可以带来丰厚回报。
c)回过头来关联传统商业的衡量方式。如果能将技术分析转化为财务数据，则更有说服力。
e)寻找恰当的时机。
86.不仅仅只控制代码，也要控制数据
在架构规划过程中，数据迁移部分经常被架构师忽略。最后数据迁移往往是作为一项事后补救描述，而且整个过程由手工完成，相当脆弱。对数据方案和数据内容的管理，应当尽早无缝集成到自动化的构建和测试过程中，还必须提供回退功能.
87.偿还技术债务
当已投入实用的项目出现了问题，往往会出现两个选择：
b)走“捷径”，完全为了满足当前的bug而填的一些代码，可以很快的推出修改的产品。
88.不要急于求解
首先看看是否可以改变问题。
89.打造上手的系统
我们是工具制造者，我们制造的系统一定要帮助人们做事，否则就推动存在的意义。“上手”即容易使用的工具。
90.找到并留住富有激情的问题解决者
优秀的团队是项目成功非常重要的原因！也要保持团队的稳定！打造健康的工作环境。好的开发人员，常常能从认可中获得强烈的激励。提防批评过度，批评过度可能会扼杀开发人员的创造力，降低其生产力。可以提出建设性的批评建议，但不要强求每个解决方案看起来好像都出自你手。以正确的方式经营开发团队。如同团队成员并肩作战，对他们一视同仁，培养团队精神等。
91.软件并非真实存在
软件是我们创造的虚拟物，相对于物理世界中的对应物，更易于改变。所以产品的需求可能会不断发生变化，计划不断调整。
92.学习新语言
94.用户接受度问题
去了解与衡量接受度问题带来的威胁，并朝能减轻这些威胁的方向开展工作。比如找代表用户利益的项目拥戴者，与用户进行直接的沟通并影响用户的接受度。（接受度：如用户不想接受一个新的系统，人们不愿意实施新的系统等）
95.清汤的重要启示
清汤是不断精练与浓缩才成的，软件架构也应该学习清汤的制作方法。
96.对最终用户而言，界面就是系统
要让界面易用，好的界面能帮助用户提高生产力，用户会因此更加喜欢我们的产品。用户交互实际和健壮性、性能等一样重要的。