标签 Subversion 下的文章

godep的一个“坑”

很多人学习和使用Golang一段时间后,都会被golang的第三方包依赖版本搞得有些烦躁,golang设计者最初过于乐观的设计使得今天大 家不得不各自想办法解决这个问题。godep就是综合了多年第三方包依赖问题的解决方案后的一个趋向统一的方案,至少是在go get的设计没有进化前的一个比较不错的方案。

今天试用了一把godep,不过“体验”并不理想,这缘于我遇到了godep的一个“坑”,不过是那种你在正式项目中不一定遇到的“坑”,这里来说到说到。

按照godep官方使用说明的第一步,先下载godep:

$ go get github.com/tools/godep
$godep
Godep is a tool for managing Go package dependencies.

Usage:

    godep command [arguments]

The commands are:

    save     list and copy dependencies into Godeps
    go       run the go tool in a sandbox
    get      download and install packages with specified dependencies
    path     print sandbox path for use in a GOPATH
    restore  check out listed dependency versions in GOPATH
    update   use different revision of selected packages

Use "godep help [command]" for more information about a command.

确认正确下载后,我们来准备一个测试例子,目录如下:

$GOPATH/
    src/
        tonybai.com/
                foolib/
                   foo.go
                fooapp/
                   main.go
       
   
//foo.go
package foo

func Add(a, b int) int {
        return a + b
}

//main.go
package main

import (
        "fmt"
        foo "tonybai.com/foolib"
)

func main() {
        fmt.Println(foo.Add(1, 3))
}

fooapp下,编译执行程序:

$go run main.go
4

接下来godep登场,根据godep文档中得步骤,接下来我们应该在一个构建依赖关系完整的项目中执行godep save以保存依赖关系以及依赖的当前版本第三方包:

$godep save
godep: directory "/Users/tony/Test/GoToolsProjects/src" is not using a known version control system
godep: error loading dependencies

出错了!godep提示$GOPATH/src目录没有使用任何版本控制系统(not using a known version control system)。 奇怪啊!这个错误什么意思呢?难道使用godep还需要将$GOPATH/src整体作为一个Project纳入git or subversion repository中?无奈之下,我只能先这么做,再作观察。我在$GOPATH下执行git init,建立一个local git repository,然后将src add到这个repository中。

回到fooapp下,再次执行godep save,居然依旧是同样地错误结果。于是到godep的issues中去查,看看是否有人和我遇到了同样地问题!godep的#116 issue中提到的问题恰恰和我的一致,不过这个issue一 直是open状态,也没有人comments。接着翻看一下godep的源码,godep依赖一些第三方包,save这个命令在分析版本控制工具库时也是 调用了多层外部包实现的,短时间内无法定位问题。

静想一下,godep是管理第三方包依赖关系的,而第三方包多是go get下载的,是不是foolib要放到repository中才行呢?于是尝试在foolib中建立git repository并做一次commit。第三次在fooapp下执行godep save,错误依旧!

难道fooapp也必须放在repository中?试试吧。在fooapp下init一个git repository,将fooapp下的main.go提交到repository中。再执行godep save:

$godep save
$ls -l
total 8
drwxr-xr-x  5 tony  staff  170 10 30 22:01 Godeps/
-rw-r–r–  1 tony  staff  103 10 30 21:44 main.go

这回成功了!godep save在fooapp下建立了Godeps目录,其结构如下:

$ls -R
Godeps.json    Readme        _workspace/

./_workspace:
src/

./_workspace/src:
tonybai.com/

./_workspace/src/tonybai.com:
foolib/

./_workspace/src/tonybai.com/foolib:
foolib.go

godep将当前版本的foolib copy到Godeps/_workspace下了。

Godeps.json记录了fooapp对foolib的依赖关系:

{
        "ImportPath": "fooapp",
        "GoVersion": "go1.3",
        "Deps": [
                {
                        "ImportPath": "tonybai.com/foolib",
                        "Rev": "20a9c2a682537813d37847f2f270bf929672cc84"
                }
        ]
}

godep记录了foolib的当前revision number,这个number恰是我最新一次commit的hash code:

~/Test/GoToolsProjects/src/tonybai.com/foolib]$git log
commit 20a9c2a682537813d37847f2f270bf929672cc84
Author: Tony Bai <bigwhite.cn@gmail.com>
Date:   Thu Oct 30 22:00:25 2014 +0800

    init

到这里让我觉得godep的设计思路有些与我的buildcC程序辅助构建工具)的思路有些类似,只是godep做得更彻底:

    1、godep将项目依赖统统放到项目的私有_workspace下,而buildc是共享的,通过project下的版本号配置区分依赖
    2、godep将依赖管理到revision(修订号)级别,buildc只是根据version来区分依赖。

godep的辅助构建原理(godep go build main.go)通过一条命令即可看出来:

$godep go env
GOARCH="amd64"
GOBIN="/usr/local/go/bin"
GOCHAR="6"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/tony/Test/GoToolsProjects/src/fooapp/Godeps/_workspace:/Users/tony/Test/GoToolsProjects"

godep临时将_workspace放在GOPATH列表的前面,这样gc在编译时就会按顺序先在_workspace下面找依赖包,这样fooapp的私有依赖就会理所当然的被gc用到,即便在其他GOPATH路径下有同名包(可能是不同版本的)。

显然这也算是godep的一个小bug吧(或者是godep依赖的包的bug,目前不确认),毕竟提示的路径是不正确的,不应该提示"/Users/tony/Test/GoToolsProjects/src" is not using a known version control system,而应该是"/Users/tony/Test/GoToolsProjects/src/tonybai.com/foolib或"/Users/tony/Test/GoToolsProjects/src/fooapp没有版本控制系统的repository留存。

另外觉得godep的author应该把这个“坑”作为一个使用godep的前提进行说明,并在github主页给出明确展示,即便这个“坑”多数人可能不会遇到。

只为那一抹释然

一切没有目标的努力,都是瞎忙活儿。
                                                    - Tony Bai

刚实施回来,就又投入到新工作中,到今天才有那么一点点时间写写这件事儿。

* 缘起

我们的遗留系统性能一直不高,导致这一局面的因素有很多,比如最初设计和实现的“考虑不足”、后续维护人员的“随波逐流”甚至缺少勇气对影响性能的关 键代码进行重构等等。技术债务就这样一直积累着。直到两年前,我们终见其导致的巨大的影响了。

由于客户方成本压缩,单节点性能低意味着需要更多的硬件投入,并连带着报价升高,导致我们的产品市场竞争力下降。而竞争对手产品的性能是我们的 3-5倍,这终于引起了领导的重视,并下达了开发高性能版本的任务命令。

* 抉择

遗留系统的问题有很多,性能差仅仅是表象之一。可维护性差更让人印象深刻。遗留系统就像一件打满补丁的旧衣裳,虽然依旧能穿着遮体御寒,但却让我 们时刻战战兢兢,生怕一个动作会导致它解体,变得支离破碎。

对于我们这样一个mission-critical的系统来说,开发周期显然是不会短的。在性能达标的同时,更为重要的是保证产品的质量,确保上 线后运行稳定。因此摆在我们面前有两条路:
    1、在遗留系统上做“大修” – 大规模重构
    2、重写,把构成系统的骨架重新设计和实现,使它能够足够坚固,满足在“高速公路”上驰骋的要求。

我们最终选择了重写,也就是风险较大的那条路。在我们的理解中,重写软件就好比汽车升级平台,就像大众将传统的PQ25、PQ35等统统升级为 MQB平台那样。平台的升级,不光影响技术,还会影响方方面面,比如团队的能力、思维方式、合作模式以及团队过程改善等等。做 得好的话,会使整个团队迈上一个新台阶,这是原地修补所不能够带来的。

对于我个人来说,这也是我期望中的实验田,我将把之前研究的诸多实践落地,帮助团队提升能力。

自私地说,重写系统也是我的一个小理想,能遇到这样一个从无到有构建一个系统的机会是不多的,因此很是希望能看到一个系统一点一点的在自己的呵护 下“成长”起来。虽然我也清楚完成这样一个系统需要很长时间,而这期间我可能需要时刻紧绷着神经,直到系统正式上线后,才能感受到那一抹释然。

* 建立“骨架(skeleton)”

我们将项目分成两个阶段:建立系统“骨架”和为系统“添肉”,即添加业务逻辑。

系统的性能目标是原遗留系统的10倍,这样我们建立的骨架的性能至少要高于原遗留系统的10倍。在“添肉”之前我们要充分证明骨架的设计是合理、 有效、稳定和高性能的。

遗留系统性能低,并非因为当初的设计者能力有什么问题,更多是局限于当初的设计目标。系统初期业务量不大,接入的外部网元不多,因此系统大量使用 了链表这种简单但低效的数据结构;为了easy coding,当初的设计者选择了全局大锁;在客户端-服务器处理模型上,选择了一个连接一个进程的“高耗能”模式。最初这样的设计应对当年的业务量也是 绰绰有余的,但应付今天的业务规模就显得颇为捉襟见肘了,以至于我们不得不通过罗列机器来满足业务增长的状况。服务器增多,却导致了我们维护 和监控难度的增加。

为了应付现有业务量规模以及未来若干年的业务量增长,我们的新系统的骨架在设计时显然要扬长避短:
    – 我们重新设计了通用的服务端框架和客户端框架,使得系统各个业务模块采用相同的通信处理机制;
    – 我们没有选择线程,而是依旧采用成熟的进程(资源隔离式) + IO多路复用(linux下epoll机制)的服务器-客户端模型,与以往不同的是,我们在每个进程中处理多个链接,设定进程数量在合理水平,避免大量上下文切换带来的性能损耗;
    – 将传统的全局big lock更换成了细粒度锁;
    – 采用高效的数据结构和算法,比如用hash和array替代掉list等;
    – 用简单队列替换掉原先复杂的队列调度结构,降低代码理解难度和后续维护门槛。
    – … …

我们要求对骨架代码进行严格的单元测试,通过lcut为骨架代码建立起单元测试集,并结合持续集成对骨架代码进行持续的单元测试验证。

骨架完成后,我们对其进行了全面的压力测试,确保其性能水平达到我们设计要求,这是我们进入下一阶段的前提条件。

* 添肉(business logic)

有了稳定、可靠、高效的骨架,我们在”添肉“阶段就更加有信心了。用C写纯业务逻辑是苦逼了一些,但还好我们没有全部将以前遗留代码扔掉,我们为了保证功 能Feature不丢失,我们会尽量复用之前的业务逻辑,当然是“规范地”搬到新系统中的,尽可能地去除原有代码中的Bad smell

与骨架相比,业务逻辑相对复杂,且耦合较多,因此对这些业务逻辑做单元测试真是一件让人头疼的事情。不过这也和我们最初的估计相符,最初制定的策略就是对骨架代码做高覆盖,对业务代码则宽松些,尽量覆盖即可。

* 附加实践

就像前面所说的那样,围绕着这次重写系统,我策划了很多实践有了落脚之地,包括:
    – 试点知识管理 :通过这次重写,建立起关于该系统的知识库;
    – 增加基于ReviewBoard在线代码评审环节;
    – 引入基于Jenkins持续集成
    – 重新思考和设计构建环节,通过buildc提高构建效率;
    – 重新设计通用安装包
    – 使用LCUT对骨架进行单元测试覆盖;
    – 规范commit log以及代码提交流程
    – 应用代码风格检查工具,使得所有代码风格一致。

事实证明上述实践在这次系统重写的过程中产生了很好的效果,尤其在代码质量保证方面,系统上线后的结果也恰恰印证了这一点。

* 上线

“丑媳妇总要见公婆”。我们的新系统也到了该上线服务的时候了。为了这次上线,我们做了较为充分的实施准备,无论是人员还是时间,都有倾向性的向这个系统 投入。我们也提前做好了应对各种突发问题的预案。可实际情况出乎预料,与遗留系统的版本升级相比,这次全新系统上线显得十分顺利,系统的核心相当稳定,出 现的一些问题也都比较边缘,对这次成功上线已经不构成什么影响了。

* 那一抹释然

在实施人员庆贺上线成功时,在领导口头表扬时,我的内心却显得十分平静。对于新系统来说,这是一个好的开始。对我个人来说,我感受到了那一抹期望已久的释 然。在这个领域里这个方向上已经摸爬滾打了多年,虽然还有好多地方需要改进,好多实践需要完善,但我的内心告诉我:“够了”、“已经没什么牵挂了”、“是 时候换换方向、换换领域了”、“让其他人去做吧”。我已经在产品和团队中融入了我的思想,我相信他们都能很好的演化和发展。而我则为接受新思想、新领域做 好了准备。

的确也到了为自己设立新目标的时候了!

代码评审,由人治过渡到“法治”

事实证明:有效的代码评审(Code Review,也有叫代码审查的),对保证代码质量具有十分重要的作用。因此这两年来我一直尝试着在这块不断改进和完善,以期望能形成一套合理、规范、有 效且高效的代码评审流程,这包括引入在线代码评审系统、走查和在线评审结合、规范评审Request的规模与有效性、设立评审专员等,用心不可谓不良苦 ^_^。大家也的确形成了及时提交Code Review Request或组织进行代码走查的良好习惯。不过我还是发现了一些问题。

* 有些组(我对其影响力不足的^_^)依旧没有严格执行代码评审环节,代码屡屡出现低级错误;
* 走查形式的会议评审缺乏全面性,效果好坏与参与者的“状态”直接相关;
* 在线评审环节缺乏“责任制”,常出现的一种情况是:请求大家评审,结果可能却是大家都没有评审。出现"Request Review Miss"的现象。

这让我陷入思考:长期以来我们在代码评审这块过于依赖人的自觉性,理想地认为每个人都能认识到代码评审的重要性,并认真地执行代码评审的流程或充满激情地 参与到其他人发起的代码评审过程中去,但结果事与愿违。这就像党员如何保持纯洁性一样,如果仅仅依靠个人道德/职业水平约束,这事往往是不成的。事实证明 人治在中国社会是会造成各种社会问题的。我们的代码评审环节也是一样,我们不能再期望所有人都能和我站在一条认知和激情水平线上,于是我打算尝试向“法 治”过渡。

"法",规则制度也,是团队一致认同的可以提升产品质量的规则制度。以此为前提,我要做的就是设立“检查和预防”机构,即以很低的Cost,检查大家是否按“法”完成了代码评审环节,提醒大家要按“法”进行。我采取了几个措施:

【规范Commit Log

这是一个前提工作。实现规范的Commit Log便于后续的检查和监督,同时细化规范的Commit Log信息对代码维护是大有裨益的。在Commit Log中还增加了一些关联信息,方便维护者了解该Commit的背景。初期的模板是这么来确定的:

模板结构:

TITLE
BODY
RELATIONSHIPS

展开后如下:

[Category] Title content

Body content

[BUGID] QC#733 | JIRA#766
[REVIEWID] RB#767
[REVIEWED BY] xx, yy, zz
[SIGNOFF BY] xx

TITLE Category:
   – BUGFIX 代码修复
   – FEATURE 新功能特性添加
   – TASK 诸如代码美化、调整版本号等
   – URGENT 紧急提交,对此类commit,可不做review和拦截

BODY Content:
   有关此次修改的详细信息说明

RELATIONSHIPS:
   – [BUGID] 一般用Bug跟踪系统的ID号
   – [REVIEWID] reviewboard上的ID号
   – [REVIEWED BY] xx, yy, zz
   – [SIGNOFF BY] xx

【"全覆盖"原则

所有变更代码都要发起在线“Code Review Request”,即便是会议走查的代码,会后也要补提“Review Request”。

【“低保”原则

每个Review Request至少选择两名评审负责人,填到"Request"中,这两个人必须对此Request给出评审意见,这是一个评审的最低保障了,这总比没有人评审要好。当然了其他人也都可以参与评审。只有这两名评审负责人明确提交"ship it" Comment后,该代码才算是通过评审。

【关键路径拦截】

"对不起,若不符合规定,你的工作将无法进行下去"。有了统一的Commit Log模板,我们就可以对大家的代码Commit环节做检查和拦截了。如果代码没有进行评审,无法填写模板中的字段内容,那代码将无法提交到代码库中。如 果虚构Commit log内容,这将是极大的错误,在抽查中一旦发现,后果将是很严重的^_^。

当然这一过程中还有很多细节需要考虑,比如Reviewer的选择不能集中在一个人身上,否则会造成热点;再比如紧急提交代码应该如何处理等等。“法治” 是与一定的“国情”相匹配的,并不是所有的组织都需要进行这么严格且略有死板“法治”手段,依团队内组员的专业能力和认知水平而定。

有些公司开发了自己的统一开发平台,将一系列流程都在一套系统中规范了起来,这当然是更好的“法治”了。但在没有这样的平台的前提下,初步使用上述的几个手段,还是会收获一些改进的。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多