60. Start with a Walking Skeletonby Clint Shank

【从可行走的骨架开始】

软件开发中，越早发现问题，修改的代价越小。因此，要及早将各个部分联接起来，形成一套可行走的骨架，按照用户需求的优先级，先验证重要的需求。验证一轮后，进行下一轮开发，调整骨架、补充肌体，实现生长，等待后续的验证。通过这种迭代、演化的方式，保证项目向正确的方向前进。

61. Share your knowledge andexperiencesby Paul W. Homer

【分享你的知识和经验】

软件业是一个年轻的行业，每个人都需要学习和进步。和他人分享你的知识、经验，让我们大家都发挥出全部的潜力，让这个行业的明天更加灿烂。

62. Make sure the simple stuff issimple by Chad LaVigne

【简单事情简单办】

设计人员往往会炫耀自己的知识，对简单的问题设计复杂的解决方案。复杂的方案往往走向延期、成本超支甚至失败。把聪明才智留着对付真正复杂的问题吧，不要再把问题复杂化。今天的事情今天办，也不要把今天的问题拖到明天，以为和明天的问题一起解决是什么智慧。要知道，处理了今天的问题，才能通过反馈引出明天的需求。

63. If you design it, you should beable to code it. by Mike Brown

【只设计自己会编码的架构】

架构师总是想创造精巧而新潮的设计。可是这样的设计对项目其实是有影响的。如果使用了一些自己没有动手做过的框架或者模式，不仅不能准确地估计工作量，而且还带来开发人员学习周期不明、新元素隐藏的问题不明、削弱开发人员对架构师的信任、给项目带来不必要的风险等副作用。记住：架构师首先是开发人员。

64. The ROI variable by GeorgeMalamidis

【计算投资回报】

在软件项目中的每一项决策，都可以视为是投资。投资是讲求回报的，即便不是金钱上的回报，也要给项目干系人带来某种可见的好处，比如降低缺陷。把投入的成本和预期的回报相比较，计算出回报率，才能合理地确定是否要做某件事。

65. Your system is legacy, designfor it. by Dave Anderson

【系统即遗产，需要精心设计】

一个系统即便最业务前卫、技术先进，对于下一任负责人来说，也是一份遗产。当今软件的特点就是迅速淘汰。如果想自己的系统投入生产，存活哪怕只是几个月，也得接受一个现实，那就是维护人员需要修修补补。这意味着：

清楚——各个组件和类的执行条理清楚;

可测——系统各部分的特性容易验证;

正确——系统按设计或常规运行;

追溯——为不了解系统内部情况的人提供问题追溯信息，以便快速定位和修复缺陷。

要抱着为继任者留下遗产的态度来设计系统。

66. If there is only one solution,get a second opinion by Timothy High

【只有一个对策时，请教他人吧】

软件架构是在各种条件下对某个问题提出解决方案。如果只能想出一个对策，这个对策往往不是最佳的，因为很难用一个解决方案满足所有条件，通常有个按照需求的优先级进行取舍的过程。只能想出一个对策，也许是因为自己缺乏经验，或者自己的经验不适于新的问题领域。比如，一个长期设计三层结构的客户端-服务器应用的人，碰到的是浏览器-服务器领域的问题。去向其他处理过类似问题的人请教，才能获得更好的意见。

67. Understand the impact of changeby Doug Crawford

【理解变化的影响】

好的架构师能把复杂度降到最低，并能设计出通用程度足以经受变化考验的解决方案。所谓变化，表现为：功能需求变化、规模演变、系统接口修改、团队人员进出等等。软件项目中变化的广度和复杂度是无法预测的，不能避免前进道路上所有的波折。但架构师应该识别出那些事关项目成败的大波折。他不仅要管理变化，还要确保变化是可管理的。比如：一个高度分布的系统，对流程的变化是在所难免的，可是又要承载长期运行、有状态的事务，那么就必须要设计成能同时支持新老版本的过程。

68. You have to understand Hardwaretoo by Kamal Wickramanayake

【必须了解硬件】

架构师不仅要关注软件架构，也要关注硬件容量。硬件容量规划是系统设计中的一个重要部分。如何准确地预测用户数量及其变化趋势，如何评估硬件的发展，都是做容量规划的必备知识。

69. Shortcuts now are paid backwith interest later by Scot Mcphee

【现在节省的，将来加倍还】

在项目开发阶段，可能会省略哪些不产生直接价值的工作，比如单元测试，又比如设计优化。现在节省了一点工作，将来系统进入维护阶段以后，要改正隐藏的错误，要花几倍的代价。

70. "Perfect" is theEnemy of "Good Enough" by Greg Nyberg

【优秀是良好的敌人】

作为软件解决方案，做到良好就行了，不要为了追求优秀而过度设计。良好的东西，在功能性、可维护性、性能指标等方面都能满足一般要求。如果过度追求优秀，可能突出了某一方面，而损害了其它方面，为系统的长期运行维护带来不好的影响。

71. Avoid "Good Ideas"by Greg Nyberg

【别提“好点子”】

当项目在按部就班地前进的时候，大家都感觉良好。这时有人就会提出所谓的好点子。比如：

“如果在这里改动一下，就太酷了。”

“嗨，他们又发布那个框架的新版本了，我们得赶紧更新。”

“一边开发新模块，一边重构老模块。”

“这项技术太强大了，可以用在我们的项目上。”

“我帮你想了一下，发现一个好主意!”

这些好点子往往是项目杀手。一旦付诸实践，对项目造成的改动不是当初想象的那么简单。除了极个别之外，大部分会把项目慢慢地拖入深渊，有的甚至会让项目迅速失败。

72. Great content creates greatsystems by Zubin Wadia

【好内容成就好系统】

不管系统的需求分析、设计、开发、安全、维护做得多好，如果忽略了内容建设，则它都不会是一个好系统。对于那些以内容为基础的系统来说，内容就是成功和失败的分界线，FaceBook 对 Orkut， Google 对 Cuil，NetFlix 对 BlockbusterOnline，等等，都是以内容取胜的例子。评价内容时，考虑一下几个条件：数量是否足够?时间上是否及时?渠道上是否丰富 (RSs、纸质表单、电子邮件等)?

73. The Business Vs. The AngryArchitect by Chad LaVigne

【业务人员与愤怒的架构师】

架构师是为业务人员服务的，要忍耐，不要和业务人员争吵。如果你和他们分歧实在太大，那就只有换个自己觉得轻松的地方了。

74. Stretch key dimensions to seewhat breaks by Stephen Jones

【撑大关键维度，发现破绽】

系统各方面的处理能力是有一定的前提条件的。这些前提条件在实际运行中有可能发生变化。对于系统的关键维度，要进行验证，看看如果运行负荷超出，哪些地方会被撑破。

75. Before anything, an architectis a developer by Mike Brown

【架构师首先是开发者】

架构设计要落实到开发工作。如果你设计它，你就要能够编码它。如果连你都不知道如何编码，别指望别人能编码。

76. A rose by any other name willend up as a cabbage by Sam Gardiner

【玫瑰不叫玫瑰，它就沦落到白菜的地位】

如果你不知道如何称呼一个系统，你就不可能编写它。如果你对一个系统三改其名，你最好先停下来想想到底要做什么，不要急于构建它。

77. Stable problems get highquality solutions by Sam Gardiner

【稳定的问题才有优质的解决方案】

现实世界的解决方案不是挑战有难度的学术研究。设计现实的方案时，要把问题划分为稳定、有限的小块，再针对明确的小块来进行解决。稳定的问题得到稳定的设计，稳定的设计得到优质的解决方案。

78. It Takes Diligence by BrianHart

【勤勉】

一招不慎，满盘皆输。架构师应当勤勉，认认真真做好每一项平凡的工作。

79. Take responsibility for yourdecisions by Yi Zhou

【对决策负责】

大约三分之二的项目是失败的，表现有工期延误、预算超支、用户不满等。失败的重要原因是架构不当。通过以下几条，可以做到对架构决策负责：

准备决策时，务必反复推敲;

进行决策时，务必决策有据(书面凭据);

做出决策后，做到定期自评;

有疑难问题，请教领域专家。