個人認為寫部落格（Blogging）是技術總結的最佳方式，甚至可以這樣子講，部落格就是積累，從一定角度上講是醬紫的。可能是受規範約束習慣了，感覺寫部落格也有一些注意事項，雖然之前寫了很多文章，但感覺都不是很規範，現總結寫部落格應該注意的幾點，以隨時提醒自己。

1. Do not Repeat Documents, link to it 不要重複文件，給出連結就好。重點寫自己的心得，體會和總結。

對於那些在官方文件中都講的很清楚的東西就沒有必要再進行重複了，給出相應的連結就好了。特別是對於像MSDN這種非常豐富的官方文件，最好不要去重複它的內容，因為你不一定比官方講的清楚。重點應該放在自己的心得，體會和總結等，這樣於自己是真正的總結和積累，能變成經驗，於他人也是一種有價值的參考的。

2. 進行全面的總結

前面說了不要重複文件，那應該寫什麼呢？愚認為，應該是自己經過實踐之後的總結：

• 把所有可靠的方法都說一下;

• 把注意事項說一下;

• 把各種方法進行比較，給出各自的優缺點和適用場合;

• 文件中沒有說明的情況，比如對文件的補充，或者文件有自相矛盾的地方。

3. 必須親自實踐進行驗證，確保可靠可行。並附上例項（原始碼，資源）和執行結果（截圖等）

4. 要總結與所談內容相關且有價值的網路資料

5. 要列出參考資料，比如官方文件，別人的部落格，原始碼等。這是對別人的尊重，也是對知識的一種尊重。

6. 可以參考，可以引用，但不要照搬，不思考式的抄襲。最重要的是要有自己的思考和理解。

如果是受他人的部落格或程式碼的啟發，最好把關鍵的句子段落引用出來，然後再寫自己的思考和討論。在文章中再給出原文或出處的連結，這樣以顯得尊重和專業。

7. 最好能有版本控制資訊和修訂記錄

對於程式碼我們都有版本控制系統來幫助維護修改記錄。但對於文件，也建議這樣做。對於部落格，可能沒有（或許我不知道）類似的工具，但可以手動來說明。比如在部落格的頭部或尾部加上修訂歷史記錄，或者在文章中把後來的修改用其他字型標明，或者用括號或腳註來說明。這樣自已日後看起來也很方便，也能看到自己的思考過程和成長過程。

8. Less But Better精深原則

講的越詳細越好，範圍越小越好，但要深入的講，正如那句話，十個百分之十不如一個百分之百。如果你不能深入的講，證明你還沒有到寫的時候，應試再去學習或者實踐，直到你能講的很清楚，講的很詳細，講的很深入的時候再來總結和寫部落格。爭取做到一篇文章一個點，這樣文章多了就成了網最後變成沒有漏洞的面。

9. 突出主題，分清主次，邏輯清楚，層次分明

這可能是對於寫作的通用要求，說起來容易，但是做起來就比較困難。其實也不難，主要表現在：

• 列表來羅列要講的東西
• 用標題先簡明概括，然後再詳細講解
• 標題與正文用不同的字型樣式標識
• 用字型和縮排來標識標題和正文

有沒有一種感覺，這好像是在講編碼規範，沒錯，很早就有人講過，寫文章跟寫程式碼是一樣的。所以，作為程式設計師的我們，可以考慮用寫程式碼的一切，包括習慣，規範來寫文章。

10. 寫完後多讀幾遍，進行校改

這就好比寫完程式碼後的除錯與測試。好程式碼是改出來的，好文章也是如此。能夠一蹴而就的人有，但很少。即使是像魯迅那樣的大作家寫文章都還需要修改，都沒有一次成型的，更何況我們呢？在寫完文章後也視情況對文章進行除錯和重構，直到自己讀起來感到滿意和舒服為止。試想，如果自己寫的文章自已都不想看，別人會看嗎？我們又不是在寫作業，不管好壞老師總會看，而且要仔細的看。要想寫出好文章，必須首先讓自己認為是好文章。

11. 用通俗易懂的平實的語言，對於專業術語要解釋

好的技術文章應該都非常容易看懂，即使你對所說的那門科學完全不知。去讀一讀《Code Complete》等之類的經典書籍的英文原版，你會發現，其實看原版書並不需要多麼NB的英語水平，可以不客氣的講上過大學的人應該都能看懂。其實這重點不在你懂不懂英語，而是要看作者能否用最易懂的語言來把事情表達清楚。這確實是一種能力，平常我們所謂的溝通能力，也基本上就在這，看你能否用最簡單的語言把事情表達清楚，讓另一方聽明白。

這裡有一些技巧：

• 多用比喻，用大家熟悉的東西來比喻，這是讓人最容易理解的一種方式。比如把軟體構建比作建房子;把軟體架構師比作樓房的設計師等。
• 多用圖示，用圖解。很多時候一張圖能抵上幾百字的文字敘述，但還不一定能說明白。給出一張圖就什麼都明明白白了。
• 圖文並茂是講解的最佳方式，合理的安排圖片，再加之文字描述會達到事半功倍的效果。

12. 用事實說話

有圖有真相，有程式碼有真相。說完了，講過了，最好附上真實事例，程式碼和截圖。否則別人可能會質疑，至少我在看到別人只“說”，沒“做”的時候會質疑的。