可以发现确实搜到了很多函数，代码不多，最好的方法就是把代码全部看一下，再注释下，流程就基本清楚了，不然也没其他方法了。 把目录里的的.git .gitee删除后，然后上传到了gitee，零散地地做了一些注释： 
发现代码虽然不多，但是这么没有方向的注释还是很难进行下去，所以注释了会，想到markdown文档里有个coap的截图，里面有关键字，可以用来定位下： 
但是discovery_service.c里没搜到json_payload.h里声明的两个函数，奇怪，你没调用，为什么还include个json_payload.h ？ 先注释下下函数 discovery_service.c: PublishService()，因为看这个函数名显然是发布服务的意思，不过第一步不是发布服务而是发起 发现请求，所以应该在discovery_service.c里面搜索 discover，不过没找到含discovery的函数名（后面可以看出，其实discover功能命令确实是从这个源文件发出的，只不过是其他函数内部调用的）： 
因为那个协议截图里的内容其实肯定用到了 json_payload.c 里函数，所以如果要搜代码的话，这是一个突破口，所以这边是从 json_payload.h 里的一个函数 ParseServiceDiscover() 出发: 
从 Clean Code 角度谈鸿蒙代码 - 仓库篇 | 解读鸿蒙源码
在鸿蒙发展初期就提 Clean Code，可能很多读者会觉得现在还不到时候，能用起来再谈优化成为很多人挂在嘴边的一句话。实际上这个问题很简单，Clean Code 是木桶其中的一块板，需要让它跟其它木板平衡起来，既不需要过度追求比其它木板长很多，也不能放任不管让它漏水。目前来说还没有精力对 134 个仓库一一分析，只能就我看到的范围内逐步深入，先写一篇权作引子，同时也是抛砖引玉希望能引出大神来一起讨论。 首先，整体而言，134 个仓库在命名上相当的规范，小写加下划线分隔几乎贯彻了全部仓库。其中有少数例外是保持了第三方软件的本来拼写，例如 third_party_FreeBSD、third_party_NuttX 等等。但是在这里其实没有必要保留第三方的大小写，统一成全小写更整齐也更容易遵从，毕竟浏览一遍仓库之后会发现比如 third_party_unity(Unity)、third_party_freetype(FreeType) 等等没有遵循原第三方软件拼写的库，两种情况实际上差不多各占一半，还是略有混乱。当然这点不是特别重要，只是一点小问题。 然后，在仓库命名方面还是能够发现另外一...
