《软件架构师应该知道的97件事》摘录

http://book.douban.com/subject/4745287/

Pvi 优秀的软件架构师，必须多才多艺、成熟练达、经验丰富，具备极强的洞察力，能够领导和提升软件开发团队，去构建整齐有序、均衡合理、可持续发展演化的虚拟数字世界中的伟大建筑——优秀杰出的软件产品。
P6 大多数项目是由人完成的，人才是项目成败与否的基础。
P12 顾客和最终用户通常提出的所谓需求，只是他们心中可行的解决方案，并不是问题唯一的解决途径。把最有价值的需求摆在第一位。
P42 仓促决定的进度会导致拙劣的设计、蹩脚的文档，可能引发质量问题，导致用户拒绝验收。仓促完成的代码，会直接导致最终产品的BUG数量增加。紧张的测试进度会导致测试不充分，直接增加测试中可能出现的问题。以上几项都会引发产品质量问题，而解决产品质量问题的代价更高。
P66 我喜欢随着时间的流逝观察哪些事物会被淘汰，哪些能保存下来。漂亮的解决方案搭配正确的任务，才能经受时间的考验。
P85 用清晰、简洁、高效的方式与同行进行沟通，是软件架构师应该具备的能力。
P86 由于需求常常互相制约，所以设计架构的关键不是贡献新内容，而是忽略那些不必要和需求。设计架构的过程其实就是作出明智决策的过程（产品则体现了架构师的设计意图）。
P99 他们付出的所有努力，都是为了产品能够经受岁月的洗礼。
P104 记录软件架构决策理由的文档，长期有用，又无须为之付出过多维护精力，具有很高的投资回报价值。
P107 事实（fact）和架设（assumption）是构建软件的两大支柱。务必确保软件的基石坚实可靠。
P124 确保简单问题有简单的解。
P134 管理变化并非架构师的职责，但架构师要确保变化是可控的。
P140 在我看来，在设计和实现上追求完美，会导致过度设计（overdesigned）和模糊混乱的解决方案，最终使系统难以维护。
P141 停止吹毛求疵的做法，不要浪费时间最求尽善尽美。
P145 优秀内容成就优秀系统，内容为王。
P156 勤奋经常和平凡（mundane）携手同行。成功的架构实践，在很多方面都是简单易行平凡无奇的。勤奋还意味着要求架构师必须真正做好那些看似简单的任务，坚守承诺。
P160 只有真正睿智的架构师才懂得如何保持质朴。
P188 人们并不总是满心欢喜地接受新系统或系统的重大升级。这种情势，可能会对项目的成功构成威胁。
P191 这些可信陈述（true statement）简单、可核实，描述了系统的本质特性。