SDK，全稱：Software Development Kit，作爲一種軟件產品爲程序員所熟知。
SDK由程序員開發，提供給程序員，有着非常獨特的開發和設計特點。如果說語言是程序員與設備的交流，那麼SDK完成程序員與程序員之間的交流。
開發SDK的程序員，往往需要作爲程序員設身處地的思考，應該提供一個怎樣的產品。
一份可用的文檔：
爲什麼要有文檔？
程序員大部分情況下並不喜歡寫文檔，而同時大部分情況下也不依賴文檔。當然還是存在少數情況的，少數情況不是程序員喜歡寫文檔，而是依賴文檔。如大部分程序員都有過在linux上man一個接口或help一個命令的體驗。因此必要的文檔還是必須的，提供文檔也是一種專業的做法。
有鑑於此，如果有文檔，很多情況下，可能本來需要技術支持的事情不需要了。因此，花一點時間，可以省去很多麻煩。天知道，程序員是有多麼的害怕被打擾。
那麼應該如何維護文檔呢？
精簡。維護文檔的工作量和文檔的大小是成正比的。SDK開發人員應該儘量減少文檔的內容。其實這裏的減少，不是裁剪，而是精簡。減少重複，避免冗餘，只提供必要的內容。想象一下SDK使用人員拿到你的SDK產品會希望從文檔獲取那些內容呢。
自動化。SDK開發人員需要考慮文檔的自動化生成，文檔應該主要來源於代碼註釋(也許有一部分開發人員不喜歡寫註釋，但是必要的註釋尤其對外公開的接口註釋還是必須的，而這必要的註釋也是文檔生成來源。除此以外，文檔的生成應該是伴隨版本的構建流程的，即每個版本發佈都自動更新文檔。
積極的閱讀自己的文檔。SDK開發人員是SDK的第一個使用者，也是文檔的第一個讀者。如果文檔不能正確的傳達所傳達的信息，那麼還不如沒有。
一份可用的示例代碼：
文檔是必須的，大部分時間是無用的。開發文檔大部分時候就像牛津大字典一樣，大部分人不會先去背誦牛津大字典，然後再去讀文章，讀文章發現單詞去查就好了。與之相反的是，一份可用的示例代碼尤爲重要。
-
即時可用。SDK的使用人員拿到SDK，首先會運行示例代碼（可能還沒有讀，示例代碼閱讀通常是伴隨着運行發生的）。如果拿到的示例代碼不能快速的進行編譯運行，或者編譯存在問題，運行失敗，(o)/，SDK的開發人員需要做好被頻繁打擾的準備了。指導另一個程序員一步一步調通程序是令人惱火的，何況是一個接一個的呢。so，。。。
-
正確且可拷貝。程序員從網上拷貝代碼已經不是什麼稀罕的事情了，甚至無可厚非。示例代碼可用，然後control＋c、control＋v！我親身經歷過一個示例代碼的一處錯誤，客戶拷貝後帶到發佈的最終產品上，最後經過多方分析定位，找到是示例代碼的原因。當時客戶的程序員理直氣壯的說，“可是，你們的示例是這樣寫的啊”。
-
符合優秀編程規範的。示例代碼也是代碼，可能有些程序員看不起示例代碼。寫出一份高質量的示例代碼也是需要很高水準的。規範的命名，模塊化，小函數，異常檢測，。。。好的示例代碼能夠讓SDK使用者快速清楚代碼的意圖，同時也對SDK的開發人員能力產生信心。英雄惜英雄嘛。相反，拿到一份不堪入目的示例代碼，天知道使用人員還有沒有勇氣使用SDK呢。
-
彌補文檔的缺陷。有時候文檔是註釋生成的，經常是乾巴巴的接口描述。而優秀的示例代碼會在進行接口調用的過程中通過清晰的代碼結構和必要的說明來讓其他程序員看清楚調用過程。並且對一些代碼注意事項進行必要說明。
一份可用的接口：
好吧，SDK程序員終於可以做點程序員該做的事情了。其實SDK產品和其他軟件產品的代碼一樣，需要一個好的設計和實現，關於如何寫好代碼的書籍一批一批的。簡單說幾點吧：
-
簡，少。儘可能少。接口數量越少越好，接口參數越少越好，調用流程越少越好。一是後續維護更加方便，少，需要維護的就少，文檔改變就少，示例代碼調整就少。二是開發者用着方便，精簡的SDK讓大家出bug的機會都少了好多。因此仔細看看頭文件，是都需要的嗎，這個接口應該可以刪掉吧。
-
統一的、自說明的接口。有時候真的可以沒有註釋和文檔，好的程序是自說明的。我們不排除一些程序員連示例代碼也沒有看，就看着接口名稱就開始寫代碼了。如果SDK提供了多個接口，那麼做好給出統一而專業的接口名稱吧。
-
向後兼容。SDK產品往往是迭代的，向後兼容非常重要。使用SDK產品的人如果要升級，他希望一行代碼也不要改，可以做到嗎？
-
定位與維護手段。錯誤碼與日誌，一方面客戶調試過程方便協助，另一方面如果SDK存在未知問題也方便自己定位。
以己度人，SDK的開發人員，也許沒有面對可惡的產品經理，變態的用戶，但是在一個柳暗花明的地方遇見的是自己。
版權聲明：本文爲CSDN博主「且走且停」的原創文章
原文鏈接：https://blog.csdn.net/swjbjxr/article/details/50987496