Q：难道开发者不需要框架或架构吗？
A：网站的确需要有架构，每一个人都需要框架，框架是一种解决问题的方法。但是你并不需要通用型框架，用一个前端控制器，来解决所有问题，这样通常没办法成功。每一个问题都不同，你需要引导框架，使用正确的设计模式，直接解决真正要处理的问题。只生产一款汽车，怎麽可能满足全世界人的需求！
用框架开发雏形系统就好，但真正的产品就不要全部套用。从框架开始比较容易，但你要拆开全部的框架，移除Runtime检查丶拿掉不需要的功能，只留下你会用到的程式模组。你不需要一个通用型框架，因为它无法提供未来的扩充性，但也不用重头写起，你需要的是介於两者之间。
Q：网站需要规画到多久以後的扩充需求？
A：我总是痛恨要帮未来考虑太多。当你无法预测未来，你就无法帮未来作决定。
网路变化太快，我通常只规画半年内的事情。现在决定半年以後的事情，可能会做出错误决策，反而让事情更糟。如果你没有解决当下的问题，而是想像未来会发生的问题，我认为不值得，我宁可解决眼前看得到的问题，真正聚焦在当下需要的产品。
Q：那麽，有任何准则是架构人员可以遵循的吗？
A：最主要的原则是，仔细考虑如何分配程式模组，尽可能将程式拆解成更小的元件，调校出适当的API，你应该规画的是使用者端点的事情，例如浏览器请求的类型是什麽？应用程式要如何回应？是否可以切割？是否可以把这些工作分配到完全分离的伺服器上执行？即使是在同一台伺服器上，你也能从使用者端点的角度来架构应用程式，有一天，当你的规模变大後，就可以很容易加入第二台伺服器，只要在前端伺服器不储存任何资料，就能进行流量分担。一般开发者最大的错误是，让程式码之间的交互关连（interrelation）太深，每个不同的元件都需要和其他外元件沟通，这样做很难调校出很乾净的API。开发者会无法抽离出效率慢的API放到辅助伺服器中，而让主要伺服器只执行必要API。
Q：切割服务丶拆解程式的难度是什麽？
A：必须在开始之前，就要非常了解问题。当你写完第一个版本的程式，才着手拆解问题，那几乎是不可能，很难事後处理。这的确很难，因为问题会一直改变。但是，若你从简单的架构开始，并且保持这个精神来区隔程式模组。每次当网站发生变化时，问题的变化也只会影响到一小部分，你就能够非常清楚那个地方，能够直接解决问题。就好像乐高游戏一样，盖好每一个小块积木，哪边还有不足，就只需要再补上一小块就好，不用对整体改变太多。
Q：除了扩充性以外，如何提高网站效能呢？
