这两天我们开发团队不知道咋的，跟包饺子下锅似的接连出了不少纰漏，有的大有的小，其实开发能力都可以，不是那种能力差导致的问题，我从外部观察，总结了一些出纰漏的原因和解决方案。
先说一下有啥纰漏。
- 小程序代码分包的时候，影响到线上正在使用的业务，损失了大概 1 晚上的流量。
- 上了身份证、人脸认证功能，测试回归的时候，测了不需要实名和人脸的场景，没测只需要身份证的场景，结果线上跑的时候用这个场景，导致功能也出了问题，用户反馈过来才发现。
- 错把代码提交到了 dev 分支。
看起来研发该死，但恐怕不全是研发的锅，当然我不是故意找理由，这些纰漏也是研发扛下来了，我只是尝试分析从更具体的原因分析，而不是简单的说一句能力太差、或者水平不够这样没法定位也没法改进的原因。
这些出问题的场景，无一例外都是很紧急的需求，开发加班加点做出来的，代码写的时候很匆忙，测试也是加班加点测的。
常在河边走，哪有不湿鞋？我觉得快和稳之间，对开发来说很难平衡，有些需求强行要那个时间点，最后只能牺牲稳定性求效率。
那怎么避免这种事情发生？
需求可以 delay，代码不能出问题
如果工作量实在大，那就先花点时间列举工作量大的原因。大部分领导其实讲道理的，你能像他说明工作量的确大，事项的确做不完，领导会额外给时间。
我觉得这是比只闷头写代码更有难度的事，也是一种能力的体现，这需要调研充分、思维清晰、表达有条理、和领导沟通的心理等等各项挑战。
只知道埋头苦干，但干不多不一定就是好。
万一要是真的只知道埋头苦干，那也要掌控好自己的节奏，一定要保证代码的质量，平时加加班，周末也来加班，通过拉长时间线的方式多写点代码，而不是通过偷懒、减少代码逻辑的方式。
加班的时候冒冒泡，留点记录，这样即使需求 delay 了，至少自己的态度表达到位了，一般领导也不会责怪。
需求这东西，delay 两天没那么恐怖，反倒是着急出了纰漏，那才是更恐怖的。
慢慢写
写代码很费脑子，要考虑到所有可能的异常场景，还要从业务上闭环，一着急，就容易漏场景，出纰漏，不要着急，细水长流。
想好再写
尤其是后端，新业务的架构设计，一定是要多花时间思考的，要充分考虑到业务的扩展性、未来的维护性、和其他业务对接的兼容性。
比如我最近写的京东商户订单支付，我们已有一套支付中心的系统，而在对接京东的时候，他们的支付其实是通过京东的订单状态回调来做的，我们一开始准备写在支付中心，后来随着三方接口的对接，对京东业务有更深的理解，我们决定做一套新的商户订单支付系统，和原本的支付中心（支付宝、微信支付）做区分。
如果我们当时匆忙的直接嵌入到支付中心，整个系统架构就会很混乱，订单和支付裹在一起，后续既不好维护，也不好扩展。
这样虽然需求有 delay 风险，但整体技术侧的方案，是绝对没问题的。大不了我周末来加班，加班都干不完，那就得赶紧汇报领导了。
包括最开始的人脸也是的，没有调研清楚，光阿里就两套不同的人脸接口，结果先用的贵的一套，后面发现有便宜的，又强行接入便宜的一套。如果一开始能多想想，先调研清楚，可能最后的工时反而更短一些。
专一写代码不要跳
写代码的时候，最好不要来回跳需求写，看起来很牛逼感觉也很吊，实际上很容易出问题，精力消耗太快了，有些场景思考不深入，就有可能埋雷。
决策和执行分开
如果开发过程中又做决策又做执行，尤其是干需求的时候，有的决策问起来吧很耗时间，需求到期上不了线了，就自己做个决策，没有告知其他人。这种场景的雷我也踩了几个。
开发对业务的理解不如运营产品深入，有时候开发觉得的最优决策不是运营想要的，最好不要为了图省隐蔽这些问题。
甩锅技巧
这部分是语言的艺术，就是当纰漏下来了，判责归自己，怎么表达，才是比较得体的。
一直说自己的责任吧，领导会觉得我很菜，一直推脱责任吧，领导又会觉得我不负责。
最好是那种和自己有点关系，但是关系不是那么直接的描述。
或是用于日常沟通，为了避免别人误把锅扣到自己头上。
我总结了同事们常用的有如下技巧：
- 首先主体对象不要说自己，比如分包的问题、锁的问题、分支的问题、没有这样的场景等等，避免说成我打的包有问题、我代码写的有问题、我分支切的不对等等。
- 先说一些撇开自己责任的话术，比如这里的代码没动过；之前还是好好的；这里用的外部接口的数据/逻辑。
- 接到莫名其妙的锅第一时间弹回去，怎么弹看 2 中的话术。我以前懒得弹，结果头上的锅越来越多。
挺瞧不上这些东西的，也不想花心思想，但有时候职场、工作、社会就是这么贱，人越是老实，就越容易被欺负；越能干活的人，最后会有越来越多的活；希望大家不要重蹈我的覆辙。
每天抽点时间学习和反思，加油，共勉。
这两天我们开发团队不知道咋的，跟包饺子下锅似的接连出了不少纰漏，有的大有的小，其实开发能力都可以，不是那种能力差导致的问题，我从外部观察，总结了一些出纰漏的原因和解决方案。
先说一下有啥纰漏。
- 小程序代码分包的时候，影响到线上正在使用的业务，损失了大概 1 晚上的流量。
- 上了身份证、人脸认证功能，测试回归的时候，测了不需要实名和人脸的场景，没测只需要身份证的场景，结果线上跑的时候用这个场景，导致功能也出了问题，用户反馈过来才发现。
- 错把代码提交到了 dev 分支。
看起来研发该死，但恐怕不全是研发的锅，当然我不是故意找理由，这些纰漏也是研发扛下来了，我只是尝试分析从更具体的原因分析，而不是简单的说一句能力太差、或者水平不够这样没法定位也没法改进的原因。
这些出问题的场景，无一例外都是很紧急的需求，开发加班加点做出来的，代码写的时候很匆忙，测试也是加班加点测的。
常在河边走，哪有不湿鞋？我觉得快和稳之间，对开发来说很难平衡，有些需求强行要那个时间点，最后只能牺牲稳定性求效率。
那怎么避免这种事情发生？
需求可以 delay，代码不能出问题
如果工作量实在大，那就先花点时间列举工作量大的原因。大部分领导其实讲道理的，你能像他说明工作量的确大，事项的确做不完，领导会额外给时间。
我觉得这是比只闷头写代码更有难度的事，也是一种能力的体现，这需要调研充分、思维清晰、表达有条理、和领导沟通的心理等等各项挑战。
只知道埋头苦干，但干不多不一定就是好。
万一要是真的只知道埋头苦干，那也要掌控好自己的节奏，一定要保证代码的质量，平时加加班，周末也来加班，通过拉长时间线的方式多写点代码，而不是通过偷懒、减少代码逻辑的方式。
加班的时候冒冒泡，留点记录，这样即使需求 delay 了，至少自己的态度表达到位了，一般领导也不会责怪。
需求这东西，delay 两天没那么恐怖，反倒是着急出了纰漏，那才是更恐怖的。
慢慢写
写代码很费脑子，要考虑到所有可能的异常场景，还要从业务上闭环，一着急，就容易漏场景，出纰漏，不要着急，细水长流。
想好再写
尤其是后端，新业务的架构设计，一定是要多花时间思考的，要充分考虑到业务的扩展性、未来的维护性、和其他业务对接的兼容性。
比如我最近写的京东商户订单支付，我们已有一套支付中心的系统，而在对接京东的时候，他们的支付其实是通过京东的订单状态回调来做的，我们一开始准备写在支付中心，后来随着三方接口的对接，对京东业务有更深的理解，我们决定做一套新的商户订单支付系统，和原本的支付中心（支付宝、微信支付）做区分。
如果我们当时匆忙的直接嵌入到支付中心，整个系统架构就会很混乱，订单和支付裹在一起，后续既不好维护，也不好扩展。
这样虽然需求有 delay 风险，但整体技术侧的方案，是绝对没问题的。大不了我周末来加班，加班都干不完，那就得赶紧汇报领导了。
包括最开始的人脸也是的，没有调研清楚，光阿里就两套不同的人脸接口，结果先用的贵的一套，后面发现有便宜的，又强行接入便宜的一套。如果一开始能多想想，先调研清楚，可能最后的工时反而更短一些。
专一写代码不要跳
写代码的时候，最好不要来回跳需求写，看起来很牛逼感觉也很吊，实际上很容易出问题，精力消耗太快了，有些场景思考不深入，就有可能埋雷。
决策和执行分开
如果开发过程中又做决策又做执行，尤其是干需求的时候，有的决策问起来吧很耗时间，需求到期上不了线了，就自己做个决策，没有告知其他人。这种场景的雷我也踩了几个。
开发对业务的理解不如运营产品深入，有时候开发觉得的最优决策不是运营想要的，最好不要为了图省隐蔽这些问题。
甩锅技巧
这部分是语言的艺术，就是当纰漏下来了，判责归自己，怎么表达，才是比较得体的。
一直说自己的责任吧，领导会觉得我很菜，一直推脱责任吧，领导又会觉得我不负责。
最好是那种和自己有点关系，但是关系不是那么直接的描述。
或是用于日常沟通，为了避免别人误把锅扣到自己头上。
我总结了同事们常用的有如下技巧：
- 首先主体对象不要说自己，比如分包的问题、锁的问题、分支的问题、没有这样的场景等等，避免说成我打的包有问题、我代码写的有问题、我分支切的不对等等。
- 先说一些撇开自己责任的话术，比如这里的代码没动过；之前还是好好的；这里用的外部接口的数据/逻辑。
- 接到莫名其妙的锅第一时间弹回去，怎么弹看 2 中的话术。我以前懒得弹，结果头上的锅越来越多。
挺瞧不上这些东西的，也不想花心思想，但有时候职场、工作、社会就是这么贱，人越是老实，就越容易被欺负；越能干活的人，最后会有越来越多的活；希望大家不要重蹈我的覆辙。
每天抽点时间学习和反思，加油，共勉。
扫一扫
1265
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
