真正的高手，做事絕不會平均用力，而是把大部分精力投入在價值更大的事情上，從而提高自身效能。
這篇文章來講，做獨立開發(fā)，在新功能的開發(fā)上、個人工作量的排布上，該做什么，該不做什么。
事倍功半
做獨立開發(fā)的，大部分都有在公司全職任職開發(fā)的經(jīng)歷，做過很多產(chǎn)品經(jīng)理要求的、細(xì)枝末節(jié)的功能。很多東西可能 1000 個用戶里面只有 1 個人用，但由于產(chǎn)品經(jīng)理認(rèn)為這個東西有價值，那作為工程師，也不得不去把它完成。
而這樣的東西，在我們獨立開發(fā)的過程中，往往事倍功半。所以我并沒有說“不該做”，我的措辭是“該不做”。獨立開發(fā)往往一個人要干十個人的活，如果事事都按公司里面那套流程來，必然效率低下。
既然獨立開發(fā)要干的活是全面的、時間是寶貴的，那么做東西必然要考慮投資回報率。如果一個需求，既不能在功能上對你的產(chǎn)品有明顯改變、也不能在體驗上有明顯優(yōu)化，那么投資回報率就是很低的，就不值得去做。
反之，有些事情在公司里找人專人負(fù)責(zé)的，我們或許只需要幾行代碼就能做到 80% 的效果，這種東西就必須去做。
該做 - 刷評分
無論是蘋果的 App Store 還是各類安卓應(yīng)用商店， 應(yīng)用都有辦法跳轉(zhuǎn)到商店來讓用戶給應(yīng)用評分。iOS 10.3 之后還有這樣一個方法，來讓用戶留在 App 內(nèi)就可以方便地給 App 進(jìn)行評分。
class func requestReview()
然而很多人對于評分這件事，都是最多在設(shè)置頁里面加一個按鈕之類的入口，讓用戶主動去給應(yīng)用評分。
這是不行的，這是低效的，讓用戶來主動做一件對他沒什么好處的事情，我們要積極主動，而不能冷淡處理。更不能嫌麻煩，覺得這和產(chǎn)品本身無關(guān)，就不去做。
而實際上，拿 iOS App 舉例，只需要上面那一行代碼，就可以引導(dǎo)用戶評分。你只需要選擇一個恰當(dāng)?shù)膶嶋H就可以了，比如用戶剛剛成功地保存了一張圖片到相冊。有人說這種評分機(jī)制被蘋果限制了，一個用戶對一個 App 一年只能用三次，于是不敢亂用。然而你看看自己的用戶留存率就知道，絕大部分用戶下載了 App 之后可能就把它刪掉了，或者是再也沒有打開。這三次機(jī)會，多數(shù)情況下，你一次都用不掉。所以一定要積極讓用戶去評分。
很多應(yīng)用在這方面沒做好，應(yīng)用下載量很大，但是應(yīng)用商店 5 分的滿分評分，用戶評分只有 4 分不到，評分?jǐn)?shù)量也非常少。這一點可能只需要花掉你不到 10 分鐘的時間就可以改變，然而它對用戶看見你的應(yīng)用的印象分提升卻可能是比較大的。
大公司雇專人來做的刷評分這件事，你沒理由不做。有關(guān)去淘寶花錢給自己刷評論、提升關(guān)鍵字搜索權(quán)重的 …… 涉及灰產(chǎn)，有興趣可以自行搜索。
該做 - 常更新
個人開發(fā)沒必要和公司里面的 App 排期更新一樣，比如固定一個月更新一次。
當(dāng)看到用戶有反饋（問題或新功能需求），自己確定可以馬上實現(xiàn)的話，沒必要等到很多東西攢到一起再打包更新。
一直迅速迭代、小步快跑。不僅可以讓新用戶覺得你的產(chǎn)品一直在更新，可以獲取用戶信任。當(dāng)用戶發(fā)現(xiàn)自己的反饋，及時地出現(xiàn)在新產(chǎn)品中時，用戶也會有一種參與感，從而幫助你的產(chǎn)品形成口碑效應(yīng)。（小米的 MIUI 論壇就是這樣做的）
當(dāng)然，如果對倉促加入的內(nèi)容的穩(wěn)定性不放心，也要使用灰度來發(fā)布新版本，并且時常關(guān)注后臺統(tǒng)計的 App 崩潰等問題。
該不做 - 永遠(yuǎn)自己寫后臺
之前寫過一篇 《入門：獨立開發(fā)者如何解決后臺問題》 也提到過。
我的建議是，有適當(dāng)?shù)男枨蠛湍芰Φ脑挘毩㈤_發(fā)者是可以自己寫后臺的。重點在于，不要認(rèn)為獨立開發(fā)者永遠(yuǎn)應(yīng)該自己寫后臺。
很多時候，如果你不是對自己的后臺維護(hù)特別放心，使用第三方服務(wù)是可以提高后臺的穩(wěn)定性的。并且，獨立開發(fā)很難 24 小時做運維，使用第三方服務(wù)，是把運維工作外包出去的一個好方法。
該不做 - 過度兼容機(jī)型與系統(tǒng)
對于各種多年以前的老版本系統(tǒng)，以及很多年前發(fā)布的舊機(jī)型，一般大公司都是選擇盡量兼容的。因為哪怕是多照顧 1% 的用戶，都可能是上百萬的收入，遠(yuǎn)大于做決策的人的工資。
而對獨立開發(fā)者來說，放棄 1% 的用戶一般不僅不會對收入帶來太大負(fù)面影響，并且這 1% 的舊機(jī)型用戶，很多年齡偏大，或者是有人把手機(jī)當(dāng)做備用機(jī)來用的，這部分的用戶的付費意愿是很低的，這 1% 的用戶量，體現(xiàn)在收入上，可能連 0.1% 都不到。
這樣一來，為了兼容舊版本系統(tǒng)和過舊機(jī)型所付出的工作量、以及解決出現(xiàn)率很低的 bug 所耗費的時間，就都可以節(jié)省下來了。用這些時間、精力，去做開發(fā)新功能、收集用戶反饋等工作，可能是投資回報率更高的事情。
該做- 盡可能多地存檔資源文件
對于平時會用到的設(shè)計稿、圖片資源、應(yīng)用商店需要用到的各個語言版本的 App 描述、不同尺寸的應(yīng)用截圖等一系列與代碼無關(guān)的內(nèi)容，都可能在你日后做重構(gòu)、改版的時候用到。
平時多花點時間，把這些內(nèi)容都索引起來，直接放到 Git 來托管，是非常值得做的一件事情。一點小習(xí)慣，可以為日后找不到文件節(jié)省大量的時間。
以及，對于 Git 里面的哪一次提交，對應(yīng)于 App Store 的哪個版本，也要有記錄。這樣在用戶反饋的時候，可以一眼看到用戶使用的版本，是不是沒有進(jìn)行過某次更新的舊代碼。
該不做 - 過于詳細(xì)地產(chǎn)出設(shè)計文檔與代碼文檔
與公司里面，文檔產(chǎn)出盡量要讓別人看懂不同。獨立開發(fā)過程中，由于從設(shè)計原型到代碼落地，這一過程很多時候是自己在完成。如果整理了很多中間步驟的設(shè)計文檔、開發(fā)文檔，其實是對時間的浪費。
唯一的標(biāo)準(zhǔn)，其實應(yīng)該是自己可以把控的 —— 未來自己能看懂即可。
我個人的習(xí)慣是，無論是設(shè)計的 Sketch 文件、還是工程的 Xcode 文件，都盡量有完整的注釋、明確的文件命名，盡量不出現(xiàn) image1、image2、rect1、rect2 這種沒有實際意義的命名，但是盡量少地單獨產(chǎn)出文檔。
