1. 行为准则2. 依赖管理2.1. 在现有的代码上增加一个依赖似乎是一个简单的决定2.2. 不要重复自己”(Don’trepeatyourself，DRY)是一个通常被教导的原则2.3. 依赖关系带来了风险2.3.1. 不兼容的变化2.3.2. 循环依赖2.3.3. 版本冲突2.3.4. 缺乏控制2.4. 相依性是指你的代码所依赖的代码2.4.1. 在编译、测试或运行期间，所有需要依赖关系的时间周期被称为依赖范围2.5. 依赖关系是在软件包管理或构建文件中声明的2.5.1. Java的Gradle或Maven配置2.5.2. Python的setup.py或requirements.txt2

1. 自己动手编写测试1.1. QA团队可以帮助你验证你的代码是否稳定，但千万不要把代码直接丢给他们，然后让他们做所有的测试1.2. 避免硬编码的值，不要重复代码1.3. 专注于测试基本功能而不是实现细节，这有助于代码库的重构1.3.1. 测试代码在重构后仍然可以运行1.4. 将测试的依赖项与常规代码的依赖项分开2. 避免过度测试2.1. 要编写那些在测试失败的时候有意义的测试，不要为了提高代码覆盖率而去提高代码覆盖率2.1.1. 测试数据库包装器、第三方类库或基本的变量赋值，即使它们能提高覆盖率指标，也是毫无价值的2.1.2. 要专注于那些对代码风险有最大影响的测试2.2. 将代码覆盖率作为

1. 行为准则2. 编写、运行和修复测试用例会让人感觉很忙碌2.1. 测试本身才更容易成为繁忙的工作2.2. 糟糕的测试会增加开发人员的开销而不提供价值，并且还会增加测试套件的不稳定性3. 测试用途3.1. 测试可以检查代码是否正常工作3.1.1. 测试本身就可以验证软件的行为是否符合预期3.1.2. 预料之外的软件行为会给用户、开发人员和运维人员带来很多困扰3.1.3. 测试这道工序可以证明代码已经按规定生效了3.2. 保护代码不会被将来那些无意中的修改所影响3.2.1. 测试可以保护现有的行为不受新变化的影响3.3. 鼓励清爽的代码3.4. 强迫开发者试用他们自己的API3.4.1. 编写

一、报错内容详情：[requestId-]2023-07-3118:32:21|ERROR|http-nio-39978-exec-1|GlobalExceptionHandler.java:86|com.xiaobai.base.service.exception.GlobalExceptionHandler|Typedefinitionerror:[simpletype,classcn.hutool.json.JSONNull];nestedexceptioniscom.fasterxml.jackson.databind.exc.InvalidDefinitionException:No

1. 行为准则2. 日志分级2.1. 日志框架设有日志级别，它可以让运维人员根据重要性过滤消息2.2. 编程语言有精良的日志类库，让运维人员对要记录的内容和时间有更多的控制2.3. TRACE2.3.1. 一个极其精细的日志级别2.3.2. 对特定的包或类开放2.3.3. 在开发阶段之外很少使用这个级别2.4. DEBUG2.4.1. 多用于那些只在调查产品出故障时有用2.4.2. 在正常操作中没有用的日志2.5. INFO2.5.1. 一般用于输出应用程序运转良好的日志2.5.2. 不应该用于输出任何问题的指示2.6. WARN2.6.1. 一般用于提示那些潜在问题2.6.2. 一个资源已经

1. 编写可维护的代码1.1. 生产环境下的软件必须一直保持可用的状态1.1.1. 用户行为不可预测，网络不可靠，事情总会出错1.2. 编写可维护的代码有助于你应对不可预见的情况，可维护的代码有内置的保护、诊断和控制1.2.1. 切记通过安全和有弹性的编码实践进行防御式编程来保护你的系统，安全的代码可以预防许多故障，而有弹性的代码可以在故障发生时进行恢复1.2.1.1. 切记让你的代码安全而有弹性1.2.1.2. 编写拥有良好防御性的代码是一种对那些运行你的代码的人（包括你自己！）富有同情心的表现1.2.1.3. 防御性的代码较少发生故障，就算它发生故障，也更有可能恢复1.2.1.4. 安全的

1. 行为准则2. 变更代码2.1. 变更代码和在新代码库中写代码完全不一样，你必须在不破坏现有行为的情况下进行这些修改2.1.1. 必须理解其他开发者的想法，坚持原有的代码风格和设计模式2.1.2. 必须在工作中温和地改进代码库2.2. 善于利用现有代码2.2.1. 安全地在现有代码库中修改代码的步骤2.2.1.1. 定义变更点2.2.1.2. 寻找测试点2.2.1.3. 打破依赖关系2.2.1.4. 编写测试2.2.1.5. 进行修改和重构2.2.2. 找到你需要修改的代码，并想出如何测试它2.2.2.1. 如果需要的话，为了让测试成为可能，可以对代码进行重构2.2.2.2. 针对现有的软

问题原因        GitHub的README.md文件通常无法直接引用本地文件或图片，因为GitHub的README.md是在远程服务器上渲染和显示的，无法访问本地文件系统。解决方案        要在GitHub的README.md中显示图片，你需要将图片上传到GitHub上，然后使用图片的URL进行引用。详细步骤一、将本地图片上传到GitHub上    1、在本地仓库新建一个存储照片的文件夹    2、将所需图片放入文件夹下    3、利用git将该文件夹上传到GitHub上二、修改图片路径    1、在.md文件上我们点击自己粘贴的图片可以看到图片的路径，如下图：由于GitHub用

1. 提出问题1.1. 所有的工程师都应该提出问题，这是学习的一个重要部分1.2. 新手工程师会担心打扰队友而试图自己解决所有问题，这样做既慢又没有效1.3. 尝试自己寻找答案1.3.1. 即使你的同事知道答案，你也要付出努力，这样你会学到更多1.3.2. 如果你没有找到答案，当你寻求帮助时，你的调查仍然会成为你的起点1.3.3. 不要只是在互联网上搜索1.3.3.1. 信息还存在于文档、内部论坛、自述文件(README)、源代码和错误跟踪器中1.3.3.2. 如果你的问题是关于代码的，试着把它变成一个可以演示的单元测试1.4. 设置一个时间限制1.4.1. 限制你研究一个问题时预期花费的时间

1. 核心领域中所需要的能力1.1. 技术知识1.1.1. 技术知识1.2. 执行力1.2.1. 过用代码解决问题来创造价值，并且你了解你的工作和业务之间的联系1.3. 沟通能力1.3.1. 能同时以书面和口头的形式进行清晰的沟通1.3.2. 能以建设性的方式提出问题和定义课题1.3.3. 文档化你的工作1.3.4. 撰写清晰的设计文档并征求反馈意见1.3.5. 与他人打交道时，你富有耐心和同理心1.4. 领导力1.4.1. 能在指定的工作范围内独立地完成工作1.4.2. 能迅速地从错误中学习1.4.3. 能很好地处理变动和模糊的问题1.4.4. 积极参与到项目和季度的规划中1.4.5. 能帮