|
3、絕對不在中午 11 點 - 12:00 部署，絕對不在 17:00 后部署。 1、寫功能一律上 feature branch 5、這是主要功能， 一定得這樣作， 否則失去此系統(tǒng)意思 一般團隊喜歡用 PHP。因為PHP工程師好找，Rails 工程師不好找。但在我一路走下來的教訓(xùn)，我認為這是一個假命題。因為在人力市場和公司實際運作的狀況里面，你會發(fā)現(xiàn)這個命題不怎么堅固。沒錯，你是找的到 PHP 工程師，但很負疚，很多人寫的代碼是不能用（更準確的說是 write only ） 的居多。（我沒有觸犯 PHP 開發(fā)者的意思） 9. 少用 Fancy 的東西，實作前先估算成本與效益 我重要是想論述以前在T客邦的經(jīng)驗方法。T客邦在一年半里面，就從臺灣 Alexa 400 名以外，沖進臺灣 Alexa 100 名內(nèi)。這一年半時間技術(shù)團隊開發(fā)出了四個大網(wǎng)站，十數(shù)個子網(wǎng)站，和當面一群深沉的基礎(chǔ)建設(shè)（HA， backup， PV stat， advertising system…etc.）。 8. 要追求一定以上的網(wǎng)頁效能，tune 在刀口上 4、客戶要求 但實作一個桌面版網(wǎng)站完整沒必要。而在網(wǎng)站性能調(diào)整的時候，優(yōu)先調(diào)整的也是界面性能，因為 C/P 值高很多，壓縮一下 CSS 也許就可以省 3 秒。db 或程式語言 tune 的要逝世可能才省 0.1 秒。 我是一個軟件工程師，從前六年我都在開發(fā)網(wǎng)站。在新創(chuàng)公司里，速度節(jié)儉時間、時間就是金錢、金錢就可以再去請更多工程師讓整個開發(fā)速度更快。學(xué)校并沒有教很多軟件工程的方法，或是怎樣才算是一個好的程序員。這些東西在臺灣業(yè)界其實不存在的，大家都是邊做邊摸，從經(jīng)驗中學(xué)習(xí)。我從書籍上和網(wǎng)絡(luò)上學(xué)了很多能讓團隊更有效力的做事方法，因為我信任我在新創(chuàng)團隊里我必須先這樣，用業(yè)界公認覺得快，且快得有道理的方法。底下是幾點可以和大家分享的。 但寫了好東西不直接 commit master 和不立刻部署，會讓 RD 非常癢。這種病連我都不能?免。 1. 讓全團隊都用一個成熟的開發(fā)框架和環(huán)境： 不可否認有些開發(fā)者效能和設(shè)想力技術(shù)著實尋求過火，好比說甚至一開始就用 Backbone 寫整個網(wǎng)站，或者是從頭到尾使用 Node.js 寫網(wǎng)站。這都是一開始就盤算寫 mobile 版 web service 給 mobile phone 使用才需要做的事。因為 3G 的 Latency 其實太大，要努力的緊縮頻寬使用量和追求頁面 response time。 比方說一直追 Rails 新版，換上效力很好的 Ruby 1.9.2，改用 SCSS 去寫 CSS，改用 CoffeeScript 寫 JavaScript。Apply 新發(fā)現(xiàn)的 Asset Pipeline 架構(gòu)。這些都是很新很棒的貨色。（T 客邦都有，架構(gòu)從最早的 2.3.2 始終 upgrade 到 3.1.3，行家人才曉得這樣工程有多大） 原因是 PHP 開發(fā)并沒有太多一致性的規(guī)范，基本上就是愛怎么寫就怎么寫。這導(dǎo)致了即使你團隊里面就算里面有一個很厲害的開發(fā)者，也是沒有多大的用途。因為大家 代碼格局不一樣，甚至連網(wǎng)站構(gòu)造也不一樣。補人幾乎是沒有措施施展到加成作用，大家只能各寫各的，就算爆炸了也幾乎只有當初的作者可以修。 但跟其他事物的情理其實是一樣的，新的東西就有新危險。而且通常引入這些東西，不是自己一個人爽就好，是大家都要用的東西。 3. 程序本身即注解 所以不能是自己喜歡 B 就 B。開發(fā)一個系同一定有成本、預(yù)計收益，而實作的方案必需要去找出這兩者的均衡點。這就是靠溝通溝通溝通… 3、ART 請求 2. 功效設(shè)計給當下應(yīng)用，斟酌必定水平的裁減性： 從昂貴的教訓(xùn)里面我學(xué)到的就是一定要有測試環(huán)境和 policy。在 Rails 中將環(huán)境切分成好幾份，并沒有超艱苦。而且一定要有測試環(huán)境（staging），是因為每個人開發(fā)的環(huán)境不一樣，在當下焦點在自己電腦前，很多設(shè)計并不會 考慮那么多。丟上遠程服務(wù)器你才會知道炸掉一大片，或者是機能極度不好。這都是會損害貿(mào)易信譽或者搞砸交易的（比如說你跟客戶談好明天on檔一支幾十萬的 廣告，但來日因為人為疏失倒站一天，請問你要去挪誰的隊列給他，一天到晚發(fā)生這樣的事。誰要跟你做生意？）。 這樣會對整個團隊程度的躍升會有非常強盛的正面效益。同時在人員流動（新進或離任時，沖擊會非常非常的小。 5、執(zhí)行了這樣的劃定之后，幾乎就沒有人需要餓著肚子修 bug，深夜因為軟件的問題跳起來加班修理了。 這在我眼中是極度揮霍團隊戰(zhàn)力的首惡。 我也不相信在新創(chuàng)團隊有人可以預(yù)知將來，即便很多東西看起來未交往那個方向擴充很合理。對我來說，我在設(shè)計功能時并不會 overthinking，甚至我也制止同事 overthinking。因為專案中最高的準則是 get things done，not over design。 1 2 下一頁世界上沒有人能夠?qū)懗鲆环萃耆捏w系架構(gòu)書可以詳盡的描寫當初系統(tǒng)上實在的狀況。但是一個好的 issue tracking system 和寫的 commit log，可以能夠很好的協(xié)助你懂得為什么現(xiàn)在系統(tǒng)會是這樣設(shè)計的，為什么當時會做出這樣的決議，導(dǎo)致程序必需要這樣設(shè)計。 在良多情況下，PM 興許計劃出來的計劃 A，需要 10小時。但你知道可以把它轉(zhuǎn)變成方案 B，只須要 3 小時。但條件是，你要好好的去追問出來，為什么他會做出 A 設(shè)計案這樣。不可否定臺灣具備專業(yè)素養(yǎng)的 PM 極度稀疏，能碰到一個就是燒香了。所以很大的程度遇到的可能是一個只會照抄其他網(wǎng)站畫架構(gòu)圖的人，或者是負責(zé)賣廣告的Sales 自己兼，但這都沒關(guān)系。要緊的是你要問出為何這樣設(shè)計，因為他的外行程度可能會讓他估出一個讓公司重大賠本的實作案，你卻沒禁止他?；蛘呤沁@個案子架構(gòu)是 公道的公司方向，但你卻曲解背地的設(shè)計原理擅自修正而生效： 新創(chuàng)團隊資源很少，人事估算不這么夠，反而要奇妙的應(yīng)用自然資源并讓集團戰(zhàn)力很高才行。 Rails 本身還有豐盛的生態(tài)系統(tǒng)，和預(yù)設(shè)的架構(gòu)最佳實踐就更不必說了。 1、PM 路上隨意抄 很多加班的狀況其實都是不用要產(chǎn)生的。比如說在腦筋不蘇醒的時候?qū)懥藸€ code commit 上去。導(dǎo)致自己清醒時要去清算這攤爛泥。在吃飯前或下班前安排了最新版的 code，成果中午倒站數(shù)小時；底本可以準時放工，十點都走不了。 身為開發(fā)者，世界上天天會冒出許多新的好東西，這些不去玩玩看手切實會手癢。但是實在每引入一項都會有一定的本錢存在，而且效益/成本比不見得是你當初想的那樣。 我的特長是 Ruby on Rails。我并沒有偏好推舉別人如果現(xiàn)在是用 PHP 或 .NET 或 JAVA，就要不計成本的導(dǎo)入新框架。就像我其實也沒有很喜歡硬導(dǎo)入Scala 或 Node.js 一樣。它們可以在它們派得上用處的地方加分，但是絕對不能是主體。道理很簡略，我不認為他們成熟到夠讓所有成員快速上手，不重造輪子。 因為我堅信：長期處在失火/救火的環(huán)境下，會倏地減低一個團隊的戰(zhàn)力。 寫 Code 規(guī)矩怎么標準？同事和我從社群中接收了很多最佳實踐，我們把這些東西收拾出來變成新手指南、最佳實踐，甚至是包裝成 Gem 和 Generator，越落后的開發(fā)者能花越少的時間追上前輩，在短時間他們的作品也能跟前輩一樣預(yù)先搭載 Best Practices。我最近也開端在撰寫另外一本書 Essential Rails Pattern for Beginners。 7. 要寫出一定程度的程序碼 學(xué)習(xí)曲線過高，我也不感到這件事真的存在。Rails 高手是難尋沒有錯，然而 Rails 中低手只有訓(xùn)練切當，出產(chǎn)力也是十分驚人。因而只要把重心放在如何幫助普通想入門者，可以疾速戰(zhàn)勝入門多少大門檻（搞定開發(fā)環(huán)境，RESTful，Plugin，Debug，Deploy），剩下的局部就可以靠網(wǎng)絡(luò)教材跟實戰(zhàn)練習(xí)出來。這也是我創(chuàng)造Rails 101 的起因。 至于政策就更重要了。 效能調(diào)校這件事，過與不迭都是不好的事。 任何舉動，最好都要是能以盡量把成本壓到差未幾低，但效益都異常高。 個別軟件實際上本身也不同意寫注解。而是激勵程式自身即要可以表白本人的行動。假如寫的程式烏七八糟讓人看不懂，進審查時是會被回退的。咱們團隊可能被接收的程式是能夠?qū)懙煤苡薇?，但每個共事都看得懂。由于笨拙但能懂得，其余先輩有時光可以去重構(gòu)。但亂寫，之后就沒人動得了了。 開發(fā)中遇到任何東西發(fā)生過錯了當前，開發(fā)者幾乎可以用 Google 找到任何可能發(fā)生的原因，修復(fù)結(jié)束。而這幾乎不是一般自建 Framework 可以比的上的地方，如果你在公司自建一套 Framework，基礎(chǔ)上發(fā)生任何問題，最后幾乎都得去煩當初設(shè)計的 Architect 才行。（這也是很糟蹋錢的地方，因為 Architect 的薪水都很貴）。 2、PM 自己愛好這么作 如果是新主意，則是在一個 event 或是小版面先行制造嘗試后果。 5. 要有測試環(huán)境和政策 在新人訓(xùn)練期時，我通常會訓(xùn)練新人要有將任何實作上遇到任何的細節(jié)和狀態(tài)具體 document 在票上的習(xí)慣。而在實現(xiàn)整個專案時或者是技術(shù)架構(gòu)稍具范圍雛形時，要把這些 ticket 上的筆記梳理紀錄下來。 但這不代表不需要在設(shè)計上不需要留一定程度的擴充性，在內(nèi)部的工作流程通常最后一道是有重構(gòu)整理空間的。在這時候同事會把混亂的 code，整理回當初規(guī)范中必須寫的樣子。如果這是常見功能，一再呈現(xiàn)，就必須整理成程序庫，或架構(gòu)模式。一但是模式，擴充性就留出來了。 但是商業(yè)網(wǎng)站是不能一天到晚失火的，團隊仍是有人要去保衛(wèi)這種大局。所以最后也只好履行了這樣的規(guī)范： 我發(fā)明很多工程師友人經(jīng)常有自干且以為自己的東西最好的偏向。認為外界的辦法相對不適用在自己的團隊上，美國的常態(tài)并不合適在臺灣使用。但事實上這 世界真的無比大，說真實 未審真的沒什么理由把自己的成長速度綁在自己的眼界里面，很多的 principle 在不同工業(yè)不同國度都是實用的。多看看別人怎么作，你會驚奇這些方式的引入，對自己事業(yè)加成的幅度是如許驚人的。而網(wǎng)站的指標和 用戶休會并不是說打的開就好。比如說網(wǎng)站開的速度會直接影響 Search Engine 和 Alexa 排名，不知道這到底有多少人知道？還有正常使用者對 Blog / Album 和 Video 各自可以忍耐的 response time 基本是不同的，Video 大家可以忍個5 秒還沒翻開都能接受，但是相冊和博客開一頁要 5 秒這大略就沒人要用了吧… -->一個設(shè)計方案會這樣設(shè)計的背后原因有很多個，有可能是： 4. 盡力寫下所有的 documentation 熱血的投入通常會讓人有假象，我投入的工時越高，結(jié)果會越好。事實上這是一個徹底的偽命題。而創(chuàng)業(yè)初期的不穩(wěn)固，繁忙，失火，更讓你會有只要我盡力 加班，一切就改良的錯覺。腎上腺素最多只能讓你撐三個月，接下來所有都會幻滅的。作一個網(wǎng)站要到可以出場，大家比得是命長，而不是 Startup weekend 冠軍。 2、上線前必須使用開發(fā)服務(wù)器， apply feature branch 測過一輪
要使用 HTML / CSS 架構(gòu)設(shè)計網(wǎng)頁，不要濫用 ORM，不要重造輪子，不要寫出會被人公干的 code ，這些都是基本的開發(fā)常識。很多新創(chuàng)網(wǎng)站寫出初版很快，但之后就陷入開發(fā)泥淖，無奈配合業(yè)務(wù)模型快捷調(diào)劑，幾乎 90% 的原因以上都是因為第一版 code 爛到當初的開發(fā)者自己也改不太動，結(jié)果光是后續(xù)調(diào)整架構(gòu)作小改版就耗掉超多時間，變成超大抵命傷。 這是 documentation 可以帶來的價值。 我設(shè)計這一套教材的目標是要讓所有新進的開發(fā)者，在最長兩周時間內(nèi)要學(xué)完根本 Linux 指令、Git、Rails 所有基礎(chǔ)的常識、部署、SCSS 撰寫等等，一個月之內(nèi)就能上戰(zhàn)場跟我們一起開發(fā)功能開發(fā)新網(wǎng)站。這樣的進度很夸張嗎？不，不夸大。這里的每一個開發(fā)者都有這樣的程度，他們有些人應(yīng)聘時是連 Rails 都不會寫的。你能相信連T 客邦的PM 和 ART 他們也會寫 Rails 嗎？（ no kidding） 綜合以上，我想說的是：在開發(fā)初期，任何一點戰(zhàn)力都是相稱可貴的，所以沒有什么理由把程序碼亂扔，不履行一定的規(guī)則而導(dǎo)致到處都失火。永遠都在作重復(fù)的白工。 6. PM 的話聽聽當參考就好，但要好好溝通 Rails 沒有這樣的狀況嗎？這是我認為 Rails 上風(fēng)的處所，它是一個非常熱門的 Framework（只有在臺灣你可能沒有感到到他很熱點）。因為這是一套 Framework，也就是它本身有很強的束縛性，至少 MVC 和 routing 規(guī)則，一般就算新手也不會亂放的太離譜。寫 code 有一定的潛規(guī)則存在。 4、部署流程必須使用工具主動化，失事要能回轉(zhuǎn)。 好的東西是不錯。但不要孤注一擲。 因為至少很多的 “basic” 的教導(dǎo)成本，在這部門會幾近于 0。一路都在 startup 的歷練，讓我很早就理解到一件事，人員流動簡直是無可防止的，所以主要的是要怎么讓職員流動造成的沖擊更小。 在新創(chuàng)事業(yè)讓同事投資一項新技巧，也是很昂貴的。所以要學(xué)的話，大家一定也都全都要會，否則就會一直很貴。 在之后新的專案中，就可以拿上一個案子打下來的基本一再反復(fù)利用再應(yīng)用。甚至最后居然還有 Event Generator 這種東西…（Authenication ， Rails Admin， SEO， …etc.）。 不追求效能實在是一句非常不堪設(shè)想的話。 以上我上面所說的這些東西都不是我的創(chuàng)舉，事實上幾乎所有 Rapid Development， Agile Development， 還有很多 Engineering Blog 常常都在聊這樣的話題。 所以通常我是這樣做的：先 branch 一個版本，我自己或是請資深 RD 自己下去把全部實作方法都做出來或者是進行評估，斷定可行后整頓成可行的 SOP。才大符推行。 相關(guān)的主題文章： (責(zé)任編輯：admin) |