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