又是管理端入口引入的错误------类似事情过去发生， 现在发生， 未来还会发生！

        程序员都知道， 要用宏定义代替魔鬼数字， 可是， 现在的产品、运营经理们也变的刁了， 他们经常说： 这个值不要写死， 做成可配的！ 呵呵！

        在这种情况下， 一般要为产品、运营同学做一个管理端， 让他们可以配置对应的数据， 然后程序去读取这个数据， 实现数据的可配置化。 这样就实现了开发同学和产品、运营同学职责的分离， 易于变动， 比较灵活。

        但这种方式也非常容易引入问题， 如果管理端做的不够好， 或者对异常考虑不充分， 产品、运营同学配置了非预期的数据， 实际上就相当于间接改变了程序员程序的逻辑， 错误就会发生。

        我遇到过很多这样的案例了：

        1. 某次， 产品、运营同学在图片文件名中带了一个空格， 结果导致app里面图片无法正常展示。 实际上， 程序员在这里就没有考虑充分， 该反思。产品、运营同学也没有足够的意识。 （这是我当时反馈的问题）

        2. 某次， 会员体验不了会员的特权。 经查， 是管理端属性配置错误。 这种情况是程序员难以避免的， 主要还是产品、运营同学错配了。 （与我的业务有关）

        3. 最近， 非会员能体验会员特权。经查， 是管理端属性配置错误。 这种情况是程序员难以避免的， 主要还是产品、运营同学错配了。      （与我的业务有关）

        4. 最近， 某图片无法展示。 经常， 是管理端上架了新的item, 而管理端并没有同步支持到， 所以除了问题。                                                  （与我的业务有关）

        5. 有一次， ....,  经查， 是管理端...        （别的业务）

        6. 有一次， ....,  经查， 是管理端...        （别的业务）

        7. 有一次， ....,  经查， 是管理端...         （别的业务）

        建议： 作为程序员， 在做管理端的时候， 一定要更加仔细地考虑各种异常， 要想着为产品、运营同学降低操作错误的风险。 而作为产品、运营同学， 在不熟悉具体功能的情况， 要和开发同学确认， 才能进行相关操作。

        管理端实现了操作和职责的分离， 但切不可掉以轻心。

         作为开发同学， 定位类似问题（假设无法提前知道是否为管理端问题）， 思路一定要开阔， 从全方位考虑， 哪些因素肯能影响程序的运行和结果