41．留意架构图里的空白区域（MichaelNygard）

　　空白区域“充满”了各种软件和“硬件”。

　　42．学习软件专业的行话（MarkRichards）

　　同行之间讲行话方便交流。

　　43．具体情境决定一切（EdwardGarson）

　　44．侏儒、精灵、巫师和国王（EvanCofsky）

　　开发团队不应该同质化。

　　45．向建筑师学习（KeithBraithwaite）

　　借鉴建筑行业的经验。

　　46．避免重复（NiclasNilsson）

　　47．欢迎来到现实世界（GregorHohpe）

　　现实世界比软件世界复杂。

　　48．仔细观察，别试图控制一切（GregorHohpe）

　　49．架构师好比两面神（DavidBartlett）

　　架构师应该像两面神一样，眼观六路、耳听八方。

　　50．架构师应关注边界和接口（EinarLandre）

　　寻找自然的边界，分而治之。

　　51．助力开发团队（TimothyHigh）

　　团队是成功的保障，要尽量助力开发团队。

　　52．记录决策理由（TimothyHigh）

　　记录架构决策背后的理由，具有极高的投资回报价值。

　　53．挑战假设，尤其是你自己的（TimothyHigh）

　　臆断是事情搞砸的主要根源。务必要确保软件基石坚实可靠。

　　54．分享知识和经验（PaulW.Homer）

　　帮助周围的人不断改善，他们也会帮助我们发挥出全部的潜力。

　　55．模式病（ChadLaVigne）

　　不要让一展设计模式功力的欲望，遮蔽了务实的真知。

　　56．不要滥用架构隐喻（DavidIng）

　　不要耽溺于系统隐喻之中，反让它拖了后腿。

　　57．关注应用程序的支持和维护（MncedisiKasper）

　　应用程序的支持和维护，永远都不应该是事后才考虑的事情。

　　58．有舍才有得（BilldehÓra）

　　珍惜需要权衡的时机，远胜毫无约束和限制。

　　59．原则、公理和类比胜于个人意见和口味（MichaelHarmer）

　　60．从“可行走骨架”开始开发应用（ClintShank）