刚从别的语言转到 golang,下面几个问题让我琢磨了好久

3,757 阅读8分钟
之前是 PHP/Java 程序员,转到用 golang 开发,下面几个问题让我着实学习了好久才弄明白
  • 谜一般的 GOPATH,到底该怎么配!
  • 为什么有 error,还需要 panic?
  • golang 的接口是一种什么样的存在?
  • goroutine panic 居然会导致进程退出!!!
  • channel 满天飞,这样真的好么?

咱尽量简明扼要,只谈要点。

谜一般的 GOPATH,到底该怎么配!

官方一开始的设想是这样的

my-gopath/
└── src
    ├── github.com
    │   └── project1
    └── golang.com
        └── project2

把 my-gopath 设置为 GOPATH,然后这个就是你开发的工作目录了。src目录下有你所有的代码。但是这种本机设置一个 GOPATH 的模式会导致非常多的问题

  • 项目之间的依赖不隔离,容易错误引用到不希望的依赖
  • 无法分清楚哪些代码是自己的,哪些代码是别人的
  • 提交代码到 git 仓库的时候怎么办?

所以我们实际的目录结构应该是

my-projects/
├── project1 (GOPATH)
│   └── src
│       └── github.com
│           └── project1 (GIT根目录)
│               └── vendor
│                   ├── github.com
│                   │   ├── others-lib1
│                   │   └── others-lib2
│                   └── vendor.json
└── project2 (GOPATH)
    └── src
        └── golang.com
            └── project2 (GIT根目录)

这个结构是普通人类第一眼就能想出来的么!!!这是我经过无数次的试错之后发现的最佳的目录设置

  • 项目隔离的需求:每个项目有自己的单独的 GOPATH。
  • GIT 提交的需求:在 git clone 之前把 my-projects/project1/src/github.com 给创建出来,然后 git clone project1 到这个目录里。
  • 区分自己和别人的代码:使用 vendor 目录

你以为这就完美了?如果你要提供一个build.sh在编译机上做打包怎么办?编译机上的GOPATH 怎么设置呢?最佳实践:在 build.sh 里自己创建一个完整的 GOPATH(下图里的tmp目录),用符号链接指向自己。

my-projects/
├── project1
│   └── src
│       └── github.com
│           └── project1
│               ├── tmp
│               │   └── src
│               │       └── github.com
│               │           └── project1 -> ../../../../project1
│               └── vendor
│                   ├── github.com
│                   │   ├── others-lib1
│                   │   └── others-lib2
│                   └── vendor.json
└── project2
    └── src
        └── golang.com
            └── project2

这是一种什么样的妖孽啊!另外友情提示一个坑,Intellij 的 golang 插件和指向上级目录的符号链接不兼容,会导致无法自动提示。把 GOPATH 调整到 IDE 高兴,git 高兴,项目隔离,build.sh 可工作,不知道花了多少时间。

为什么有 error,还需要 panic?

panic 表示进程内的错误。panic 的原因来自于代码的逻辑 bug,比如强制类型转换失败,比如数组越界。这个代表了程序员的责任不到位,导致了程序的panic。

error 代表进程外的错误。比如输入符合预期。比如访问外部的服务失败。这些都不是程序员可以设计控制的。这些情况的错误处理是业务逻辑的一部分。

Java 在设计的时候 checked exception 就是 error,runtime exception 就是 panic。但是玩崩了。checked exception 和 error 一样都是想强制让程序员思考 error 的业务逻辑,但是没有成功。

golang 的接口是一种什么样的存在?

public function myFunc(SomeClass someObj) SomeResponseClass {
  someObj.method1();
  someObj.method2();
}

Java 这样的语言设置会导致的问题是容易导致依赖于实现,而不是依赖于接口。也就是这个 myFunc 依赖的输入可能只需要一个 method1(), method2(),但是 SomeClass 上除了这两个方法之外还有很多其他的行为。把输入接口设置为 SomeClass,导致了接口的“扩大化”。

public myFunc($someObj) {
  $someObj->method1();
  $someObj->method2();
}

PHP 的写法其实要比 SomeClass 更好。动态语言是 “duck typing”的,也就是你只要给一个实现了 method1(),method2() 的方法的对象,那么就能够调用成功。也就是 myFunc 的接口恰到好处的,不会因为类型声明而使得接口扩大化。但是 PHP 的问题是,不看实现,你永远不知道应该传一个什么样的 obj 进来。接口模糊了,导致调用方要查看对方的实现。

public function myFunc(SomeInterface someObj) SomeResponseClass {
  someObj.method1();
  someObj.method2();
}

Java 为了解决传实体类的问题,创造了 interface。interface 很好的解决了接口”扩大化“的问题。你可以给myFunc的需求,创造一个恰到好处的interface。但是 Java 的 interface 的问题是,需要 class 定义方的配合。我如果声明了一个interface,需要传入的对象在定义的时候就写了”implement interface"。相比动态类型来说,这就很不方便了。

综上

  • Java Class,依赖具体实现,而不是接口。导致接口扩大化
  • PHP Object,依赖的是接口,不存在接口扩大化的问题。但是调用方很痛苦,需要来看你的内部实现才知道你的接口是什么。
  • Java Interface,依赖接口,但是需要提前定义。无法随时按需定制接口。实践中仍然会导致 interface 的扩大化。

golang 的实现兼顾了 Java 的静态类型,和 PHP 的 duck typing 的好处。它使得你可以给 myFunc 定制一个最精确的接口依赖。只要实现了 method1() 和 method2() 的对象,自动就符合了调用的条件,可以被传入。这个行为非常类似 duck typing。但是相比纯动态语言的 duck typing,golang interface 又有一个肉身的实体存在,可以很方便查看。其实当我们在动态语言里做 duck typing 的时候

public myFunc($someObj) {
  $someObj->method1();
  $someObj->method2();
}
// 这里对$someObj 的使用,隐式地定义了$someObj 的interface,只是这个interface缺少一个肉身

golang 的interface就是避免了duck typing缺陷的,duck typing。其鼓励地行为是给你的函数定义“精确”地依赖接口,不要过大,也不要过小,精确。

这种精确也体现在了返回值允许多个上面。如果不允许返回多个返回值,我们被迫返回一个结构体。而定义很多小的结构体是非常麻烦的。这个实践中,就会导致很多人写没有返回值的的函数,把返回值隐藏到对一个大的结构体的变更中。或者返回一个很宽泛的结构体(比如map),仅仅因为给每个方法定义一个struct作为response太麻烦了。

golang简单务实,让你返回多个返回值,这样你就可以避免去定义一大堆小的struct来代表函数的返回值。目标就是让你精确地定义函数的输入输出。

goroutine panic 居然会导致进程退出!!!

前面说了,checked exception 是 error。runtime exception 是 panic。

Java 的 thread 里抛里抛异常,thread 挂掉,但是进程不挂掉。

Go 的 goroutine 里panic,整个进程挂掉。

goroutine 必须经过包装使用。

goroutine 越多,代码的线索就越多。线索越多,线索打结的可能性就越高。千万不要随手搞一个 go,fork 一堆 goroutine 出来。

channel 满天飞,这样真的好么?

channel 是一个很新鲜的东西。只需要一天就可以学会channel,然后需要剩下的时间让你忘掉它。

  • channel 不是一种抽象手段,不要用 channel 来组装逻辑。channel 是并发的控制手段,不牵涉并发的,不要过度设计。
  • channel 不能用来搞进程内的微服务,你写一块逻辑,我写一块逻辑,我们之间用 channel 通信。因为 rpc 是同步的,相对好掌控。channel 是纯异步的,你们搞不定。别说我看不起你们。
  • channel 漫天飞导致 goroutine 漫天飞。如非必要,勿增实体。goroutine 越多,代码理解起来复杂度成指数增加

You have to be this tall to use go/channel

go 相比 thread,channel 相比 lock,再简化也是有复杂度的。这些东西能不碰就不碰。它们始终是控制并发的工具,组织业务逻辑还是靠朴实的函数套函数吧。

任何一个 go/channel 关键字出现的地方,想一下是不是必要的。再想一下是不是必要的。再仔细想一下是不是必要的。


总结

  • 按照我给的模板使用 GOPATH,虽然看起来很不优雅
  • 你控制不了的进程外错误用 error,凡是程序员的锅,用panic
  • golang 鼓励你精确定义函数的输入和输出,感谢 golang。error 作为函数接口的一部分,checked exception 未竟的事业在 golang 发扬光大。
  • 任何一个 go/channel 关键字出现的地方,三思再三思
Go 语言golang最佳实践 程序员 18 solarhell cyhone chong ling 张昌鑑 袁大 分享 举报文章被以下专栏收录 13 条评论 写下你的评论
取消评论 su21 su21

> channel 不能用来搞进程内的微服务,你写一块逻辑,我写一块逻辑,我们之间用 channel 通信

实践下来,暂时没发现太大问题。不用channel,直接调用的话,就需要小心模块间循环调用产生死锁。

0 赞 举报 陶文 查看对话 陶文(作者)回复 su21开心就好 0 赞 举报 辣妹打太极 辣妹打太极 问个问题陶师傅,如果channel的生产者太多,会不会因为锁而影响性能? 1 赞 举报 陶文 查看对话 陶文(作者)回复 辣妹打太极

会。docs.google.com/document/d/…

0 赞 举报 冒泡 冒泡

GOPATH的问题,我倾向于外部不要配置,而是在每个project的makefile里面临时设置,临时使用,用来隔离

非入侵接口实际是用包含来实现的,而不像java的入侵式接口用多态来做,具体的就是说,你可以这样手工弄:

interface Intf {

void f();

}

class Intf_for_A implements Intf {

Intf_for_A(A a) {obj = a;}

void f() {obj.f();}

A obj;

}

使用的时候,如果要将一个类A的对象a赋值给Intf这个接口,则Intf i = new Intf_for_A(a);

缺点是对于每个实现了void f();的类,都要写一个代理类Intf_for_XXX,麻烦,而go是帮你干了这种事情,go的interface打印出来,是两个指针,一个是包含的对象的,一个是存储了接口的函数表和对象本身函数表的对应关系的结构

实际上,C++可以更容易实现非入侵接口,用模板实现,让编译器帮你自动生成Intf_for_XXX这堆就可以了

chan和go程的问题,go本来就是声称go程极端廉价,做微服务没啥问题,也可以同步通讯,比如

...

ret = f(a, b) //调用f函数

...

如果将f函数实现为一个go程,则变成:

...

f_in <- []interface{}{a, b} //函数调用做成通信请求,打包slice好像是这样写吧

ret <- f_out //通过通信得到执行结果

...

这种做法在某些情形下可能更合理,由于chan的通信一般还是算快的,性能还好(个人认为go的性能本来就在第二梯队,抠这个细节必要性不大了),当然,如果没必要这么做,则函数调用也是最简洁的