Skip to main content

Dev FAQ

  • Optimize
    • PGO - Profile Guided Optimization
      • GCC, Clang, MSVC, Golang
    • LTO - Link Time Optimization
      • 使得 Link 能全局优化而非局限于单个模块
    • AutoFDO - Auto Feedback Directed Optimization
      • by Google
      • 通过运行时采集数据，优化编译
    • ThinLTO - Thin Link Time Optimization
      • 一种 LTO 的变种，用更少的内存和时间
    • BOLT - Binary Optimization and Layout Tool
      • by Facebook/Meta
      • GCC, LLVM
      • 一种 PLO 技术
      • 重新布局代码块，减少分支预测错误，提高 CPU 缓存命中率
    • PLO - Post Link Optimization
    • XRay - XRay Instrumentation
      • LLVM 的性能分析工具
    • Intel VTune Profiler
    • Binary Instrumentation
      • Pin
      • DynamoRIO
      • Valgrind
  • Research -> POC -> Integration -> Functionality -> Service -> Product
    • Research - 是否能解决问题？ - 理论可行性
    • POC - 是否能解决我的问题？ - 初步实践验证
    • Integration - 是否能解决团队的问题？ - 整合
    • Functionality/MVP - 提供一个可靠的解决方案 - 完善功能实现
    • Service - 将解决方案变成可用服务 - 对用户或客户可直接使用
    • Product - 将服务产品化或商业化 - 面向市场和用户的成品
  • 研究，投入资金产出技术。创新，投入技术产出资金。
    • Research - “研究”是用钱换技术，是投入成本、积累知识的阶段
    • Innovation - “创新”是用技术换钱，是将技术付诸实践，创造经济价值的阶段
  • 研发划分
    • Fundamental - 基础
    • Domain - 领域
    • Application - 应用
    • Service - 服务
    • Product - 产品
    • Operation - 运营
    • Optimization - 优化
    • Monetization - 价值变现
    • Management - 管理
  • 专注于价值交付
    • 定义“价值”
      • 客户
      • 内部
      • 个人
    • 理解核心需求
      • 结果导向
      • 体验导向
      • 目标驱动
      • 客户优先
    • 减少非核心工作
    • 优化交付流程
    • 聚焦高价值任务
    • 打造客户价值感知
    • 解放精力，聚焦资源
  • 2/8原则
    • MVP
    • 避免过度设计
  • 参考

常见命名格式​

casedemofor
SNAKE_CASE,UPPER_SNAKE_CASEMY_CONSTANT_VALUE常量值、宏定义
camelCasemyVariableName变量名、函数名
PascalCaseMyClassName类名、构造函数名
kebab-case,dash-casemy-variable-name文件名、URL 路径
Title CaseTitle Case Example标题、文章标题
lower_snake_casemy_variable_name文件名、数据库列名
Train-CaseTrain-CaseAPI 名称、某些特定语言的类名
dot.casemy.variable.name配置项、文件路径
Sentence caseSentence case example标题、段落开头
path/casepath/case/example文件路径、URL 路径
PascalCase\PascalCaseGrpc\BaseStubPHP namespace
UPPERCASEUPPERCASE缩写、某些特定语言的常量
lowercaselowercase某些特定文件名或变量名
namespace:identifiersystem:admin命名空间、标识符、OIDC Scope
com.case.lowerme.wener.codeReverse Domain Name, namespace
  • golang 里特殊的名词会做大写

keycode​

Roles​

  • 管理岗
  • 专业岗
rolefor
项目经理项目管理
运营价值变现
产品经理交付价值
开发满足需求
测试质量
运维稳定
安全安全
  • 需求分析
    • 角色 -> 用例 -> 功能 -> 任务

中式管理​

  • 中式管理
    • 管人 - 人情
    • 管事 - 美式管理、流程制度化
  • 美式管理 - 契约
  • 日式管理

为什么枚举 名字 要用中文？​

tip

推荐 支持中文的语言 且 业务性强的场景 尽量用中文定义枚举名字。

  • 支持的语言: Java, C#
  • 不支持的语言: Golang
  • 通用的，公共的可以用英文
  • 业务域的含义往往很专业
  • 为了方便阅读
    • 代码是给人读的
    • 是可以加注释，但是多一个步骤，打断阅读逻辑
  • 不存在编码问题 - UTF8 编码都支持
  • 没多少人能读对
    • 过代码的时候就尴尬了 😅
  • 没多少人能写对英文
    • 可能产生莫名其妙的英文
    • 放弃写英文后会直接写“拼音”
  • 没多少人能理解英文
    • Pending ？ ChinaResidentIdentityCard？
    • gender ? sex ?

为什么枚举 值 要用英文？​

tip

推荐 业务场景 里尽量用 字符串/英文 作为枚举值

  • 推荐 PascalCase
    • vs. snake-case 可以直接作为名字
    • vs. camelCase 区别于变量
    • vs. UPPER_CASE 更好看，更好写
  • 数字没有含义 - 必然要找定义
  • 可能记错
  • 不一定写的准确，但别人能猜个大概

Framework vs. Library​

  • Framework
    • 框架 - 蓝图 - 结构 - 按照给定的方式达成目标
    • 不易替换 - 替换等于是新的结构
      • React -> Angular
    • 写代码 被 调用
  • Library
    • 库 - 工具 - 辅助辅助完成目标
    • 可替代
      • React -> Preact
    • 写代码 去 调用

Framework vs. Business Logic​

FrameworkBusiness Logic
提供骨架、流程实现接口、契约
核心流程的调度和装配被调用，注入具体实现
运行容器特定需求定制开发
通用流程个性化实现
负责谁调用谁负责怎么调用
可重用的模版和工具接口规范的具体实现
  • functionality - 功能
  • Business Logic - 业务逻辑
  • Application logic - 应用层逻辑
  • Domain logic - 领域层逻辑
  1. 不要过早锁定框架,保持开放和可替换性。使用适配器、接口等方式解耦。
  2. 与利益相关方充分讨论,了解真实业务需求。不要为框架增加非必要的复杂性。
  3. 先实现核心业务流程的简单可行版本,然后再逐步完善。不要一开始就追求架构完美。
  4. 采用增量引入新技术的策略,先保证核心业务,再扩展架构。
  5. 做好框架和业务逻辑的负责划分,各司其职,但要加强沟通协作。
  6. 不断优化和重构代码,保证业务需求变更可以轻松适配。
  7. 更多考虑业务价值,而非技术本身。业务获益才是成功的关键。
  8. 避免流于“敏捷 Architecture astronauts”,保持与业务的密切联系。
  9. 业务范围清晰后,再构建匹配的架构。

Agile Architecture astronauts​

  1. 过于狂热追求完美架构的倾向。
  2. 偏重技术本身,而非业务需求。
  3. 设计非常复杂和“完美”的架构,但实际不可用。
  4. 自说自话,没有与团队真正合作。
  5. 做出太多不必要的假设。
  6. 一味追求新技术,不考虑学习成本。
  7. 架构只存在白皮书,没有落地。
  8. 缺少快速迭代和用户反馈。
  9. 更看重架构的“完美程度”,而非实际价值。
  10. 像“宇航员”那样与实际业务脱节。

build your system out of small tools, that do only one thing well, and that communicate through a standard protocol. Systems built that way can be re-written one piece at a time.

Private Cloud vs. On-Premise​

  • Private Cloud
    • 基础设施
    • 强调物理设施本地化
  • On-Premise
    • 服务、软件
    • 强调服务功能本地化
    • 公有云上也可以 On-Premise

health vs. healthz​

  • 类似的 readyz, varz, statusz, rpcz, livez
  • 来自于谷歌内部实践 - z-pages
  • z 是为了避免和现有 endpoint 冲突
  • 大多用带 z 的名字，系统常用，类似 /metrics，与业务无关
  • 参考
  • 其他
    • /health/live
    • /health/ready
  • /ready, /readyz
    • 是否准备好接受请求
  • /livez, /live
    • alive/up and running
  • /health, /ping
    • 通用的健康检查
  • /statusz
    • 服务状态信息
  • /varz
    • 内部变量和 metrics
  • /rpcz
    • 一般是 RPC 统计

什么是边缘计算​

个人简单理解，Edge 就是 DataCenter 的反义词。

  • 早期计算：集中式应用程序，仅在一台孤立的计算机上运行
  • 个人计算：本地运行的去中心化应用程序
  • 云计算：在数据中心运行的集中式应用程序
  • 边缘计算：在靠近用户的地方——设备本身或者网络边缘——运行的集中式应用程序

什么是无服务​

  1. 云计算执行模型，云提供商动态管理分配和提供计算资源。
  2. 允许开发者专注于代码，而无需管理服务器。

例如

  • PaSS -> 提供 Redis 管理
  • Serverless -> 提供集成了 Redis 的环境，直接使用 SDK/API 进行调用

API URL​

Orchestration vs Choreography​

  • Orchestration
    • 编排 - 可同步、可异步
    • 可总览服务流程
    • 中心服务可能会重、复杂
    • temporal 这样的服务让异步复杂编排变得简单
  • Choreography
    • 事件总线 - 异步
    • 相对更解偶
    • 失去业务全局观

开发缓存​

clidirmacOSforclean
mvn~/.m2/repository/Maven
npm~/.npm/NPM
zig~/.cache/zig/
~/.cache/prisma/
buf~/.cache/buf/
~/.cache/huggingface
~/.cache/puppeteer
~/go/pkg/modgo env GOMODCACHE
~/.cache/go-build~/Library/Caches/go-build/go env GOCACHEgo clean --cache
~/Library/Caches/Homebrewbrew --cache
pnpm~/.pnpm-store~/Library/Caches/pnpm
yarn~/Library/Caches/Yarn
~/Library/Caches/typescript
pip~/.cache/pip~/Library/Caches/pip
  • ~/Library/Caches/JetBrains
  • ~/Library/Caches/electron
  • ~/Library/Caches/esbuild
  • ~/Library/Caches/golangci-lint
  • ~/Library/Caches/hardhat-nodejs
  • ~/Library/Caches/helm
  • ~/Library/Caches/turbo
ls -d \
  ~/.cache/* ~/.m2 ~/.npm \
  ~/go/pkg/mod \
  ~/Library/Caches/{JetBrains,electron,go-build,esbuild,golangci-lint,hardhat-nodejs,helm,turbo,Yarn,pnpm,Homebrew} 2> /dev/null \
  | xargs du -sh | sort -h
# Maven
mvn dependency:purge-local-repository -DactTransitively=false -DreResolve=false --fail-at-end

# Maven Dir
mvn help:evaluate -Dexpression=settings.localRepository -q -DforceStdout

缓存清理​

brew cleanup
go clean -modcache

mvn dependency:purge-local-repository -DactTransitively=false -DreResolve=false --fail-at-end
gradle clean

ls ~/.nvm/versions/node/v{12,14,16}* -d 2> /dev/null | xargs -n1 basename
# for s in $(  ls ~/.nvm/versions/node/v{12,14,16}* -d 2>/dev/null | xargs -n1 basename );do echo nvm uninstall $s; done
rm -rf ~/.nvm/versions/node/v{12,14,16}*

nvm cache clear
yarn cache clean
npm cache clean --force
pnpm store prune

pip cache purge

How to ask​

127.0.0.1 vs localhost​

尽量使用 127.0.0.1

CRLF​

  • 换行符 - new line - ␤ - line ending, end of line (EOL), next line (NEL), line break
    • ⏎ - enter 符号
  • carriage return (CR) - ␍ - \r
    • 以前的 Mac OS
  • line feed (LF) - ␊ - \n
    • unix, macOS
  • crlf - \r\n
    • Windows
    • HTTP 头部的换行符

新手常见问题​

  1. 未掌握 std 库
  2. 未掌握 core 库
  3. 不考虑扩展性
  4. 技术名词拼写不规范
  5. 提交不规范
  6. 书写时中英文混排不规范
  7. 写复杂冗长的函数
  8. 不会写文档
  9. 不看官方文档，只看垃圾博客
  10. 宣扬内功无用论
  11. 乐于炫技
  12. 不接受质疑
  13. 接口协议不规范
  14. 遇到问题自己死磕
  15. 一说就会，一写就废
  16. 表达没有逻辑，不站在对方角度看问题
  17. 不主动思考，伸手党
  18. 经常犯重复的错误
  19. 接口不自测，出问题不打日志
  20. 直接写代码
  21. 重要设计不写文档

Magic Number​

  • 1048576
    • Excel 行限制
  • 16384
    • Excel 列限制

关于 K8S 服务重启导致服务中断问题的说明​

  • 部署使用 startProbe 等到 health 才切换，避免新版本出现问题导致服务启动失败，旧版本服务下线问题
  • Java 通常较慢，启动可能 1m 左右

问题

  1. 用到了 nacos 导致服务注册更新延迟
  • 新版本服务启动后会重新注册到 nacos，旧版本服务下线
  • 客户端不一定来得及更新 - 因此下线后可能出现还未更新的客户端部分异常
  1. 现在 cloud native 一般基于 service/dns 访问，这种问题不会出现

解决办法

  1. 部署多副本，避免单点问题，使用滚动升级
  2. 延长启动时间，避免服务注册更新延迟
  3. 使用 sts，确保相同的 hostname - 不确定注册逻辑，是否能避免中断问题 - 使用 sts 至少 2 副本
  4. 减少发布频度
  5. 配置自动更新窗口避免热点时间自动更新

API & 合约 & 协同​

当我们把 API 比作合约时，意味着它为开发者定义了一系列规则、约定和协议，这些规则描述了如何访问和使用这些功能。遵循这些规则可以确保软件组件之间的顺畅交互。API 合约包括以下几个方面：

  1. 数据格式：API 规定了开发者应该如何向其发送数据（如 JSON、XML 等）以及如何接收返回的数据。
  2. 资源和操作：API 提供了一组可用的资源（如数据对象、功能等）以及可以对这些资源执行的操作（如创建、查询、更新和删除等）。
  3. 调用约定：API 定义了如何构建请求（如 HTTP 请求方法、URL 结构等）以及接收和处理响应（如状态代码、响应头等）。

遵守 API "合约"的好处包括：

  1. 易于集成：开发者只需遵循约定，即可轻松地将软件组件集成到自己的项目中。
  2. 可重用性：遵循 API 合约的代码在多个项目中都可以重复使用，提高了开发效率。
  3. 可扩展性：API 可以独立于底层实现进行版本控制和演进，从而确保系统的可扩展性和长期稳定性。

因此，API 被称为合约，主要是因为它为开发者提供了一种标准化、可靠的方式来互动和访问其他软件组件的功能。

合约和协同是两个相关但不同的概念。合约通常是指一种约定，规定了各方如何进行交互，从而实现共同目标。协同则是指多个实体（如人、团队、组织或系统）共同努力以实现共同目标的过程。

合约和协同之间的关系：

  1. 合约作为基础：合约为协同创造了条件，确保各方遵循相同的规则和约定，以便更高效地协同工作。例如，在软件开发中，API 合约规定了如何访问和使用特定功能，使得不同软件组件可以无缝地协同工作。
  2. 协同促进合约执行：在实际应用中，协同可以帮助各方更好地理解和执行合约。当各方共同努力实现目标时，合约可以确保双方以一种可预测和可靠的方式互动，从而促进有效的协同。
  3. 互相调整和改进：在实际协同过程中，可能会发现合约中的某些规定不适用或需要调整。这种情况下，各方可以通过沟通和协商来修改合约，以满足实际需求。同样，成功的协同也可能导致新的合约产生，以满足不断发展的需求。

综上所述，合约和协同之间存在密切关系。合约为协同提供了基础和规则，协同则依赖于合约来实现各方之间的有效合作。在实际应用中，合约和协同需要不断调整和改进，以适应不断变化的需求。

北向接口​

  • Northbound API
  • 服务组件对外提供的 API 接口
  • 对外暴露的 API
  • 抽象和封装内部逻辑
  • 服务组合和编排
  • 实现多渠道服务
  • 保证系统安全

Data is code, code is data​

  • code is data
    • Relfectin
    • Enum
    • Annotation
    • AOP
    • Model - ORM
    • Meta Programming
    • Macro
    • 生成器
    • DSL
  • data is code
    • Code=Engine, Data=Fuel
    • Data 定义了逻辑规则 = Code

schema vs validator​

  • Schema-First - 模式优先
    • 数据类型定义
    • 通常和类型能一一对应
    • 可以用来做验证，还可以用来生成代码
    • e.g. typebox, typia, jsonschema, ajv
  • Validate-First - 验证优先
    • 业务逻辑定义
    • 通常包含额外的处理逻辑 - 功能更多，能自定义处理
    • 通常能生成 Schema - 但是会丢失一些信息且不一定准确
    • e.g. zod

monorepo​

链接超时​

  • 云平台会主动切断 idle 的链接，这个和局域网的链接不同 - 云平台 nat 资源
  • 应用需要主动 ping/keepalive 保持链接，否则从链接池里拿出来链接可能已经 timeout
  • 操作系统层面可以配置 tcp keepalive 进行保活
  • 大多链接池都支持
    • IdleTimeout
      • 建议小于 10 分钟
      • idle 时长，如果配置的比 平台/系统 层 idle 短，也能避免取到无效链接的问题
    • TestOnBorrow - 有一定性能影响
    • TestOnReturn
    • TestWhileIdle - 影响小，但会浪费一定链接数量
      • 需要慎重考虑配置的 idle 数量
  • 链接池
    • apache commons-pool GenericObjectPool
      • 支持 IdleTime, TestWhileIdle, TestOnCreate, TestOnBorrow, TestOnReturn
    • HikariCP HikariConfig
      • IdleTimeout, KeepaliveTime
      • KeepaliveTime 检测 idle 的周期

系统 TCP KeepAlive

  • tcp_keepalive_time
    • 上次数据包发送后，多久开始发送 keepalive
    • 开始发送 keepalive 后，该值不在重要
    • TCP_KEEPIDLE
  • tcp_keepalive_intvl
    • 发送 keepalive 的间隔
    • TCP_KEEPINTVL
  • tcp_keepalive_probes
    • 多少次 unack 后认为链接已经断开，通知应用层
    • TCP_KEEPCNT
# Linux
# 默认 7200，75，9
# 2小时, 75s, 9次
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes

# 1分钟, 1分钟, 5次
sysctl -w \
  net.ipv4.tcp_keepalive_time=60 \
  net.ipv4.tcp_keepalive_intvl=60 \
  net.ipv4.tcp_keepalive_probes=5

cat << EOF | sudo tee /etc/sysctl.d/99-tcp_keepalive.conf
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 5
EOF
sudo sysctl -p /etc/sysctl.d/99-tcp_keepalive.conf

# macOS
sysctl net.inet.tcp.always_keepalive net.inet.tcp.keepidle net.inet.tcp.keepinit net.inet.tcp.keepintvl

重构的价值​

  1. 提高 可维护性
  2. 提高 质量
  3. 提高 开发效率
  4. 提高 系统的灵活性和可扩展性
  5. 技术债务管理
  6. 提高 系统性能
  7. 提高 团队士气
  8. 改善 系统安全性

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

任何傻瓜都能写出计算机能理解的代码，而优秀的程序员会写出人类能理解的代码

-- Martin Fowler

技术债务​

技术债务（Technical Debt）

  • 类型
    • 设计
    • 代码
    • 测试
    • 文档
    • 流程
  • 成因
    • 时间
    • 不充分的设计
    • 技能不足
    • 不良的开发习惯
    • 业务需求变化
  • 影响
    • 维护成本
    • 系统稳定性
    • 开发效率
    • 团队士气
  • 管理
    • 识别评估
    • 制定计划
    • 优先级排序
    • 重构优化
    • 改进流程

endian​

endian, endianness, byte-order

  • 端序 / 字节序
  • big / big-endian / bigEndian / BE / 大端序
    • 反序
    • network byte order
    • 网络通信、文件格式
      • 因此大多时候操作数据都是大端序
    • RISC, IBM PowerPC, Solaris, SPARC
    • 0x12345678 -> 0x12 0x34 0x56 0x78
  • little / little-endian / littleEndian / LE
    • 处理器, 内存, 计算
      • 因此大多时候实现模拟器、虚拟机都是小端序
    • Intel x86, x86-64
    • Windows
    • 和内存地址对齐
    • 0x12345678 -> 0x78 0x56 0x34 0x12
# Byte Order: Little Endian
lscpu | grep Endian

# 0 for Big Endian, 1 for Little Endian
echo -n I | od -to2 | head -n1 | cut -f2 -d" " | cut -c6

Design vs. Architecture​

  • Design - 设计
    • 侧重细节和实现
    • UX/UI 设计、API 设计、数据库设计
  • Architecture - 架构
    • 偏向整体结构和系统层次的设计决
    • 整个系统的 结构 和 组件之间的 交互方式
    • 设计决策
      • 选择技术、组件、模块、库、框架
      • 可扩展性、容错性
      • 微服务架构、分布式、RPC
    • 设计原则 - SOLID, DRY, KISS, YAGNI

如何判断是否过度设计？​

分辨「需要」和「可能需要」之间的界限，并权衡当前与未来的复杂性成本。

  • 是否解决了当前明确的核心需求？
  • 是否在为未来的“可能性”做设计？
  • 是否为少数特殊情况增加了复杂度？
  • 是否增加了维护成本？
  • 好的设计能减少维护和控制复杂度
  • 优先解决当前问题
  • 设计可演进的系统
  • 使用 MVP 原则
  • 定义一个“YAGNI”边界 - You Aren’t Gonna Need It
    • 明确列出「不需要」的内容，避免“顺手实现”。
  • 以成本和收益为衡量标准
    • ROI

Theory vs Pattern vs Best Practice​

  • Theory - 理论
    • 抽象、普适，通常具有一定的数学或逻辑基础。
    • 目的: 描述和解释现象，提供抽象框架
    • 抽象程度: 更加抽象和通用
    • 来源: 学术研究、逻辑推导
    • 应用范围: 适用于广泛领域和各种问题
    • 形式: 数学模型、定理、定义
    • 示例: CAP 定理、类型系统、计算复杂性理论
  • Pattern - 模式
    • 结构化、可复用、问题解决导向
    • 目的: 提供可复用的实际解决方案
    • 抽象程度: 更加具体，针对特定问题
    • 来源: 实践与理论结合，通常经过标准化描述
    • 应用范围: 适用于特定场景和上下文
    • 形式: 模板化描述，包括问题、上下文、解决方案
    • 示例: 单例模式、CQRS 模式、微服务架构
  • Best Practice - 最佳实践
    • 经验驱动、上下文敏感、目标导向
    • 定义: 实践中总结的建议或方法
    • 来源: 实践经验驱动
    • 结构化程度: 非结构化，通常是指导性建议
    • 适用场景: 针对某些场景的通用指导
    • 目标: 提供方法论以提高效率和质量
    • 示例: 使用环境变量管理配置
  • Best Practice 是 Pattern 的基础
    • Pattern 往往从实践中总结和提炼出来，是 Best Practice 的抽象和结构化表达。
  • Pattern 是 Best Practice 的补充
    • Best Practice 更偏向于“如何做”的指导，而 Pattern 提供了更细化和通用的模板。
  • Pattern 是结构化的解决方案，更倾向于模板化描述。
  • Best Practice 更注重经验和建议，可能缺乏明确的结构化定义。
  • Best Practice：当你需要快速了解某一领域的通用建议时。
  • Pattern：当你需要解决特定问题且希望复用解决方案时。
  • Pattern
    • 实现（Implementation）：将抽象的模式转化为具体的代码或模块。
    • 工具化（Tooling）：开发工具或库，简化模式的使用。
    • 工程化（Productization）：优化工具，形成产品，便于广泛使用。
    • 标准化（Standardization）：规范化，确保跨组织、跨系统的兼容性。
    • 应用化（Application）：结合实际需求，将模式转化为解决问题的业务价值。

程序员 vs 软件工程师​

  • Programmer - Coding
  • Engineer - Design

缩进​

  • Indent
    • 缩进 - 代码块的开始和结束
    • 代码的层级关系
    • 代码的可读性
    • 代码的可维护性
  • Space vs Tab
  • Space
    • 所有人看起来都一样
  • Tab
    • 能够自定义

Impedance Mismatch​

  • 阻抗失配
  • 计算机科学中，阻抗失配是指在不同系统或组件之间进行数据交换时，由于数据表示、格式或语义的差异，导致的兼容性问题。
  • 例如，关系型数据库和面向对象编程语言之间的阻抗失配，通常表现为对象模型和关系模型之间的差异。
  • 解决阻抗失配的方法包括使用 ORM（对象关系映射）工具、数据转换器或适配器等。
  • 阻抗失配通常会导致性能下降、数据一致性问题和开发复杂性增加。
  • CQRS: 命令查询责任分离 - 明确分离读写关注点
  • 在分层架构和DDD实践中频繁出现。
  • 原因
    • 设计范式不同
      • 面向对象 vs. 关系型数据
      • 命令式 vs. 声明式
      • 同步模型 vs. 异步模型
    • 关注点分离（Separation of Concerns）
    • 优化目标不同（Optimization Trade-offs）
      • 领域模型追求表达准确性，接口模型追求传输高效
    • 数据表达方式的差异（Representational Gap）
  • 缓解方法
    • Mapper 层 - DTO, PO, VO, Mapper, AutoMapper, MapStruct
      • 不同模型之间增加一层映射逻辑，专门负责适配与转换
    • ORM - 对象模型（继承、多态、关联）与关系模型（表、行、列、主外键）之间的差异。
      • 自动化对象与关系型数据库之间映射
    • CQRS - 将读写模型分离，针对不同关注点独立优化
      • Event Sourcing
        • 事件溯源 - 通过事件流重建状态，避免阻抗失配
    • Event-driven Architecture
      • 使用事件驱动解耦系统，减少紧密耦合导致的转换复杂度
      • Event Bus, Kafka
    • 微服务
      • 每个服务内部保持更小范围的一致性，服务之间通过明确接口通信
      • RESTful API, gRPC, GraphQL

对象关系映射

维度面向对象模型（OOP）关系型数据模型（RDB）失衡表现
数据表达对象（Object）、实体（Entity）、聚合（Aggregate）表、行、列（Table, Row, Column）表达方式不同，需额外转换
关联关系继承、组合、多态外键、关系规范化（Normalization）关联关系映射复杂
导航方式通过对象引用导航（引用、指针）SQL查询、外键、JOIN 操作导航模式差异，易造成 N+1 问题
状态管理对象生命周期（内存、GC）数据库事务、锁机制状态管理模型差异，复杂性提高

领域模型与 API 模型（DTO）

维度领域模型（Domain Model）API模型（DTO）失衡表现
关注点业务精确表达、封装业务规则数据传输高效、稳定、通用不同关注点致模型不兼容
变化频率频繁变化，随业务调整相对稳定，关注接口兼容性变化不同步导致转换层复杂化
数据结构层次复杂、对象关联紧密扁平化结构、简单易序列化结构差异致额外映射逻辑

后端业务逻辑与前端 UI 模型之间的

维度后端业务模型前端 UI 模型失衡表现
关注点业务逻辑正确性、一致性、事务性处理用户体验、交互流畅性、界面响应性后端模型难以直接用于前端交互
数据结构完整业务状态、领域对象前端状态、增量更新、响应式数据数据结构不同，需额外转换
更新方式事务性、整体性局部增量更新、异步响应更新策略不同导致额外适配逻辑

float​

  • ieee754
  • JS
    • Number.MIN_SAFE_INTEGER - (-(2^53 - 1))
    • Number.MAX_SAFE_INTEGER - (2^53 - 1)
    • 在安全整数范围内的 整数 操作没问题
    • 除法如果有小数还是有问题
    • 位运算一般没问题
    • 判断容差 Math.abs(a - b) < Number.EPSILON

Writing Code Was Never the Bottleneck​

  • LLM 编码质量通常很差，存在一些 微妙且新颖 的错误
  • 真正的工作在于思考和设计
  • “努力倒置”（Effort Inversion）现象与高级工程师角色的转变
    • 传统模式：初级开发者花费大量时间思考、编写和调试，然后提交。高级工程师进行审查，指出问题，双方进行有意义的讨论。
    • LLM 模式：实习生在几分钟内生成大量代码，但对这些代码的底层逻辑、边界情况和潜在缺陷几乎一无所知。代码审查不再是“讨论”，而变成了高级工程师单方面的“考古”和“修复”。
    • 效率假象： 表面上的代码产出速度飞快，但隐藏了巨大的技术债务和审查开销。
    • 指导失效：传统的“授人以渔”的指导模式难以维系。高级工程师变成了代码的“质检员”和“修理工”，而不是“导师”。
    • 团队负担：团队的整体效率和代码质量实际上可能在下降，因为最昂贵、最宝贵的资源（高级工程师的时间）被大量消耗在低质量的“擦屁股”工作上。
  • 重新定义软件开发的“瓶颈”
    • “上游”瓶颈：问题定义与系统设计
      • 需求的模糊性与复杂性
      • 架构的“杠杆效应”
    • “下游”瓶颈：质量保障与长期维护
      • “代码是负债”原则
      • 不可见的工作
      • 集成的复杂性
    • 软件工程的“冰山模型”
      • 代码编写只是浮在水面上的 10%，而水面下 90% 的工作 需求分析、架构设计、测试、集成、部署、维护 才是决定项目成败和成本的关键。
  • 对初级开发者技能成长的深远忧虑
    • 可能会成为“提示词工程师”（Prompt Engineers），而不是真正的“软件工程师”（Software Engineers）。
    • 缺乏第一性原理的思考
    • “知其然，不知其所以然”
    • 职业天花板
    • “必要难度”理论 (Desirable Difficulty)
  • 代码作为一种“负债”（Liability）
    • 代码并非越多越好。每一行代码都是需要被理解、测试、维护和保护的“负债”。
  • 不是快速地编写代码，而是智慧地构建系统。
  • LLM 是一个杠杆，而不是方向盘。
  • Writing Code Was Never the Bottleneck