[翻译]Feedback on the Go Challenge solutions
浏览数：19 /
时间：2015年06月12日
第一次Go Challenge比赛，中国区只有3人参赛。
赛后收到邮件，是一个审阅者的反馈，“Feedback on the Go Challenge solutions”，摘录如下：
保持简单粗暴
- 一个语义单元一个文件即可，不要像Java那样一个文件就一个类型定义
- decoder.go 放解码相关的内容，而 drum.go 放 Pattern 和 Track 类型，以及 String()
- 不要添加额外的类型，除非需要为其增加方法
Streaming 是个好概念
- 许多代码基于io.Reader 和 io.Writer，包括都用到的encoding/binary
- 有人直接将文件全部读到内存中，然后将[]byte封装到bytes.Reader里，这是不可取的，还不如直接使用打开的file，因为这就是一个 bytes.Reader
- 建议阅读“Crossing Streams: a Love Letter to io.Reader”
了解标准库
- 使用 io.LimitedReader 可以封装已有的io.Reader并设定最大长度来读取，结合上面提到的直接使用io.Reader更简单粗暴
Errors are values
- 没必要不停地做错误检查，这太繁琐
- 将io.Reader封装到自定义的Reader中，记录碰到的最后一个error
- 解析整个文件，别管那些错误
- 最后检查下存储错误的结构
- 建议阅读Rob Pike的“Errors are values”
不要泄露实现细节
- 虽然文件中使用[16]byte来存储节拍，但是对于ON/OFF类型，用[16]bool就好
- 没必要为了节省空间使用uint16，因为这会让API不好搞
写代码不是为了通过测试，而是为了解决问题
- Pattern 5在文件末尾有额外的数据，应该通过解码文件头获取文件长度来解析文件，而不是看ID有没有SPLI
- 通过测试不代表一切OK
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
