真正的高手，做事絕不會平均用力，而是把大部分精力投入在價值更大的事情上，從而提高自身效能。
這篇文章來講，做獨立開發，在新功能的開發上、個人工作量的排布上，該做什么，該不做什么。
事倍功半
做獨立開發的，大部分都有在公司全職任職開發的經歷，做過很多產品經理要求的、細枝末節的功能。很多東西可能 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 文件，都盡量有完整的注釋、明確的文件命名，盡量不出現 image1、image2、rect1、rect2 這種沒有實際意義的命名，但是盡量少地單獨產出文檔。
