开发网站实战经验分享:效益非常高的网站开发团队

申请免费试用、咨询电话：400-8352-114

我主要是想阐述以前在T客邦的经验方法。T客邦在一年半里面，就从台湾 Alexa 400 名以外，冲进台湾 Alexa 100 名内。这一年半时间技术团队开发出了四个大网站，十数个子网站，和背后一群深厚的基础建设（HA， backup， PV stat， advertising system…etc.）。

我是一个软件工程师，过去六年我都在开发网站。在新创公司里，速度节省时间、时间就是金钱、金钱就可以再去请更多工程师让整个开发速度更快。学校并没有教很多软件工程的方法，或是怎样才算是一个好的程序员。这些东西在台湾业界其实不存在的，大家都是边做边摸，从经验中学习。我从书籍上和网络上学了很多能让团队更有效率的做事方法，因为我相信我在新创团队里我必须先这样，用业界公认觉得快，且快得有道理的方式。底下是几点可以和大家分享的。

1. 让全团队都用一个成熟的开发框架和环境：

我的专长是 Ruby on Rails。我并没有偏好推荐别人如果现在是用 PHP 或 .NET 或 JAVA，就要不计成本的导入新框架。就像我其实也没有很喜欢硬导入Scala 或 Node.js 一样。它们可以在它们派得上用途的地方加分，但是绝对不能是主体。道理很简单，我不认为他们成熟到够让所有成员快速上手，不重造轮子。

一般团队喜欢用 PHP。因为PHP工程师好找，Rails 工程师不好找。但在我一路走下来的经验，我认为这是一个假命题。因为在人力市场和公司实际运作的状况里面，你会发现这个命题不怎么牢靠。没错，你是找的到 PHP 工程师，但很抱歉，很多人写的代码是不能用（更精确的说是 write only ） 的居多。（我没有冒犯 PHP 开发者的意思）

原因是 PHP 开发并没有太多一致性的规范，基本上就是爱怎么写就怎么写。这导致了即使你团队里面就算里面有一个很厉害的开发者，也是没有多大的用处。因为大家 代码格式不一样，甚至连网站结构也不一样。补人几乎是没有办法发挥到加成作用，大家只能各写各的，就算爆炸了也几乎只有当初的作者可以修。

这在我眼中是极度浪费团队战力的元凶。

Rails 没有这样的状况吗？这是我觉得 Rails 优势的地方，它是一个非常热门的 Framework（只有在台湾你可能没有感觉到他很热门）。因为这是一套 Framework，也就是它本身有很强的约束性，至少 MVC 和 routing 规则，一般就算新手也不会乱放的太离谱。写 code 有一定的潜规则存在。

开发中遇到任何东西发生错误了以后，开发者几乎可以用 Google 找到任何可能发生的原因，修复完毕。而这几乎不是一般自建 Framework 可以比的上的地方，如果你在公司自建一套 Framework，基本上发生任何问题，最后几乎都得去烦当初设计的 Architect 才行。（这也是很浪费钱的地方，因为 Architect 的薪水都很贵）。

学习曲线过高，我也不觉得这件事真的存在。Rails 高手是难寻没有错，但是 Rails 中低手只要训练得当，生产力也是非常惊人。因此只要把重心放在如何协助一般想入门者，可以快速克服入门几大门槛（搞定开发环境，RESTful，Plugin，Debug，Deploy），剩下的部分就可以靠网络教材和实战训练出来。这也是我发明Rails 101 的原因。

我设计这一套教材的目的是要让所有新进的开发者，在最长两周时间内要学完基本 Linux 指令、Git、Rails 所有基础的知识、部署、SCSS 撰写等等，一个月之内就能上战场跟我们一起开发功能开发新网站。这样的进度很夸张吗？不，不夸张。这里的每一个开发者都有这样的程度，他们有些人应聘时是连 Rails 都不会写的。你能相信连T 客邦的PM 和 ART 他们也会写 Rails 吗？（ no kidding）

写 Code 规则怎么规范？同事和我从社群中吸收了很多最佳实践，我们把这些东西整理出来变成新手指南、最佳实践，甚至是包装成 Gem 和 Generator，越后进的开发者能花越少的时间追上前辈，在短时间他们的作品也能跟前辈一样预先搭载 Best Practices。我最近也开始在撰写另外一本书 Essential Rails Pattern for Beginners。

Rails 本身还有丰富的生态系统，和预设的架构最佳实践就更不用说了。

新创团队资源很少，人事预算没有这么够，反而要巧妙的运用天然资源并让团体战力很高才行。

2. 功能设计给当下使用，考虑一定程度的扩充性：

我也不相信在新创团队有人可以预知未来，即使很多东西看起来未来往那个方向扩充很合理。对我来说，我在设计功能时并不会 overthinking，甚至我也禁止同事 overthinking。因为专案中最高的原则是 get things done，not over design。

但这不代表不需要在设计上不需要留一定程度的扩充性，在内部的工作流程通常最后一道是有重构整理空间的。在这时候同事会把杂乱的 code，整理回当初规范中必须写的样子。如果这是常见功能，一再出现，就必须整理成程序库，或架构模式。一但是模式，扩充性就留出来了。

在之后新的专案中，就可以拿上一个案子打下来的基础一再重复利用再利用。甚至最后竟然还有 Event Generator 这种东西…（Authenication ， Rails Admin， SEO， …etc.）。

3. 程序本身即注解

一般软件实践上本身也不赞成写注解。而是鼓励程式本身即要可以表达自己的行为。如果写的程式乱七八糟让人看不懂，进审查时是会被回退的。我们团队能够被接受的程式是可以写得很笨拙，但每个同事都看得懂。因为笨拙但能理解，其他前辈有时间可以去重构。但乱写，之后就没人动得了了。

4. 尽力写下所有的 documentation

世界上没有人能够写出一份完整的系统架构书可以详尽的描述现在系统上真实的状况。但是一个好的 issue tracking system 和写的 commit log，可以能够很好的协助你了解为什么现在系统会是这样设计的，为什么当时会做出这样的决策，导致程序必须要这样设计。

在新人训练期时，我通常会训练新人要有将任何实作上遇到任何的细节和状况详细 document 在票上的习惯。而在完成整个专案时或者是技术架构稍具规模雏形时，要把这些 ticket 上的笔记梳理纪录下来。

这样会对整个团队程度的跃升会有非常强大的正面效益。同时在人员流动（新进或离职时，冲击会非常非常的小。

因为至少很多的 “basic” 的教育成本，在这部分会几近于 0。一路都在 startup 的历练，让我很早就理解到一件事，人员流动几乎是无可避免的，所以重要的是要怎样让人员流动造成的冲击更小。

在新创事业让同事投资一项新技术，也是很昂贵的。所以要学的话，大家一定也都全都要会，否则就会一直很贵。

这是 documentation 可以带来的价值。

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 在不同产业不同国家都是适用的。多看看别人怎么作，你会惊讶这些方法的引入，对自己事业加成的幅度是多么惊人的。