都不同，你需要引导框架，使用正确的设计模式，直接解决真正要处理的问题。只生产一款
汽车，怎麽可能满足全世界人的需求！

用框架开发雏形系统就好，但真正的产品就不要全部套用。从框架开始比较容易，但你要拆
开全部的框架，移除

Runtime 检查、拿掉不需要的功能，只留下你会用到的程式模组。你不

需要一个通用型框架，因为它无法提供未来的扩充性，但也不用重头写起，你需要的是介
于两者之间。

Q：网站需要规画到多久以后的扩充需求？
A：我总是痛恨要帮未来考虑太多。当你无法预测未来，你就无法帮未来作决定。
网路变化太快，我通常只规画半年内的事情。现在决定半年以后的事情，可能会做出错误决
策，反而让事情更糟。如果你没有解决当下的问题，而是想像未来会发生的问题，我认为不
值得，我宁可解决眼前看得到的问题，真正聚焦在当下需要的产品。

Q：那麽，有任何准则是架构人员可以遵循的吗？
A：最主要的原则是，仔细考虑如何分配程式模组，尽可能将程式拆解成更小的元件，调
校出适当的

API，你应该规画的是使用者端点的事情，例如浏览器请求的类型是什麽？应

用程式要如何回应？是否可以切割？是否可以把这些工作分配到完全分离的伺服器上执行
即使是在同一台伺服器上，你也能从使用者端点的角度来架构应用程式，有一天，当你的
规模变大后，就可以很容易加入第二台伺服器，只要在前端伺服器不储存任何资料，就能
进行流量分担。一般开发者最大的错误是，让程式码之间的交互关连（

interrelation）太深，

每个不同的元件都需要和其他外元件沟通，这样做很难调校出很乾淨的

API。开发者会无法

抽离出效率慢的

API 放到辅助伺服器中，而让主要伺服器只执行必要 API。

Q：切割服务、拆解程式的难度是什麽？
A：必须在开始之前，就要非常了解问题。当你写完第一个版本的程式，才着手拆解问题，
那几乎是不可能，很难事后处理。这的确很难，因为问题会一直改变。但是，若你从简单的
架构开始，并且保持这个精神来区隔程式模组。每次当网站发生变化时，问题的变化也只会
影响到一小部分，你就能够非常清楚那个地方，能够直接解决问题。就好像乐高游戏一样，
盖好每一个小块积木，哪边还有不足，就只需要再补上一小块就好，不用对整体改变太多。

Q：除了扩充性以外，如何提高网站效能呢？
A：要提高效能，得先知道每一支程式花了多少时间。我会问，使用者送出 Request 请求后，
要多久才会收到第一个

Byte 的资料？很多开发人员不晓得这个时间（First Byte Latency）

是多久，不晓得自己的程式码用掉多少时间？可以透过

Profile 来追踪效能，画出视觉化的

效能流程图，来了解瓶颈在哪。

甚至要考虑到单一机器上的延迟，透过系统层级的追踪程式，知道程式执行的每一个系统
呼叫（

System Call）耗费多久。还要考虑浏览器中的延迟，从使用者实际感受的速度来改善

网页执行方式等。
每次你增加一个新功能，要能计算出新功能会增加多少毫秒，想一想这麽做值不值得。

Q：那么，网站的安全性又需注意哪些原则？
A：基本精神很简单，只要用资料防火牆的概念来设计网站。网路防火牆会严密监控每一个