1、可读性第一

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

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

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

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

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

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

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

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

2、关注扩展性

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

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

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

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

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

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

3、不要过多地关注争议点

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

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

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

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

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

p.s. 如果你是Go初学者，下图的资料可以下载看看。点击小编头像，关注之后私信回复“资料”即可获取。