一個新創(chuàng)網(wǎng)站要怎樣來開發(fā)才夠快？

2022-09-25    分類： 網(wǎng)站建設

我主要是想闡述以前在T客邦的經(jīng)驗方法。T客邦在一年半里面，就從臺灣 Alexa 400 名以外，沖進臺灣 Alexa 100 名內(nèi)。這一年半時間技術團隊開發(fā)出了四個大網(wǎng)站，十數(shù)個子網(wǎng)站，和背后一群深厚的基礎建設（HA， backup， PV stat， advertising system…etc.）。

我是一個軟件工程師，過去六年我都在開發(fā)網(wǎng)站。在新創(chuàng)公司里，速度節(jié)省時間、時間就是金錢、金錢就可以再去請更多工程師讓整個開發(fā)速度更快。學校并沒有教很多軟件工程的方法，或是怎樣才算是一個好的程序員。這些東西在臺灣業(yè)界其實不存在的，大家都是邊做邊摸，從經(jīng)驗中學習。我從書籍上和網(wǎng)絡上學了很多能讓團隊更有效率的做事方法，因為我相信我在新創(chuàng)團隊里我必須先這樣，用業(yè)界公認覺得快，且快得有道理的方式。底下是幾點可以和大家分享的。
1. 讓全團隊都用一個成熟的開發(fā)框架和環(huán)境：
我的專長是 Ruby on Rails。我并沒有偏好推薦別人如果現(xiàn)在是用 PHP 或 .NET 或 JAVA，就要不計成本的導入新框架。就像我其實也沒有很喜歡硬導入Scala 或 Node.js 一樣。它們可以在它們派得上用途的地方加分，但是絕對不能是主體。道理很簡單，我不認為他們成熟到夠讓所有成員快速上手，不重造輪子。
一般團隊喜歡用 PHP。因為PHP工程師好找，Rails 工程師不好找。但在我一路走下來的經(jīng)驗，我認為這是一個假命題。因為在人力市場和公司實際運作的狀況里面，你會發(fā)現(xiàn)這個命題不怎么牢靠。沒錯，你是找的到 PHP 工程師，但很抱歉，很多人寫的代碼是不能用（更精確的說是 write only ） 的居多。（我沒有冒犯 PHP 開發(fā)者的意思）
原因是 PHP 開發(fā)并沒有太多一致性的規(guī)范，基本上就是愛怎么寫就怎么寫。這導致了即使你團隊里面就算里面有一個很厲害的開發(fā)者，也是沒有多大的用處。因為大家 代碼格式不一樣，甚至連網(wǎng)站結(jié)構也不一樣。補人幾乎是沒有辦法發(fā)揮到加成作用，大家只能各寫各的，就算爆炸了也幾乎只有當初的作者可以修。
這在我眼中是極度浪費團隊戰(zhàn)力的元兇。
Rails 沒有這樣的狀況嗎？這是我覺得 Rails 優(yōu)勢的地方，它是一個非常熱門的 Framework（只有在臺灣你可能沒有感覺到他很熱門）。因為這是一套 Framework，也就是它本身有很強的約束性，至少 MVC 和 routing 規(guī)則，一般就算新手也不會亂放的太離譜。寫 code 有一定的潛規(guī)則存在。
開發(fā)中遇到任何東西發(fā)生錯誤了以后，開發(fā)者幾乎可以用 Google 找到任何可能發(fā)生的原因，修復完畢。而這幾乎不是一般自建 Framework 可以比的上的地方，如果你在公司自建一套 Framework，基本上發(fā)生任何問題，最后幾乎都得去煩當初設計的 Architect 才行。（這也是很浪費錢的地方，因為 Architect 的薪水都很貴）。
學習曲線過高，我也不覺得這件事真的存在。Rails 高手是難尋沒有錯，但是 Rails 中低手只要訓練得當，生產(chǎn)力也是非常驚人。因此只要把重心放在如何協(xié)助一般想入門者，可以快速克服入門幾大門檻（搞定開發(fā)環(huán)境，RESTful，Plugin，Debug，Deploy），剩下的部分就可以靠網(wǎng)絡教材和實戰(zhàn)訓練出來。這也是我發(fā)明Rails 101 的原因。
我設計這一套教材的目的是要讓所有新進的開發(fā)者，在最長兩周時間內(nèi)要學完基本 Linux 指令、Git、Rails 所有基礎的知識、部署、SCSS 撰寫等等，一個月之內(nèi)就能上戰(zhàn)場跟我們一起開發(fā)功能開發(fā)新網(wǎng)站。這樣的進度很夸張嗎？不，不夸張。這里的每一個開發(fā)者都有這樣的程度，他們有些人應聘時是連 Rails 都不會寫的。你能相信連T 客邦的PM 和 ART 他們也會寫 Rails 嗎？（ no kidding）
寫 Code 規(guī)則怎么規(guī)范？同事和我從社群中吸收了很多好實踐，我們把這些東西整理出來變成新手指南、好實踐，甚至是包裝成 Gem 和 Generator，越后進的開發(fā)者能花越少的時間追上前輩，在短時間他們的作品也能跟前輩一樣預先搭載 Best Practices。我最近也開始在撰寫另外一本書 Essential Rails Pattern for Beginners。
Rails 本身還有豐富的生態(tài)系統(tǒng)，和預設的架構好實踐就更不用說了。
新創(chuàng)團隊資源很少，人事預算沒有這么夠，反而要巧妙的運用天然資源并讓團體戰(zhàn)力很高才行。
2. 功能設計給當下使用，考慮一定程度的擴充性：
我也不相信在新創(chuàng)團隊有人可以預知未來，即使很多東西看起來未來往那個方向擴充很合理。對我來說，我在設計功能時并不會 overthinking，甚至我也禁止同事 overthinking。因為專案中高的原則是 get things done，not over design。
但這不代表不需要在設計上不需要留一定程度的擴充性，在內(nèi)部的工作流程通常最后一道是有重構整理空間的。在這時候同事會把雜亂的 code，整理回當初規(guī)范中必須寫的樣子。如果這是常見功能，一再出現(xiàn)，就必須整理成程序庫，或架構模式。一但是模式，擴充性就留出來了。
在之后新的專案中，就可以拿上一個案子打下來的基礎一再重復利用再利用。甚至最后竟然還有 Event Generator 這種東西…（Authenication ， Rails Admin， SEO， …etc.）。
3. 程序本身即注解
一般軟件實踐上本身也不贊成寫注解。而是鼓勵程式本身即要可以表達自己的行為。如果寫的程式亂七八糟讓人看不懂，進審查時是會被回退的。我們團隊能夠被接受的程式是可以寫得很笨拙，但每個同事都看得懂。因為笨拙但能理解，其他前輩有時間可以去重構。但亂寫，之后就沒人動得了了。
4. 盡力寫下所有的 documentation
世界上沒有人能夠?qū)懗鲆环萃暾南到y(tǒng)架構書可以詳盡的描述現(xiàn)在系統(tǒng)上真實的狀況。但是一個好的 issue tracking system 和寫的 commit log，可以能夠很好的協(xié)助你了解為什么現(xiàn)在系統(tǒng)會是這樣設計的，為什么當時會做出這樣的決策，導致程序必須要這樣設計。
在新人訓練期時，我通常會訓練新人要有將任何實作上遇到任何的細節(jié)和狀況詳細 document 在票上的習慣。而在完成整個專案時或者是技術架構稍具規(guī)模雛形時，要把這些 ticket 上的筆記梳理紀錄下來。
這樣會對整個團隊程度的躍升會有非常強大的正面效益。同時在人員流動（新進或離職時，沖擊會非常非常的小。
因為至少很多的 “basic” 的教育成本，在這部分會幾近于 0。一路都在 startup 的歷練，讓我很早就理解到一件事，人員流動幾乎是無可避免的，所以重要的是要怎樣讓人員流動造成的沖擊更小。
在新創(chuàng)事業(yè)讓同事投資一項新技術，也是很昂貴的。所以要學的話，大家一定也都全都要會，否則就會一直很貴。
這是 documentation 可以帶來的價值。

網(wǎng)頁題目：一個新創(chuàng)網(wǎng)站要怎樣來開發(fā)才夠快？
分享URL：http://www.muchs.cn/news/197876.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供App設計、動態(tài)網(wǎng)站、網(wǎng)站導航、建站公司、電子商務、標簽優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)

網(wǎng)站建設網(wǎng)站維護公司