根本复杂性（essential complexity）指的是问题与生俱来的、无法避免的困难。...与之相反，偶发复杂性（addidental complexity）是人们解决根本复杂性的过程中衍生的。...架构师的责任在于解决问题的根本复杂性，同时避免引入偶发复杂性。
《简化根本复杂性，消除偶发复杂性》Neal Ford
大多数项目是由人完成的，人才是项目成败与否的基础。如何帮助团队成员完成项目，这个问题很值得静下心来好好思考。
关于对话的技巧非常多，但有几个简单的技巧可以显著改善对话的效果：
1.不要把对话当成对抗。如果你能看到他人的优点，并把沟通视为请教问题的机会，就会有所收获，同时也能避免引起对方的戒备之心。
2.不要带着情绪与人沟通。当你处于愤怒、沮丧、烦恼，或者慌张的情绪中时，对方很可能会误认为你的举动不怀好意。
3.尝试通过沟通设定共同的目标。有些人开会时喋喋不休影响别人发言，与其命令他闭嘴，不如请他协助你提高其他人的参与度。告诉他有些同事比较内向，发言前需要安静地理清思路。请他在每次发言之前稍作等待，让同事有机会表达意见。
首先与同事达成一致的目标，把处理冲突和矛盾的过程视为学习的机会，控制住自己的情绪，那么每次沟通都会有所收获，你会做得越来越好。
《关键问题可能不是出在技术上》Mark Ramm
以沟通为中心，坚持简明清晰的表达方式和开明的领导风格。Mark Richards
让沟通事半功倍，起立发言是最简单、有效的方法！《起立发言》Udi Dahan
工程师总是想尽办法寻求合作，谈判者则绞尽脑汁占得先机。谈判时，绝不能在对方的第一个要求上妥协让步。《我们常常忽略了自己在谈判》Michael Nygard
众所周知，坚持技术测试是需要耐心和毅力的，无论是搭建合适的测试环境，采集适当的数据集，还是编写必要的测试用例，都须要投入大量的时间。提前开展性能测试，能让你有条不紊地逐步完善测试环境，为解决性能问题节省下大量的时间和精力。《提前关注性能问题》Rebecca Parsons
以维护流程通畅为重，以浪费他人时间为耻。《草率提交任务是不负责任的行为》Niclas Nilsson
如果存在多个可实施方案难以取舍，“先简单后通用”原则可以成为最终的评判标准。挑选基于具体需求的简单方案，放弃鼓吹通用性的负责方案。而且简单的方案在实践中完全有可能表现出更好的通用性。退一步来说，修改简单方案满足需求，也比修改通用方案容易，因为通用方案常常在最关键的地方使不上劲儿。
追求随心所欲的灵活性，会使人们在无意中错失（有些人甚至故意忽略）更简单的设计和更有价值的特性。《先确保解决方案简单可用，再考虑通用性和复用性》Kelin Henney
称职的架构师应该通过示范领导团队。他能胜任团队的所有工作，从网络布线到配置构建流程，从编写单元测试到担任测试工作。对技术缺乏全面理解的架构师，充其量只是个项目经理。《架构师应该亲力亲为》John Davies
架构师应该明白鱼和熊掌不可兼得的道理。世上不存在十全十美的设计——既具有高性能，又具有高可用性；既高度安全，又高度抽象；有一个真实的历史事件，软件架构师应该烂熟于心，在与客户或同事沟通时能派上用场。这就是瓦萨号战舰的故事。
17世纪20年代，瑞典和波兰之间爆发战争。瑞典国王迫于战争经费的压力，急欲速战速决，他下令建造一艘名为瓦萨号的战舰。这可不是一艘普通的战舰，其设计要求绝非同时代战舰可比：战舰长60米，两个炮台上配备64门舰炮，可以将300名士兵从水路安全运送到波兰。时间紧迫，资金紧张，而且设计师从未设计过这种规模的战舰，只能凭经验和猜测着手设计。最终，工匠们按照设计说明建造了战舰。下水那天，瓦萨号在隆重的仪式中驶入海港，鸣完礼炮后，径直沉入了海底。
瓦萨号的问题很明显。参观过17、18世界大型战舰的人都知道，甲板上空间有限而危险，作战时情况更糟。建造一艘既能作战又能运兵的战舰是一个巨大的错误。设计师为了满足国王的心愿，设计了一艘性能失衡、不堪一击的战舰。《取舍的艺术》Mark Richards
《不要轻易放过不起眼的问题》全文 Dave Quick
即便是最精美的架构，最优雅的框架，可复用性最高的系统，也必须满足下面的条件才可能被复用。
大家知道他们存在；
大家知道如何使用他们；
大家认识到利用已有资源好过自己动手。
《让大家学会复用》Jeremy Meyer
《架构里没有大写的“I”》全文 Dave Quick
两条公认的软件开发的真理：
复制是魔鬼；
重复性的工作拖累开发进度。
消灭重复的内容是你的责任，为此，应该重新研究框架，创造更完善的抽象机制，请专门制作工具的程序员帮你完成切面框架，或者使用代码生成器。要想消灭重复内容必须有人采取行动。
这个人就是你。
《避免重复》Niclas Nilsson
计算机科学家设想的完美世界正在崩溃，我们该怎么办？克服所有困难的步骤都一样，首先要接受现实。向令人怀念的调用堆栈架构告别吧，忘掉那些程序员决定程序流程的日子，准备好应付随时出现的乱序事件，不断根据具体情境调整策略。用异步的、并发的请求代替一个接一个的方法调用。设计应用时，借助事件驱动的过程链模型或状态模型控制无序的状况，通过调整、重发，甚至试探的办法纠正错误。
《欢迎来到现实世界》Gregor Hohpe
架构师会从主观的判断或潜在不确定需求出发，产生调整解决方案的强烈冲动。请记住一点：试图猜测未来的需求时，错的概率是50%，错得很离谱的概率是49%。今天只需要解决今天的问题就好。《确保简单的问题有简单的解》Chad La Cigne
长远看来，系统维护将比项目初期的开发消耗更多的资源。进行系统架构设计时，牢记这点非常重要。在项目开发初期走捷径，可能会以日后付出高昂的维护费用为代价。
碰到架构问题或设计缺陷，作为架构师，一定要坚持成本还很低廉时就动手。搁置越久，为之付出的利息也将越高。《现在走捷径，将来付利息》Scot ZMcphee
我的建议是：不要屈服于企图使设计或实现达到完美的诱惑！把目标设定在“足够好”就行，当已经达成目标时，就停下来。
你可能会问，究竟什么是“足够好”？“足够好”指得是，剩余的不完美之处，对系统的功能、可维护性或性能不会产生任何有深远意义的影响。架构和设计协调一致；系统的实现正确可用，并符合性能需求；代码整合简洁，文档化良好。还可以做得更好吗？当然可以，但这样已经足够好，所以就到此为止了吧。可以宣布设计胜利完成，然后转入下一个任务了。
在我看来，再设计和实现上追求完美，会导致过度设计和模糊混乱的解决方案，最终使系统难以维护。
《不要追求完美，足够好就行》Greg Nyberg
如果出现下面这些关键词，要小心了：
“如果。。。，会更酷。”实际上，任何语句如果带有“酷”字，都是危险信号。
“嘿，他们刚刚发布了YYY框架的XXX版本。我们应该马上升级！”
“由于我们在使用ZZZ，你知道，我们确实应该重构XXX。。。”
“XXX技术真的很强大！也许我们可以把它用于。。。”
《小心“好主意”》Greg Nyberg
如果都不知道一个东西应该叫什么，那你肯定不知道它究竟是什么。如果你不知道它究竟是什么，那么你也肯定不能坐下来为它编写代码。
如果无法给出合适的命名，那也就无法继续编程。如果发现自己需要多次更改命名，那么最好停下来，直到弄清楚要做的究竟是什么。
《命名要恰如其分》Sam Gardiner
聪明的软件价格昂贵，不易维护，僵脆易折。所以，不要追求聪明，尽量用最浅显易懂的质朴方法，恰如其分的进行设计。
《弃聪明，求质朴》Eben Hewitt
软件架构师工作很大的一部分，是要选择用以攻克难题的合适技术。精心选择熟悉的武器，不到万不得已绝不轻易抛弃它们。这些技术在过去给你带来了成功，尽量让它们在未来也能为你带来胜利，同时，以审慎的态度更新你的技术武器库。
《精心选择有效技术，绝不轻易抛弃》Chad La Vigne
没错，你的客户确实不是你的客户。你的客户的客户，才是你的客户。如果你的客户的客户赢了，你的客户也就赢了。这意味着，你也赢了。
我们也不配称得上真正关爱我们的客户，如果不能更为关爱他们的客户。
《客户的客户才是你的客户》Eben Hewitt
《着重强调项目的商业价值》全文 周异
设计尽可能小的系统，帮助成功交付，并推动它向宏伟的远景目标不断演化。虽然听起来似乎是放弃了控制权，甚至是在逃避责任，但是最终，利益相关者会感谢你。
《优秀软件不是构建出来的，而是培育起来的》Bill de Hora