Reddit聯合創始人教你避免軟件開發中的低級錯誤

Reddit聯合創始人教你避免軟件開發中的低級錯誤

2012-07-12 09:41 | 1743次閱讀 | 來源：CSDN編譯 【已有0條評論】發表評論

關鍵詞：軟件開發 | 做者：王然 | 收藏這篇資訊

關於做者：Reddit聯合創始人Aaron Swartz今年年僅26歲，是一位知名工程師、做家。14歲參與RSS1.0規範定製，並所以成爲W3C RDF核心工做小組成員。參與了Markdown、Infogami、Demandprogress、Reddit等公司、組織的創辦，早在2000年就開發了「theinfo」百科全書（知名百科全書Wikipedia創辦於2001年），同時他還熱衷參加衆多其它社會活動。

需求很重要

好的產品源於需求。雖然潛在用戶很重要，但迫切的需求對於產品來講更重要。用戶急於填補這方面的需求，因此在他們發現你的產品時就會迅速使用你的產品。若是你是爲了一我的的需求作產品，那你至少會有一個忠實用戶，但若是你想以60億用戶爲目標，頗有可能會最終一無所得。但一般是你知足了一我的的需求時也會同時知足不少有相似需求的人，或者只須要作簡單的改變。

最重要的是你本身有這樣的需求，對這個需求深有體會。若是你沒有這樣的需求，退而求其次，你能夠本身去嘗試以一種能激發這種需求的方式生活，雖然和真正需求不徹底同樣，但至少和有此需求的人能有所共鳴。

有時候你也許須要將你的需求增長一些特性，由於人們也會對本身可能的需求感興趣。要確保你的需求是不是真正的需求，因此你至少要找到一個跟你有一樣強烈感受的陌生人。

光有需求還不夠

光有需求確定不夠，你還須要一個好的想法來知足需求。認真地看看你的想法，它真得能知足需求嗎？要記住，不少想法很糟糕是由於他們沒能察覺到這是一個不知足需求的想法。你應該從需求導出解決方法，而不是反過來爲了實現本身的想法胡謅一個需求。

不是說一個想法必定不能解決多個需求，但好的想法的評判標準在與是否能完美地解決需求。

可是不要着急想這該如何實現，若是你真的是一個能給出富有創造力的想法的人，你確定會在接下來的世界裏不斷地冒出稀奇古怪的新特點、附加功能和用途。但這些都不重要，除非你如今就實現它們，不然它們只會讓你分心。因此請先將它存在「列寧文檔」（「列寧文檔」是指包括從核心功能到更抽象的特點想法中的多數派版本maximalist version）裏。

也許你不再會看這個文檔，但除非你把這些想法記下了，不然它們會不停地騷擾擬合你的同事。

如何招聘正確的人？

說到同事，你毫無疑問須要一個團隊來解決一個問題。在尋找同事的時候，你首先須要確保三個條件：

1. 他們足夠聰明嗎？
2. 他們能把事情作好嗎？
3. 他們能和你一塊兒工做嗎？

即便可以招到知足這三個問題中兩項的人可能也會讓你心滿意足！但這其實是大錯誤：足夠聰明可是完成不了任務的人無法當你的僱員，即便不去聘請他們，你也能夠把他們當作朋友一塊兒討論問題；能完成任務可是不夠聰明的人作起事來很低效，他們能完成任務，可是老是在走彎路，聰明的人會對此難以接受，因而會擠出時間來幫他；但沒法和你一塊兒工做的人確定是不要與之共事的！也許你會想：「這只是工做，反正我也沒必要和他成爲朋友。」但實際上和沒法交流的人一塊兒工做是很是痛苦的，大家沒法互相糾錯也沒法互相幫助。

傳統的招聘流程包括：

1. 閱讀簡歷；
2. 問一些難題；
3. 給他們一個真正的編程題。

我認爲這是一個糟糕的聘用系統，能從簡歷中看到的東西太少了，而在採訪中提難題很容易是人緊張，在壓力下很難完成編程。在這樣很是正常狀態下的工做是無法反映一我的真實水平的。用問題決定面試結果是殘酷的，那些出題的面試官也不必定能在第一次看到這個題目的時候就想到解決方案。

相反，問他們三個問題。找出他們能完成全部任務，問他能作什麼？若是有人真的能完成全部的工做，那他能夠如今就開始。若是有人擅長完成任務，他不會逃避。好的程序員不會缺乏經驗，由於如今任何人均可以在自由軟件項目中獲得實戰經驗。因此只要讓他作一個Demo就知道他的水平如何了。代碼是否簡潔？是否清楚？是否優雅？是否可用？是不知你正在尋找的東西？

要想知道一我的是否聰明只須要和他隨意交談。儘量地下降壓力：在咖啡廳見面，讓他明白這不是面試，儘量地休閒和友好，就像一次朋友之間的聊天。這樣能夠很容易地判斷這我的是否足夠聰明，就像咱們一直在判斷某我的是否有吸引力同樣。

最後，肯定大家是否合適一塊兒工做。有的人很聰明，可是他的一些小怪癖讓人難以接受。因此在聊天后，你能夠邀請他一塊兒吃飯或者和同事們一塊兒在辦公室打遊戲，這很容易看出一我的是否對你的口味。

在正式僱傭以前，你還須要再確認一遍本身有沒有被欺騙。你能夠調挑選項目裏的一些獨立組件讓他實現。

固然，也許你會問「爲何不先試用他一個月呢？」這根本不起做用！你會讓他不斷地去證實本身，這是很是殘酷的，並且每每會拔苗助長。並且在試用結束後，即便他並不合適，你也不必定下得了口辭去他而影響接下來的工做。

如今開始假設

你如今已經有了本身的團隊，該是作實事的時候了。是時候開始你的遠大夢想了，你確定不但願多作無用功，因此最好去找到一條最簡潔的實現方案。因此你首先提出幾個假設，假設很重要，由於每個解決方法都來自假設，若是這些假設不成立，那麼解決方法確定也是不會成功的。

寫下這些假設，而且挑出最重要的。這點很是重要，若是這個假設是錯誤的，那麼咱們全部的工做都將付諸流水。因此咱們須要作一些實驗來證實這是真實可靠的。

由於針對不一樣的猜測，實驗代碼會須要不停地改動，因此在此加入一些控制器是不錯的選擇。

團隊和任務

一旦你確認假設是正確的以及最簡潔的解決方法和一套明確的評價標準，開始建設的時候就真正到來了。你首先須要挑選一個可靠的產品擁有者，這是你的產品的「喬布斯」，他們有權決定產品的每一個細節來確保產品的一致。

你還須要製做一張卡片來描述你的的建議以及你的評價標準，簡單地創建一個任務管理系統。根據重要度將一堆任務卡片排序，當你的設計師在完成一項任務的時候就從最上面抽走一張卡片，而後由擁有者決定詳細的設計（按鈕放在哪兒？它究竟寫着什麼？）。但產品擁有者決定了具體的設計後就能夠開始把任務交付給程序員了，並與他們共同實現實驗。

實現過程當中免不了會遇到一些實際問題，可能會須要屢次修改設計，這時候還須要產品擁有者從新進行校正。

開發與測試

在開發中使用自動化測試是件好事，這樣就能很容易地發現是否有錯誤發生。你以爲已經完成時也可使用自動化測試來確保徹底經過。固然，你須要確保自動化測試覆蓋了全部控制和功能。

編程是一件很費心力的工做，因此程序員結對編程每每能更高效——一個輸入，另外一個觀察並評論。（有時候 一我的寫測試，另外一個寫代碼來保證測試經過頗有趣。）

固然你並不須要一直兩我的一塊兒編程，但你得保證有人來評估你的更改。你須要在提交代碼以前審閱差別變化。

體系結構

若是你正在開發網絡服務（好比Web應用），你應該把它當作十二因子應用（Twelve-Factor Application）來設計。

十二因子應用的十二條原則以下：

1. 整個應用的代碼存儲在一個版本的控制庫裏。若是你爲軟件的不一樣部分準備了多個版本庫，你應該把他們當作是不一樣的應用，而他們之間互爲服務。若是你將多個應用加入了同一個代碼庫，你須要找出它們共同的依賴庫，並將它們分到兩個代碼庫裏。
2. 明確聲明依賴。在Ruby裏你可使用Gemfile，在Python裏是requirements.txt，等等。本地你可使用bundler和viirtualenv這樣的工具來隔離環境來保證沒有使用任何未聲明的依賴。
3. 全部配置值都應該當作環境變量存儲。這裏包括全部不適宜公開的東西：密碼、密鑰以及其它在部署間各不相同的東西包括數據庫地址以及管理員帳戶等等。
4. 全部支持服務（如數據庫和內存裏的緩存）都視爲服務。對於本地和第三方服務沒有任何區別：他們都經過網絡訪問。
5. 代碼分三個獨立步驟部署：編譯、釋出和運行。
6. 應用應該當作一系列無狀態進程執行，全部進程均可以在任時候關閉。
7. 應用應該是徹底獨立的，經過IP端口和外界通訊，而不該該存在於某些大型進程裏。
8. 應用應該有不少進程類型組成，而且能夠擴展更多進程類型。
9. 進程應該是可任意使用的，你能夠在任什麼時候候啓動或中止它，而不用擔憂任何破壞。
10. 開發和產品間的隔閡應該儘量地的小——相同的支持服務、依賴、團隊應該在兩處都被使用。
11. 日誌應該是無緩衝的和標準輸出的事件流。
12. 管理任務應該當作是一次性的進程。

部署要注意些什麼

開發者應該在代碼通過測試後提交到版本庫中。若是代碼會改變支持服務，這應該經過遷移來實現。遷移會描述如何製造或者回滾這樣的改變。當新版本的軟件部署後，全部沒在運行的遷移開始運行，並同步這個版本的支持服務到它所依賴的代碼裏。回滾使得遷移也回滾，這保證支持服務和代碼始終同步。

幾乎全部的代碼都提交到開發主線。這避免了不一樣分支痛苦的合併過程。由於全部大的變化都應該當作實驗，若是變化未完成或者未準備好，能夠經過禁止大部分用戶來關閉它。當代碼已經完善，更多的人就能夠進入到這個實驗羣體裏，開關也就所以能夠永久地移除了。

確保每一塊添加進產品裏的代碼都通過了產品擁有者的檢查，他們須要控制產品發佈。對實驗的評估能夠先從項目擁有者開始漸漸增長用戶，直到全部的用戶滿意爲止，此時才能夠將實驗中的控制器代碼移除。

怎樣發佈更合適？

有人會建議你使用好萊塢式的試行，提早幾個月公佈發佈日期並大肆炒做。這也許很適合好萊塢，但它並不適合軟件發佈，由於你的產品不會在劇院，而是在網上發佈！你不用擔憂一週後劇院就不爲你宣傳了，只要在網上，你能夠一直作推廣，慢慢積累你的用戶羣。

除非你是個可貴的天才，不然軟件在推出當天確定仍是會遺留不少以前沒有注意到的bug和概念錯誤，而如今數以百萬計的用戶會使用你的產品並遇到錯誤。

相反，你應該把發佈當作是另外一個實驗，隨着產品的進一步完善慢慢增長用戶數量，GMail就是一個不錯的案例。