最新

至少在过去半年里，我时常在思考软件工程的未来方向。关于我的业余项目，我现在使用Cursor/Claude Code来实现我的愿景（一个自2013年以来的数据库系统，作为在康斯坦茨大学项目的延续），进行我一直想做的大规模重构，但由于这将是一个耗时多年的重大工程，我一直没有动力去开始。如今，在人工智能代理的时代，这一切变得非常令人印象深刻，因为在很多情况下，确实存在非常重复的模式，此外还有一些我从未有时间（和技能？）自己解决的问题。当然，有时候测试没有意义，有时它们会出错（例如，宁愿删除测试或“简化”它们，而不是修复真正的生产代码问题……）。但另一方面，我在AI代理的帮助下构建了一个完整的前端（而我是一名后端工程师，一直以来都具备一些嵌入式软件工程的专业知识）。 话虽如此，每当我找到一些时间，我就能更高效地推进我的愿景（主要作为产品负责人兼架构师，而不是“手动”编写所有内容）。因此，我当然在想我们的工作在未来是否安全。我认为，你始终需要对代理进行严格指导，并在它们即将失控时立即制止，因此你必须具备高级软件工程师的技能；但另一方面，我相信小型高级工程师团队的效率可以比以往更高。因此，要么是未来你需要的软件工程师数量会减少，要么是你能够更快地交付产品，实施更多的创意，或者只是说新的创意可以比以前更高效地被探索——这意味着会有更多的小型初创公司？我真的不知道……

作者在此。之所以开发这个工具，是因为团队（包括我的团队）在CI/CD中不断与GCP认证作斗争。 谷歌为Firestore和Pub/Sub提供了模拟器，但没有为Secret Manager提供任何工具。我找到的唯一替代方案是一个基本的测试助手，只有18次提交，并且没有生产环境的关注。 这是一个生产级的实现，具有以下特点： • 100% API覆盖（11/12个方法 - IAM故意省略，因为本地测试中没有认证） • 双协议支持：原生gRPC + REST/HTTP • 与官方GCP SDK兼容 - 只需将指向localhost而不是googleapis.com • 所有变体的Docker镜像 • 90%以上的测试覆盖率 在安静发布的两个月内，有公司联系我，表示他们在生产CI/CD中使用该工具。我实现了他们的功能请求，并添加了完整的REST API支持。 最适合于： • 封闭测试（无网络调用，确定性） • 无需GCP凭证的CI/CD • 无云成本的本地开发 我使用grpc-gateway来保持与GCP官方REST端点的语义兼容性 - 路径相同，JSON格式相同。 欢迎就实现、用例或与其他方法的比较提出问题。 GitHub: [https://github.com/blackwell-systems/gcp-secret-manager-emulator](https://github.com/blackwell-systems/gcp-secret-manager-emulator)

在你的类中采用成员的实现，并在C#中拥抱委托、组合优于继承以及混入风格的编码。