我是一個(gè)軟件工程師，過去六年我都在開發(fā)網(wǎng)站。在新創(chuàng)公司里，速度節(jié)省時(shí)間、時(shí)間就是金錢、金錢就可以再去請更多工程師讓整個(gè)開發(fā)速度更快。學(xué)校并沒有教很多軟件工程的方法，或是怎樣才算是一個(gè)好的程序員。這些東西在臺灣業(yè)界其實(shí)不存在的，大家都是邊做邊摸，從經(jīng)驗(yàn)中學(xué)習(xí)。我從書籍上和網(wǎng)絡(luò)上學(xué)了很多能讓團(tuán)隊(duì)更有效率的做事方法，因?yàn)槲蚁嘈盼以谛聞?chuàng)團(tuán)隊(duì)里我必須先這樣，用業(yè)界公認(rèn)覺得快，且快得有道理的方式。底下是幾點(diǎn)可以和大家分享的。
1. 讓全團(tuán)隊(duì)都用一個(gè)成熟的開發(fā)框架和環(huán)境：
我的專長是 Ruby on Rails。我并沒有偏好推薦別人如果現(xiàn)在是用 PHP 或 .NET 或 JAVA，就要不計(jì)成本的導(dǎo)入新框架。就像我其實(shí)也沒有很喜歡硬導(dǎo)入Scala 或 Node.js 一樣。它們可以在它們派得上用途的地方加分，但是絕對不能是主體。道理很簡單，我不認(rèn)為他們成熟到夠讓所有成員快速上手，不重造輪子。
一般團(tuán)隊(duì)喜歡用 PHP。因?yàn)镻HP工程師好找，Rails 工程師不好找。但在我一路走下來的經(jīng)驗(yàn)，我認(rèn)為這是一個(gè)假命題。因?yàn)樵谌肆κ袌龊凸緦?shí)際運(yùn)作的狀況里面，你會發(fā)現(xiàn)這個(gè)命題不怎么牢靠。沒錯(cuò)，你是找的到 PHP 工程師，但很抱歉，很多人寫的代碼是不能用（更精確的說是 write only ） 的居多。（我沒有冒犯 PHP 開發(fā)者的意思）
原因是 PHP 開發(fā)并沒有太多一致性的規(guī)范，基本上就是愛怎么寫就怎么寫。這導(dǎo)致了即使你團(tuán)隊(duì)里面就算里面有一個(gè)很厲害的開發(fā)者，也是沒有多大的用處。因?yàn)榇蠹?代碼格式不一樣，甚至連網(wǎng)站結(jié)構(gòu)也不一樣。補(bǔ)人幾乎是沒有辦法發(fā)揮到加成作用，大家只能各寫各的，就算爆炸了也幾乎只有當(dāng)初的作者可以修。
這在我眼中是極度浪費(fèi)團(tuán)隊(duì)?wèi)?zhàn)力的元兇。
Rails 沒有這樣的狀況嗎？這是我覺得 Rails 優(yōu)勢的地方，它是一個(gè)非常熱門的 Framework（只有在臺灣你可能沒有感覺到他很熱門）。因?yàn)檫@是一套 Framework，也就是它本身有很強(qiáng)的約束性，至少 MVC 和 routing 規(guī)則，一般就算新手也不會亂放的太離譜。寫 code 有一定的潛規(guī)則存在。
開發(fā)中遇到任何東西發(fā)生錯(cuò)誤了以后，開發(fā)者幾乎可以用 Google 找到任何可能發(fā)生的原因，修復(fù)完畢。而這幾乎不是一般自建 Framework 可以比的上的地方，如果你在公司自建一套 Framework，基本上發(fā)生任何問題，最后幾乎都得去煩當(dāng)初設(shè)計(jì)的 Architect 才行。（這也是很浪費(fèi)錢的地方，因?yàn)?Architect 的薪水都很貴）。
學(xué)習(xí)曲線過高，我也不覺得這件事真的存在。Rails 高手是難尋沒有錯(cuò)，但是 Rails 中低手只要訓(xùn)練得當(dāng)，生產(chǎn)力也是非常驚人。因此只要把重心放在如何協(xié)助一般想入門者，可以快速克服入門幾大門檻（搞定開發(fā)環(huán)境，RESTful，Plugin，Debug，Deploy），剩下的部分就可以靠網(wǎng)絡(luò)教材和實(shí)戰(zhàn)訓(xùn)練出來。這也是我發(fā)明Rails 101 的原因。
我設(shè)計(jì)這一套教材的目的是要讓所有新進(jìn)的開發(fā)者，在最長兩周時(shí)間內(nèi)要學(xué)完基本 Linux 指令、Git、Rails 所有基礎(chǔ)的知識、部署、SCSS 撰寫等等，一個(gè)月之內(nèi)就能上戰(zhàn)場跟我們一起開發(fā)功能開發(fā)新網(wǎng)站。這樣的進(jìn)度很夸張嗎？不，不夸張。這里的每一個(gè)開發(fā)者都有這樣的程度，他們有些人應(yīng)聘時(shí)是連 Rails 都不會寫的。你能相信連T 客邦的PM 和 ART 他們也會寫 Rails 嗎？（ no kidding）
寫 Code 規(guī)則怎么規(guī)范？同事和我從社群中吸收了很多最佳實(shí)踐，我們把這些東西整理出來變成新手指南、最佳實(shí)踐，甚至是包裝成 Gem 和 Generator，越后進(jìn)的開發(fā)者能花越少的時(shí)間追上前輩，在短時(shí)間他們的作品也能跟前輩一樣預(yù)先搭載 Best Practices。我最近也開始在撰寫另外一本書 Essential Rails Pattern for Beginners。
Rails 本身還有豐富的生態(tài)系統(tǒng)，和預(yù)設(shè)的架構(gòu)最佳實(shí)踐就更不用說了。
新創(chuàng)團(tuán)隊(duì)資源很少，人事預(yù)算沒有這么夠，反而要巧妙的運(yùn)用天然資源并讓團(tuán)體戰(zhàn)力很高才行。
2. 功能設(shè)計(jì)給當(dāng)下使用，考慮一定程度的擴(kuò)充性：
我也不相信在新創(chuàng)團(tuán)隊(duì)有人可以預(yù)知未來，即使很多東西看起來未來往那個(gè)方向擴(kuò)充很合理。對我來說，我在設(shè)計(jì)功能時(shí)并不會 overthinking，甚至我也禁止同事 overthinking。因?yàn)閷０钢凶罡叩脑瓌t是 get things done，not over design。
但這不代表不需要在設(shè)計(jì)上不需要留一定程度的擴(kuò)充性，在內(nèi)部的工作流程通常最后一道是有重構(gòu)整理空間的。在這時(shí)候同事會把雜亂的 code，整理回當(dāng)初規(guī)范中必須寫的樣子。如果這是常見功能，一再出現(xiàn)，就必須整理成程序庫，或架構(gòu)模式。一但是模式，擴(kuò)充性就留出來了。
在之后新的專案中，就可以拿上一個(gè)案子打下來的基礎(chǔ)一再重復(fù)利用再利用。甚至最后竟然還有 Event Generator 這種東西…（Authenication ， Rails Admin， SEO， …etc.）。
3. 程序本身即注解
一般軟件實(shí)踐上本身也不贊成寫注解。而是鼓勵(lì)程式本身即要可以表達(dá)自己的行為。如果寫的程式亂七八糟讓人看不懂，進(jìn)審查時(shí)是會被回退的。我們團(tuán)隊(duì)能夠被接受的程式是可以寫得很笨拙，但每個(gè)同事都看得懂。因?yàn)楸孔镜芾斫?，其他前輩有時(shí)間可以去重構(gòu)。但亂寫，之后就沒人動(dòng)得了了。
4. 盡力寫下所有的 documentation
世界上沒有人能夠?qū)懗鲆环萃暾南到y(tǒng)架構(gòu)書可以詳盡的描述現(xiàn)在系統(tǒng)上真實(shí)的狀況。但是一個(gè)好的 issue tracking system 和寫的 commit log，可以能夠很好的協(xié)助你了解為什么現(xiàn)在系統(tǒng)會是這樣設(shè)計(jì)的，為什么當(dāng)時(shí)會做出這樣的決策，導(dǎo)致程序必須要這樣設(shè)計(jì)。
在新人訓(xùn)練期時(shí)，我通常會訓(xùn)練新人要有將任何實(shí)作上遇到任何的細(xì)節(jié)和狀況詳細(xì) document 在票上的習(xí)慣。而在完成整個(gè)專案時(shí)或者是技術(shù)架構(gòu)稍具規(guī)模雛形時(shí)，要把這些 ticket 上的筆記梳理紀(jì)錄下來。
這樣會對整個(gè)團(tuán)隊(duì)程度的躍升會有非常強(qiáng)大的正面效益。同時(shí)在人員流動(dòng)（新進(jìn)或離職時(shí)，沖擊會非常非常的小。
因?yàn)橹辽俸芏嗟?“basic” 的教育成本，在這部分會幾近于 0。一路都在 startup 的歷練，讓我很早就理解到一件事，人員流動(dòng)幾乎是無可避免的，所以重要的是要怎樣讓人員流動(dòng)造成的沖擊更小。
在新創(chuàng)事業(yè)讓同事投資一項(xiàng)新技術(shù)，也是很昂貴的。所以要學(xué)的話，大家一定也都全都要會，否則就會一直很貴。
這是 documentation 可以帶來的價(jià)值。
5. 要有測試環(huán)境和政策
從昂貴的教訓(xùn)里面我學(xué)到的就是一定要有測試環(huán)境和 policy。在 Rails 中將環(huán)境切分成好幾份，并沒有超困難。而且一定要有測試環(huán)境（staging），是因?yàn)槊總€(gè)人開發(fā)的環(huán)境不一樣，在當(dāng)下焦點(diǎn)在自己電腦前，很多設(shè)計(jì)并不會 考慮那么多。丟上遠(yuǎn)程服務(wù)器你才會知道炸掉一大片，或者是性能極度不好。這都是會傷害商業(yè)信用或者搞砸交易的（比如說你跟客戶談好明天on檔一支幾十萬的 廣告，但明天因?yàn)槿藶槭枋У拐疽惶?，請問你要去挪誰的隊(duì)列給他，一天到晚發(fā)生這樣的事。誰要跟你做生意？）。
至于政策就更重要了。
很多加班的狀況其實(shí)都是不必要發(fā)生的。比如說在頭腦不清醒的時(shí)候?qū)懥藸€ code commit 上去。導(dǎo)致自己清醒時(shí)要去清理這攤爛泥。在吃飯前或下班前部署了最新版的 code，結(jié)果中午倒站數(shù)小時(shí)；原本可以準(zhǔn)時(shí)下班，十點(diǎn)都走不了。
但寫了好東西不直接 commit master 和不馬上部署，會讓 RD 非常癢。這種病連我都不能倖免。
但是商業(yè)網(wǎng)站是不能一天到晚失火的，團(tuán)隊(duì)還是有人要去捍衛(wèi)這種大局。所以最后也只好執(zhí)行了這樣的規(guī)范：
1、寫功能一律上 feature branch
2、上線前必須使用開發(fā)服務(wù)器， apply feature branch 測過一輪
3、絕對不在中午 11 點(diǎn) - 12:00 部署，絕對不在 17:00 后部署。
4、部署流程必須使用工具自動(dòng)化，出事要能回轉(zhuǎn)。
5、執(zhí)行了這樣的規(guī)定之后，幾乎就沒有人需要餓著肚子修 bug，半夜因?yàn)檐浖膯栴}跳起來加班修理了。
因?yàn)槲疑钚牛洪L期處在失火/救火的環(huán)境下，會快速減低一個(gè)團(tuán)隊(duì)的戰(zhàn)力。
熱血的投入通常會讓人有假象，我投入的工時(shí)越高，成果會越好。事實(shí)上這是一個(gè)徹底的偽命題。而創(chuàng)業(yè)初期的不穩(wěn)定，忙碌，失火，更讓你會有只要我努力 加班，一切就改善的錯(cuò)覺。腎上腺素最多只能讓你撐三個(gè)月，接下來一切都會破滅的。作一個(gè)網(wǎng)站要到可以出場，大家比得是命長，而不是 Startup weekend 冠軍。
6. PM 的話聽聽當(dāng)參考就好，但要好好溝通
在很多情形下，PM 也許規(guī)劃出來的方案 A，需要 10小時(shí)。但你知道可以把它改變成方案 B，只需要 3 小時(shí)。但前提是，你要好好的去追問出來，為什么他會做出 A 設(shè)計(jì)案這樣。不可否認(rèn)臺灣具備專業(yè)素養(yǎng)的 PM 極度稀少，能遇到一個(gè)就是燒香了。所以很大的程度遇到的可能是一個(gè)只會照抄其他網(wǎng)站畫架構(gòu)圖的人，或者是負(fù)責(zé)賣廣告的Sales 自己兼，但這都不要緊。要緊的是你要問出為何這樣設(shè)計(jì)，因?yàn)樗耐庑谐潭瓤赡軙屗莱鲆粋€(gè)讓公司嚴(yán)重虧本的實(shí)作案，你卻沒阻止他?；蛘呤沁@個(gè)案子架構(gòu)是 合理的公司方向，但你卻誤解背后的設(shè)計(jì)原理擅自修改而失效：
一個(gè)設(shè)計(jì)方案會這樣設(shè)計(jì)的背后原因有很多個(gè)，有可能是：
1、PM 路上隨便抄
2、PM 自己喜歡這么作
3、ART 要求
4、客戶要求
5、這是主要功能， 一定得這樣作， 否則失去此系統(tǒng)意義
所以不能是自己喜歡 B 就 B。開發(fā)一個(gè)系統(tǒng)一定有成本、預(yù)計(jì)收益，而實(shí)作的方案必須要去找出這兩者的平衡點(diǎn)。這就是靠溝通溝通溝通…
7. 要寫出一定程度的程序碼
要使用 HTML / CSS 架構(gòu)設(shè)計(jì)網(wǎng)頁，不要濫用 ORM，不要重造輪子，不要寫出會被人公干的 code ，這些都是基本的開發(fā)常識。很多新創(chuàng)網(wǎng)站寫出第一版很快，但之后就陷入開發(fā)泥淖，無法配合業(yè)務(wù)模型快速調(diào)整，幾乎 90% 的原因以上都是因?yàn)榈谝话?code 爛到當(dāng)初的開發(fā)者自己也改不太動(dòng)，結(jié)果光是后續(xù)調(diào)整架構(gòu)作小改版就耗掉超多時(shí)間，變成超大致命傷。
8. 要追求一定以上的網(wǎng)頁效能，tune 在刀口上
不追求效能實(shí)在是一句非常不可思議的話。
不可否認(rèn)有些開發(fā)者效能和想象力技術(shù)實(shí)在追求過頭，比如說甚至一開始就用 Backbone 寫整個(gè)網(wǎng)站，或者是從頭到尾使用 Node.js 寫網(wǎng)站。這都是一開始就打算寫 mobile 版 web service 給 mobile phone 使用才需要做的事。因?yàn)?3G 的 Latency 實(shí)在太大，要盡力的壓縮頻寬使用量和追求頁面 response time。
但實(shí)作一個(gè)桌面版網(wǎng)站完全沒必要。而在網(wǎng)站性能調(diào)整的時(shí)候，優(yōu)先調(diào)整的也是界面性能，因?yàn)?C/P 值高很多，壓縮一下 CSS 也許就可以省 3 秒。db 或程式語言 tune 的要死可能才省 0.1 秒。
而網(wǎng)站的指標(biāo)和 用戶體驗(yàn)并不是說打的開就好。比如說網(wǎng)站開的速度會直接影響 Search Engine 和 Alexa 排名，不知道這到底有多少人曉得？還有一般使用者對于 Blog / Album 和 Video 各自能夠忍受的 response time 根本是不同的，Video 大家可以忍個(gè)5 秒還沒打開都能接受，但是相冊和博客開一頁要 5 秒這大概就沒人要用了吧…
效能調(diào)校這件事，過與不及都是不好的事。
9. 少用 Fancy 的東西，實(shí)作前先估算成本與效益
身為開發(fā)者，世界上每天會冒出很多新的好東西，這些不去玩玩看手實(shí)在會手癢。但是其實(shí)每引入一項(xiàng)都會有一定的成本存在，而且效益/成本比不見得是你當(dāng)初想的那樣。
比如說一直追 Rails 新版，換上效能很好的 Ruby 1.9.2，改用 SCSS 去寫 CSS，改用 CoffeeScript 寫 JavaScript。Apply 新發(fā)明的 Asset Pipeline 架構(gòu)。這些都是很新很棒的東西。（T 客邦都有，架構(gòu)從最早的 2.3.2 一直 upgrade 到 3.1.3，內(nèi)行人才知道這樣工程有多大）
但跟其他事物的道理其實(shí)是一樣的，新的東西就有新風(fēng)險(xiǎn)。而且通常引入這些東西，不是自己一個(gè)人爽就好，是大家都要用的東西。
所以通常我是這樣做的：先 branch 一個(gè)版本，我自己或是請資深 RD 自己下去把整個(gè)實(shí)作方法都做出來或者是進(jìn)行評估，確定可行后整理成可行的 SOP。才大符推行。
如果是新想法，則是在一個(gè) event 或是小版面先行制作嘗試效果。
好的東西是不錯(cuò)。但不要孤注一擲。
綜合以上，我想說的是：在開發(fā)初期，任何一點(diǎn)戰(zhàn)力都是相當(dāng)寶貴的，所以沒有什么理由把程序碼亂扔，不實(shí)行一定的規(guī)則而導(dǎo)致到處都失火。永遠(yuǎn)都在作重復(fù)的白工。
任何舉措，最好都要是能以盡量把成本壓到差不多低，但效益都非常高。
以上我上面所說的這些東西都不是我的創(chuàng)舉，事實(shí)上幾乎所有 Rapid Development， Agile Development， 還有很多 Engineering Blog 常常都在聊這樣的話題。
我發(fā)現(xiàn)很多工程師朋友常常有自干且認(rèn)為自己的東西最好的傾向。認(rèn)為外界的方法絕對不適用在自己的團(tuán)隊(duì)上，美國的常態(tài)并不適合在臺灣使用。但事實(shí)上這 世界真的非常大，說實(shí)在真的沒什么理由把自己的成長速度綁在自己的眼界里面，很多的 principle 在不同產(chǎn)業(yè)不同國家都是適用的。多看看別人怎么作，你會驚訝這些方法的引入，對自己事業(yè)加成的幅度是多么驚人的。
