工作两年以来，被磨圆滑了，心智有所成长……
刚毕业时候年轻气盛，和邻居组的老板吵了几句。后来我晋升时，发现他是评委…… 曾经的我多么嚣张，现在的我就多么低调。
一路走来，磕磕绊绊，几年来，我总结了工作上的思考……
工作思考
- 有效控制情绪，在沟通时使用适当的表情包以传达善意。无论线上还是线下，都应避免争吵。只有和气相处，我们才能推动工作的进展。
- 在讨论具体问题之前，先进行一些预备性的交流。情绪应放在第一位，工作讨论放在第二位。如果对方情绪不好，最好选择另一个时间再进行讨论。
- 在与他人交流时要保持初学者的态度和需求，不要用技术去怼人。
- 进入新团队先提升自己在团队的业务能力，对整个系统有足够的了解，不要怕问问题和学习。不要新入职就想毁天灭地，指手画脚 ”这里的设计不合理，那里有性能瓶颈“。
- 在各个事情上，都要比别人多了解一点。对于关键的事情要精通，对于其他事情也要多花一点时间去投入。
- 遇到困难时，先自己思考和尝试解决，然后再请教他人。不要机械地提问，也不要埋头一直搞而不主动提问。但如果是新入职，可以例外，多提问总没有坏处，但要在思考的基础上提问。
- 当向他人求助时，首先要清晰地阐述自己正在面临的问题、目标、已尝试的方法以及所需要的帮助和紧迫程度。所有的方面都要有所涉及。在提问之前，最好加上一句是否可以帮忙，这样对解决问题是否有帮助更加明确。因为别
- 一定有时间来帮助你，即使有时间，你也不一定找对了人。
- 在明确软件产品要解决的业务问题之前，先了解自己负责的那部分与业务的对应关系。
- 主要核心问题一定要提前叙述清楚,不要等别人问
- 要始终坚持追踪事情的进展，与与自己有交互的队友讨论接口，并关注他们的进度，以确保协调一致。
- 要主动向队友述说自己的困难，在项目延期或遇到困难时，要主动求助同事或领导，是否能分配部分工作给其他人，不要全部自己承担。
- 如果预计任务需要延期，要提前告知领导。如果有进展，也要及时向领导汇报。
- 如果无法参加会议但是自己是会议的重要参与者，一定要提前告知领导自己的进度、计划和想法，最好以书面形式或电话告知。如果可以远程参加，可以选择电话参加。除非有极其重要的事情，务必参加会议。不要假设别人都知道你的进度和想法。
- 要少说话，多做事。在开会时，不要凭借想当然的想法，可以询问其他小组的细节，但不要妄自揣测别人的细节，以为自己是对的。否则会被批评。
- 程序员如果经验丰富，很容易产生自我感觉良好的情绪。要避免这种情况，我们必须使用自己没有使用过的东西，并进行充分的测试，这样才能减少问题的出现。要提前考虑好所有细节，不要认为没有问题就不加考虑。要给自己留出处理问题的时间，并及时反馈并寻求帮助。
- 当与他人交流时，要始终保持有始有终的态度，特别是当寻求他人帮助时，最后一定要确认OK。要胆大心细，不要害怕犯错，要有成果，要快速并提高效率，不择手段地追求快速，并对结果负责。工作一定要完成闭环，要记事情要好，记住重要的事情并使用备忘录记录待办事项。
- 每完成一个项目后，应该回顾一下使用了什么知识、技能和工具。要总结并记录下这些，并与之前积累的知识和技能进行关联。如果发生了错误，也要记录下来，并将经验进行总结。
- 每天早上先思考今天要做什么，列出1、2、3，然后每天晚上下班时回顾已完成的任务、未完成的任务以及遇到的问题。
- 如果有待办事项没有立即处理，一定要用工具记录下来，不要心存侥幸以为自己能记住。
代码编写和技术问题
- 在代码编写过程中要认真对待，对于代码审核之前，要自己好好检查，给人一种可靠的感觉。
- 对于代码审核，不要过于苛刻，要容忍个人的发挥。
- 在提交代码给测试之前，应该先自行进行测试验证通过。
- 如果接口没有做到幂等性，那就会给未来的人工运维增加困难。当数据存在多份副本时，例如容量信息和上下游同时存在的资源，需要评估数据不一致的可能性以及解决方法。可以考虑通过数据校准或严格的代码编写来保证最终的一致性，或者考虑只在一方保存数据或以一方的数据为准。一旦出现数据不一致，则以其中一方的数据为准，无需人为干预即可自动达到数据再次一致。
- 要学会横向和纵向分割隔离系统，明确系统的边界，这样可以更好地进行并发合作开发和运维，提高效率。各个子系统应该独立变化，新的设计要考虑向后兼容性和上下游兼容性问题，包括上线期间的新老版本兼容。在设计评审阶段就应该重视这些问题。
- 如果在代码审查中无法发现业务问题或代码风格问题，不妨重点关注日志的打印是否合理和是否存在bug。
- 在依赖某个服务或与其他服务共享时，要确认该服务是否要废弃、是否是系统的瓶颈，以及是否可以自己进行改造或寻找更优的提供者。
- 使用缓存时注意预热，以防止开始使用时大量的缓存未命中导致数据库负载过高。
- 在使用rpc和mq、共享数据库、轮询、进程间通信和服务间通信时，要根据情况做出选择，并注意不要产生依赖倒置。
- 在接口有任何变动时，务必通过书面和口头确认。在这方面，要多沟通，尽量详细，以避免出现严重问题！毕竟，软件系统非常复杂，上下游之间的理解难以保持一致。
- 尽可能使用批量接口，并考虑是否需要完全批量查询。当批量接口性能较差时，设置适当的最大数量，并考虑客户端支持将批量接口聚合查询。批量接口往往是tp99最高的接口。
- 对于系统重要设计和功能，要考虑降级预案，并加入一些开关来满足安全性和性能需求。
- 如果数据不一致，可以考虑对比两方的不一致数据并打印错误日志，例如es/db等。
- 在系统设计之前，要充分调研其他人的设计，了解背景和现状。
- 废弃的代码应立即删除，如果以后需要，可以从git中找回。如果实在不想删除，也要注释掉！特别是对外的rpc、http接口，不使用的要立即删除，保持代码简洁。接手项目的人不熟悉背景情况，很难判断这段废弃代码的意义，容易造成混乱和浪费时间。要努力将其和其他有效代码联系起来，但这很困难。
- 在代码中要有详尽的日志记录！但是必须有条理和规范，只打印关键部分。对于执行的定时任务，应该打印足够详细的统计结果。最好使用简洁明了的日志，只记录最少量但最详细的信息，反馈程序的执行路径。
- 如果接口调用失败或超时，应该如何处理？幂等和重试如何处理？
当你写下一行代码前
- 要明确这行代码可能出现的异常情况以及如何处理，是将异常隔离、忽略还是单独处理，以防遗漏某些异常。
- 需要确保该行代码的输入是否已进行校验，并考虑校验可能引发的异常。
- 需要思考由谁调用该代码，会涉及哪些上游调用，并确定向调用者提供什么样的预期结果。
- 需要确定是否调用了一个方法或接口，以及该调用是否会阻塞或是异步的，并考虑对性能的影响。
- 需要评估该行代码是否可以进行优化，是否可以复用。
- 如果该行代码是控制语句，考虑是否能简化控制流程是否扁平。
- 对于日志打印或与主要逻辑无关的输出或报警，是否需要多加关注，因为它们可能还是很重要的。
- 如果代码是set等方法，也要仔细检查，避免赋错属性。IDE可能会有误提示，因为属性名前缀类似，set方法容易赋值错误。
当你设计一个接口时
- 接口的语义应该足够明确，避免出现过于综合的上帝接口
- 如果语义不明确，需要明确上下游的期望和需求。有些需求可以选择不提供给上游调用。
- 对于接口超时的处理，可以考虑重试和幂等性。在创建和删除接口时要确定是否具有幂等性，同时，幂等后返回的数据是否和首次请求一致也需要考虑。
- 接口是否需要防止并发，以及是否成为性能瓶颈也需要考虑。
- 设计接口时要确保调用方能够完全理解，如果他对接口的理解有问题，就需要重新设计接口。这一点非常关键，可以通过邮件确认或者面对面交流来确保调用方理解得清楚。
- 在开发过程中，需要定期关注队友的开发进度，了解他们是否已经使用了接口以及是否遇到了问题。这个原则适用于所有的上下游和相关方，包括产品和测试人员。要想清楚如何对接口进行测试，并与测试人员明确交流。
- 最好自己整理好测试用例，不要盲目地指望测试人员能发现所有的bug。
- 需要考虑是否需要批量处理这个接口，以减少rpc请求的次数。但即使是批量处理，也要注意一次批处理最多处理多少条记录，不要一次性处理全部记录，避免由于网络阻塞或批量处理时间过长导致上游调用超时，需要适度控制批量处理的规模。
作者：五阳
来源：juejin.cn/post/7306025036656787475
来源：juejin.cn/post/7306025036656787475
