From b612ec8f049aff405a49c97236205079952ea578 Mon Sep 17 00:00:00 2001 From: 01Petard <1520394133@qq.com> Date: Mon, 2 Dec 2024 19:55:29 +0800 Subject: [PATCH] =?UTF-8?q?doc:=20=E6=96=B0=E5=A2=9E=E6=96=87=E7=AB=A0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...13\346\213\233\350\256\260\345\275\225.md" | 16 ++ ...76\347\232\204\350\260\203\347\240\224.md" | 174 ++++++++++++++++++ ...23\347\216\260\345\234\250\345\223\252.md" | 51 +++++ 3 files changed, 241 insertions(+) create mode 100644 "docs/\346\235\202\350\260\210/\345\220\216\346\227\245\350\260\210/2024\345\271\264\347\247\213\346\213\233\350\256\260\345\275\225.md" create mode 100644 "docs/\346\235\202\350\260\210/\345\257\271\344\272\216\345\244\247\346\250\241\345\236\213\347\273\230\345\210\266UML\345\233\276\347\232\204\350\260\203\347\240\224.md" create mode 100644 "docs/\346\235\202\350\260\210/\350\256\276\350\256\241\346\250\241\345\274\217\347\232\204\350\215\274\346\257\222\344\275\223\347\216\260\345\234\250\345\223\252.md" diff --git "a/docs/\346\235\202\350\260\210/\345\220\216\346\227\245\350\260\210/2024\345\271\264\347\247\213\346\213\233\350\256\260\345\275\225.md" "b/docs/\346\235\202\350\260\210/\345\220\216\346\227\245\350\260\210/2024\345\271\264\347\247\213\346\213\233\350\256\260\345\275\225.md" new file mode 100644 index 0000000..9b92217 --- /dev/null +++ "b/docs/\346\235\202\350\260\210/\345\220\216\346\227\245\350\260\210/2024\345\271\264\347\247\213\346\213\233\350\256\260\345\275\225.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/\346\235\202\350\260\210/\345\257\271\344\272\216\345\244\247\346\250\241\345\236\213\347\273\230\345\210\266UML\345\233\276\347\232\204\350\260\203\347\240\224.md" "b/docs/\346\235\202\350\260\210/\345\257\271\344\272\216\345\244\247\346\250\241\345\236\213\347\273\230\345\210\266UML\345\233\276\347\232\204\350\260\203\347\240\224.md" new file mode 100644 index 0000000..e3e2d85 --- /dev/null +++ "b/docs/\346\235\202\350\260\210/\345\257\271\344\272\216\345\244\247\346\250\241\345\236\213\347\273\230\345\210\266UML\345\233\276\347\232\204\350\260\203\347\240\224.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/) + +### 般若 + +这是**时序图**吧？我要的是**流程图**啊。不过般若能直接浏览，这挺好的。 + +image-20241202141327633 + +```mermaid +sequenceDiagram + participant 用户 + participant 应用程序 + participant 第三方支付接口 + + 用户->>应用程序: 发起支付请求 + 应用程序->>第三方支付接口: 调用支付接口 + 第三方支付接口-->>应用程序: 返回支付页面URL + 应用程序->>用户: 跳转到支付页面 + 用户->>第三方支付接口: 在支付页面完成支付 + 第三方支付接口-->>应用程序: 支付结果通知 + 应用程序->>用户: 显示支付结果 +``` + +### 豆包 + +比较符合，不过缺点就是不能预览。 + +image-20241202141627680 + +```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的预览和源码，不过这个图严格来说是时序图吧 + +image-20241202142630756 + +```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. 应用程序将支付结果展示给用户。 + +请注意，实际的支付流程可能会更加复杂，涉及到更多的安全验证、错误处理和异步通信等步骤。这个流程图仅作为一个基本的参考。 + +### 通义千问 + +好家伙，直接玩拟人的了…… + +image-20241202141903861 + +``` ++-------------------+ +---------------------+ +---------------------+ +| 用户选择支付 | | 应用程序准备支付 | | 应用程序调用支付 | +| 方式并提交订单 | ----> | 请求（创建支付 | ----> | 接口，传递支付 | +| | | 订单，获取支付参数）| | 参数 | ++-------------------+ +---------------------+ +---------------------+ + | + 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也干了，不过图中的单词起码看得清…… + +image-20241202142111474 + +## 总结 + +[般若](https://banruoai.cn/)、[豆包](https://www.doubao.com/chat/)、[KIMI](https://kimi.moonshot.cn/)都挺不错的，看得出对程序员的使用场景有特殊优化，对markdown语法的支持也比较好，反而是之前市面上比较火的通义和CHatGPT直接拉了，这是没想到的。 \ No newline at end of file diff --git "a/docs/\346\235\202\350\260\210/\350\256\276\350\256\241\346\250\241\345\274\217\347\232\204\350\215\274\346\257\222\344\275\223\347\216\260\345\234\250\345\223\252.md" "b/docs/\346\235\202\350\260\210/\350\256\276\350\256\241\346\250\241\345\274\217\347\232\204\350\215\274\346\257\222\344\275\223\347\216\260\345\234\250\345\223\252.md" new file mode 100644 index 0000000..ac935de --- /dev/null +++ "b/docs/\346\235\202\350\260\210/\350\256\276\350\256\241\346\250\241\345\274\217\347\232\204\350\215\274\346\257\222\344\275\223\347\216\260\345\234\250\345\223\252.md" @@ -0,0 +1,51 @@ +## 什么是过度设计？ + +假如我有一个加减乘除的方法，我可以这样写： + +image-20241202183805321 + +但如果我希望后续支持更多的计算模式，用了策略模式后，就变成了这样，代码变多了，逻辑也复杂了很多： + +image-20241202183754131 + +## 设计模式的荼毒体现在哪？ + +设计模式本身是软件工程中的最佳实践，它们提供了解决常见问题的模板或蓝图。然而，当不恰当地使用或过度使用时，设计模式可能会带来一些负面效果，这可以被称为“设计模式的荼毒”。以下是几个体现： + +1. **过度设计**：开发人员可能倾向于为每一个小问题都应用设计模式，即使这些问题并不需要如此复杂的解决方案。这会导致代码变得过于复杂，难以理解和维护。 + +2. **性能损失**：某些设计模式，如装饰器模式或代理模式，可能会引入额外的层次和间接性，从而导致性能下降。 + +3. **学习曲线**：对于新手开发者来说，理解设计模式可能是一个陡峭的学习过程。如果项目中广泛使用了各种设计模式，那么新加入团队的成员可能需要花费大量时间来熟悉这些模式，从而降低了开发效率。 + +4. **僵化的设计**：过度依赖设计模式可能导致系统设计变得僵化，限制了系统的灵活性和适应性。例如，严格遵循单一职责原则（SRP）可能会导致过多的小类，使得系统难以管理和扩展。 + +5. **不必要的复杂性**：有时候，简单直接的解决方案会更加有效。而设计模式可能会增加不必要的抽象层，使得代码更难阅读和调试。 + +6. **模式误用**：不正确地选择或实现设计模式可能会导致代码质量下降。例如，错误地使用工厂模式（Factory Pattern）可能导致紧耦合，而不是预期的松耦合。 + +7. **忽视上下文**：设计模式通常是在特定上下文中提出的解决方案。如果不考虑实际的应用场景盲目套用，可能会适得其反。 + +8. **沟通障碍**：团队成员之间对设计模式的理解可能存在差异，这可能导致沟通上的误解，影响协作效率。 + +## 简化思维：避免不必要的复杂性 + +把复杂问题搞简单，而不是把简单问题搞复杂，以下是两个例子，在考虑编写代码时，我们往往会陷入一种最优思维，这其实是没必要的，这会加重我们的思维负担。 + +- 数据结构和算法－>大数据量问题：在考虑排序算法时，应该从数据量的角度去选择排序算法，如果数据量较小，则越简单越好。 +- 设计模式或代码设计－>复杂代码的问题：如果代码比较简单，业务变动大，完全没必要用设计模式。 + +## 如何避免过度设计？ + +1. 不要为了应用设计模式而应用，解决问题而不是炫技。 +2. 不以破坏代码可读性为前提，宁要可读不要优雅。 +3. 不要为了短期不存在的扩展而费神（YAGNI : You Ain't Gonna Need It）。 +4. 持续重构优于提前设计，发现问题，解决问题，不要试图一开始就打造完美代码。 + +## 总结 + +在使用设计模式时，重要的是要根据具体的情况权衡利弊，并且保持适度。 + +设计模式应该是用来帮助解决问题的工具，而不是问题本身。 + +在实际开发中，应该以简洁性和实用性为原则，避免为了模式而模式。 \ No newline at end of file