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()
func logln(message string)

以上就是位於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相當於這些匯出的結果就都是程序安全的了。