一个设计方案会这样设计的背后原因有很多个，有可能是：

1、PM 路上随便抄

2、PM 自己喜欢这么作

3、ART 要求

4、客户要求

5、这是主要功能， 一定得这样作， 否则失去此系统意义

所以不能是自己喜欢 B 就 B。开发一个系统一定有成本、预计收益，而实作的方案必须要去找出这两者的平衡点。这就是靠沟通沟通沟通…

7. 要写出一定程度的程序码

要使用 HTML / CSS 架构设计网页，不要滥用 ORM，不要重造轮子，不要写出会被人公干的 code ，这些都是基本的开发常识。很多新创网站写出第一版很快，但之后就陷入开发泥淖，无法配合业务模型快速调整，几乎 90% 的原因以上都是因为第一版 code 烂到当初的开发者自己也改不太动，结果光是后续调整架构作小改版就耗掉超多时间，变成超大致命伤。

8. 要追求一定以上的网页效能，tune 在刀口上

不追求效能实在是一句非常不可思议的话。

不可否认有些开发者效能和想象力技术实在追求过头，比如说甚至一开始就用 Backbone 写整个网站，或者是从头到尾使用 Node.js 写网站。这都是一开始就打算写 mobile 版 web service 给 mobile phone 使用才需要做的事。因为 3G 的 Latency 实在太大，要尽力的压缩频宽使用量和追求页面 response time。

但实作一个桌面版网站完全没必要。而在网站性能调整的时候，优先调整的也是界面性能，因为 C/P 值高很多，压缩一下 CSS 也许就可以省 3 秒。db 或程式语言 tune 的要死可能才省 0.1 秒。

而网站的指标和 用户体验并不是说打的开就好。比如说网站开的速度会直接影响 Search Engine 和 Alexa 排名，不知道这到底有多少人晓得？还有一般使用者对于 Blog / Album 和 Video 各自能够忍受的 response time 根本是不同的，Video 大家可以忍个5 秒还没打开都能接受，但是相册和博客开一页要 5 秒这大概就没人要用了吧…

效能调校这件事，过与不及都是不好的事。

9. 少用 Fancy 的东西，实作前先估算成本与效益

身为开发者，世界上每天会冒出很多新的好东西，这些不去玩玩看手实在会手痒。但是其实每引入一项都会有一定的成本存在，而且效益/成本比不见得是你当初想的那样。

比如说一直追 Rails 新版，换上效能很好的 Ruby 1.9.2，改用 SCSS 去写 CSS，改用 CoffeeScript 写 JavaScript。Apply 新发明的 Asset Pipeline 架构。这些都是很新很棒的东西。（T 客邦都有，架构从最早的 2.3.2 一直 upgrade 到 3.1.3，内行人才知道这样工程有多大）

但跟其他事物的道理其实是一样的，新的东西就有新风险。而且通常引入这些东西，不是自己一个人爽就好，是大家都要用的东西。

所以通常我是这样做的：先 branch 一个版本，我自己或是请资深 RD 自己下去把整个实作方法都做出来或者是进行评估，确定可行后整理成可行的 SOP。才大符推行。