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

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。才年夜符推行。

如果是新想法，则是在一个 event 或是小版面先行制作测验测验效果。

好的东西是不错。但不要背注一掷。

综合以上，我想说的是：在开辟早期，任何一点战力都是相当珍贵的，所以没有什么来由把法度码乱扔，不实行一定的法则而致使处处都失火。永远都在作重复的白工。

任何行动，最好都要是能以尽可能把本钱压到差不多低，但效益都很是高。

以上我上面所说的这些东西都不是我的创举，事实上几近所有 Rapid Development， Agile Development， 还有很多 Engineering Blog 常常都在聊这样的话题。

我发现很多工程师朋友常常有自干且认为自己的东西最好的倾向。认为外界的体例绝对不适用在自己的团队上，美国的常态其实不适合在台湾使用。但事实上这世界真的很是年夜，说实在真的没什么来由把自己的成长速度绑在自己的眼界里面，很多的 principle 在不合财产不合国度都是适用的。多看看他人怎么作，你会惊奇这些体例的引入，对自己事业加成的幅度是多么惊人的。（文：xdite）