獨立開發該做什麼，該不做什麼
真正的高手，做事絕不會平均用力，而是把大部分精力投入在價值更大的事情上，從而提高自身效能。
這篇文章來講， 做獨立開發，在新功能的開發上、個人工作量的排布上，該做什麼，該不做什麼。
事倍功半
做獨立開發的，大部分都有在公司全職任職開發的經歷，做過很多產品經理要求的、細枝末節的功能。很多東西可能 1000 個使用者裡面只有 1 個人用，但由於產品經理認為這個東西有價值，那作為工程師，也不得不去把它完成。
而這樣的東西，在我們獨立開發的過程中，往往事倍功半。所以我並沒有說“不該做”，我的措辭是“該不做”。獨立開發往往一個人要幹十個人的活，如果事事都按公司裡面那套流程來，必然效率低下。
既然獨立開發要乾的活是全面的、時間是寶貴的，那麼做東西必然**要考慮投資回報率。**如果一個需求，既不能在功能上對你的產品有明顯改變、也不能在體驗上有明顯優化，那麼投資回報率就是很低的，就不值得去做。
反之，有些事情在公司裡找人專人負責的，我們或許只需要幾行程式碼就能做到 80% 的效果，這種東西就必須去做。
該做 - 刷評分
無論是蘋果的 App Store 還是各類安卓應用商店， 應用都有辦法跳轉到商店來讓使用者給應用評分。iOS 10.3 之後還有這樣一個方法，來讓使用者留在 App 內就可以方便地給 App 進行評分。
class func requestReview()
然而很多人對於評分這件事，都是最多在設定頁裡面加一個按鈕之類的入口，讓使用者主動去給應用評分。
這是不行的，這是低效的，讓使用者來主動做一件對他沒什麼好處的事情，我們要積極主動，而不能冷淡處理。 更不能嫌麻煩，覺得這和產品本身無關，就不去做。
很多應用在這方面沒做好，應用下載量很大，但是應用商店 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 這種沒有實際意義的命名，但是儘量少地單獨產出文件。