doc: 新增文章

01Petard · Dec 2, 2024 · b612ec8 · b612ec8
1 parent c81db71
commit b612ec8
Show file tree

Hide file tree

Showing 3 changed files with 241 additions and 0 deletions.
diff --git a/docs/杂谈/后日谈/2024年秋招记录.md b/docs/杂谈/后日谈/2024年秋招记录.md
@@ -0,0 +1,16 @@
+---
+title: 2024年秋招记录
+date: 2024-12-02 19:03:00
+updated:
+categories: 
+- 其他
+tags:
+- 研究生
+keywords:
+- 研究生
+description: 秋招，寄！
+cover: 
+top_img: 
+---
+
+彻底完了，就这个大环境，已经完全找不到什么理想的工作了，明明去年还能看看什么好工作，现在就只能看自己能做的了，也没感觉自己哪里菜了，就是大环境整体都在收缩，企业也不好过，唉，就先这样吧……
diff --git a/docs/杂谈/对于大模型绘制UML图的调研.md b/docs/杂谈/对于大模型绘制UML图的调研.md
@@ -0,0 +1,174 @@
+## 对于大模型绘制UML图的调研
+
+在2024年年底，我简单考察了市面上一些大模型对UML图绘制的能力。
+
+## 提示词
+
+提示词都是一样的：`画一个应用程序调用第三方支付接口的流程图`
+
+## 调研的大模型
+
+- [般若](https://banruoai.cn/)
+- [豆包](https://www.doubao.com/chat/)
+- [KIMI](https://kimi.moonshot.cn/)
+- [通义千问](https://tongyi.aliyun.com/)
+- [智谱清言](https://chatglm.cn/)
+- [ChatGPT](https://chatgpt.com/)
+
+### 般若
+
+这是**时序图**吧？我要的是**流程图**啊。不过般若能直接浏览，这挺好的。
+
+<img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202412021413663.png" alt="image-20241202141327633" style="zoom: 40%;" />
+
+```mermaid
+sequenceDiagram
+    participant 用户
+    participant 应用程序
+    participant 第三方支付接口
+
+    用户->>应用程序: 发起支付请求
+    应用程序->>第三方支付接口: 调用支付接口
+    第三方支付接口-->>应用程序: 返回支付页面URL
+    应用程序->>用户: 跳转到支付页面
+    用户->>第三方支付接口: 在支付页面完成支付
+    第三方支付接口-->>应用程序: 支付结果通知
+    应用程序->>用户: 显示支付结果
+```
+
+### 豆包
+
+比较符合，不过缺点就是不能预览。
+
+<img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202412021416704.png" alt="image-20241202141627680" style="zoom:50%;" />
+
+```mermaid
+graph TD;
+    A[用户在应用程序中发起支付请求] --> B[应用程序将支付请求信息发送给第三方支付接口];
+    B --> C[第三方支付接口验证请求信息合法性];
+    C -->|信息合法| D[第三方支付平台生成支付订单并跳转至支付页面（如收银台页面）];
+    D --> E[用户在支付页面选择支付方式（如银行卡、微信支付、支付宝支付等）];
+    E --> F[用户完成支付操作（输入密码、指纹验证等）];
+    F --> G[第三方支付平台将支付请求发送给相应支付渠道（如银行、微信支付服务器、支付宝服务器等）];
+    G --> H[支付渠道处理支付请求并进行资金结算等操作];
+    H --> I[支付渠道将支付结果反馈给第三方支付平台];
+    I --> J[第三方支付平台将支付结果更新到订单状态并通知应用程序];
+    J --> K[应用程序根据支付结果更新界面展示给用户（如显示支付成功或失败信息）];
+    C -->|信息不合法| L[第三方支付接口返回错误信息给应用程序];
+    L --> M[应用程序展示错误提示给用户];
+```
+
+### KIMI
+
+KIMI也不错，比般若体验更好，可以切换markdown的预览和源码，不过这个图严格来说是时序图吧
+
+<img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202412021426783.png" alt="image-20241202142630756" style="zoom:50%;" />
+
+```mermaid
+sequenceDiagram
+    participant A as 应用程序
+    participant B as 第三方支付平台
+    participant C as 用户
+    participant D as 银行
+
+    A->>C: 请求支付
+    Note over C: 用户输入支付信息
+    C->>A: 确认支付
+    A->>B: 发送支付请求
+    Note over B: 第三方支付平台验证请求
+    B->>D: 请求银行扣款
+    D->>B: 扣款成功
+    B->>A: 支付成功通知
+    A->>C: 显示支付结果
+
+```
+
+这个流程图描述了以下步骤：
+
+1. 应用程序（A）向用户（C）请求支付。
+2. 用户输入支付信息并确认支付。
+3. 应用程序发送支付请求到第三方支付平台（B）。
+4. 第三方支付平台验证请求的合法性。
+5. 第三方支付平台请求银行（D）扣款。
+6. 银行扣款成功后，通知第三方支付平台。
+7. 第三方支付平台将支付成功的通知发送给应用程序。
+8. 应用程序将支付结果展示给用户。
+
+请注意，实际的支付流程可能会更加复杂，涉及到更多的安全验证、错误处理和异步通信等步骤。这个流程图仅作为一个基本的参考。
+
+### 通义千问
+
+好家伙，直接玩拟人的了……
+
+<img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202412021419896.png" alt="image-20241202141903861" style="zoom:40%;" />
+
+```
++-------------------+       +---------------------+       +---------------------+
+|  用户选择支付     |       | 应用程序准备支付    |       | 应用程序调用支付    |
+|  方式并提交订单   | ----> | 请求（创建支付      | ----> | 接口，传递支付      |
+|                   |       | 订单，获取支付参数）|       | 参数                |
++-------------------+       +---------------------+       +---------------------+
+                                                         |
+                                                         v
+                                                  +---------------------+
+                                                  | 第三方支付平台处理  |
+                                                  | 支付请求，返回支付  |
+                                                  | 结果或重定向到支付  |
+                                                  | 网关页面            |
+                                                  +---------------------+
+                                                         |
+                                                         v
+                                                  +---------------------+
+                                                  | 用户完成支付        |
+                                                  | （通过网银、移动支  |
+                                                  | 付应用等）          |
+                                                  +---------------------+
+                                                         |
+                                                         v
+                                                  +---------------------+
+                                                  | 第三方支付平台通知  |
+                                                  | 应用程序支付结果    |
+                                                  +---------------------+
+                                                         |
+                                                         v
+                                                  +---------------------+
+                                                  | 应用程序验证支付结  |
+                                                  | 果，并更新订单状    |
+                                                  | 态                  |
+                                                  +---------------------+
+                                                         |
+                                                         v
+                                                  +---------------------+
+                                                  | 应用程序向用户显示  |
+                                                  | 支付成功/失败信息  |
+                                                  +---------------------+
+```
+
+这个流程图可以分为以下几个关键步骤：
+
+1. 用户在应用程序中选择支付方式并提交订单。
+2. 应用程序准备好支付请求，这通常包括创建一个支付订单，并从第三方支付平台获取必要的支付参数。
+3. 应用程序调用第三方支付接口，传递支付参数给支付平台。
+4. 第三方支付平台处理支付请求，这可能涉及到重定向用户到银行或其他支付网关的页面。
+5. 用户通过选定的方式完成支付过程。
+6. 第三方支付平台将支付结果通知给应用程序，这通常是通过回调URL或服务器间的通知来完成。
+7. 应用程序验证支付结果，并根据支付结果更新订单状态。
+8. 应用程序向用户展示支付成功的确认信息或支付失败的消息。
+
+当您绘制这个流程图时，确保使用清晰的箭头来表示数据流和控制流的方向，并且为每个步骤提供简短的描述。如果您需要更详细的流程或者针对特定支付平台的流程图，请提供更多的上下文信息。
+
+### 智谱清言
+
+这位更是重量级……而且图中的单词都是乱码
+
+![image-20241202142018980](https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202412021420016.png)
+
+### ChatGPT
+
+OpenAI也干了，不过图中的单词起码看得清……
+
+<img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202412021421505.png" alt="image-20241202142111474" style="zoom:40%;" />
+
+## 总结
+
+[般若](https://banruoai.cn/)、[豆包](https://www.doubao.com/chat/)、[KIMI](https://kimi.moonshot.cn/)都挺不错的，看得出对程序员的使用场景有特殊优化，对markdown语法的支持也比较好，反而是之前市面上比较火的通义和CHatGPT直接拉了，这是没想到的。
diff --git a/docs/杂谈/设计模式的荼毒体现在哪.md b/docs/杂谈/设计模式的荼毒体现在哪.md
@@ -0,0 +1,51 @@
+## 什么是过度设计？
+
+假如我有一个加减乘除的方法，我可以这样写：
+
+<img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202412021838343.png" alt="image-20241202183805321" style="zoom:50%;" />
+
+但如果我希望后续支持更多的计算模式，用了策略模式后，就变成了这样，代码变多了，逻辑也复杂了很多：
+
+<img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202412021837157.png" alt="image-20241202183754131" style="zoom:50%;" />
+
+## 设计模式的荼毒体现在哪？
+
+设计模式本身是软件工程中的最佳实践，它们提供了解决常见问题的模板或蓝图。然而，当不恰当地使用或过度使用时，设计模式可能会带来一些负面效果，这可以被称为“设计模式的荼毒”。以下是几个体现：
+
+1. **过度设计**：开发人员可能倾向于为每一个小问题都应用设计模式，即使这些问题并不需要如此复杂的解决方案。这会导致代码变得过于复杂，难以理解和维护。
+
+2. **性能损失**：某些设计模式，如装饰器模式或代理模式，可能会引入额外的层次和间接性，从而导致性能下降。
+
+3. **学习曲线**：对于新手开发者来说，理解设计模式可能是一个陡峭的学习过程。如果项目中广泛使用了各种设计模式，那么新加入团队的成员可能需要花费大量时间来熟悉这些模式，从而降低了开发效率。
+
+4. **僵化的设计**：过度依赖设计模式可能导致系统设计变得僵化，限制了系统的灵活性和适应性。例如，严格遵循单一职责原则（SRP）可能会导致过多的小类，使得系统难以管理和扩展。
+
+5. **不必要的复杂性**：有时候，简单直接的解决方案会更加有效。而设计模式可能会增加不必要的抽象层，使得代码更难阅读和调试。
+
+6. **模式误用**：不正确地选择或实现设计模式可能会导致代码质量下降。例如，错误地使用工厂模式（Factory Pattern）可能导致紧耦合，而不是预期的松耦合。
+
+7. **忽视上下文**：设计模式通常是在特定上下文中提出的解决方案。如果不考虑实际的应用场景盲目套用，可能会适得其反。
+
+8. **沟通障碍**：团队成员之间对设计模式的理解可能存在差异，这可能导致沟通上的误解，影响协作效率。
+
+## 简化思维：避免不必要的复杂性
+
+把复杂问题搞简单，而不是把简单问题搞复杂，以下是两个例子，在考虑编写代码时，我们往往会陷入一种最优思维，这其实是没必要的，这会加重我们的思维负担。
+
+- 数据结构和算法－>大数据量问题：在考虑排序算法时，应该从数据量的角度去选择排序算法，如果数据量较小，则越简单越好。
+- 设计模式或代码设计－>复杂代码的问题：如果代码比较简单，业务变动大，完全没必要用设计模式。
+
+## 如何避免过度设计？
+
+1. 不要为了应用设计模式而应用，解决问题而不是炫技。
+2. 不以破坏代码可读性为前提，宁要可读不要优雅。
+3. 不要为了短期不存在的扩展而费神（YAGNI : You Ain't Gonna Need It）。
+4. 持续重构优于提前设计，发现问题，解决问题，不要试图一开始就打造完美代码。
+
+## 总结
+
+在使用设计模式时，重要的是要根据具体的情况权衡利弊，并且保持适度。
+
+设计模式应该是用来帮助解决问题的工具，而不是问题本身。
+
+在实际开发中，应该以简洁性和实用性为原则，避免为了模式而模式。