与业务方需求方沟通
1、开发进度同步，主动反馈、沟通进展，让需求方心里有数。
- 开发前
- 主动沟通需求，不是等别人来找你沟通
- 需求的确认澄清得到结论之后，也用文字描述清楚，在群里cc相关业务方，保证各方信息、结论对齐，并且有信息的留存，可追溯。
- 需要做开发排期的同步，什么时候开启开发，预计什么时候交付。
- 即使你还没那么快开发，你需要及时告知进展、安排，让需求方知道这个功能什么时候能上，现在开发到哪了。有了进展、风险需求同步，让大家心中有数。
- 开发过程中
- 需要及时同步开发的进度，目前的进度是什么？完成了什么的开发
- 目前进度是否正常，是否存在什么问题风险是否可控，能否如期交付。
- 如果识别出了风险需要及时同步，遇到拿不准的问题，也需要将问题上升。
- 开发交付
- 功能上线之后，需要同步信息给业务方，告知功能已经上线，可以正常使用。
- 最好也能抽空观察下运行情况，能够在业务方提出质疑前，解决bug。
- 问题反馈已读即回，不要先排查问题，但是未跟用户说。用户不知道，只能看到已读不回，感官不好，需要传达我现在正常处理你的问题，有进展会及时同步，或者我现在比较忙，需要稍等处理你的问题。
2、尽量避免研发直接对接业务方。
- 引导业务方有问题找PO的意识，不能引导他来找研发。有信息同步，也是直接同步给PO。
- 插入需求。所有的需求提出、评估都应该由PO去对接，尽量避免业务方直接给研发提需求这种情况。
- 所有流程、产品层面上的改动，都让业务方直接找产品确认，得出结论之后，开发只负责开发工作。是否变动原有设计和实现，业务方提出要改造的时候，不能单从实现难易就妄下结论。觉得实现简单，就说改造，需要从产品设计层面上考虑能不能这么改？合不合理？拿不定的时候需要找产品经理对齐。
变更、发版与线上问题：
1、积极尽致。发现问题，立刻处理，不能存在侥幸心理，慢慢修。
发现一个地方似乎有点问题，临近下班点，想着明天早上再处理，结果凌晨一点多被紧急call起来处理。
- 等用户反馈或者问题突然暴露，只会将自己处于非常被动的情境，影响也很不好。
- 同时，还可能会连累相关的同事排查问题。
2、不要在特殊节点做变更
（下班点、饭点、周五晚），变更完必须能观察一下情况，不能发就完事。此时如果出现了问题，才能及时回退，减少问题的影响范围。
3、完整测试。
用户很多、牵一发动全身的组件、代码，无论改动多小，都要进行完整的测试。不能改的很少，就不做测试，直接上线。一出问题，影响范围太广。
4、变更前，考虑是否为兼容性变更，是，则必须先发公告。
用户不做变更，会不会影响功能使用，如果会，必须先做公告。
开发：
1、从宏观的角度来考虑需求。
而不是单单从需求的切面考虑需求，容易陷在细节中，考虑不全面。
- 为什么要做这个需求，背景是什么？意义是什么？
- 这个需求的上下游是什么？
- 这个需求的需求方是谁？防止需求gap
2、方案的设计和选型。
- 需求不断变更，核心功能考虑方案的时候一定要多想一下
- 执行逻辑搞清楚了，但相关的东西是否考虑到？可能的异常情况：数据量多少？业务方异常？第三方异常？
- 找大佬进行方案评审，评估实现的合理性**。有一些特殊场景，最好找有经验的前辈review一下，不要着急开发。**
- 是否需要考虑并发安全。
3、调用第三方的接口。必须打印日志信息，便于问题排查、实锤。
- 请求前，打印你的调用参数。
- 请求后，打印第三方的原始返回、整体的接口耗时。
4、别人调你的接口。
- 对所有参数零信任，必须进行参数校验。防止恶意的调用，你不能要求调用方来保证参数的合法性。
- 打印所有请求的入参。
- 所有的报错，都应该打印错误日志。跟数据相关的，最好也在关键节点打印原始信息。
5、特殊接口需要考虑熔断和降级。
- 例如第三方的接口调用异常，我们服务内部不断重试，在大数据量下把服务拉垮。比如如果第三方接口调用超过多少次报错，就直接给业务方抛错。
- 数据量的考虑，接口调用的量级普通的同步能不能抗住===> 用异步线程池能不能抗住=>kafka 消费订阅能不能抗住？都有什么比较好的实现方式。最简单的是同步，但是够不够用？
6、排查问题的时候不要着急下手，先理清其中的逻辑，定位原因。不然就是白费力气。
7、把精力聚焦，用整块的时间去处理一个事项。时间被碎片化，效率非常低下。
不时看有什么消息，一会回复这，一会回复那，做会这个又去处理那个，开发了没几分钟，又处理线上问题去了。
8、做好自己的定位，把活给专业的、更合适的人做。
比如自己的定位是开发，有运维的需求，应该给运维去处理，他不能处理的时候才考虑是否需要介入。
