神魂顛倒論壇-Flash--Front-end網頁前端討論最新50篇論壇主題-全文

[程式設計]Coding 發表眾包平台「碼市」，共用經濟下的新商業樣式？

類型：
程式設計

在新視窗檢視

[b]編者按： 隨?行動網路的高速發展，軟體外包的領域也在迅速崛起，工信部資料顯示，中國軟體外包企業在 2014 年總收入已經整超過了一萬億，增速 20% 以上，軟體眾包在國內迅速火熱，成為企業服務行業發展最為迅猛的行業。然而傳統軟體外包公司競爭激烈，往往收費標準混亂不透明，惡意競價，導致需求方選擇困難，除此以外，還有灰色收入，服務費高等等的一系列問題。

[/b]

「眾包，是以自由意願的形式外包給非特定的大眾或專業個體的做法樣式。」

近日，雲端協作平台 Coding.net 正式發表旗下軟體眾包平台：碼市，成為企業服務領域完成「工具+平台」戰略布局的技術主導型公司。

Coding 碼市言下之意是「程式碼市場」，對於開發者，Coding 碼市提供各種懸賞專案，使用者可以隨時申請成為碼士並參與感興趣的懸賞專案，從而獲得高額的回報；對於需求方，Coding 碼市提供懸賞平台和海量的碼士，亦可以隨時發表懸賞，挑選合適的開發者。

Coding CEO 張海龍表示，搭建碼市的目的是為了更好的鏈結企業需求方及專業程式員使用者，幫助雙方最大限度的實作價值，提高專案效率及品質，打造標準化軟體眾包。

在新視窗檢視

相關資料顯示，無論是傳統外包還是眾包，由於缺乏監管導致的爛尾率高達 30%。由此，Coding 碼市也為需求方提供了三重保障讓整個開發流程處於實時監管狀態，以保障開發的進度與品質。

首先，Coding 工具保障。 開發者在專案開發時必須吧開發程式碼託管在 Coding.net 雲端協作工具上，利用雲端演示功能隨時看到專案的成果演示，並且有生成程式碼品質報告的工具，同在一個專案內的需求方可以實時查看專案的進度、成果以及程式碼的品質情況，可劃分專案階段節點，讓開發進度實作按階段驗收； 其次，專案經理保障。 碼市創立了專案經理人樣式，在網路都提倡「輕」的時代，碼市為何要反其道而行？張海龍表示：「正是因為這種「重」樣式讓需求方的需求得到專業的梳理，使開發專案合理化」；同時，專案經理人團隊還充當溝通的橋樑，解決模糊需求及溝通問題，幫助需求方對開發進度進行把控，階段性驗收專案及完成專案測試， 最後對交付後的專案進行使用情況跟進 ，從專案開始至完成全方位監管，解放需求方的時間精力；最後，專業測試保障。碼市引入專業的測試服務，與 Testin 雲測試平台達成戰略合作，讓測試流程更智慧，實作軟體專案測試自動化。

在新視窗檢視

Coding 碼市服務說明

「有能力的出售技能，有需求的人低價取得。」張海龍說到。

在專案類別上，Coding 碼市定位到了包括微信、APP、站台、HTML5、功能模組等專案類型 ，並意欲把這些類型的開發標準化。不過，這樣可能會對傳統的小型外包公司產生衝突。

談論到細節時，他同時表示：「假如專案有一百個功能，Coding 碼市會將其分割階段性的若干個進度單位，然後再去修改解決其中存在的問題，從而再開發下面的階段。」據悉，Coding 碼市在整個專案中會 收取 10%的傭金，但不會收平台費用 。

在新視窗檢視

記者了解到，在對程式員的認證上，Coding 碼市會有一個稽核的程序，其中包括 對技能的基本判斷、Coding 工具的使用熟悉程度以及對個人的身份證和銀行帳號的認證 。

關於交易風險以及支付方面，張海龍對記者說：「Coding 碼市的交易資金會通過支付寶和銀行帳號的形式轉給 Coding，再根據開發的進度逐步通過支付寶支付給開發者。」同時，在進行程序之前 Coding 會先跟需求方簽合同以及提供發票。

在新視窗檢視

宏觀來看，Coding 碼市同樣是共用經濟環境下技術領域的 C2C 樣式，而對於這種商業樣式的可行性有多高，走得通有需要多久？

「其實我們從最開始成立的時候就想好了要做碼市，這也是的定戰略的執行。首先做了工具是因為我們認為無論如何碼市是需要工具支撐的。我們已經做了一年的工具，積累了足夠多的開發者的資源，可以用現有的工具和現有開發者資源為碼市提供服務。周期上的話，我覺得大概需要兩年左右吧。」

據張海龍透露，Coding 還在嘗試做歐美的專案，並在西雅圖已經設立了辦公室。看來，中國網路公司出海的路上又會多出一個身影了。

Coding 成立於 2014 年 2 月，並於 2014 年 7 月正式上線，現有團隊人數 47 人。在 2014 年 7 月及 2015 年 3 月，分別完成了 A、B 兩輪融資，其中 A 輪融資在百萬美元層級，由 IDG 領投，B 輪千萬美元層級融資，由光速資本領投，IDG 跟投。截止 2015 年 10 月，Coding 程式員使用者數已突破 15 萬人，專案數量達到 20 萬單，私有專案達到 80%；碼市上線一個月，交易金額就已超 100 萬元。

在近日 Coding 碼市的戰略發表會上，CEO 張海龍還宣布推出碼市「助推器排程」，旨在對初創團隊進行扶持及技術支援；同時通過該排程，程式員使用者有望實作 1 萬/周的收入水平，最大限度了解放程式員的生產力。

想在手機查閱更多程式設計資訊？免費下載【香港矽谷】Android App

在新視窗檢視

原文站台: 動點科技 Technode

在新視窗檢視

分享到Facebook

最近的Line Notify、Line Login，以及前一陣子的Microsoft Graph API，全都使用到了OAuth作為用戶身分驗證以及資源存取的基礎。但很多讀者會卡在OAuth的運作流程上，根本的原因是不理解OAuth到底是幹嘛的?其存在的目的為何?以及如何應用?

因此，我想花一個篇幅，盡可能短的介紹一下OAuth與SSO，但，與坊間文章不同的是，我希望從應用情境的角度(而非技術)切入談這件事情，冀望能夠讓開發人員對OAuth有個最基本的認識。

OAuth的背景

我們回頭看Line Login與Line Notify中的例子，OAuth在這邊最簡單的應用情境，就是身分驗證。典型的情境中有幾個角色，分別是:

網站或App的開發單位 : 也就是各位開發人員
OAuth服務的提供者(Provider) : 也就是Line(或Google、Microsoft…etc.)
終端用戶(End-User) : 網站使用者、Line使用者、消費者、客戶…etc.

上面這三者的關係是什麼？

當我們建立一個網站（例如Pc Home購物）、或App(例如一個手機遊戲)，都非常有可能需要建立一組會員機制，這些機制包含:

登入（包含身分驗證，帳號、密碼保存…等）
個資管理（用戶名稱、地址、電話、暱稱、手機…等)

以往，幾乎都是每一個網站自己做一套，但這樣有很多麻煩事，首先用戶要記得很多組帳號密碼，而每一個網站都自己搞一套會員機制，網站開發人員自己也很辛苦，加上最近這幾年大家都很重視個資，網站儲存（保管）了很多帳號密碼與個人資料，總是會有被駭的風險。因此，這十年來，很多大廠開始提供登入（與身分驗證）機制服務。

也就是說，小網站你不用自己做登入和會員管理了，你連過來我這邊，我是大網站，我已經有幾百萬上億的用戶，(例如全台灣都用Line)，而且早就做了超級安全的會員管理機制，你這小網站何必自己做會員管理呢？你跟我連結不就得了，我大網站來幫你管理個資，提供你登入的服務，你把會員資料通通存我這裡，用戶也不需要記得很多組帳密，只需要記得我大網站的帳密，一樣可以登入你小網站(或稱為第三方應用）來使用你提供的服務，這樣皆大歡喜。

因此，大家就這麼做了。

但提供這樣服務的大廠越來越多，Google、Microsoft、Yahoo…都提供了這樣的服務，導致小網站為了對使用者更貼心，可能要同時連結上很多這種提供身分服務的大網站，如果每一家連結方式都不同，就很煩。因此，業界就開了幾個會，共同決定了一套工業標準，就是OAuth了。

有哪些功能？

所以你會發現，基本上網站開發人員有兩種身分，一種是OAuth服務的提供者(像是Google、微軟、Line)，另一種是OAuth服務的使用者，像是一般的小網站(trello)。而終端用戶只需要在大網站申請過帳號，就可以登入小網站來使用服務。

但，大網站當然不能給你(小網站)用戶的帳號和密碼，否則多麼不安全呢?因此OAuth工業標準讓服務提供者(大網站)透過一種標準的作法，在用戶驗證過身分之後，提供一組會過期的令牌給小網站，這就是token。

小網站拿著這個令牌，就可以跟大網站取得用戶的個資，或是其他需要的資料。小網站也可以拿著這個令牌，跟大網站確認該令牌是否已經到期。

所以，整個流程大概是底下這樣:

由於上述過程中的(2)，登入畫面是大網站提供的，因此你小網站不會得知用戶的帳號密碼，大網站只會在登入成功後，把一個具有有效期限的Token傳給你小網站，一旦你需要存取用戶的資料，就拿這個token去跟大網站溝通。

當然，實際上的OAuth操作步驟又更複雜，如果你參考我們前面介紹的Line Login那篇，就會知道，用戶被引導到大網站完成登入之後，你小網站是無法直接取得token的，而是取得一個code，再去用這個code跟大網站換得一個token。為何要多這一道手續?因為，網際網路是個不安全的所在，在網路上傳遞的任何東西，都可能被路上經手的路由器或其他設備給擷取、偽造、變更，因此要確保安全，得更加小心一點。

因此一般的OAuth流程，其實應該長得像是底下這樣(這是微軟Graph API的OAuth Auth Authorization Code Flow流程) :

還有更複雜的、更進階的。

如果大網站除了提供用戶的個資之外，還要可以讓小網站有權限做一些額外的事情，像是變更用戶大頭照、取得用戶上傳的檔案、幫用戶book一個行事曆…這都是Office 365/Google Apps裡面典型的情境，如此一來，終端使用者(end-user)可能就要授權小網站，到底能夠使用該用戶在大網站中多少資料，也就是大網站的用戶要賦予小網站多大的權限，來存取該終端用戶的個資? 這部分，一般稱之為 Permission Scope。

所以，OAuth除了提供登入身分驗證之外，也逐漸開始負擔了網站合作之間的授權管理功能。

好，現在回過頭來看，請參考Line Login與Line Notify這兩篇中的例子，你會發現一開始我們都只是組出一個URL，來取得Authorization Code，這一段取得的code是明碼，走的是http get，透過瀏覽器網址列來傳遞，所以在網際網路上是可以被任何人擷取看到的(因此你當然應該加上SSL)，但你會發現接下來小網站取得Authorization Code之後，要透過http post，從後端走另一個路徑去跟大網站換得token，這一段並不是走瀏覽器http get，而是在小網站的伺服器端走另一個https路徑，去跟大網站溝通。由於這一段往往是在背後做的(伺服器端對伺服器端，不會經過用戶端)，因此安全性相對高(OAuth也有實作成在前端取token的implicit flow，但走後端相對安全點)。如果從後端換取Token，不管是瀏覽器或用戶本身都無法得知token，就算你的用戶被人在瀏覽器或電腦中安裝了木馬也無法得知，再加上Token還有期限，因此相對安全。

這也是我們前面說的，實務上小網站被導引到大網站完成登入之後，並非直接取得token而是取得一個Authorization Code的原因。

所以你也不難理解，既然Token會到期，就衍生出需要更新(refresh)token、判斷token的有效性、設定Token的生命長度…等相關議題，但在這邊就先不介紹了。

更進一步實現SSO

好的，假設網路世界的身分驗證，都是某一個大網站(例如Google)提供的，而其他服務的小網站(網站A、網站B、網站C…)，都使用Google提供的身分驗證服務，那這世界就很單純了，一旦用戶登入了網站B，用著用著，連結到了網站A，還需要重新登入一次嗎? 不需要，因為在網站B已經登入過了，這就是SSO(Single Sign On)在internet上的實現。

一旦OAuth提供者和使用者(也就是大小網站)，都有實作這樣的功能，那用戶翱翔於網際網路上時，就只需要記得一組帳號密碼了，這世界多麼美好…

當然，現實世界不是這樣的，你想想，當個大網站將會擁有所有人的個資耶，這意味著什麼呢? 不用大腦想也知道。所以，只有你想做大網站? 不，每個人都想做。因此只要稍具規模網際網路服務提供者，都希望自己是最大的那個身分驗證提供者。

現在、連Line這個IM界的新玩家(相對What’s app、skype來說，真的算是新的)，挾著在亞洲(其實也只有台灣、日本、和韓國…)的超人氣，都開始提供OAuth Provider服務了，你說，Line這家公司它還不夠任性嗎?