因為這個我要點名批評 Hacker News

指責開源軟體總是離奇難用已經不是一個新論點了；這樣的論點之前就被很多比我更為雄辯的人提及過，甚至是出自一些人非常推崇開源軟體的人士口中。那麼為什麼我要在這裡老調重彈呢？

在周一的 Hacker News 期刊上，一段文章把我逗樂了。文章談到，一些人認為 編寫代碼實現和一個跟 StackOverflow 一樣的系統可以簡單到爆，並自信的 聲稱他們可以在 7 月 4 號的周末就寫出一版和 StackOverflow 原版一模一樣的程序，以此來證明這一切是多麼容易。另一些人則插話說，現有的那些仿製產品 就已經是一個很好的例證了。

秉承著自由討論的精神，我們來假設一個場景。你在思考了一陣之後認為你可以用 ASP.NET MVC 來編寫一套你自己的 StackOverflow 。我呢，在被一塊兒搖晃著的懷錶催眠之後，腦袋又挨了別人一頓棒槌，然後像個二哈一樣一頁一頁的把 StackOverflow 的源碼遞給你，讓你照原樣重新拿鍵盤逐字逐句的在你的環境下把那些代碼再敲一遍，做成你的 StackOverflow。假設你可以像我一樣打字飛快，一分鐘能敲 100 個詞 (也就是大約每秒敲八個字母)，但是卻可以牛叉到我無法企及的打字零錯誤率。從 StackOverflow 的大小共計 2.3MB 的源碼來估計（包括 .CS、 .SQL、 .CSS、 .JS 和 .aspx 文件），就單單是照著源代碼這麼飛速敲一遍而且一氣呵成中間一個字母都不錯，你也要差不多用掉至少 80 個小時的時間。

或者你打算從零開始編碼實現你自己的 StackOverflow，雖然我知道你肯定是不會那樣做的。我們假設你從設計程序，到敲代碼，再到最終完成調試只需要區區十倍於抄襲 StackOverflow 源代碼的時間。即使在這樣的假設條件下，你也要耗費幾周的時間晝夜不停得狂寫代碼。不知道你是否願意，但是至少我可以欣然承認，如果只給我照抄 StackOverflow 源代碼用時的十倍時間來讓我自己寫 StackOverflow，我可是打死也做不到。

好的，我知道你在聽到這些假設的時候已經開始覺得泄氣了。你在想，如果不是全部實現，而只是實現 StackOverflow 大部分 的功能呢？這總歸會容易很多了吧。

好的，問題是什麼是 「大部分」 功能？如果只去實現提問和回答問題的功能？這個部分應該很簡單吧。其實不然，因為實現問和答的功能還要求你必須做出一個對問題及其答案的投票系統，來顯示大家對某個答案是贊同還是反對。因為只有這樣你才能保證提問者可以得到這個問題的唯一的可信答案。當然，你還不能讓人們贊同或者反對他們自己給出的答案，所以你還要去實現這種禁止自投自票的機制。除此之外，你需要去確保用戶在一定的時間內不能贊同或反對其他用戶太多次，以此來防止有人用機器人程序作弊亂投票。你很可能還需要去實現一個垃圾評論過濾器，即使這個過濾器很基礎很簡陋，你也要考慮如何去設計它。而且你恐怕還需要去支持用戶圖標（頭像）的功能。並且你將不得不尋找一個自己真正信任的並且與 Markdown 結合很好的乾淨的 HTML 庫（當然，假設你確實想要復用 StackOverflow 的 那個超棒的編輯器 ）。你還需要為所有控制項購買或者設計一些小圖標、小部件，此外你至少需要實現一個基本的管理界面，以便那些喜歡搗鼓的用戶可以調整和改動他們的個性化設置。並且你需要實現類似於 Karma 的聲望累積系統，以便用戶可以隨著不斷地使用來穩步提升他們的話語權和解鎖更多的功能以及可操作性。

但是如果你實現了以上所有功能，可以說你就已經把要做的都做完了。

除非……除非你還要做全文檢索功能。尤其是在「邊問邊搜」（動態檢索）的特性中，支持全文檢索是必不可少的。此外，錄入和顯示用戶的基本信息，實現對問題答案的評論功能，以及實現一個顯示熱點提問的頁面，以及熱點問題和帖子隨著時間推移沉下去的這些功能，都將是不可或缺的。另外你肯定還需要去實現回答獎勵系統，並支持每個用戶用多個不同的 OpenID 賬戶去登錄，然後將這些相關的登錄事件通過郵件發送出去來通知用戶，並添加一個標籤或徽章系統，接著允許管理員通過一個不錯的圖形界面來配置這些標籤和 徽章 Badge 。你需要去顯示用戶的 Karma 歷史，以及他們的歷史點贊和差評。而且整個頁面還需要很流暢的展開和拉伸，因為這個系統的頁面隨時都可能被 Slashdot、Reddit 或是 StackOverflow 這些動作影響到。

在這之後！你會以為你基本已經大功告成了！

……為了產品的完整性，在上面所述的工作都完成之後，你又奮不顧身的去實現了升級功能，界面語言的國際化，Karma 值上限，以及讓網站更專業的 CSS 設計、AJAX，還有那些看起來理所當然做起來卻讓人吐血的功能和特性。如果你不是真的動手來嘗試做一個和 StackOverflow 一模一樣的系統，你肯定不會意識到在整個程序設計實施的過程中，你會踩到無數的鬼才會知道的大坑。

那麼請你告訴我：如果你要做一個讓人滿意的類似產品出來，上述的哪一個功能是你可以省略掉的呢？哪些是「大部分」網站都具備的功能，哪些又不是呢？

正因為這些很容易被忽視的問題，開發者才會以為做一個 StackOverflow 的仿製版產品會很簡單。也同樣是因為這些被忽視了的因素，開源軟體才一直讓人用起來很痛苦。很多軟體開發人員在看到 StackOverflow 的時候，他們並不能察覺到 StackOverflow 產品的全貌。他們會簡單的把 Stackoverflow 的實現抽象成下面一段邏輯和代碼:

create table QUESTION (ID identity primary key,
                                             TITLE varchar(255), --- 為什麼我知道你認為是 255
                                             BODY text,
                                             UPVOTES integer not null default 0,
                                             DOWNVOTES integer not null default 0,
                                             USER integer references USER(ID));
create table RESPONSE (ID identity primary key,
                                             BODY text,
                                             UPVOTES integer not null default 0,
                                             DOWNVOTES integer not null default 0,
                                             QUESTION integer references QUESTION(ID))

如果你讓這些開發者去實現 StackOverflow，進入他腦海中的就是上面的兩個 SQL 表和一個用以呈現表格數據的 HTML 文件。他們甚至會忽略數據的格式問題，進而單純的以為他們可以在一個周末的時間裡就把 StackOverflow 做出來。一些稍微老練的開發者可能會意識到他們還要去實現登錄和註銷功能、評論功能、投票系統，但是仍然會自信的認為這不過也就是利用一個周末就能完成了；因為這些功能也不過意味著在後端多了幾張 SQL 表和 HTML 文件。如果藉助於 Django 之類的構架和工具，他們甚至可以直接拿來主義地不花一分錢就實現用戶登錄和評論的功能。

但這種簡單的實現卻遠遠不能體現出 StackOverflow 的精髓。無論你對 StackOverflow 的感覺如何，大多數使用者似乎都同意 StackOverflow 的用戶體驗從頭到尾都很流暢。使用 StackOverflow 的過程就是在跟一個精心打磨過的產品在愉快地交互。即使我沒有深入了解過 StackOverflow ，我也能猜測出這個產品的成功和它的資料庫的 Schema 沒有多大關係 —— 實際上在有幸研讀過 StackOverflow 的源碼之後，我得以印證了自己的想法，StackOverflow 的成功確實和它的資料庫設計關係甚小。真正讓它成為一個極其易用的網站的原因，是它背後大量的精雕細琢的設計和實施。多數的開發人員在談及仿製和克隆一款產品的難度時，真的很少會去考慮到產品背後的打磨和雕琢工作，因為他們認為這些打磨和雕琢都是偶然的，甚至是無足輕重的。

這就是為什麼用開源工具去克隆和山寨 StackOverflow 其實是很容易失敗的。即使這些開源開發者只是想去實現 StackOverflow 的主要的「規範和標準特性」，而非全面的高級特性，他們也會在實現的過程中遭遇種種關鍵和核心的問題，讓他們陰溝翻船，半途而廢。拿徽章功能來說，如果你要針對普通終端用戶來設計徽章， 則要麼需要實現一個用戶可用來個性化設置徽章的 GUI，要麼則取巧的設計出一個比較通用的徽章，供所有的安裝版本來使用。而開源設計的實際情況是，開發者會有很多的抱怨和牢騷，認為給徽章這種東西設計一個功能全面的 GUI 是根本不可能的。而且他們會固執地把任何標準徽章的提案踢回去，踢出第一宇宙速度，擊穿地殼甩到地球的另一端。最終這些開發者還是會搞出一個類似於 Roundup 的 bug tracker 程序都在使用的流程和方案：即實現一個通用的機制，提供以 Python 或 PHP 為基礎的一些系統 API， 以便那些可以自如使用 Python 或 PHP 的人可以輕鬆的通過這些編程介面來定製化他們自己的徽章。而且老實說，PHP 和 Python 可是比任何可能的 GUI 介面都要好用和強大得多，為什麼還要考慮 GUI 的方案呢？（出自開源開發者的想法）

同樣的，開源開發者會認為那些系統設置和管理員界面也一樣可以省略掉。在他們看來，假如你是一個管理員，有 SQL 伺服器的許可權，那麼你就理所當然的具備那些系統管理員該有的知識和技能。那麼你其實可以使用 Djang-admin 或者任何類似的工具來輕鬆的對 StackOverflow 做很多設置和改造工作。畢竟如果你是一個 mods （懂如何 mod 的人）那麼你肯定知道網站是怎麼工作的，懂得如何利用專業工具去設置和改造一個網站。對啊！這不就得了！ 毋庸置疑，在開源開發者重做他們自己的 StackOverflow 的時候，他們也不會把任何 StackOverflow 在介面上面的失敗設計糾正過來。即使是原版 StackOverflow 裡面最愚蠢最失敗的那個設計（即要求用戶必須擁有一個 OpenID 並知道如何使用它）在某個將來最終被 StackOverflow 刪除和修正掉了， 我相信正在複製 StackOverflow 模式的那些開源克隆產品也還是會不假思索的把這個 OpenID 的功能仿製出來。這就好比是 GNOME 和 KDE 多年以來一直在做的事情，他們並沒有把精力放在如何在設計之初就避免 Windows 的那些顯而易見的毛病和問題，相反的卻是在亦步亦趨的重複著 Windows 的設計，想辦法用開源的方式做出一個比擬 Windows 功能的系統。

開發者可能不會關心一個應用的上述設計細節，但是終端用戶一定會。尤其是當他們在嘗試去選擇要使用哪個應用的時候，這些終端用戶更會重視這些介面設計是否易用。就好像一家好的軟體公司希望通過確保其產品在出貨之前就有一流的質量，以降低售後維護支持的成本一樣，懂行的消費者也會在他們購買這些產品之前就確保產品好用，以防在使用的時候不知所措，然後無奈的打電話給售後來解決問題。開源產品就失敗在這裡，而且相當之失敗。一般來講，付費軟體則在這方面做得好很多。

這不是說開源軟體沒有自己的立足之地，這個博客就運行在 Apache、Django、PostgreSQL 和 Linux 搭建的開源系統之上。但是讓我來告訴你吧，配置這些堆棧可不是誰都可以做的。老版本的 PostgreSQL 需要手工配置 Vacuuming 來確保資料庫的自動清理，而即使是最新版本的 Ubuntu 和 FreeBSD 也仍然要求用戶去手工配置他們的第一個資料庫集群。

相比之下，MS SQL (微軟的 SQL 資料庫) 則不需要你手工配置以上的任何一樣東西。至於 Apache …… 我的天，Apache 簡直複雜到讓我根本來不及去嘗試給一個新用戶講解我們如何可以通過一個一次性的安裝過程就能把虛擬機、MovableType，幾個 Diango apps 和 WordPress 配置在一起併流暢地使用。單單是給那些技術背景還不錯但並非軟體開發者的用戶解釋清楚 Apache 的那些針對多進程和多線程的設置參數就已經夠我喝一壺的了。相比之下，微軟的 IIS 7 或者是使用了 OS X 伺服器的那個幾乎閉源的 GUI 管理器的 Apache ，在配置的時候就要簡單上不止一個數量級了。Django 確實是一個好的開源產品，但它也 只是 一個基礎構架，而並非是一個可以直接面向終端普通用戶的商業產品。而開源真正的強項就 恰恰在 這種基礎構架的開發和創新上，這也正是驅使開發者為開源做貢獻的最本真的動力。

所以我的結論是，如果下次你再看到一個你喜歡的應用程序，請好好細心地揣摩一下這款產品，揣摩一下所有的那些針對用戶的體貼入微的設計細節。而不是武斷的認為你可以輕輕鬆鬆的在一周之內就用開源工具做一個和這個應用一摸一樣的產品出來。那些認為製作和實現一個應用程序如此簡單的人，十之八九都是因為忽略了軟體開發的最終產品是要交給用戶去用的。

via: https://bitquabit.com/post/one-which-i-call-out-hacker-news/

作者：Benjamin Pollack 譯者：hopefully2333，yunfengHe 校對：yunfengHe，wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive