开发网站实战经验分享:效益非常高的网站开发团队(2)
5. 要有测试环境和政策
从昂贵的教训里面我学到的就是一定要有测试环境和 policy。在 Rails 中将环境切分成好几份，并没有超困难。而且一定要有测试环境（staging），是因为每个人开发的环境不一样，在当下焦点在自己电脑前，很多设计并不会考虑那么多。丢上远程服务器你才会知道炸掉一大片，或者是性能极度不好。这都是会伤害商业信用或者搞砸交易的（比如说你跟客户谈好明天on档一支几十万的广告，但明天因为人为疏失倒站一天，请问你要去挪谁的队列给他，一天到晚发生这样的事。谁要跟你做生意？）。
至于政策就更重要了。
很多加班的状况其实都是不必要发生的。比如说在头脑不清醒的时候写了烂 code commit 上去。导致自己清醒时要去清理这摊烂泥。在吃饭前或下班前部署了最新版的 code，结果中午倒站数小时；原本可以准时下班，十点都走不了。
但写了好东西不直接 commit master 和不马上部署，会让 RD 非常痒。这种病连我都不能倖免。
但是商业网站是不能一天到晚失火的，团队还是有人要去捍卫这种大局。所以最后也只好执行了这样的规范：
1、写功能一律上 feature branch
2、上线前必须使用开发服务器， apply feature branch 测过一轮
3、绝对不在中午 11 点 - 12:00 部署，绝对不在 17:00 后部署。
4、部署流程必须使用工具自动化，出事要能回转。
5、执行了这样的规定之后，几乎就没有人需要饿着肚子修 bug，半夜因为软件的问题跳起来加班修理了。
因为我深信：长期处在失火/救火的环境下，会快速减低一个团队的战力。
热血的投入通常会让人有假象，我投入的工时越高，成果会越好。事实上这是一个彻底的伪命题。而创业初期的不稳定，忙碌，失火，更让你会有只要我努力加班，一切就改善的错觉。肾上腺素最多只能让你撑三个月，接下来一切都会破灭的。作一个网站要到可以出场，大家比得是命长，而不是 Startup weekend 冠军。
6. PM 的话听听当参考就好，但要好好沟通
在很多情形下，PM 也许规划出来的方案 A，需要 10小时。但你知道可以把它改变成方案 B，只需要 3 小时。但前提是，你要好好的去追问出来，为什么他会做出 A 设计案这样。不可否认台湾具备专业素养的 PM 极度稀少，能遇到一个就是烧香了。所以很大的程度遇到的可能是一个只会照抄其他网站画架构图的人，或者是负责卖广告的Sales 自己兼，但这都不要紧。要紧的是你要问出为何这样设计，因为他的外行程度可能会让他估出一个让公司严重亏本的实作案，你却没阻止他。或者是这个案子架构是合理的公司方向，但你却误解背后的设计原理擅自修改而失效：
一个设计方案会这样设计的背后原因有很多个，有可能是：
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 在不同产业不同国家都是适用的。多看看别人怎么作，你会惊讶这些方法的引入，对自己事业加成的幅度是多么惊人的。