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

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 的原因。