武功是无招胜有招,太极是四两破千斤,而Go是无框胜有框,为什么?Let‘sGo!
在领导 Go 研发团队的几年里,我从初学者那里听到的最常见问题是:“我该用什么框架?”
其实,在Go中你能做的最烂的事情之一就是遵循其它编程语言的方法。
在其它语言中,已经建立了“默认”框架。Java有Spring,Python有Django和Flask,Ruby有Rails,C#有ASP.NET,Node有Express,PHP有Symfony和Laravel。
而 Go 则与众不同:没有自己的框架!
更有趣的是,许多使用Go的人建议你根本不应该使用框架。难道他们是真疯了吗?
从库中构建Go服务会给人一种构造弗兰肯斯坦怪物的感觉
编写只做好一件事的程序。
编写程序是用来协同工作。
编写程序来处理文本流,因为这是一个通用接口。
这种哲学起源于B 语言(C语言的前身)的设计者KenThompson,还有Go!
实际上,Unix 哲学倾向于构建独立的小软件来做好一件事,而不是构建做所有事情的大块。
各位可能已经在自己的终端中看到这些小东东。比如:cat example.txt | sort | uniq。cat从文件中读取文本,sort对行进行排序,用uniq删除重复项。这些命令都是独立的,它们只做一件事,直接来自 Unix 哲学。就是因为这样的设计,用户可以独立开发更小的、属于自主的命令行应用。
在Go中,Unix哲学在标准库中随处可见。最好的例子是最广泛使用的接口:theio.Reader和io.Writer,它里面最好的库也是遵循这一理念。
而软件框架也是针对这种理念设计的。通常情况下,作者试图在一个框架内涵盖所有可能的用例。它们不是为与其它工具一起使用而设计的,而是目标不能重复使用。这意味着不可能将开发工作转移到其它不兼容的框架。如果你的框架采用率很低(或者很快就死了),那么所有的努力就算白费。
你能多快开始这个项目,
从长远来看,你能以多快的速度开发这个项目
项目对未来变化的灵活性(与前一点密切相关)
让我们开始评估一些决策。
节省时间
框架给出我们的最大承诺之一是节省时间。
运行一个命令,你就得到了一个功能齐全的项目。框架通常提供项目的固定架构,如果还不知道该怎么做,它会提供帮助信息,与大多数其他技术决策一样,它并不是完全免费的。
随着时间的推移,当项目增长时,您将很快碰到框架的约定和限制。该框架的作者要求可能与自己的不一样。框架创建者做出的决定可能适用于简单的 CRUD 应用程序,但可能无法处理更复杂的场景。 为了与一个框架限制作斗争,很容易很快就浪费掉在项目引导程序上节省的所有时间。
随着时间的推移,它可能会给你的团队带来不少挫败感。
几年前,我在一家最初使用一个Go框架起家的公司工作(我跳过使用该框架的名字)。公司正在快速发展并创造新的服务。随着时间的推移,当我们想要支持更复杂的用例时,我们开始感到痛苦了。
使用这个框架也是这个严重错误的来源。糟糕的是,摆脱框架并不太那么容易。
有一次,一些框架组件无人维护了,并且与生态系统的其它版本不兼容。我们被迫扔掉它,然后该框架已经非常紧密耦合到整个系统。从数十个服务中删除它变成一项非常重要的任务。它需要一个跨团队的建议,需要花费多个人/月和一些会议才能搞定。即使最后项目成功了,我也不怎么看好。 如果有人早点做出不同的决定,那么所花费的时间都可以得到更好的利用,不需要涉及到整个项目。
当然,许多公司对开发团队缺乏信任,这种情况也并不奇怪。
下面是一个很好的例子,从一个小的决策开始,如何在几年后成为一项代价高昂的救火项目的。
当你的项目开始变得更加复杂时,如果你已经知道让库如何协同工作,不妨开始重构它。
最后,你不需要大多数看起来很重要的框架功能,最终你可以得到一个更简单的项目和更少的研发。
总结
决定如何构建服务,不是你应该走捷径的地方。从长远来看,做出错误的决定会对自己和团队产生负面的影响,尤其会对团队的速度产生负面影响,影响士气。
做出错误的决定后,你很快就会陷入沉没成本的谬误陷阱。我们不应成为解决别人制造问题的英雄,而应该全力避免制造它们。
在本篇文章的末尾,相信各位应该了解一些方法的权衡与含义,你现在可以做出负责任的一些决策。
我希望这篇文章至少能帮助一家公司避免几个人几个月的痛苦项目重构。你是否有相关框架造成的故事?可以在评论区中让更多人知道。
编译:洛逸
作者:Robert Laszczak
来源:
https://threedots.tech/post/best-go-framework/