事情還得在兩天前說起，部門經理拉我去單獨聊天，跟我說公司現在需要做乙個平台型的sdk。因為公司接的遊戲都是租用著別人的sdk，要給租金不說，處理突發事情也不夠及時。所以，希望我來開發乙個屬於公司自己的sdk。當時，我一聽，這挺好啊，那就做吧。就問要需求文件，經理居然回我，需求的話就是按照我們現在租用的sdk來開發就可以了。當時我就懵逼了，沒有需求文件怎麼去開發。就因為這個問題，我們討論了快半個小時，經理很堅定說，其實我就是需要和這個sdk一樣功能的就可以了。你就去用一下這個sdk就知道了，為什麼要我寫文件。其實，對於我們開發來說，比起看得到的功能來說，我認為sdk裡面的業務邏輯才是最重要的。我們能看見的功能，就只能模仿到表面，卻了解不了真正的精髓。沒辦法啊，既然經理給不了具體的需求，那只能靠自己了。
既然靠自己，就得看看自己手上現在有什麼資源，自己的目標是什麼，下一步要做什麼。有什麼資源呢，有乙個sdk的jar和乙個sdk的lib。目標就是按照這個sdk去開發自己的sdk，現在我知道這個sdk的表面功能，下一步我要了解sdk裡面的業務邏輯。左思右想，要怎麼了解業務邏輯呢？叫開發商給原始碼是不可能，這輩子不可能給原始碼的。但是可以個接入文件，我這裡可能了解個大概的流程啊！於是，我拿到了sdk的接入文件，與接入的demo。經過認真的跑demo，看文件後。我為自己畫了個流程圖
在這個流程圖能看得見也就是 登入，註冊，支付，登出。其他的都是sdk內部業務邏輯上的介面。所以我從不相信sdk能靠幾個功能這麼簡單就可以撐起來乙個sdk平台，能撐起來的是背後強大的業務邏輯。
畫了流程，知道了乙個sdk的大概框架。我的下一步就要看他們的原始碼，讓他們給原始碼是不可能，還是得靠自己。看原始碼才是看出乙個應用真身，才知道乙個應用能穩定執行的真正原因是什麼。看原始碼，那就用反編譯吧，把sdk反編譯，只能祈禱sdk沒有做過混淆的操作。經過一系列猛如虎的操作，成功把sdk反編譯了，謝天謝地，可以看原始碼。這就很滿足了！真開心去看原始碼的時候，才發現乙個看起來簡單的sdk，原始碼居然這麼多！而且讓人不知從**看起，更不知道每個檔案，每個方法的作用是什麼！
到這裡我才知道，我痛苦的開發sdk歷程才剛剛開始。我告訴自己不能慫，直面原始碼，別人看書我看原始碼。想開發出乙個穩定的sdk，就要學習前人的經驗。
如何寫乙個好的需求文件
1 從使用者角度的編寫 2 使用screen shots 3 用簡單的語言編寫 a 保持簡短的語句，把長的語句分解成多個小的語句。b 避免大篇幅的連續文字，把他們分解成多個小的章節。c 把大塊文字內容分解成，screen shots，重點列表等等。4 小心的使用模板 我發現mrd模板非常有用。他們的...
如何寫乙個好的需求文件
1 從使用者角度的編寫 2 使用screen shots 3 用簡單的語言編寫 a 保持簡短的語句，把長的語句分解成多個小的語句。b 避免大篇幅的連續文字，把他們分解成多個小的章節。c 把大塊文字內容分解成，screen shots，重點列表等等。4 小心的使用模板 我發現mrd模板非常有用。他們的...
如何編寫乙個專案開發文件
專案開發過程中為了增加程式的可讀性和程式的健壯性，方便後期程式的除錯和維護，所以需要在開發過程中統一技術規範，一般會在專案初期確定好相關文件作為這一統一的規範。不同公司會對文件做不同要求，劃不同的分類，但一般來說 或者拿自己的經驗說 大致可以分為需求文件 介面文件 流程圖 可以單獨作為乙份檔案可以作...