FileKit 是我今天看到的一個庫, 本來還以為是一個 iOS 的文件管理框架, 我想想無非就是 iOS bundle 內(nèi)的那幾種文件夾, 這種東西一查就知道了, 但是顯然的, 它其實是為了 swift 在 cocoa 和 linux 上使用而出現(xiàn)的, 當(dāng)然既然是工具類庫, 其實也就應(yīng)該沒有什么高深的知識了, 有的是作者對我們操作的各種封裝, 工具的好壞我感覺也就是 效率和功能, 所以如何能找到痛點, 并且以 簡潔 高效 優(yōu)雅 的方式寫出來, 這就是考驗我們功力的地方了. 正好, 今天我就來說一下如何寫出一個好的工具.
工具需要/能夠幫助我們做什么
工具能夠幫助我們的就是把復(fù)雜的事情變得簡單, 把啰嗦的事情變得簡潔.
舉文件管理的一個簡單例子, 我們要實現(xiàn)某個對象和文件的讀寫的時候,往往要先把對象轉(zhuǎn)化為一個 data, 然后再進行文件存儲, 那么其實這個過程在我看來就是啰嗦的.
說到這里, 就該說到我所認為的工具應(yīng)該有的樣子是什么呢:
就是輸入?yún)?shù) 得到結(jié)果
工具隱藏了所有的中間狀態(tài), 因為那些并不是我所關(guān)心的, 一個對象是否需要變成 data 我不關(guān)心, 保存是否成功才是我所關(guān)心的. 而且我希望的能夠重復(fù)的在不同地方都可以使用這個工具
那么我們說到這里其實已經(jīng)說出了工具核心 -- 封裝和復(fù)用, 這里的封裝就不用多說了,就是把代碼扔到函數(shù)中, 而復(fù)用我要用我自己的理解說明一下, 我所理解的復(fù)用是工具的方法的調(diào)用不應(yīng)該相互影響, 這個就有點函數(shù)式編程的味道了, 無狀態(tài). 當(dāng)然, 這個核函數(shù)式編程還是千差萬別的.
雖然我上面說工具不應(yīng)該相互影響, 但是這個也是相對的, 在為了效率的前提下, 我們往往要對工具做一些配置, 或者對線程進行一些調(diào)度, 或者把同時運行的相同的工作合并起來, 這些都是我們要考慮的.
那么如何寫好一個工具呢
如果一定要強行給好的工具加一些特性的話, 我覺得我們應(yīng)該從這幾個方面進行思考和優(yōu)化
- 從需求分析
上面其實已經(jīng)簡單的說了一下, 工具就是把我們的操作封裝起來, 那么我們到底到把那些操作封裝呢, 這是一個問題, 我的理解就是- 第一種情況是把那些使用頻次很高的操作組合進行封裝
- 第二種情況就是把邏輯或者操作復(fù)雜的操作進行封裝
- 如果一定要把什么東西都湊成 3 的話, 那么第三種情況我認為就是把枯燥的/或者不適于人類做的事情使用工具, 比如說大段文的本修改或者對某些事物進行監(jiān)聽
- 從使用者的角度出發(fā)
工具好不好用, 不僅要看他能不能滿足我的需求, 其次當(dāng)然也要看用起來爽不爽- 對開發(fā)者友好是個很重要的前提, 如果你這個工具很好很吊,但是完全沒有文檔,難道你希望使用者自己去看源代碼嗎,顯然是不可能的,所以好的借口設(shè)計和文檔是好的工具必備屬性
- 使用者都是貪心的, 他們往往希望一個工具能夠滿足他們所有的愿望, 所有的使用場景, 所有的需求, 所有嘍, 滿足他們, 盡可能的滿足他們, 給他們自定義的權(quán)限, 盡可能的考慮所有的使用場景
- 不要把使用者想的太聰明, 所以不要對使用者傳進來的東西深信不疑, 去驗證這些東西, 當(dāng)他們出現(xiàn)錯誤的時候也不要給使用者留下任何后患, 比如說發(fā)生錯誤的時候要清理所有的臨時文件等等
- 最后要說點什么,恩,這個就是我最后的感觸了了,就是作為一個工具要解決問題,要先集中一個方向去做,不要在很早的時候就試圖去解決一些很大的問題,但是最后其實每一個小問題都不能很好的解決.
