我下载了大量的 golang 项目源码来阅读,发现了一个问题,为啥它们的目录结构很多都不对,比如:
在 golang 中,标准的结构是 internal/model 目录存放数据库表结构体,和数据表一一对应,或者同类模型放在一个文件,不放任何逻辑,不放 SQL,最多放一个表名函数,为啥现实是很多 golang 项目在 model 下放些乱七八糟的东西,比如初始化数据库连接?分页函数,创建/获取数据,更狠的是一个项目把全局通用的响应函数 Success 和 Fail 放在了 model 目录里边,这合理吗?
最近写了一篇关于 MCP: Easy Code Reader 的文章登上了掘金的周报,蛮不错的一次体验。这个 MCP 的灵感来自日常开发中 AI IDE 无法跨项目读取代码和在 Jar 包中无法读取代码的痛点,花了几个晚上就写好了初版,后来组内小范围分享后,根据大家的意见添加了能够根据链路进行分析的 Tool,这能够让大模型根据业务逻辑的调用链路分析逻辑,说实话第一次试用这个功能的时候真的把我震惊到了:在较为复杂的场景下也能根据冗长的调用链路画出与代码相符的流程图并告知其中的要点!这如果是让开发者一点点的在多个应用中扣代码进行梳理,准确性不一定能保证而且还要花费很多时间,AI 对开发者带来的改观未来一定会越来越大...
展开
评论
1
![[不失礼貌的微笑]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_16.9d17f6d.png)