for
and benchmarking.len
, varargs, range
and test coverage.struct
, methods, interface
and table driven tests.WaitGroup
and Mutex
math
package to draw an SVG clockNow that you have hopefully digested the Go Fundamentals section you have a solid grounding of a majority of Go's language features and how to do TDD.
This next section will involve building an application.
Each chapter will iterate on the previous one, expanding the application's functionality as our product owner dictates.
New concepts will be introduced to help facilitate writing great code but most of the new material will be learning what can be accomplished from Go's standard library.
By the end of this, you should have a strong grasp as to how to iteratively write an application in Go, backed by tests.
time
package to schedule activities.I often run in to questions on the internets like
How do I test my amazing function that does x, y and z
If you have such a question raise it as an issue on github and I'll try and find time to write a short chapter to tackle the issue. I feel like content like this is valuable as it is tackling people's real questions around testing.
io.Reader
with cancellation. Based on Context-aware io.Reader for GoI have some experience introducing Go to development teams and have tried different approaches as to how to grow a team from some people curious about Go into highly effective writers of Go systems.
An approach we tried was to take the blue book and every week discuss the next chapter along with the exercises.
I love this book but it requires a high level of commitment. The book is very detailed in explaining concepts, which is obviously great but it means that the progress is slow and steady - this is not for everyone.
I found that whilst a small number of people would read chapter X and do the exercises, many people didn't.
Katas are fun but they are usually limited in their scope for learning a language; you're unlikely to use goroutines to solve a kata.
Another problem is when you have varying levels of enthusiasm. Some people just learn way more of the language than others and when demonstrating what they have done end up confusing people with features the others are not familiar with.
This ends up making the learning feel quite unstructured and ad hoc.
By far the most effective way was by slowly introducing the fundamentals of the language by reading through go by example, exploring them with examples and discussing them as a group. This was a more interactive approach than "read chapter x for homework".
Over time the team gained a solid foundation of the grammar of the language so we could then start to build systems.
This to me seems analogous to practicing scales when trying to learn guitar.
It doesn't matter how artistic you think you are, you are unlikely to write good music without understanding the fundamentals and practicing the mechanics.
When I learn a new programming language I usually start by messing around in a REPL but eventually, I need more structure.
What I like to do is explore concepts and then solidify the ideas with tests. Tests verify the code I write is correct and documents the feature I have learned.
Taking my experience of learning with a group and my own personal way I am going to try and create something that hopefully proves useful to other teams. Learning the fundamentals by writing small tests so that you can then take your existing software design skills and ship some great systems.
if
, variables, functions etc.Logo is by egonelbre What a star!
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。