开发实战方法论

问题1：测试同事把Bug提出来，是指派给前端同事，还是给后端同事处理？

答：初出茅庐的同学可能会有这方面困扰，前后端同学有时候会因为这个问题发生争执。

黑盒测试的同学不知道前后端交互的具体过程，也 不需要 知道具体过程。他提Bug只能从前端发现，因此，默认都是把Bug提给前端同事，由前端同事甄别到底是前端的Bug，还是后端的Bug

这里的甄别，并不是通过经验，或者直觉去判断，这样甩锅如果遇到不好讲的后端同事，可能会引起争执，因此，甩锅需要证据。比如后端的响应数据不正确，导致前端出错。前端同学就应该把响应报文打印出来与后端沟通处理。

这里还有一种特殊情况，就是同一个问题，多次查出由后端引起。则理应由后端排除自身问题再甩锅。

问题2：一个计算逻辑，是由前端做，还是由后端做？

答：这个要看情况。

情况1：APP接口
APP因为上架应用商店流程比较长，有任何的改动都要重新上架，不够灵活，因此，业务逻辑一般都由后端写，前端尽量只做页面逻辑。有Bug的时候，后端重新发布便可。

情况2：重要数据
比如金额的计算，可能包含优惠养，满减，活动等一些因素的影响，如果最终的金额由前端计算，就有可能被非法用户篡改数据，造成安全风险。

情况3：如果没有其他因素的影响，可以由前后端商量，看谁比较方便做
比如，有一个计算需要用到A、B、C三个数，这三个数的值前端缓存着，要计算直接拿便可以，但是后端要取这三个数，要调好几个三方接口配合完成。造成较大的系统开销，这个时候，应该由前端实现。

问题3：如何快速定位Bug？

答：一个项目出现Bug，可能是因为网络错误，可能是用户非法输入，前端非法传参，后端响应非法数据，第三方接口响应非法数据，第三方系统非法传参，最后一种情况，才是自己的代码没写对。

如果把上面的可预知的错误，都校验出来，并输出到前端，准确而友好的提示出来，系统90%的问题都能快速定位解决

前端开发面对的是“操作用户”，后端开发面对的是“前端用户”，第三方接口面对的是“第三方用户”，开发系统的人应该都有产品意识，把自己的“产品”设计得好用。这不仅能减少别人的麻烦，也可以减少自己的麻烦。
一种错误的认知是，用户输入导致报错，开发系统的人还要责骂用户非法输入。系统健壮性没做好，却要指导用户“改正错误”。

做第三方系统对接，一定 要把传参和响应记录下来，不然一旦出现问题将无法排查。有的同事为了图省事，或者为了减少系统存日志的开销，而放弃日志，这样是不科学的。除非一个系统经过了长年累月的运行，已经非常稳定，并且不做什么改动，不然日志还是要常开。

问题4：开发一个功能，是追求系统性能和用户体验，还是追求维护成本

答：大部分情况下，一个功能的性能和体验并不能增加公司的效益，却可能因为功能复杂度的上升让整个功能变得难以维护

难以维护，会增加学习成本，降低开发效率，增加出bug风险，公司的换人成本也会变得很高。

除非能明显增加公司效益，不然就是维护成本优先

问题5：生产环境是否只输出Error日志？

答：一些人可能会觉得，生产环境用户使用频率非常高，日志太多，99%是没什么价值的日志，有Error日志就可以，所以会要求生产环境把日志级别改成Error。但是在实际开发过程中，这样做的结果，往往是无法还原问题，问题排查会变得非常困难。因此，是否只输出Error日志，判断标准是：系统是否已经非常稳定。如果系统一直处于开发阶段，平常的入参还是需要打印出来的。

想要减少日志，一般是定时清理。有一种折衷的办法，就是在系统异常的时候再打印入参或者一些过程日志，这样既可以减少日志量，又可以还原部分问题。但是这样做无法根据日志还原用户的操作过程，应谨慎使用。

to be continue

个人见解，仅供参考