我在蘋果公司學到的編程技巧

當我還在蘋果在線商店工做的時候，咱們歷來沒有對在線網站作過負載測試。咱們也不 以爲須要這麼作。然而，當每次史蒂夫·喬布斯在演示某個幻燈片過程當中切換到在線商店時，會走下臺來等待，這是很是有趣的經歷。做爲過後檢查的一部分，每次 在線商店從新上線時，咱們都會問本身服務器的瓶頸在哪裏：是CPU、網絡帶寬、磁盤I/O仍是內存？雖然準確預測整個系統在實際環境中的行爲很是困難，幸 運的是咱們有一整套的測試策略來確保在從新啓動以前有足夠的測試。

負載測試 / Load Testing

許多公司用負載測試來試驗他們的web應用程序可以支持怎樣的負載。一個最日常用到的，可是錯誤的方式是把web站點上線而後啓動負載測試。這 種方式的問題在於，它不會告訴你web站點從在線狀態到不能提供服務這個過程當中是如何運行的。當一個web站點在使用狀態時宕機而後從新啓動，這時web 站點表現出的行爲，必定與負載測試狀態下有很大的區別。例如，咱們發如今iTunes商店（iTunes Store）第一次啓動時，一個被信任的WebObjects組件不是線程安全的，而這個問題只有在該對象處於重負荷狀況下才會出現。

初生牛犢 / Cutting My Teeth

當我第一次加入蘋果在線商店開發小組時，我和一位經驗豐富的軟件工程師搭檔，他教會我如何快速地熟悉代碼庫，構建流程以及單元測試和組件測試。因爲在線商店已經上線了，咱們只有在對新代碼進行測試以及蒐集數據以後才能發佈。

個人第一項任務是和搭檔一塊兒實現一個在網絡上用特性表形式蒐集產品信息的簡單web服務。通常這樣的簡單web服務程序只須要一到兩天，而咱們 倆在師傅的一步步指導下花了一整個禮拜，經過結對編程方式完成了整個流程。（雖然咱們採用結對編程，可是咱們使用的是Agile/Scrum，而不是極限 編程。每一個開發小組能夠在保證進度的前提下使用任何他們達成共識的開發技術。我服務的團隊碰巧有幾個通過訓練的scrum大師，他們獲得了管理團隊的支 持。）

在實際開始編寫產品代碼以前，咱們須要編寫單元測試。全部的軟件工程師都被要求先爲他們的API編寫單元測試，這個一個很值得學習的規範。接下 來，咱們在Eclipse/WOLips上使用WebObjects/Java編寫代碼，與此同時，咱們爲應用程序設下關鍵的斷點，而後在調試模式下運 行，這樣咱們就能夠單步調試代碼。我見到了有太多在別處工做的軟件工程師，他們不斷地編碼然，就像他們在不斷地往牆上扔東西，而後看看到底會有什麼會粘在 牆上（像碰運氣同樣）。

在咱們簽入咱們代碼的同時，軟件倉庫會自動構建全部的應用程序，而後對它們運行單元測試。若是你的代碼讓此次構建失敗，開發小組的每一個人，包括一到兩位項目經理會受到郵件通知——你就是構建失敗的罪魁禍首。

令牌 / Token

咱們有一段很是特殊的軟件代碼，一次只能由一個軟件工程師簽出（check out）、編寫（work on）、而後簽入（check in）。你只有在獲得一個物理令牌時纔可以接觸到這段代碼。在咱們這裏，這個令牌就是一個Darth Tater玩偶，它放在你工做的格子間或者書架上最顯眼的地方。

蒐集度量數據 / Gathering Metrics

一旦咱們的服務編碼完成，沒有錯誤，而且被簽入到代碼倉庫後，咱們開始組件測試並蒐集新代碼的度量數據。這是另一個在新手團隊裏被忽略的步 驟。我懷疑蒐集度量數據這個步驟甚至都沒有被包含在Joel測試中，由於Joel Spolsky的產品是一個桌面應用程序而不是一個須要重負載測試的web程序（或者，也許這個被隱含在「你有測試工程師嗎？」這個步驟裏）

甚至在咱們考慮將代碼放到實時代碼分支以前，咱們就已經對代碼進行了數百萬次的請求測試。在蘋果公司，咱們有一個很是複雜的緩存算法，根據咱們 設定的目標，它能夠保存咱們須要的任意數目的記錄。咱們是否須要五百個或是五萬個產品的請求記錄緩存呢？在一次冷啓動開始以後，咱們是否須要對指定的產品 用緩存來熱身呢？在沒有任何的請求命中時，咱們須要等多久才把一個產品從緩存中移除並釋放內存呢？

附註一點，咱們的緩存一般是一個哈希表。哈希表的優勢在於它的大O表示法運行時間是常量O(1)。當你在一個面試中被問道什麼事最快的查找函數時，千萬不要說一個B樹二叉樹。完美的哈希表一般會輕鬆勝出。

調整並完成 / Tweaking and Done

咱們會不斷調整代碼直到咱們獲得可接受的度量數據。咱們的測量數據會對緩存內存消耗多少以及知足每一個服務請求/響應的時間長短進行度量。根據我 們的需求，咱們會努力達到99.7%的服務請求在35毫秒以內返回，95%的請求在10毫秒以內返回，沒有單個請求超過50毫秒的響應時間。

這些測試在一個很是接近產品環境的實時數據庫的拷貝中運行。這不能完美地指出web應用程序一旦在實際環境中會如何執行。可是將它變成一個設按期望的很好的辦法，這不會須要好久時間。

在咱們疾跑（Sprint）結束的時候，全部這些度量數據都會做爲敏捷定義完成時演示的一部分。這時代碼已經準備就緒能夠被簽入質量保證的代碼分支，在代碼發佈上線以前還會進行功能測試。

編注：

1. 大O表示法：用來描述算法的時間複雜度，O(1)的時間複雜度最低。

2. 疾跑（Sprint）：是scrum開發方法的一個最基本開發單元。

原文地址 http://www.chengxuyuans.com/program_life/9275.html