Code Quality - kitlau's blog

10

AUG

借 Moq 事件谈一谈单元测试的重要性

近期.NET社区因Moq库的隐私争议引发激烈讨论其最新版本通过扫描本地git配置向Azure服务发送用户邮件地址以识别Sponsor身份这一行为在国内外产生截然不同的反响国内开发者群体对此事件关注度极低与国外社区形成鲜明对比这种反差背后暴露出国内软件开发领域长期存在的单元测试认知鸿沟作者通过代码示例揭示了Moq作为单元测试Mock工具的核心价值——通过模拟依赖接口实现代码逻辑的精准验证而非对真实数据库的直接操作单元测试的本质在于构建可信赖的代码基石它能显著提升代码质量降低维护成本并形成良性开发循环然而现实中不写单元测试的恶性循环却在持续恶化代码可维护性项目健康度和新需求开发效率都因缺乏测试保障而遭受重创当时间压力迫使开发者跳过测试时技术债务不断累积导致重构风险攀升最终陷入"开发耗时增加→交付延迟→开发加速→测试缺失"的死循环这种现状在中小型开发团队中尤为普遍开发者在缺乏测试实践的环境中逐渐丧失对代码质量的把控能力文章最后抛出值得深思的命题：为何国内开发者对单元测试的价值认知与国外存在代际差距？当技术社区对核心工具的争议反应出现断层时我们是否正在错失构建软件质量基础的关键机会？--Qwen3

18

JUL

C# required：跟 string 的空引用异常说再见

C# 11 的 required 关键字为开发者提供了一个优雅的解决方案来规避字符串类型的空引用异常问题。文章通过一个典型的数据库映射场景展示了传统开发模式中的痛点——当开发者将数据库字段设计为可为 null 但代码模型声明为 string 类型时，既可能触发编译器警告又可能在运行时引发 NullReferenceException。这种矛盾在 C# 11 之前需要开发者使用 null! 断言或者修改数据库约束来强行消除警告，但本质上只是将问题从开发阶段转移到生产环境。required 关键字的出现打破了这种妥协，它强制要求属性必须在初始化时赋值，从而在代码层面建立了不可变的约束。这种设计不仅消除了 null 值的可能性，更将数据完整性验证提前到了对象构造阶段。文章更深层的讨论触及了软件开发领域的核心矛盾——在压缩工时与代码质量之间的博弈。当团队过度追求上线速度而忽视基础架构设计时，开发者被迫在代码中埋下隐患。required 关键字的出现恰恰揭示了一个值得深思的问题：当技术手段可以解决某个具体问题时，为何仍有大量项目选择在管理层面制造更多技术债务？文章通过对比外包模式与产品开发模式的异同，抛出了一个尖锐的质疑：在绩效考核体系驱动下，开发者是否正在沦为写代码的"码工"而非架构设计者？当单元测试被当作"不创造价值的累赘"时，我们究竟在用什么样的开发成本换取"快速上线"的光环？这些看似与技术无关的管理问题，或许才是导致空引用异常这类基础错误反复出现的根本原因。--Qwen3

C# Code Quality required keyword Nullables Engineering Practices Software Product Management

10

MAR

谁是你的菜？IEnumerable、IQueryable 和 ICollection 选择指南

这篇博客深入探讨了C#中IEnumerable IQueryable和ICollection等集合接口的使用场景与潜在陷阱通过实际代码示例揭示了IEnumerable的延迟执行特性可能导致的多次迭代问题例如当Task集合被重复遍历时引发的代码行为异常作者进一步比较了三种接口的核心差异IEnumerable强调遍历灵活性IQueryable专为数据库等数据源的高效查询设计而ICollection则提供元素增删操作但核心建议远不止于此文章指出在方法返回值设计中应避免直接返回IQueryable以防止抽象泄露导致调用方过度依赖底层数据源实现细节同时推荐使用IReadOnlyCollection等不可变集合类型作为返回值既保证集合安全性又提供Count属性等实用功能此外博客还强调了延迟执行的双刃剑效应当使用IEnumerable作为返回值时需警惕数据源生命周期与遍历时机的耦合问题通过将IQueryable限制在Repository层内部使用并最终转换为IEnumerable可实现更好的封装性文章最后抛出值得深思的问题如何在不可变集合与集合可变性之间找到平衡如何设计既能满足功能需求又避免潜在陷阱的集合返回策略当面对大量数据处理时如何在内存操作与数据库查询之间做出最优选择这些思考将引导开发者重新审视集合类型的选择逻辑并建立更稳健的代码设计模式--Qwen3

.NET C# Code Quality IEnumerator IQueryable Lazy Evaluation