Go最差实践

Transcript

1. Go Worst Practices 李俱顺(Kevin Lee) EKEYNOW Pte Ltd.
2. $ whoami About Me • Gopher & Pythonista • CTO @ EKEYNOW Pte Ltd. • Community Contributor @ GoCN About ekeynow • A IoT SaaS startup company. All system powered by Go.
3. Best practice is useless, we only learn from worst practice. Trying to copy the best others have done amounts to ignoring context of both place and time, and reduces you to copying which in its turn is the death of innovation. DAVE SNOWDEN https://www.zylstra.org/blog/2003/11/keynote_dave_sn/
4. #1 NOT CLOSING THINGS
5. NOT CLOSING THINGS https://zhuanlan.zhihu.com/p/48039838
6. NOT CLOSING THINGS • Database-related • File/socket/connection • Something should be close.
7. #2 NOT SETTING TIMEOUT
8. NOT SETTING TIMEOUT https://zhuanlan.zhihu.com/p/48039838
9. NOT SETTING TIMEOUT https://hackernoon.com/avoiding-memory-leak-in-golang-api-1843ef45fca8
10. NOT SETTING TIMEOUT Go Concurrency Patterns: Context https://blog.golang.org/context
11. #3 OVERREACHING FOR CONCURRENCY
12. OVERREACHING FOR CONCURRENCY https://github.com/system-pclub/go-concurrency-bugs
13. OVERREACHING FOR CONCURRENCY Concurrency is Hard. • CSP does not change that. https://medium.com/oreillymedia/why-concurrency-is-hard-f93104cad54b
14. OVERREACHING FOR CONCURRENCY
15. OVERREACHING FOR CONCURRENCY
16. OVERREACHING FOR CONCURRENCY Single thread is still powerful & relaxed.
17. OVERREACHING FOR CONCURRENCY https://www.usenix.org/system/files/conference/hotos15/hotos15-paper-mcsherry.pdf Scalability! But at what COST?
18. #4 EXCESSIVE MOCKING
19. EXCESSIVE MOCKING
20. EXCESSIVE MOCKING Wait… don’t I need interface to mock? It depends.
21. EXCESSIVE MOCKING Be careful with interface mocking • Mocking is not real
22. EXCESSIVE MOCKING Testing your application in real world.
23. #5 LARGE INTERFACE
24. LARGE INTERFACE Domain Driven Design microservice
25. LARGE INTERFACE
26. The bigger the interface, the weaker the abstraction. ROB PIKE https://www.youtube.com/watch?v=PAAkCSZUG1c&t=317s
27. It is more important for a module to have a simple interface than a simple implementation. JOHN OUSTERHOUT https://www.youtube.com/watch?v=bmSAYlu0NcY
28. LARGE INTERFACE • Abstractions that have simple interfaces (deep modules) but hide complex functionality help reduce the complexity of programs. • Deep modules more better than shallow modules do - modules that have a simple implementation, but complex interfaces.
29. LARGE INTERFACE
30. #6 INTERFACE POLLUTION
31. INTERFACE POLLUTION
32. INTERFACE POLLUTION Why is this bad? • Good abstraction is hard. • Force interface onto the implementor. • Dependency injection?
33. INTERFACE POLLUTION defer abstraction()
34. #7 DRY TRAP
35. DRY TRAP
36. DRY TRAP
37. DRY TRAP defer DRY()
38. Q&A Thanks for your patience