企业移动应用开发管理之浅谈

为什么要写这篇博客呢，事情的原因是这样的。 大前天公司那边下来需求，要求移动端应用主要的详情页面加上图片的展示， 公司的后台和前台的业务比较复杂，改动的话涉及到三个端；代理商，商户，用户。 逻辑是这样的，商户创建，创建的时候添加图片，然后代理商审核，然后用户端展示，用户端展示又分两个接口。因为前期追求开发速度的原因，整个应用包括后台都是比较臃肿的，负责改动的后台人员也是刚来不久的新人，熟悉流程，制定方案在前天上午，然后下午两三点左右，产品经理过来说希望能加班上掉，上面催的紧，周末加加班。因为种种因素吧，催的很紧，然后后台人员在写的时候由于失误，改了老接口的一个东西， 导致线上应用崩溃，显示 异常等（周六晚上刚刚后台正式上线。） 然后产品经理就打电话，让我们赶紧到公司解决问题。原因是一个名称的字符串没有传，导致安卓端空异常崩溃，IOS显示异常。造成的影响还是比较严重的。从这件事，浅谈一下企业移动应用开发和日常维护升级等注意的问题，因为博主之前虽然做过后台开发，但是时间不长，只能主要的从安卓这方面开始谈，希望大家有补充的请多多留言，本篇博客会持续更新，避免更多的人遇到相似的问题。

日常篇：

1、尽量避免在周末的时候发版本和后台升级，因为周末本来是放假的时候，之前连着上了五天的班，肯定也是比较累的， 状态可能不是太好。还有有些人可能不在，需要他范围之内的问题有可能不会及时的解决;最主要的是突发的问题很有可能找不到当事人。 

2、上线前测试新版本的同时也不要忘记测试老版本。（又回到了 1 上面去，周末，人心都比较浮躁）。

技术篇：

1、后台更新的时候没有规划和把握不要去动老接口，很可能会发生一些恐怖的事情。

2、后台传字符串输局的时候解析的时候如果是null的话不同的解析工具解析出来的不同，有的是解析出来的是“”，有的直接是null，最好加个判断。

3、类型转换的时候最好在工具类中转换，避免null异常。

4、产品设计的时候最好给个无数据的时候的或者为空的时候默认的显示。

5、使用热修补，发生严重bug的时候能第一时间控制现场。

6、添加全局的异常捕获，发生崩溃之后下个版本修补。

  最后再谈一下app的事情：

众所周知，现在的市场，得用户者得天下。现在的企业大部分讲究快速迭代（说白了就是这个版本点子不行下个版本再换），丝毫不关心app的质量和用户的交互体验，大部分产品经理对app的交互这块知之甚少（这就体现出开发转产品的优势），对与app的各种动画和交互效果不怎么了解。大部分想的是感觉有用户或者是哪个版本用户买账，然后再细化。然后，没有想到， 假如你前期app半个月一个月一个大的版本，先不说别的，质量有保证么？，质量不保证，没有什么好的页面效果， 用户会买账么，如此就导致了一种恶性循环，需求一直变，一直开发，然而用户一直不买账，如果一个产品，业务不是太搓，app的交互效果和展示形式能帮你吸引或者是留住一部分用户，

而不是用户下下来一看，app感觉好搓，肯定是不会用的，我从技术上的角度上认为，保证业务通畅的同时，花一点时间在界面和用户体验上下下功夫，两三个月出了一个大版本，会比两三个月出了两伞个大版本的效果更好。这点让我想到了手机市场上，中国的各种手机开始的时候几个月或者半年就一款旗舰机，过个几天就没声了，然后被淘汰了，苹果的一下发布导致了巨大的效应，瞬间击败所有的竞争对手，中国的产品普遍的多而不精，这种情况，确实值得我们多多深思，时间太晚了，今天就写这么点，睡了，安。