編者按：原文作者喬納森·丹尼可（Jonathan Danylko）是一位自由職業的web架構師和程序員，編程經驗已超過20年，涉足領域有電子商務、生物技術、房地產、醫療、保險和公用事業。正如喬納 森在文中所言，本文適合剛畢業的大學生和剛入門的程序員。如果你已是高級開發人員，或許你在本文中看到自己的身影。

從11歲時，我就一直在編程，并且一直都很喜歡技術和編程。這些年來，我積累了一些艱難又容易的經驗。作為一名程序員，你或許還沒這些經驗，但我會把它們獻給那些想從中學到更多的朋友。

我會持續更新這些經驗，我可能還會有更多的感想，但就我這20年來看，我想下面這個列表中基本不需要增添額外的東西了。下面就是我至今最難忘的經驗。

1. 估算解決問題所需要的時間。不要怕，承認吧！我曾見過一些程序員為了解決一個特殊問題而坐在顯示器前面8小時。為自己定一個時間限制吧，1小時、30分鐘或甚至15分鐘。如果在這期間你不能解決問題，那就去尋求幫助，或到網上找答案，而不是嘗試去做“超級堆碼員”。

2. 編程語言是一種語言，只是一種語言。隨著時光推移，只要你理解了一種語言的原理，你會發現各種語言之間的相似之處 。你所選擇的語言，你應該覺得“舒服”，并且能夠寫出有效（而且簡潔）的代碼。最重要的，讓語言去適應項目，反之亦然。

3. 不要過于注重程序的“設計模式”。 有時候，寫一個簡單的算法，要比引入某種模式更容易。在多數情況下，程序代碼應是簡單易懂，甚至清潔工也能看懂。

4. 經常備份代碼。在我年輕時，我就有過因硬盤故障而丟了大量代碼的經歷，這經歷很恐怖的。只要你一次沒有備份，就應當像有著嚴格的期限，客戶明天就需要。此時就該源碼/版本控制軟件大顯身手了。

5. 承認自己并不是最頂尖的程序員 - 知不足。我常想，我對編程了解已足夠多，但是總有其他人比你優秀。正所謂，“一山總比一山高”。所以，向他們看齊吧！

6、學習再學習。正如第5點所說，我經常會在手里拿一本計算機或編程相關的雜志或書（不信，可以問我的朋友）。誠然，總有很多你不知道的技術，你可以從中學習以保持不落后。如果你有一種靈巧的方式來獲取你需要的新技術，那你每天都應該堅持學習。

7. 永恒的變化。你 對待技術/編程知識，就應像你對待股票一樣：多樣化。不要在某一特定技術上自我感覺良好。如果那種技術或語言已經沒有足夠支持，那你還不如現在就開始更新 你的簡歷，并啟動培訓新計劃。我能保持前行的主要原則是什么呢？至少了解兩到三種語言，所以，如果某種語言過時了，你在學習新技術的時候還可以依靠另一種 語言。

8. 提攜新人。協助并且培養初級/入門的開發人員學習優秀的編程方法和技巧。也許你還不知道，在幫助他們向更高一層前進時，你自己也在向更高一層提升，你會更加自信。

9. 簡化算法。代碼如惡魔，在你完成編碼后，應回頭并且優化它。從長遠來看，這里或那里一些的改進，會讓后來的支持人員更加輕松。

10. 編寫文檔。無 論是Web服務的API，還是一個簡單的類，你盡量編寫相應文檔。我曾經引以為豪的代碼注釋，因過度注釋而有人指責。給三行代碼加一行注釋，只需要你幾秒 時間。如果那是一個比較難以理解的技術，千萬別擔心過多注釋。如果你能很好做好自己的工作，大多數架構師、后備程序員、支持組都會感激你。

11. 測試、測試再測試。我是一名黑盒測試粉絲。當你完成編碼后，你“被認可”的時候就開始了。如果你們公司有QA部門，如果你的代碼中有錯誤，那你得到的評論，會比項目經理還多。如果你不徹底測試自己的代碼，那恐怕你開發的就不只是代碼，可能還會聲名狼藉。

12. 慶祝每一次成功。我見過很多程序員在解決編程技術難題后，會和同伴握手、擊掌或甚至手舞足蹈。每個人在生命中都會碰到“頓悟”。如果一個程序員高興地跑來叫你去看他的非凡代碼，也許你已經看過這樣的代碼100遍了，但你也應該為了這個家伙而慶祝第101次。（編者注：《慶祝成功的九種方式》。）

13. 經常檢查代碼。 在公司，你的代碼要經常檢查（包括自查和其他同事檢查）。不要把別人的檢查，看成是對代碼風格的苛求。應該把它們看作是有建設性的批評。對個人來說，經常檢查你的代碼并且自問，“我怎樣才能寫得更好呢？” 這會讓你加速你的成長，讓你成為一個更優秀的程序員。

14. 回顧你的代碼。在 看到自己以前的代碼時，通常會有兩種方式：“難以至信，這代碼是我寫的”和“難以至信，這代碼是我寫的”。第一種往往是厭惡的語氣，并在想如何改進它。你 也許會驚嘆，舊代碼也能復活成為一種更好的程序，甚至是一個完整的產品。第二種通常帶著驚奇和成就感。開發人員應該一到兩個自己完成的項目成果，能讓眾人 不禁而立并注目而觀的項目。同樣，基于你優越的編程能力，你可以把過去的程序或項目拿出來，把它們更新為更加優秀的產品或想法。

15. 幽默是不可缺的。在我20年的開發生涯中，我還沒有碰到哪位程序員是沒有幽默感的。實際上，干我們這行，幽默是一項必備品。

16. 謹防那些無所不知的程序員，不愿分享的程序員，還有經驗不足的程序員。當你遇到這幾種程序員時，你自己要謙虛。無所不知的程序員，更想當一個英雄而不是團隊成員；保守的程序員則是在編寫著他們獨享的代碼；而經驗不足的程序員則會每十分鐘就來問你一下，當代碼完成后，代碼已經是你的，而不是他們。

17. 任何項目都不會那么簡單。朋 友、家人和同事曾請求我倉促做一些事情，倉促做一個程序或者網站。對于這樣的事，應該從雙方做計劃，才能做出令兩方都會滿意的東西。如果某人起初只是需要 一個使用Microsoft Access的、只有有3個頁面的網站，但來就很可能變成一個有15個頁面的網站，并使用SQL Server，有一個論壇，還有一個定制的CMS（內容管理系統）。

18. 任何時候不要想當然。假如你承接一個簡單的項目，你可能會認為某個部分可以輕松完成。千萬別這樣想！除非你有一個類、組件、或者一段已經寫好的代碼，并且在現有的項目已經測試通過。不要認為這將是很容易的。

19. 沒有已經完成的軟件。曾經有一位程序員告訴我，沒有軟件是已經完成的，它只是“暫時完成了”。這是明智的忠告。如果客戶還在使用你寫的程序，并經受了時間的考驗。如果有機會，你仍在更新它，這并不是什么壞事，這讓你不斷地前行。

20. 耐心是一種美德。當 客戶、朋友或家庭成員用電腦的時候，他們也許會受挫，進而想砸電腦，或氣沖沖地離開。我一直在告訴他們，“是你掌控電腦，不是電腦掌控你。”對于用作編程 的電腦，你要有一定的耐心。一旦程序員知道問題所在后，他們就會站在電腦的角度看問題，并且說 “哦，這就是為什么它是這樣做。”

編者后話

對本文深有感觸！雖然本文沒有華麗的辭藻，其中樸實的道理，其實并非只適用程序員，同樣可以擴展到其他行業。記得以前練字時，總感覺當時寫得很好，但后來回頭再看時，也會想“這居然是我寫的字！”

在閱讀本文的朋友，不知你是否也有看到了自己的身影呢？歡迎你在微博或評論中和大家一起分享感觸。

A java based workflow suite,include engine、designer...

一個java工作流套件，包含引擎、設計器等等。歡迎大家積極報告錯誤，同時也歡迎大家加入Fireflow。

QQ群號是：200人高級群 80347522（已滿）

500人超級群 32897788

官方論壇：www.fireflow.org

Fire Workflow的開發計劃¶

• 流程模型+引擎：已于2009年2月2日發布預覽版本
• netbeans設計器-模擬器插件：已經發布預覽版本。
• eclipse設計器-模擬器插件：已于2009年2月2日發布預覽版本。
• 圖形化流程實例跟蹤：即在瀏覽器中顯示流程執行的進度情況，使用SVG技術。尚無明確時間表。
• 基于Web的流程自定義程序：嚴格說是對系統已經存在的流程作局部調整，而不是完全的自定義。這個東東是否有必要，怎么實現，正在考慮中。

A java based workflow suite,include engine、designer...

一個java工作流套件，包含引擎、設計器等等。歡迎大家積極報告錯誤，同時也歡迎大家加入Fireflow。

QQ群號是：200人高級群 80347522（已滿）

500人超級群 32897788

官方論壇：www.fireflow.org

Fire Workflow的開發計劃¶

• 流程模型+引擎：已于2009年2月2日發布預覽版本
• netbeans設計器-模擬器插件：已經發布預覽版本。
• eclipse設計器-模擬器插件：已于2009年2月2日發布預覽版本。
• 圖形化流程實例跟蹤：即在瀏覽器中顯示流程執行的進度情況，使用SVG技術。尚無明確時間表。
• 基于Web的流程自定義程序：嚴格說是對系統已經存在的流程作局部調整，而不是完全的自定義。這個東東是否有必要，怎么實現，正在考慮中。

A java based workflow suite,include engine、designer...

一個java工作流套件，包含引擎、設計器等等。歡迎大家積極報告錯誤，同時也歡迎大家加入Fireflow。

QQ群號是：200人高級群 80347522（已滿）

500人超級群 32897788

官方論壇：www.fireflow.org

Fire Workflow的開發計劃¶

• 流程模型+引擎：已于2009年2月2日發布預覽版本
• netbeans設計器-模擬器插件：已經發布預覽版本。
• eclipse設計器-模擬器插件：已于2009年2月2日發布預覽版本。
• 圖形化流程實例跟蹤：即在瀏覽器中顯示流程執行的進度情況，使用SVG技術。尚無明確時間表。
• 基于Web的流程自定義程序：嚴格說是對系統已經存在的流程作局部調整，而不是完全的自定義。這個東東是否有必要，怎么實現，正在考慮中。

為Google app engine開發JAVA Hello Word

After hearing the buzz about java support in Google App Engine I decided to write a hello, world application and run it on Google App Engine.

在聽說GAP 支持java以后，我決定寫一個在gap 上運行的java hello world程序。我使用的開發工具是eclipse 3.4,google推出了gap的Eclipse插件，以方便開發者。 

添加Eclipse的Google app engine  plugin

 第一步： 打開eclipse，選擇 幫助>軟件更新>添加站點。站點的url 是：

 勾選sdk，plugin，toolkit 可選，點擊安裝，重啟Eclipse等更新完成。 

創建工程 

創建一個新的web application ，點擊file >New >project，在對話框中選擇google下面的google web application。 

 指定web應用的名稱和包的名稱。為了保持應用的簡單，不要勾選‘use GWT’ and check ‘，勾選‘Use app engine’，之后點擊完成。  

這樣就生產了應用文件，工程結構如下：

本地運行web應用 

Right click on your application and click on Run as… > Web Application.

右鍵點擊helloword工程，選擇Run as… > Web Application.

Eclipse將啟動web app服務器在端口8080，你可以通過這個url訪問應用：

Create a Google App Engine account

創建gap 帳號 

Before you can deploy you hello world application to google app engine, you need to create an account on google app engine.

在你把web應用部署在gap以前，你必須創建一個gap帳號。可以登錄http://appengine.google.com/按照步驟創建app帳號。

 首先通過已有的google帳號登錄，當你第一次創建app帳號的時間必須通過短消息驗證。我們選擇 其他國家和地區，手機號碼輸入：+086 13888886666 （13888886666是你的手機號碼，可以接受短信），之后在下一步的驗證中輸入你的手機收到的驗證碼。

 選擇一個唯一的application ID

Application id, 就像登錄名字一樣必須是唯一的。在操作之前你必須選擇一個唯一的id。在你選擇application id后，http://<你的 application id>.appspot.com 就是你的應用的地址。

配置eclipse  application的application id

右鍵點擊 helloworld工程，google >app engine settings。

輸入你的application id。也可修改appengine-web.xml中的application標簽。

<application>wjjapp</application>  

部署你的app到Google app engine

 右擊 你的應用> Google > Deploy to app engine.輸入google帳號名，和密碼，點擊部署即可。

完成上面的步驟后，你的web應用就部署到了Google app engine.如果部署失敗，收到這樣的消息：

java.io.IOException: Error posting to URL: http://appengine.google.com/api/appversion/...  

這是由于你沒有訪問java version的權限，你可以點擊 here申請。

申請成功的話，你將會收到google的mail通知，這個過程一般需要1到2天的時間。Email如下：

再次嘗試部署web應用，這次將會成功，你將看到下面的控制臺輸出：

在線訪問你的應用 

登錄 google app engine，你將看到你的application頁面。

你將看到你的版本號為1的web應用，點擊鏈接，打開應用。鏈接如下的格式：http://<applicationid>.appspot.com, 例http://wjjapp.appspot.com/.

對于 Java 程序員來說，除 SSH 之外，的另一個選擇:

Nutz

當然，它是開源的，并且是完全免費的,同時也是商業友好的(Licensed under the Apache License, Version 2.0)。

同傳統的 SSH 相比，它具備如下特點：¶

• 輕 -- 當前最新版，整個 jar 文件共 820k
• 薄 -- 針對 JDBC 的薄封裝，無緩存
• 全 -- 提供了 Dao (ORM, SQL 管理)， Ioc, Aop, Mvc, Json解析 等必要功能
• 活 -- 各個部分可以獨立使用，比如在 Spring 里采用 Nutz.Dao ，又比如在 Nutz.Ioc 里使用 Hibernate 等
• 整 -- 它所有功能均不依賴第三方 jar 文件。

這就意味著：如果一個 Web 應用，你在 WEB-INF/lib 下只 需要放置一個 nutz.jar 就夠了

當然你要使用其它的連接池，數據庫驅動，打印PDF支持等功能，還需要自行添置 jar 包。

Nutz 為誰而設計？¶

• 如果你覺得 Hibernate 控制比較繁瑣，iBatis 編寫SQL又比較麻煩，Nutz.Dao 專為你設計。
• 如果你覺得在多個服務器部署或者修改 Spring 配置文件很麻煩，Nutz.Ioc 專為你設計
• 如果你覺得直接寫 XML 配置文件很麻煩，可視化編輯器又沒控制感，Nutz.Mvc 專為你設計
• 如果你覺得 JSON 轉換很麻煩（要寫超過一行以上的代碼），Nutz.Json 專為你設計
• 如果你覺得 Java 語法不如 Ruby 便捷， Nutz.Castor 以及 Nutz.Lang 專為你設計
• 如果你以前根本沒接觸過 SSH ，只使用 JDBC 編程， 整個 Nutz 專門為你設計
• 你只要在你的 classpath 下部署這個 800多K 的小 jar 包，你會得到上述所有好處

我要使用 Nutz，該從那里入手呢？¶

1. 下載 Nutz -- 包括文檔和源碼都包含在下載包中
2. 閱讀文檔 -- Wiki 頁面 有充分的介紹，每個部分都有 Hello World
3. 運行 Demo -- Demo 在不斷的添加中 ... 現在已有 7 個可用 Demo
4. 編譯 -- 請看詳細介紹
5. 運行測試 -- 請看詳細介紹

另外：

1. Amosleaf 寫了一個 Nutz.Dao 入門的例子
2. Peter Tung 寫的 Nutz Json Book 幾分鐘可以讓你對 Json 解析入門

Nutz 的質量¶

托社區的福，截至到現在為止，Nutz 一共通過了超過 500 個JUnit測試。其中有 152 個用例針對數據庫，并在如下數據庫中工作良好：

• H2
• MySql
• Oracle
• Postgresql
• SqlServer2005
• SqlServer2000
• DB2

截止到 1.a.31 為止，大約有 66% 的代碼被 JUnit 測試用例覆蓋：

更多詳情，請請 查看最新emma測試報告

在一個功能告一段落以后，我通常會花1－2個晚上在一邊咂著廉價的紅酒一邊頗有成就感的書寫JUnit測試。 通常我會用 JUnit 把我自己擊潰，緊接著的那幾天我都努力讓那個該死紅條變綠，之后，又想方設法寫出 新的Junit測試試圖讓它再度變紅。并且我還要保證所做的修改不能讓代碼膨脹，這的確讓我死掉了不少腦 細胞。這些測試中，不僅涵蓋各種功能上的測試，也涵蓋了一些跨越線程的測試。在以后，我會針對代碼執 行的效率加入一些新的測試。

我能保證的就是Nutz的代碼是小巧的，以及通過盡可能多的 JUnit 測試。但是所有我能做的也就只是 這些了，找出剩下的那些代碼上的缺陷，就應該交給 Nutz 第一批“小白”們了。“小白”們，加油！我 支持你們...

^{小白： 是小白鼠的簡稱。小白鼠是實驗室的最愛，實驗室是產生新東西的地方。}

注: 從 09年9月開始，隨著“小白”們的不斷增多，項目的 Issue 列表越來越長，不斷的有人發現缺陷，也不斷的有人 提交修復，現在，基本上是整個社區在決定 Nutz 的品質。

Nutz 的未來¶

Nutz 是一個新興的開源項目

它沒有過去，只有未來

我可以保證，在未來，Nutz 的代碼 絕對不會膨脹。 所有的功能設計的出發點就是最大限度給予程序員實惠。

• 下面一些計劃會被執行，但是不一定按照我給出的順序：

  * 為 Nutz 的 Ioc 和 Mvc 開發一個代碼生成器
  * 讓 Nutz.mvc 支持自動生成縮略圖
  * 為 Nutz 建立一個官方網站，提供討論區和 Wiki
  * 提供英文文檔

• Nutz 會是一個長期的項目，因為
 

   1. 我寫它不花錢
   2. 我喜歡寫代碼
   3. 我不擔心自己的生計
   4. 社區很活躍，越來越多的人在貢獻代碼，測試，提交問題

http://www.zentao.net/

禪道項目管理軟件(ZenTaoPMS)是一款國產的，基于LGPL協議，開源免費的項目管理軟件，它集產品管理、項目管理、測試管理于一體，同時還包含了事務管理、組織管理等諸多功能，是中小型企業項目管理的首選。
禪道項目管理軟件主要理念基于scrum，因此它也是一款好用的scrum管理工具。
禪道項目管理軟件使用PHP + MySQL開發，基于自主的PHP開發框架──ZenTaoPHP而成。第三方開發者或者企業可以非常方便的開發插件或者進行定制。

http://www.playframework.org/documentation/1.1/firstapp

本文是使用 B3log Solo 從 Solo 示例 進行同步發布的。

http://code.google.com/p/javabloger-mini-books/

本文是使用 B3log Solo 從 Solo 示例 進行同步發布的。

mongodb由C＋＋寫就，其名字來自humongous這個單詞的中間部分，從名字可見其野心所在就是海量 數據的處理。關于它的一個最簡潔描述為：scalable, high-performance, open source, schema-free, document-oriented database。我對于文檔型數據庫有一些個人的偏好，這種偏好是從半年前研究couchdb而來的，因為我覺得用它來描述一個具有個性化特征的實體對 象正合適，比如網站上的用戶或商品書籍之類的條目。

一些概念：

跟mysqld一樣，一個mongod服務可以有建立多個數據庫，每個數據庫可以有多張表，這里的表名叫collection，每個 collection可以存放多個文檔（document），每個文檔都以BSON（binary json）的形式存放于硬盤中。跟關系型數據庫不一樣的地方是，它是的以單文檔為單位存儲的，你可以任意給一個或一批文檔新增或刪除字段，而不會對其它文 檔造成影響，這就是所謂的schema-free，這也是文檔型數據庫最主要的優點。跟一般的key-value數據庫不一樣的是，它的value中存儲 了結構信息，所以你又可以像關系型數據庫那樣對某些域進行讀寫、統計等操作。可以說是兼備了key-value數據庫的方便高效與關系型數據庫的強大功 能。

索引

跟關系型數據庫類似，mongodb可以對某個字段建立索引，可以建立組合索引、唯一索引，也可以刪除索引。當然建立索引就意味著增加空間開銷，我 的建議是，如果你能把一個文檔作為一個對象的來考慮，在線上應用中，你通常只要對對象ID建立一個索引即可，根據ID取出對象某些數據放在 memcache即可。如果是后臺的分析需要，響應要求不高，查詢非索引的字段即便直接掃表也費不了太多時間。如果還受不了，就再建一個索引得了。

默認情況下每個表都會有一個唯一索引：_id，如果插入數據時沒有指定_id，服務會自動生成一個_id，為了充分利用已有索引，減少空間開銷，最好是自己指定一個unique的key為_id，通常用對象的ID比較合適，比如商品的ID。

capped collection

capped collection是一種特殊的表，它的建表命令為：

db.createCollection("mycoll", {capped:true, size:100000})

允許在建表之初就指定一定的空間大小，接下來的插入操作會不斷地按順序APPEND數據在這個預分配好空間的文件中，如果已經超出空間大小，則回到 文件頭覆蓋原來的數據繼續插入。這種結構保證了插入和查詢的高效性，它不允許刪除單個記錄，更新的也有限制：不能超過原有記錄的大小。這種表效率很高，它 適用于一些暫時保存數據的場合，比如網站中登錄用戶的session信息，又比如一些程序的監控日志，都是屬于過了一定的時間就可以被覆蓋的數據。

復制與分片

mongodb的復制架構跟mysql也很類似，除了包括master-slave構型和master-master構型之外，還有一個 Replica pairs構型，這種構型在平常可以像master-slave那樣工作，一但master出現問題，應用會自動了連接slave。要做復制也很簡單，我 自己使用過master-slave構型，只要在某一個服務啟動時加上–master參數，而另一個服務加上–slave與–source參數，即可實現 同步。

分片是個很頭疼的問題，數據量大了肯定要分片，mysql下的分片正是成為無數DBA的噩夢。在mongodb下，文檔數據庫類似key- value數據庫那樣的易分布特性就顯現出來了，無論構造分片服務，新增節點還是刪除節點都非常容易實現。但mongodb在這方面做還不足夠成熟，現在 分片的工作還只做到alpha2版本（mongodb v1.1），估計還有很多問題要解決，所以只能期待，就不多說了。

性能

在我的使用場合下，千萬級別的文檔對象，近10G的數據，對有索引的ID的查詢不會比mysql慢，而對非索引字段的查詢，則是全面勝出。 mysql實際無法勝任大數據量下任意字段的查詢，而mongodb的查詢性能實在讓我驚訝。寫入性能同樣很令人滿意，同樣寫入百萬級別的數 據，mongodb比我以前試用過的couchdb要快得多，基本10分鐘以下可以解決。補上一句，觀察過程中mongodb都遠算不上是CPU殺手。

GridFS

gridfs是mongodb一個很有趣的類似文件系統的東西，它可以用一大塊文件空間來存放大量的小文件，這個對于存儲web2.0網站中常見的大量小文件（如大量的用戶頭像）特別有效。使用起來也很方便，基本上跟一般的文件系統類似。

用合適的數據庫做適合的事情

mongodb的文檔里提到的user case包括實時分析、logging、全文搜索，國內也有人使用mongodb來存儲分析網站日志，但我認為mongodb用來處理有一定規模的網站日 志其實并不合適，最主要的就是它占空間過于虛高，原來1G的日志數據它可以存成幾個G，如此下去，一個硬盤也存不了幾天的日志。另一方面，數據量大了肯定 要考慮sharding，而mongodb的sharding到現在為止仍不太成熟。由于日志的不可更新性的，往往只需APPEND即可，又因為對日志的 操作往往只集中于一兩列，所以最合適作為日志分析的還是列存儲型的數據庫，特別是像infobright那樣的為數據倉庫而設計的列存儲數據庫。

由于mongodb不支持事務操作，所以事務要求嚴格的系統（如果銀行系統）肯定不能用它。

mongodb占用空間過大的原因，在官方的FAQ中，提到有如下幾個方面：

1、空間的預分配：為避免形成過多的硬盤碎片，mongodb每次空間不足時都會申請生成一大塊的硬盤空間，而且申請的量從64M、128M、 256M那樣的指數遞增，直到2G為單個文件的最大體積。隨著數據量的增加，你可以在其數據目錄里看到這些整塊生成容量不斷遞增的文件。

2、字段名所占用的空間：為了保持每個記錄內的結構信息用于查詢，mongodb需要把每個字段的key-value都以BSON的形式存儲，如果 value域相對于key域并不大，比如存放數值型的數據，則數據的overhead是最大的。一種減少空間占用的方法是把字段名盡量取短一些，這樣占用 空間就小了，但這就要求在易讀性與空間占用上作為權衡了。我曾建議作者把字段名作個index，每個字段名用一個字節表示，這樣就不用擔心字段名取多長 了。但作者的擔憂也不無道理，這種索引方式需要每次查詢得到結果后把索引值跟原值作一個替換，再發送到客戶端，這個替換也是挺耗費時間的。現在的實現算是 拿空間來換取時間吧。

3、刪除記錄不釋放空間：這很容易理解，為避免記錄刪除后的數據的大規模挪動，原記錄空間不刪除，只標記“已刪除”即可，以后還可以重復利用。

4、可以定期運行db.repairDatabase()來整理記錄，但這個過程會比較緩慢。

因為官方文檔中對各方面的內容已經有很詳細的敘述，所以我并沒有再過多的引用原文與代碼，只是結合自己的使用歸納一些心得，有興趣的朋友不妨直接去翻文檔中自己感興趣的問題，超群的博客上有一個很好的入門介紹。

最后總結一句，文檔型數據庫有點像波粒二象性，總能在適當的時候表現出它作為關系型數據庫或key-value數據庫的優勢來。

實戰案例：

昨天我訪問mongodb的python程序開始出錯，經常拋出AssertionError異常，經查證只是master查詢異常，slave正常，可判斷為master的數據出了問題。

修復過程：

1、在master做db.repairDatabase()，不起作用；

2、停止slave的同步；

3、對slave作mongodump，備份數據；

4、對master作mongostore，把備份數據恢復，使用–drop參數可以先把原表刪除。

5、恢復slave的同步。

本文是使用 B3log Solo 從 Solo 示例 進行同步發布的。