企業移動應用開發管理之淺談

爲什麼要寫這篇博客呢,事情的原因是這樣的。 大前天公司那邊下來需求,要求移動端應用主要的詳情頁面加上圖片的展示, 公司的後臺和前臺的業務比較複雜,改動的話涉及到三個端;代理商,商戶,用戶。 邏輯是這樣的,商戶創建,創建的時候添加圖片,然後代理商審覈,然後用戶端展示,用戶端展示又分兩個接口。因爲前期追求開發速度的原因,整個應用包括後臺都是比較臃腫的,負責改動的後臺人員也是剛來不久的新人,熟悉流程,制定方案在前天上午,然後下午兩三點左右,產品經理過來說希望能加班上掉,上面催的緊,週末加加班。因爲種種因素吧,催的很緊,然後後臺人員在寫的時候由於失誤,改了老接口的一個東西, 導致線上應用崩潰,顯示 異常等(週六晚上剛剛後臺正式上線。) 然後產品經理就打電話,讓我們趕緊到公司解決問題。原因是一個名稱的字符串沒有傳,導致安卓端空異常崩潰,IOS顯示異常。造成的影響還是比較嚴重的。從這件事,淺談一下企業移動應用開發和日常維護升級等注意的問題,因爲博主之前雖然做過後臺開發,但是時間不長,只能主要的從安卓這方面開始談,希望大家有補充的請多多留言,本篇博客會持續更新,避免更多的人遇到相似的問題。


日常篇:

1、儘量避免在週末的時候發版本和後臺升級,因爲週末本來是放假的時候,之前連着上了五天的班,肯定也是比較累的, 狀態可能不是太好。還有有些人可能不在,需要他範圍之內的問題有可能不會及時的解決;最主要的是突發的問題很有可能找不到當事人。 

2、上線前測試新版本的同時也不要忘記測試老版本。(又回到了 1 上面去,週末,人心都比較浮躁)。

技術篇:

1、後臺更新的時候沒有規劃和把握不要去動老接口,很可能會發生一些恐怖的事情。

2、後臺傳字符串輸局的時候解析的時候如果是null的話不同的解析工具解析出來的不同,有的是解析出來的是“”,有的直接是null,最好加個判斷。

3、類型轉換的時候最好在工具類中轉換,避免null異常。

4、產品設計的時候最好給個無數據的時候的或者爲空的時候默認的顯示。

5、使用熱修補,發生嚴重bug的時候能第一時間控制現場。

6、添加全局的異常捕獲,發生崩潰之後下個版本修補。



  最後再談一下app的事情:

衆所周知,現在的市場,得用戶者得天下。現在的企業大部分講究快速迭代(說白了就是這個版本點子不行下個版本再換),絲毫不關心app的質量和用戶的交互體驗,大部分產品經理對app的交互這塊知之甚少(這就體現出開發轉產品的優勢),對與app的各種動畫和交互效果不怎麼了解。大部分想的是感覺有用戶或者是哪個版本用戶買賬,然後再細化。然後,沒有想到, 假如你前期app半個月一個月一個大的版本,先不說別的,質量有保證麼?,質量不保證,沒有什麼好的頁面效果, 用戶會買賬麼,如此就導致了一種惡性循環,需求一直變,一直開發,然而用戶一直不買賬,如果一個產品,業務不是太搓,app的交互效果和展示形式能幫你吸引或者是留住一部分用戶,

而不是用戶下下來一看,app感覺好搓,肯定是不會用的,我從技術上的角度上認爲,保證業務通暢的同時,花一點時間在界面和用戶體驗上下下功夫,兩三個月出了一個大版本,會比兩三個月出了兩傘個大版本的效果更好。這點讓我想到了手機市場上,中國的各種手機開始的時候幾個月或者半年就一款旗艦機,過個幾天就沒聲了,然後被淘汰了,蘋果的一下發布導致了巨大的效應,瞬間擊敗所有的競爭對手,中國的產品普遍的多而不精,這種情況,確實值得我們多多深思,時間太晚了,今天就寫這麼點,睡了,安。

發佈了58 篇原創文章 · 獲贊 20 · 訪問量 4萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章