真正的高手先壕，做事絕不會平均用力，而是把大部分精力投入在價值更大的事情上谆甜，從而提高自身效能垃僚。
這篇文章來講，做獨立開發(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 進行評分。
class func requestReview()
然而很多人對于評分這件事湃鹊，都是最多在設(shè)置頁里面加一個按鈕之類的入口儒喊，讓用戶主動去給應(yīng)用評分。
這是不行的币呵，這是低效的怀愧，讓用戶來主動做一件對他沒什么好處的事情，我們要積極主動余赢，而不能冷淡處理芯义。更不能嫌麻煩，覺得這和產(chǎn)品本身無關(guān)妻柒，就不去做扛拨。
而實際上，拿 iOS App 舉例蛤奢，只需要上面那一行代碼鬼癣，就可以引導(dǎo)用戶評分。你只需要選擇一個恰當(dāng)?shù)膶嶋H就可以了啤贩，比如用戶剛剛成功地保存了一張圖片到相冊待秃。有人說這種評分機制被蘋果限制了，一個用戶對一個 App 一年只能用三次痹屹，于是不敢亂用章郁。然而你看看自己的用戶留存率就知道，絕大部分用戶下載了 App 之后可能就把它刪掉了，或者是再也沒有打開暖庄。這三次機會聊替，多數(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)該自己寫后臺唠粥。
很多時候疏魏，如果你不是對自己的后臺維護特別放心，使用第三方服務(wù)是可以提高后臺的穩(wěn)定性的晤愧。并且大莫，獨立開發(fā)很難 24 小時做運維，使用第三方服務(wù)官份，是把運維工作外包出去的一個好方法葵硕。
該不做 - 過度兼容機型與系統(tǒng)
對于各種多年以前的老版本系統(tǒng)，以及很多年前發(fā)布的舊機型贯吓，一般大公司都是選擇盡量兼容的懈凹。因為哪怕是多照顧 1% 的用戶，都可能是上百萬的收入悄谐，遠(yuǎn)大于做決策的人的工資介评。
而對獨立開發(fā)者來說，放棄 1% 的用戶一般不僅不會對收入帶來太大負(fù)面影響爬舰，并且這 1% 的舊機型用戶们陆，很多年齡偏大，或者是有人把手機當(dāng)做備用機來用的情屹，這部分的用戶的付費意愿是很低的坪仇，這 1% 的用戶量，體現(xiàn)在收入上垃你，可能連 0.1% 都不到椅文。
這樣一來，為了兼容舊版本系統(tǒng)和過舊機型所付出的工作量惜颇、以及解決出現(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 的哪個版本乾颁，也要有記錄涂乌。這樣在用戶反饋的時候，可以一眼看到用戶使用的版本英岭，是不是沒有進行過某次更新的舊代碼湾盒。
該不做 - 過于詳細(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)出文檔茅茂。
