写 Golang 程序的三条建议

写在前面:
其实写这篇文章初衷很简单，有人质疑我的上篇文章是抄袭的，就想再写点个人心得。刚看到时有点不忿，不过转头想了想，这难道不是对文章的肯定吗？????
秉着不要把写文章当作一个负担的原则，我接下来还是以 想聊什么，就写什么 的心态来面对，以免出现 "挤牙膏" 的文章。

可读性第一

优秀的代码必须保证可读性，没有可读性的代码就是 一次性产品。代码的可读性，再怎么强调也不为过。

可能会有不少朋友认为，代码最核心是为了 实现业务 。从公司角度来说，这个说法完全正确。我们作为开发者，如果以业务为第一导向，那么只会成为 码农，而 程序员 需要有技术上的思考。

程序员入门时，往往把开发认为是 实现业务需求的一次性工作。但实际情况却复杂很多：在一个软件生命周期内，你会遇到很多问题，例如：

• 测试中反馈的 bug 如何修复
• 线上程序出错如何排查
• 如何快速迭代需求
• 工作如何快速交接给他人

业界有很多关于写好代码的书，个人在这里推荐三本：

• 代码整洁之道
• 重构 改善既有代码的设计
• 代码大全

初读这些书时，会让人觉得讲得太细碎了；而工作几年后，就会觉得字字珠玑。

在此，我不赘述细节，只谈一个以前团队的代码验收标准 ：阅读代码时，感觉到整个逻辑通畅，绝大多数的变量、函数、模块都能通过名字猜测到大致功能。

关注扩展性

以前在做 C++ 和 Java 等项目时，大家更关注于程序本身的稳定性(太容易出bug了~)，而无法兼顾到扩展性。 作为 云时代的编程语言 ，Golang 给我们的最大体验就是 高效 (自然牺牲了部分性能)。而如今已大规模应用的两大概念 微服务 与 容器， 则是 Go 语言极佳的实践平台。

公司是否肯走 微服务 与 容器 的路线取决于领导，而程序员可以在开发时，有意识地往这个方向发展。如果学习 Go 语言却专注于普通的业务开发，很难体现 Go 语言的最大价值。

以一个简单的 基于 web 查询平台 为例，我们做的功能就是 http 请求/回复 与 后台数据库操作 的两块，做一个简单的设计：

• 将对数据库的操作集中写在一个 package 内，每个操作对应一个 数据库API函数
• 将 http 请求通过 路由分类，分别调用 数据库API函数

如果后续拆分服务时，那么就将 数据库API函数 封装成标准的 http服务，任何希望操作数据库的请求，都通过向这个 http服务 发送请求。

微服务 的改造工作很多，拆分服务 是第一步。有很多公司因各种原因，卡在这一步，迟迟没有进展。

不要过多地关注争议点

作为一个兴起不久的编程语言， Golang 存在很多的争议点，讨论最热烈的是以下两点：

• 对 error 的处理方式
• 包管理工具

如何处理错误/异常 是每个编程语言都很关注的话题，而 Golang 官方认为，错误应该在返回时立即处理。这个话题暂不深入，但很值得探索，有兴趣的读者可以关注其余各类语言的 错误/异常的处理机制。

而包管理工具则是官方遗留下来的问题，从原始的 go get 下载，到 glide,govendor 等第三方层出不穷，到如今官方推荐(但实践起来并不好用)的 gomod。个人建议暂时找个过渡方案，等成熟后再强制统一。

任何技术都存在争议，我们做技术选型时，更多地关注的是 用它能解决什么问题。如果这个技术经得起市场的考验，那么肯定会逐渐完善的。

Practice Makes Perfect

这篇文章是个人的实践心得，带有很多的主观想法。

希望有共鸣或持有保留意见的朋友，能在评论里和我闲聊几句~

有疑问加站长微信联系（非本文作者）