獨立開發該作什麼，該不作什麼

真正的高手，作事毫不會平均用力，而是把大部分精力投入在價值更大的事情上，從而提升自身效能。

這篇文章來說，作獨立開發，在新功能的開發上、我的工做量的排布上，該作什麼，該不作什麼。

---

事倍功半

作獨立開發的，大部分都有在公司全職任職開發的經歷，作過不少產品經理要求的、細枝末節的功能。不少東西可能 1000 個用戶裏面只有 1 我的用，但因爲產品經理認爲這個東西有價值，那做爲工程師，也不得不去把它完成。

而這樣的東西，在咱們獨立開發的過程當中，每每事倍功半。因此我並無說「不應作」，個人措辭是「該不作」。獨立開發每每一我的要幹十我的的活，若是事事都按公司裏面那套流程來，必然效率低下。

既然獨立開發要乾的活是全面的、時間是寶貴的，那麼作東西必然**要考慮投資回報率。**若是一個需求，既不能在功能上對你的產品有明顯改變、也不能在體驗上有明顯優化，那麼投資回報率就是很低的，就不值得去作。

反之，有些事情在公司裏找人專人負責的，咱們或許只須要幾行代碼就能作到 80% 的效果，這種東西就必須去作。

該作 - 刷評分

不管是蘋果的 App Store 仍是各種安卓應用商店， 應用都有辦法跳轉到商店來讓用戶給應用評分。iOS 10.3 以後還有這樣一個方法，來讓用戶留在 App 內就能夠方便地給 App 進行評分。

class func requestReview()

然而不少人對於評分這件事，都是最多在設置頁裏面加一個按鈕之類的入口，讓用戶主動去給應用評分。

這是不行的，這是低效的，讓用戶來主動作一件對他沒什麼好處的事情，咱們要積極主動，而不能冷淡處理。更不能嫌麻煩，以爲這和產品自己無關，就不去作。

而實際上，拿 iOS App 舉例，只須要上面那一行代碼，就能夠引導用戶評分。你只須要選擇一個恰當的實際就能夠了，好比用戶剛剛成功地保存了一張圖片到相冊。 有人說這種評分機制被蘋果限制了，一個用戶對一個 App 一年只能用三次，因而不敢亂用。然而你看看本身的用戶留存率就知道，絕大部分用戶下載了 App 以後可能就把它刪掉了，或者是再也沒有打開。這三次機會，多數狀況下，你一次都用不掉。因此必定要積極讓用戶去評分。

不少應用在這方面沒作好，應用下載量很大，可是應用商店 5 分的滿分評分，用戶評分只有 4 分不到，評分數量也很是少。這一點可能只須要花掉你不到 10 分鐘的時間就能夠改變，然而它對用戶看見你的應用的印象分提高卻多是比較大的。

大公司僱專人來作的刷評分這件事，你沒理由不作。有關去淘寶花錢給本身刷評論、提高關鍵字搜索權重的 …… 涉及灰產，有興趣能夠自行搜索。

該作 - 常更新

我的開發不必和公司裏面的 App 排期更新同樣，好比固定一個月更新一次。

當看到用戶有反饋（問題或新功能需求），本身肯定能夠立刻實現的話，不必等到不少東西攢到一塊兒再打包更新。

一直迅速迭代、小步快跑。不只可讓新用戶以爲你的產品一直在更新，能夠獲取用戶信任。當用戶發現本身的反饋，及時地出如今新產品中時，用戶也會有一種參與感，從而幫助你的產品造成口碑效應。（小米的 MIUI 論壇就是這樣作的）

固然，若是對倉促加入的內容的穩定性不放心，也要使用灰度來發布新版本，而且時常關注後臺統計的 App 崩潰等問題。

該不作 - 永遠本身寫後臺

個人建議是，有適當的需求和能力的話，獨立開發者是能夠本身寫後臺的。重點在於，不要認爲獨立開發者永遠應該本身寫後臺。

不少時候，若是你不是對本身的後臺維護特別放心，使用第三方服務是能夠提升後臺的穩定性的。而且，獨立開發很難 24 小時作運維，使用第三方服務，是把運維工做外包出去的一個好方法。

該不作 - 過分兼容機型與系統

對於各類多年之前的老版本系統，以及不少年前發佈的舊機型，通常大公司都是選擇儘可能兼容的。由於哪怕是多照顧 1% 的用戶，均可能是上百萬的收入，遠大於作決策的人的工資。

而對獨立開發者來講，放棄 1% 的用戶通常不只不會對收入帶來太大負面影響，而且這 1% 的舊機型用戶，不少年齡偏大，或者是有人把手機當作備用機來用的，這部分的用戶的付費意願是很低的，這 1% 的用戶量，體如今收入上，可能連 0.1% 都不到。

這樣一來，爲了兼容舊版本系統和過舊機型所付出的工做量、以及解決出現率很低的 bug 所耗費的時間，就均可以節省下來了。用這些時間、精力，去作開發新功能、收集用戶反饋等工做，多是投資回報率更高的事情。

該作- 儘量多地存檔資源文件

對於平時會用到的設計稿、圖片資源、應用商店須要用到的各個語言版本的 App 描述、不一樣尺寸的應用截圖等一系列與代碼無關的內容，均可能在你往後作重構、改版的時候用到。

平時多花點時間，把這些內容都索引發來，直接放到 Git 來託管，是很是值得作的一件事情。一點小習慣，能夠爲往後找不到文件節省大量的時間。

以及，對於 Git 裏面的哪一次提交，對應於 App Store 的哪一個版本，也要有記錄。這樣在用戶反饋的時候，能夠一眼看到用戶使用的版本，是否是沒有進行過某次更新的舊代碼。

該不作 - 過於詳細地產出設計文檔與代碼文檔

與公司裏面，文檔產出儘可能要讓別人看懂不一樣。獨立開發過程當中，因爲從設計原型到代碼落地，這一過程不少時候是本身在完成。若是整理了不少中間步驟的設計文檔、開發文檔，實際上是對時間的浪費。

惟一的標準，其實應該是本身能夠把控的 —— 將來本身能看懂便可。

我我的的習慣是，不管是設計的 Sketch 文件、仍是工程的 Xcode 文件，都儘可能有完整的註釋、明確的文件命名，儘可能不出現 image一、image二、rect一、rect2 這種沒有實際意義的命名，可是儘可能少地單獨產出文檔。

---

關於做者

KyXu，多年獨立開發經驗，長期致力於幫助廣大移動端開發者 變現、擁有本身的產品、成爲獨立開發者，微信公衆號：KyXuIndie

關注專欄解鎖更多幹貨：xiaozhuanlan.com/kyxuDev

加我微信入專欄讀者羣：balabala-ba