我主要是想阐述以前在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 可以带来的价值。
