B站的代码质量整体上还是相当不错的。无论是目录的布局还是业务代码的风格，都有不少值得称赞的地方。这显示了B站在技术建设方面的实力。比如，在众多技术公司还在为技术选择和建设苦恼时，B站能够基于开源项目进行优化。而且，技术总监毛剑的技艺颇高，他还公开分享了Go微服务实战的经验，这对业界同仁具有一定的参考价值。这不仅展示了B站的技术实力，也促进了行业的交流。
在现实情况里，对众多中小型企业来说，B站的这种技术构建堪称典范，值得借鉴。许多初创公司对于技术架构的挑选和技术建设感到迷茫，观察B站的做法，或许能找到一些灵感。
B站进行了从PHP、Java到Go微服务的技术转型，这一过程颇具观察价值。在这一转型中，涉及了微服务的演进和中间件的建设。比如，admin服务和job服务各司其职，从服务功能的划分上，我们可以看出其架构的合理性。对于其他正在经历技术转型的公司来说，这可以作为一个参考的案例。
观察B站的微服务架构，每个服务都担负着特定的职能。这就像工厂里，每个车间都有其专门的职责，只有如此，整个工厂才能高效运作。在我国，许多企业正处于技术转型的关键时期，它们都面临着如何从旧的技术体系顺利过渡到新的技术体系的挑战。
B站运用了集中仓库模式来管理Go语言的代码。这样的做法使得新手能够迅速掌握，一旦下载即能获得编写代码的指引。对于新加入的程序员来说，这能让他们迅速进入项目，开始工作。但这种方法也存在不少弊端。随着时间的流逝，版本控制可能会变得杂乱无章，同时，分支开发的压力也会随之增大。
在我之前任职的公司里，曾遇到过相似问题。那时，我们把众多服务集中在一个仓库中，这使得查阅git日志变得异常艰难。不久后，项目代码的管理便岌岌可危，这一状况充分暴露了这种代码仓库管理方法的不足。
B站的代码结构层次分明。model层、dao层以及http层等各司其职。这种结构类似于Java的开发方式，在服务需要调整时，可以迅速定位到特定层次进行修改。此外，当服务接口数量增加，例如从单一接口增至十个接口，其架构依旧保持清晰。同时，这种设计有助于目录的规范化以及服务的维护，便于新成员上手。
然而，这种分类方式对某些开发者不太适宜。许多开发者对这种繁杂的文件夹布局持反对态度，他们更愿意将所有内容集中存放。这实际上反映了开发者个人习惯与规范要求之间的冲突。
cmd: 放main.go和配置文件, 作为启动入口
conf: 放配置文件对应的golang struct, 使用的是toml
model: 放结构体, 比如Http参数转换用的struct, DB存储对应的struct, 各层之间传递用的struct
dao: data access object, 数据库访问方法, redis, memcache访问方法, 还有一些RPC调用也放在这里面
http: 提供http服务, 主要是提供协议转换, 聚合. 逻辑还是再service层做.
service: 对于后端服务来说, 该目录提供服务的实现, 对于http服务, 该目录提供http服务的实现.
实现目录规范不易，仅靠口头教导或硬性规定让程序员遵守实属困难。毕竟，人们都有图省事的本能。因此，拥有能够自动生成代码目录和模式的工具变得尤为关键。在B站，其超过300个服务目录之所以统一，正是得益于这些生成工具。这确实是一种高明的做法。
新加入项目的程序员可能不太注重规范，只图完成业务代码。然而，若采用这种生成工具编写代码，便能自然地遵循规范。这种做法在众多其他项目中同样适用。
B站的代码管理及架构布局给其他企业提供了不少借鉴。在技术选择、代码库维护、层级规划和目录规范实施等方面，其他企业能学习其成功做法，同时也能规避其曾犯的错误。对于一家刚开始发展且技术实力尚显薄弱的企业，又该如何作出明智的决策？
看完这篇文章，希望大家能在评论区交流各自在类似技术建设方面的经历和观点。同时，也欢迎点赞并转发这篇文章。
