2022.6.13-6.19
本周的工作内容，
周一安装环境，了解docker
周二了解docker，可以把docker的镜像跑起来
周三出现了巨大问题，程序一直没有弄明白，也没有问别人
周四还是在做周三做的事情，而且效率很底下
周五完成任务，得到了新的任务
总结和反思：
1.当自己有问题解决不了的，分析问题的原因，来自自己，还是来自别人，接下来，我解决这个问题，需要寻求别人的帮助，还是自己去找方法解决
2.下午后半段的工作效率不高，在中午的时候，以3:00区分，规划一下下午的3点前后的任务。
在3:00的时候应该对自己当前的工作状况进行反思，看一下现在自己状态好不好，设计一下接下来干什么
3.当自己程序看不懂的时候，很大情况下是自己知识点的欠缺，需要去补足，先把东西学会，再去做东西，效率会更高
4.应该一直做同一个工作，不要总是换来换去
需要加强的：
构建docker镜像的能力，只是会用docker命令，还是没有具体了解docker内部的情况
202.6.20-6.24
本周内容：
周一熟悉gorm,gRPC，看代码，还没有跑起来
周二得到需求，分析需求，搭调试环境，学postman
周三实现导出名字和身份证
周四读取图片，不会连接轨迹服务器
周五花了一天的时间连接轨迹服务器，终于连上了
不足的：
1.遇到业务上无法解决的问题，应该及时的提问
2.写业务的时候，可以先构思需要的函数的输入输出是什么，然后把每个子函数都写好，然后再去写内容（封装的思想）
3.对一个新语言的不熟悉，就是要手打代码段一点一点的多敲才能熟悉，不要总是粘贴
4.大佬写的代码总是能一气呵成，修改比较少，自己的代码就是需要反复的修改，所以特别慢，并且这次是新语言，新框架，而且要用数据库，所以写起来，试错的时间更加长了
5.总结一下：语法不熟悉、对业务的把控能力很弱、对代码的把控能力很弱（不知道要怎么开这些函数）
postman 的问题
如果实际的proto没有更新，但是自己在发送框里面写了内容，实际上是没有发出去的
思考和总结
- 思考一个问题，准备开发一个项目的时候，考虑的方式应该是”先大后小再大“
以档案导出为例来说明
- 先大——先从最大的角度考利，档案导出需要什么样的接口，导出的时候会会遇到什么样的问题，先确定最主要的三个接口，导出档案，查询进度，删除档案
但是也不用特别的大，要有范围，给一定的总体的布局时间 - 后小——真正开始写项目了，就需要落到细节处理，思考这个具体的功能应该如何实现，
- 全部写完以后，从头到尾开始审查，这个项目现在还有什么问题，需要怎么去解决
比如全都写完以后做错误处理
4）交给测试
参考文献
[mysql和sqlserver删除指定条数的数据记录，mysql delete limit和sqlserver delete top]https://blog.csdn.net/guangmo0123/article/details/109353553
[mysql 中数据表 DATA_LENGTH & INDEX_LENGTH]http://dbaselife.com/project-7/doc-1112/
[mySQL 数据类型]https://www.runoob.com/mysql/mysql-data-types.html
[Amazon S3]https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjects.html#API_ListObjects_RequestSyntax
[mysql 官方文档]https://www.mysqlzh.com/doc/65.html
[mysql 中 创建索引很慢，怎么解决]https://www.debugease.com/mysql/282296.html
[TIDB 的书]https://book.tidb.io/
[从一个简单的Delete删数据场景谈TiDB数据库开发规范的重要性]https://zhuanlan.zhihu.com/p/427227246