轉：從零開始作app須要作的事情列表

時間 2019-11-14

標籤開始 app 須要事情列表简体版

原文原文鏈接

https://qdan.me/list/VaXl7N8emfv1ayWgapi

從零開始作App的Bootstrap

作一個App，須要不少東西。服務器

不按期更新。微信

團隊

工欲善其事，必先利其器。app
需求管理

支持版本、迭代、需求的建立與管理。工具

產品經理在上面錄入需求，開發參照開發，測試參照寫測試用例，並進行狀態流轉。測試

國內大廠如騰訊都有內部本身開發的管理平臺如tapd。優化

小團隊可使用輕量級的平臺如：網站

國外：Trello、Basecamp、Jira、Asana搜索引擎

國內：Tower、Teambition、FengChe阿里雲

也可使用較傳統的重型工具如禪道（真的很醜，可是流程和大公司內的比較像）
缺陷管理

測試在上面錄入從各個渠道收集到的bug，分配給開發，並進行狀態的流轉。

在諸如tapd、禪道這樣的傳統平臺上，都包含缺陷管理模塊。反而在上文中的輕量級的項目管理平臺裏，缺陷管理並非很是容易作，簡單的還好，複雜的歸類、人員間的流轉就不容易了。

傳統的解決方案如Bugzilla等太老舊不利於使用，目前沒看到特別好的方案。
代碼託管

一流小團隊用Git，買GitHub或者自建GitLab或者用第三方的代碼託管甚至雲開發平臺，如Coding之類。

不入流的大多用SVN。
雲服務＋CDN

選定雲服務商和CDN服務商，再也不本身買機器租機房。

國外主流用Amazon家，國內主流用阿里雲，騰訊百度也有云可是穩定性不說了。新浪的雲是打醬油的。也有青雲之類作的不錯。

CDN選擇就更多了，雲CDN是主流，國外如Akamai 、CloudFlare，國內阿里雲的CDN最普遍。
持續集成與分發

大多數團隊在初期都會忽視持續集成，而後它很重要。

每次有代碼提交到主幹或每日特定時間，都應自動以最新代碼編譯一次出一個app版本，並上傳到分發渠道上，如 TestFlight。這樣產品、測試和其餘外圍人員隨時能夠安裝並檢查最新版本。

傳統的持續集成有Jenkins/Hudson，本身部署本身設定，iOS的話還有Xcode Server的bot。但云持續集成也在逐漸流行起來，Travis CI就是其中的典型。

內部分發渠道上，TestFlight在Apple買了以後就不是那麼好用。國外還有HockeyApp，國內Fir.im、蒲公英則是使用的比較多的分發渠道。

而將持續集成和分發渠道聯繫在一塊兒，除了本身寫腳本外，也有第三方工具如http://nomad-cli.com 和 https://fastlane.tools
設計資源交付與共享

設計師與開發之間須要一個平臺來共享設計稿、切圖、標註等資源。

有些團隊是給設計師代碼權限，讓設計師直接把切圖提交到代碼裏，也有些團隊是用Dropbox等雲盤來和開發分享切圖。

另外一方面，還有Sketch＋Zeplin這樣的工具來分享設計稿、自動批量切圖並支持自動查看標註，把設計師從標註中解放出來。結合上面提到的雲盤，能夠實現自動切圖＋標註＋同步到開發一鼓作氣。
內部溝通工具

內部溝通工具和傳統IM不一樣，講究的是：

1. 自帶組織構架、人員查找

2. 方便發起羣組討論

3. 多人文件共享場景更多

4. 和郵件、持續集成等其餘系統的互通互動更重要

5. 手機和桌面版本一樣重要

不入流團隊愛用的QQ微信就不說了。

之前騰訊的RTX用的比較多，但明顯缺點是RTX的Mac版問題不少，Windows版也很老舊（不是騰訊內用的新版），手機版也不好。

後起之秀如Slack、瀑布IM、BearyChat等值得嘗試，特色是支持大量第三方服務。

阿里也有作釘釘，但針對的是傳統企業，功能臃腫不實用。
郵件系統

在保守乃至正常的工做流程中，郵件都是有效的事務推進和留痕工具。須要具有：

1. 和組織構架打通

2. 清晰的郵件組劃分

3. 和日曆、會議邀請掛鉤

4. 與溝通工具的互通。

目前只看到微軟的Exchange能夠知足此類需求。
開發、測試、線上環境及快速上線流程

設定三個不一樣的環境，確保數據同步。而且支持每一個小的代碼變更能夠自助式的在三個環境逐個部署並驗證，最終能夠在短期內快速上線。避免傳統式的開發一大坨、部署一禮拜的狀況。
OA系統

外圍事務，如請假、調休、事務投票、我的信息補全等。與核心業務無關，可是能避免瑣事影響效率。
App

一個App須要有的基本模塊
帳號體系+第三方登陸

email/手機號短信驗證是主流的註冊帳號體系，有需求可再加微博、微信、QQ的第三方登陸。涉及到在三者的開放平臺註冊並經過審覈拿到api key。

第三方登陸有第三方的SDK能夠支持，但其中還不乏一些不靠譜的平臺。

登陸時
版本更新提示與強制更新

在早期版本就須要預埋好的功能。儘管 Apple 不容許 App 內出現檢查更新字樣，但仍然能夠在有更新的時候彈出更新提示。而且爲以防版本出現重大bug，須要支持對老版本能夠封停的能力，也就是強制更新，不更新不給用。
Push服務

一個強健的Push服務後臺，支持高效率的大量Push發送，以及對每條Push打開率的統計。大多數團隊本身開發的後臺都作不到，包括髮送效率和打開率統計。額外從運營層面還會須要支持預設定時發送Push等功能。

所以大多數狀況下，建議使用第三方的方案。國內作的主要有百度雲推送、極光、雲巴、個推、騰訊信鴿、友盟，據傳百度雲推送團隊已經沒了，極光的後臺感受粗糙，個推貌似新浪微博也沒再用了送達率低，雲巴不知道，此外知乎用的是LeanCloud的推送。
短信下行服務

手機號註冊等功能涉及驗證碼短信下行，須要有一個低延遲、高送達率、不受運營商白名單影響的短信服務商接入。

國內的短信服務商多如牛毛，收費也從1毛到5分不等，但基本上處於便宜沒好貨的狀態。除了送達率的問題，還有對於17*的新號段常有支持很差，以及運營商有白名單，名單中的用戶容易送達不到。

最簡單的方式是直接和移動等運營商談，價格不貴且專線保證送達率。其餘服務商的免費體驗帳號都存在上述問題，客服通常反饋都說付費了就行了。
郵件發送服務

重郵件的業務，必定須要一個強大的郵件代發業務，由於：

1. edm郵件須要統計到達率和打開率等，須要支持針對特定用戶發送，傳統的郵件服務器並無這些功能。

2. 大多數郵件代發服務提供足夠多的樣式，能夠快速編輯產出

3. 國內許多郵件商對發送IP等都有過濾限制，郵件代發服務則提供白名單的途徑能夠避免被過濾。

經常使用的郵件代發服務有：Mailchimp、Mailgun、Sendgrid、SendCloud。其中SendCloud是國內作的比較不錯的。
數據上報與統計

支持App內的各種規模類、點擊類數據上報，而且有支持各類複雜分析的後臺，最好能與用戶帳號掛鉤。

這方面國內算友盟作的最有名，其餘還有TalkingData、百度統計等，但作的都通常，國外的Flurry、Localytics更爲成熟，Google Analytics for Mobile也很強大。

通常建議一個App接入至少兩個數據上報平臺，在也就是在App內封裝一層。
內測問題反饋

用於在內測（甚至正式版本）用戶發現問題時，能夠簡單快速的將當前問題反饋到開發團隊。須要支持截圖和註釋。

目前已知有Instabug支持此項功能，可是Instabug的管理功能不好，幸虧他家支持自動與其餘缺陷管理平臺集成。

建議配置成盡在內測版時啓用該項功能。
用戶互動

在App中放置入口，容許用戶向開發團隊反饋問題或提意見，而且能夠收到開發團隊的回覆。通常以聊天或私信的形式。

國外主要有UserVoice、ZenDesk等，國內LeanCloud中包含該服務，還有逸創雲客服算是對ZenDesk複製的比較好的，比其餘的更多的是有幫助中心頁面可用；此外還有Udesk和美洽。

其餘App如知乎等則選擇將該功能和本身的私信功能和在一塊兒。
Crash上報&質量監控

收集每一個版本上線的同類Crash的log和堆棧。後臺應支持快速轉入缺陷管理。

此類服務國外Crashlytics較有名，國內則有騰訊的Bugly作的不錯。同時也能夠選擇本身架設相關上報Server，也有足夠多的開源方案。
官方網站+博客

若有網頁版，那麼網站會有額外的工做。

1. 搜索引擎優化，這裏涉及到的除了傳統內容，還有和iOS 9相結合的地方

2. 登陸時的機器識別，避免被批量註冊號碼。這裏的服務有好比geetest等。
App分享

容許用戶從App內簡單分享當前App到微信、微博等。因爲微信的存在，須要開發一個承接頁用來判斷是否在微信中打開，是則跳轉至應用寶的產品頁。
內容分享

容許分享應用內內容到微信、微博、QQ等。大多數團隊選擇用第三方的SDK來實現一次性支持多家分享。但目前大多數第三方SDK的使用交互和樣式都很是很是爛。

考慮到分享出去的網頁存在不斷被轉發的狀況，因此須要支持Open Graph protocol讓微信等app能夠正確的讀出預覽圖片、描述而不是顯示一個默認的連接。

http://ogp.me