AgendaGo 实现分析
我的本地代码仓库
以上是本次的代码连接
大致结构
作为一个为了让大家熟悉go语言的一次课程作业,组队实现一个agenda程序还是比较科学的,可以比较有效地让大家在实现的过程中了解go语言的模块化和io和一些常用库的一些知识。
说回agenda,还是熟悉的配方,三层结构,底层提供最基本entity操作,中间层对于entity的操作进行访问控制和安全控制,最上层和ui交互提供服务。
涉及到的包因为这次实现的是命令行程序,所以用的cobra包,同时在实现的时候的同样也是套用了cobra的官方模板,然后在这个基础上再进行了对于功能的补充。
实现过程介绍
因为我们小组有4个人,怎么分配工作任务其实还是有点难度的,因为工作太少而人太多了。
这导致一开始的时候是按照最顶层的任务来分配的工作,这样做就导致每个人在写函数的时候都同时得要写底层的一些基础的函数,但是这样做的结果就是虽然是用git进行合作但是自己更新的结果并没有一直同步地传送上去,但是同样的底层代码被重复实现了很多次,虽然能用但是还是不够美观。
个人负责部分介绍
我个人是负责meeting的一些指令和storage类(序列化操作)和log代码的编写。
写起来还是很快的,毕竟在写的时候很欢脱不用考虑冲突啊什么的事。
而且这些东西也不是什么有意思的玩意。
不过还是踩了一些坑。
- 原来如果要跨包调用能调用的函数必须得是大写字母开头的,小写字母的函数只能在同一个包下调用,这是什么玩意规则,真的是有点过了,完全就是当今社会的封建主义。
接下来就主要介绍一下log是怎么做的吧。
为什么要log,log有什么用这个问题其实是很有学问的,因为一般在调试的时候大家都会选择直接在控制台输出来调试,谁也没那个心情把输出导出到其他文件再来打开来分析。
但是针对大多数情况来说确实直接打印出来是没错的,但是针对多进程(线程)的程序这就有问题了,因为如果同时进行多个任务,全部都输入到控制台往往输出的顺序会是错的。
这个时候你就会很失落,本来想着打印出来这玩意是能够减轻你自己的负担的,但是顺序错了这还玩啥。
如果你就是很执着想要用这个方式来debug,那你能做的就是只能通过mutex来加锁来保证进程的安全,这样得到的结果才可以算的上的是完全正确的没有差错的log。
但是如果你真的这么搞我不是不赞同,但是你多进程编写的难度可能直接就超过你本身再编写的程序了,而且你写的程序还很有可能是只能使用一次的东西,完全就是吃力不讨好,这种情况如果有别人写好的东西为什么不直接拿过来用呢。
所以这就是为什么我们需要使用log(功能或者说一种debug方式)的原因了,通过把能够反映相关程序操作输出到文件中,并且以一种进程安全的方式来实现这一点还是很爽的。
代码分析
package service
import (
"log"
//"os"
"io"
)
var (
logfile io.Writer
logger *log.Logger
)
func InitLogger(){
/*
filename := "agenda.log"
logfile,_ = os.OpenFile(filename, os.O_WRONLY|os.O_TRUNC|os.O_CREATE, 0666)
logger = log.New(logfile,"[Info]",log.Llongfile)
logger.Println("--start log--")
*/
}
func logln(message string){
logger.Println(message)
}
以上就是位于service包里面的log文件里面的代码
其中涉及到的主要的key函数就是
os.O_WRONLY|os.O_TRUNC|os.O_CREATE, 0666)
logger = log.New(logfile,"[Info]",log.Llongfile)
其中logfile的作用是生成一个io.Writer 然后作为之后的logger的参数传入,就可以把之后所有log产生的结果全部都导入到这一个文件之中。
再折后可以通过logger.Println()的方式把导出的结果全部都导入到新的文件之中。同样的由于是调用log包里面的println相当于这些导出的结果就都是进程安全的了。