Go语言学习_tips

本文最后更新于2015年11月8日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

=Start=

1.Go代码的结构

Go 语言的基础组成有以下几个部分:

包声明(比如:package main)
引入包(比如:import “fmt”)
函数(func关键字)
变量(var 或 :=)
语句 & 表达式
注释(单行注释、多行注释)

2.在浏览器中本地查看文档

3.在命令行中查看Go文档/手册

4.别名

5.如何将字节数组转换成字符串

6.Go语言中如何判断map中是否包含某个key?

http://stackoverflow.com/questions/2050391/how-to-check-if-a-map-contains-a-key-in-go

7.将string转换成int类型、将int转换成string类型

http://stackoverflow.com/questions/4278430/convert-string-to-integer-type-in-go

8.Golang中的文件操作
9.Go程序的代码注释

10.Go语言的工程管理

……待添加……

11.格式化代码

12.待续

……

=EOF=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/2527.html

《Go语言学习_tips》上有23条评论

  1. 视频笔记:7种 Go 程序性能分析方法 – Dave Cheney
    https://blog.lab99.org/post/golang-2017-10-20-video-seven-ways-to-profile-go-apps.html

    方法一:time
     shell 内置的 time
     GNU 实现的 time
     *BSD、macOS 的 time
     go tool 中的 -toolexec 参数
    方法二:GODEBUG
     插曲一:Profiler 是如何工作的?
      性能分析注意事项
    方法三:pprof
     CPU 性能分析
     内存性能分析
     阻塞性能分析
     一次只分析一个东西
     对函数分析
     对整个应用分析
     方法四:/debug/pprof
     使用 pprof
      内存性能分析
      阻塞性能分析
    插曲二:Frame Pointer
    方法五:perf
    方法六:火焰图 (Flame Graph)
    方法七:go tool trace
    总结

  2. 近期一个Golang项目的测试实践全记录
    https://mp.weixin.qq.com/s/3Sngh1Y_HPpttp64Pxm6uw

    测试金字塔
    按照Mike Cohn提出的“测试金字塔”概念,测试分为4个层次:
    UI Tests
    End to End Tests
    Integration Tests
    Unit Tests

    最下面是单元测试,单元测试对代码进行测试。再而上是集成测试,它对一个服务的接口进行测试。继而是端到端的测试,我也称他为链路测试,它负责从一个链路的入口输入测试用例,验证输出的系统的结果。再上一层是我们最常用的UI测试,就是测试人员在UI界面上根据功能进行点击测试。

    测试是一个费时费力的工作,大多数情况下,业务的迭代速度估计都不允许做很详细的测试。但是对于复杂,重要的业务,强烈建议这四层的测试都能做到,这样代码上线才能有所底气。

  3. 如何写好 GO 语言单元测试
    https://mp.weixin.qq.com/s/_8-K85LrflBbPOZsodKEbQ

    用断言来代替原生的报错函数
    避免随机结果
    避免无意义重复
    尽量避免断言时间的结果
    尽量避免依赖外部服务
    优雅地实行前置和后置任务
    测试用例之间相互隔离
    面向接口编程

    最后是一些是code Smell(更多的是对代码的可测性要求),用例设计遵循原则:
    1、注释要清晰明朗,谜一样的注释、无注释都会影响阅读代码的理解
    2、重复代码需要抽取与分离
    3、声明与使用距离太远,不容易读懂
    4、箭头式的代码,提升了圈复杂度,也降低了可测性
    5、将内部逻辑与外部请求分开测试(small测试)
    6、函数太复杂,没有拆分到位,让单个函数功能行为单一且简单
    7、大量使用成员方法和函数,不利于传参进行测试
    8、函数不要太长(建议小于40行)
    9、文件不要太长(建议小于400行)
    10、原子性,所有的测试只有两种结果:成功或失败
    11、避免测试中的逻辑,即不该包含if、switch、for、while等
    12、每个用例只测试一个关注点
    13、少用sleep,延缓测试时长的行为都是不健康的

发表评论

电子邮件地址不会被公开。 必填项已用*标注