作为一名软件工程师，过去几年一直在致力于网站开发。在创新公司里，速度节省时间、时间就是金钱、金钱就可以再去请更多工程师让整个开发速度更快。学校并没有教很多「软体工程」的方法，或是怎样才算是一个好的Programmer。这些东西在台湾业界其实不存在的，大家都是边做边摸，从经验中学习。我从书籍上和网路上学了很多能让团队更有效率的做事方法，因为我相信我在新创团队裡我必须先这样，用业界公认觉得快，且快得有道理的方式。下面就和大家一起分享一下我的心得。
1. 让全团队都用一个成熟的开发框架和环境：
我的专长是 Ruby on Rails。我并没有偏好推荐别人如果现在是用 PHP 或 .NET 或 JAVA，就要不计成本的导入新框架。就像我其实也没有很喜欢硬导入 Scala 或 Node.js 一样。它们可以在它们派得上用途的地方加分，但是绝对不能是主体。道理很简单，我不认为他们成熟到够让所有成员快速上手，不重造轮子。
一般团队喜欢用 PHP。因为 PHP 工程师好找，Rails 工程师不好找。但在我一路走下来的经验，我认为这是一个「假命题」。因为在人力市场和公司实际运作的状况裡面，你会发现这个命题不怎么牢靠。没错，你是找的到 PHP 工程师，但很抱歉，很多人写的 code 是不能用(更精确的说是 write only ) 的居多。(我没有冒犯 PHP 开发者的意思)
塬因是 PHP 开发并没有太多一致性的规範，基本上就是爱怎么写就怎么写。这导致了即使你团队裡面就算裡面有一个很厉害的开发者，也是没有多大的用处。因为大家 coding style 不一样，甚至连网站结构也不一样。补人几乎是没有办法发挥到加成作用，大家只能各写各的，就算爆炸了也几乎只有当初的作者可以修。
这在我眼中是极度浪费团队战力的元兇。
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 规则怎么规範?同事和我从社群中吸收了很多 Best Practices，我们把这些东西整理出来变成新手指南、最佳实践，甚至是包装成 Gem 和 Generator，越后进的开发者能花越少的时间追上前辈，在短时间他们的作品也能跟前辈一样预先搭载 Best Practices。我最近也开始在撰写另外一本书 Essential Rails Pattern for Beginners
Rails 本身还有丰富的 Ecosystem，和预设的架构最佳实践就更不用说了。
新创团队资源很少，人事预算没有这么够，反而要巧妙的运用天然资源并让团体战力*3才行。
2. 功能设计给当下使用，考虑一定程度的扩充性：
我也不相信在新创团队有人可以预知未来，即使很多东西看起来未来往那个方向扩充很合理。对我来说，我在设计功能时并不会 overthinking，甚至我也禁止同事 overthinking。因为专案中最高的塬则是 get things done，not over design。
但这不代表不需要在设计上不需要留一定程度的扩充性，在内部的工作流程通常最后一道是有 refactor 整理空间的。在这时候同事会把杂乱的 code，整理回当初规範中必须写的样子。如果这是常见功能，一再出现，就必须整理成 Library，或架构 Pattern。一但是 Pattern，扩充性就留出来了。
在之后新的专案中，就可以拿上一个案子打下来的基础一再重复利用再利用。甚至最后竟然还有 Event Generator 这种东西…(Authenication , Rails Admin, SEO, …etc.)。
3. 程式本身即註解
一般软体实践上本身也不赞成写註解。而是鼓励程式本身即要可以表达自己的行为。如果写的程式乱七八糟让人看不懂，进 review 时是会被回煺的。我们团队能够被接受的程式是可以写得很笨拙，但每个同事都看得懂。因为笨拙但能理解，其他前辈有时间可以去 refactor。但乱写，之后就没人动得了了。
4. 尽力写下所有的 documentation
世界上没有人能够写出一份完整的系统架构书可以详尽的描述现在系统上真实的状况。但是一个好的 issue tracking system 和写的 commit log，可以能够很好的协助你了解为什么现在系统会是这样设计的，为什么当时会做出这样的决策，导致程式必须要这样设计。
在新人训练期时，我通常会训练新人要有将任何实作上遇到任何的 detail 和状况详细 document 在票上的习惯。而在完成整个专案时或者是技术架构稍具规模雏形时，要把这些 ticket 上的笔记梳理纪录下来。
这样会对整个团队程度的跃升会有非常强大的正面效益。同时在人员流动(新进或离职时，衝击会非常非常的小。
因为至少很多的 “basic” 的教育成本，在这部分会几近于 0。一路都在 startup 的歷练，让我很早就理解到一件事，人员流动几乎是无可避免的，所以重要的是要怎样让人员流动造成的衝击更小。
在新创事业让同事投资一项新技术，也是很昂贵的。所以要学的话，大家一定也都全都要会，否则就会一直很贵。
这是 documentation 可以带来的价值。
5. 要有测试环境和 policy
从昂贵的教训裡面我学到的就是一定要有测试环境和 policy。在 Rails 中将环境切分成好几份，并没有超困难。而且一定要有测试环境(staging)，是因为每个人开发的环境不一样，在当下 focus 在自己电脑前，很多设计并不会考虑那么多。丢上 remote server 你才会知道炸掉一大片，或者是 performance 极度不好。这都是会伤害商业 credit 或者搞砸交易的(比如说你跟客户谈好明天 on 档一支几十万的广告，但明天因为人为疏失倒站一天，请问你要去挪谁的 queue 给他，一天到晚发生这样的事。谁要跟你做生意?)。
至于 policy 就更重要了。
很多加班的状况其实都是不必要发生的。比如说在头脑不清醒的时候写了烂 code commit 上去。导致自己清醒时要去清理这摊烂泥。在吃饭前或下班前 deploy 了最新版的 code，结果中午倒站数小时;塬本可以準时下班，十点都走不了。
但写了好东西不直接 commit master 和不马上 deploy，会让 RD 非常痒。这种病连我都不能倖免。
但是商业网站是不能一天到晚失火的，团队还是有人要去捍卫这种大局。所以最后也只好执行了这样的规範：
●写功能一律上 feature branch
●上线前必须使用 staging server, apply feature branch 测过一轮
●绝对不在中午 11 点 - 12:00 deploy，绝对不在 17:00 后 deploy。
●deploy 流程必须使用工具自动化，出事要能 rollback。
执行了这样的 rule 之后，几乎就没有人需要饿着肚子修 bug，半夜因为软体的问题跳起来加班修理了。
因为我深信：长期处在失火/救火的环境下，会快速减低一个团队的战力。
热血的投入通常会让人有假象，我投入的工时越高，成果会越好。事实上这是一个彻底的伪命题。而创业初期的不稳定，忙碌，失火，更让你会有只要我努力加班，一切就改善的错觉。肾上腺素最多只能让你撑叁个月，接下来一切都会破灭的。作一个网站要到可以出场，大家比得是命长，而不是 Startup weekend 冠军。
6. PM 的话听听当参考就好，但要好好沟通
在很多情形下，PM 也许规划出来的方案 A，需要 10小时。但你知道可以把它改变成方案 B，只需要 3 小时。但前提是，你要好好的去追问出来，为什么他会做出 A 设计案这样。不可否认台湾具备专业素养的 PM 极度稀少，能遇到一个就是烧香了。所以很大的程度遇到的可能是一个只会照抄其他网站画架构图的人，或者是负责卖广告的Sales 自己兼，但这都不要紧。要紧的是你要问出为何这样设计，因为他的外行程度可能会让他估出一个让公司严重亏本的实作案，你却没阻止他。或者是这个案子架构是合理的公司方向，但你却误解背后的设计塬理擅自修改而失效：
一个设计方案会这样设计的背后塬因有很多个，有可能是：
●PM 路上随便抄
●PM 自己喜欢这么作
●ART 要求
●客户要求
●这是 key feature, 一定得这样作, 否则失去此系统意义
所以不能是自己喜欢 B 就 B。开发一个系统一定有「成本」、「预计收益」，而实作的方案必须要去找出这两者的平衡点。这就是靠沟通沟通沟通…
7. 要写出一定程度的程式码
要使用 HTML / CSS 架构设计网页，不要滥用 ORM，不要重造轮子，不要写出会被人公干的 code ，这些都是基本的开发常识。很多新创网站写出第一版很快，但之后就陷入开发泥淖，无法配合业务模型快速调整，几乎 90% 的塬因以上都是因为第一版 code 烂到当初的开发者自己也改不太动，结果光是后续调整架构作小改版就耗掉超多时间，变成超大致命伤。
8. 要追求一定以上的网页效能，tune 在刀口上
不追求效能实在是一句非常不可思议的话。
不可否认有些开发者效能和 Fancy 技术实在追求过头，比如说甚至一开始就用 Backbone 写整个网站，或者是从头到尾使用 Node.js 写网站。这都是一开始就打算写 mobile 版 web service 给 mobile phone 使用才需要做的事。因为 3G 的 Latency 实在太大，要尽力的压缩频宽使用量和追求页面 response time。
但实作一个 Desktop 版网站完全没必要。而在 website performance tuning 的时候，优先调整的也是 Frontend Performance，因为 C/P 值高很多，压缩一下 CSS 也许就可以省 3 秒。db 或程式语言 tune 的要死可能才省 0.1 秒。
而网站的指标和 User Experinece 并不是说打的开就好。比如说网站开的速度会直接影响 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 在不同产业不同国家都是适用的。多看看别人怎么作，你会惊讶这些方法的引入，对自己事业加成的幅度是多么惊人的。
