# 前言
---
可以讓自己的知識share出來提供給別人參考是一件不錯的事，因此我寫IT文章的習慣，會先想好以下三個要點:
- 為什麼我要寫這篇文章
- 這篇文章能解決什麼問題
- 讀者可能有其他的疑問
## 為什麼我要寫這篇文章
通常我們對於自己腦袋中的知識深信不疑，很容易陷入一種迷思，覺得自己知識是完全正確但實際上是漏洞百出的，殊不知等到請你解說你的知識時，才發現描述的不夠實在、正確。舉例如下:
Q: 解釋 process 與 thread 的不同?
A: process所需要建立的資源成本較高，但是它對於資料獨立性保護較佳；而thread所需要的建立成本較低但是資料獨立性保護較差。
以上的舉例就很容易透露出我對process與thread差異根本不是很熟，因為我不能進一步描述這兩者間的差異性。假如今天面試官進一步詢問建立process與thread注意事項，我百分之百無法應對。
因此為自己撰寫一篇知識文章，既可以確保自己知識是有系統化的，也比較不怕被別人挑戰。而文章是自己寫的，就像老師自己編教材一樣，才能胸有成竹地去教學生。
## 這篇文章能解決什麼問題
既然花了時間寫文章，就要提出優點來，才能說服別人看到文章標題時，讓他產生一種想法: 這篇文章也許可以解決我目前的問題...
因此在撰寫文章前，要在文章開頭特別註明你的文章是解決什麼樣的問題? 例如我今天要寫一篇對於:process與thread差異。
那我就會特別說，這篇文章可以提供process與thread差異之外，還可以:
- 在撰寫程式的時候可以考量到底是要用process還是thread
- 可以回答面試官的問題XD (通常面試官常問此類型問題)
- 可以了解process與thread創建過程
適時提出優點可增加閱讀文章的動力，畢竟要顯現優點才有被閱讀的價值。
## 讀者可能有其他的疑問
很多人在寫文章時，通常會犯了一個錯誤，例如今天撰寫一篇文章叫做:
How to create & use Dynamic Shared Objects
在某個小節，其中介紹編譯dynamic shared object 指令如下:
gcc -shared -o lib_addition.so lib_addition.c
在寫這個指令的時候，重點要告訴讀者這樣做就會產生lib_addition.so就可以了，
請不要一個個詳細解釋-shared 與 -o 還是其他指令的意義，因為我們今天文章的標題叫做:
How to create & use Dynamic Shared Objects
而不是
Explanation of gcc command parameters
因此我習慣把指令參數的意義放在Q&A就可以了，這樣才不會讓文章失焦。
---
# Conclusion
說到底我本來就不太相信大腦記憶，因此要有系統地去整理自己的知識，並寫出來公布在網路上，因為網友們也許會發現文章不足的地方而提供建議。另外也可以給自己一個壓力:
貼出來的東西是不能誤人子弟的
才能確保自己的知識是完整且無懈可擊。
GJ 2018/05/01 in Taipei
