随笔分类 - 软件工程
摘要：## 过载保护 ### 令牌桶算法 存放固定容量令牌的桶，按照固定速率往桶里添加令牌 https://pkg.go.dev/golang.org/x/time/rate ### 漏桶算法 作为计量工具(The Leaky Bucket Algorithm as a Meter)时，可以用于流量整形(
阅读全文
摘要：上线上了大半天，原因：因为慢查询了导致跑不出来，后来同事帮忙看了下发现慢查询了，程序hang住了 select * from table where cdate = '2023-02-01' and id > ? order by id limit 500 这条sql线上执行了300ms，一共900
阅读全文
摘要：定义 复杂问题：一下子想不到解决方式的问题，或者说是一个新项目或者工程化的项目。这样也没有办法量化，比如说是 30人日 的项目，需要一个人做30天，4个人做10个工作日的项目这些都属于复杂的工程用来解决某个问题的项目。 心态 不要害怕复杂的问题，复杂的工程问题你去分析，不过是由一个一个稳定的组件组装
阅读全文
摘要：为什么要做这件事情？这件事情的收益是什么 拿章淼老师举的例子，比如定位追踪导弹，导弹很重要，但是它的定位功能是最重要的。类比我们在软件开发和技术方案设计的时候也是这样，为什么做这件事情比怎么做这件事情可能更加的重要。 Design for Fail 设计的时候要考虑失败的情况下，如何处理，比如发奖状
阅读全文
摘要：对修改上下游关联的影响：比如新增字段后存量数据的处理 新增字段或者字段定义修改的时候，对存量数据要考虑到。这部分数据很容易被忽略，但是这些也是很重要的一环 这件事情是否需要做，从长线的角度去考虑 从长期考虑，先做紧急&重要的，然后做重要&不紧急的。比如一个慢查询sql，当下可能没有索引不会出现慢查询
阅读全文
摘要：如何处理复杂的问题 关注点分离：将复杂的问题，模块化，将每个模块做到高效稳定，然后将模块通信机制稳定建立起来。 积极思考，给出自己的解决方案 计算机是人造的学科，所以每个步骤的变化与计算人都是清晰地知道的，它只是一个工具，帮我们去解决复杂的问题，所以对问题不要害怕，积极思考，想方案去解决，联系现实生
阅读全文
摘要：对于Git 的成功：林纳斯表示： Git的设计其实很简单，它有一个稳定而合理的数据结构。事实上，我强烈建议围绕着数据来设计代码，而不是反其道而行之，我觉得这可能就是Git如此成功的原因。坏程序员总是担心他们的代码，而优秀的程序员则会担心数据结构和它们之间的关系。 -- 来源： 《MacTalk 跨越
阅读全文
摘要：Api 设计 代码目录组织原则和规范 配置文件如何存放(local/qa/prd) 异常处理 缓存设计与使用 需求设计和分析 单元测试 日志存储和查看 消息队列进行解耦 监控 分支如何维护 多套测试环境如何搭建
阅读全文
摘要：需求分析： 使用业务语言将功能场景写到文档上，然后画出相应的流程图和交互图，然后和产品check一些需求理解是否正确，没有理解清楚的地方，问清楚。 存储设计 根据第一步分析出来需要存储的数据及使用场景，设计MySQL表结构以及根据对应的SQL查询语言，设计表结构需要的索引信息，如果需要缓存信息，规划
阅读全文
摘要：越来越觉得工程师不仅仅是写代码实现需求这么简单，真正写代码的时间应该在30%～50%左右的时间。其余的需要进行需求分析、需求check、逻辑设计、代码设计、Design Review、Coding、单元测试、Code Review、代码测试用例自测、代码上线CI,CD、线上监控报警、日志处理、线上问
阅读全文
摘要：开发流程 这篇文章记录一些我对Design Review 的一些思考，下面是我当下对开发流程的理解： 开发流程： 收到需求 需求分析 设计分析 项目排期 项目开发 测试环境测试 线上回归测试 上线观察 问题修复和优化 需求结束，代码下线 Design Review 根据需求我们需要给出实现方案，如D
阅读全文
摘要：跳出岗位之分，共同解决问题 产品经理和工程师之间难免会有意见不一致的地方，产品经理是从业务角度，从商业价值去分析和看待问题的，而工程师是从实现角度，从代码、工程、后期维护等角度看待问题的。二者之间其实并没有很大的矛盾之分，二者之间应该是共赢的关系，他们都是想要解决公司业务的难点，痛点。既然目标一致，
阅读全文
摘要：了解清楚项目的上下游 预估量级，对可能发生的事情有所预估，才能做好准备 跑脚本的时候没有预估脚本运行的时间，然后也没有使用多进程的方式，所以不知道脚本大概执行的时间，这种是一个懒惰的行为和不负责任的做法。
阅读全文
摘要：项目开发周期安排 前期 如果开放和负责的是一个新项目的话，前期一定要紧凑一点，要多付出一点时间，因为很多前期没有梳理清楚的东西都在这一部分需要梳理和整理，所以这一部分会比预估的时间要长，所以这一部分周期要稍微紧张一点，不让后面项目有可能会出现延期的风险。 中期 维护和优化，找出可以进行优化和迭代的地
阅读全文
摘要：项目排期 = 个人任务完成 + 风险预估 + 意外情况 + 项目上下游依赖 个人任务完成 个人任务具体话 不要考虑私人情感，专注工作 风险预估 对可能出现的情况进行考虑 意外情况 对出现的意外情况提前准备和处理 项目上下游依赖 不要仅仅考虑自己的时间，还要考虑中间数据接口需要调整的时间 合理排期 一
阅读全文
