拉巴力不吃三文鱼
后端开发
|
TME
主要使用Java开发项目，最近两年也使用Go。
大多从事互联网业务开发，同时也参与通用基础库的开发和维护。
获得徽章 0
赞了这篇文章
最近由于特定需求，我创建了一个代理项目，该项目可以对进出流量进行加密解密等操作。
虽然该项目在实际应用场景中可能使用不多，但我通过这个项目加深了自己在 Golang 编程方面的能力。
作为初学者，总体来说代码比较浅薄，但希望还是能大家提供一些帮助以及接收一些反馈，持续优化。
项目地址：
github.com
项目使用sdk的方式运行项目, 并尽量保持扩展性，可以使用WithOption的方式自定义某些配置。
使用示例：github.com
在项目中，我将我的学习成果应用于实践，并将总结如下：
1. 在 outproxy/internal/pack/pack.go 文件中，使用 Middleware 模式，可以让代码更加优雅。
2. 在 common/logger/logger.go 文件中，使用 logger 抽象技巧，支持后续使用时传入自定义的 logger，例如 logrus、zap、zerolog 和 seelog。默认使用 zap。
3. 在 common/compress/compress.go 文件中，使用数据压缩技术，目前支持 snappy 和 gzip。
4. 在 common/config/config.go 文件中，使用配置抽象技巧，目前内置了 YAML 和 Apollo，当然也可以自定义。
5. 在 common/encrypt/encrypt.go 文件中，使用数据加解密技术，目前支持 AES 算法。
6. 在 common/pool/bytes_pool.go 文件中，使用 sync.Pool 技术，可以复用内存，提高代码性能。
7. 在 common/proto/proxy_payload.proto 文件中，使用 protobuf 协议传输数据，性能和效率都非常高。
8. 在 common/server/server.go 文件中，使用经典的 Option 模式和优雅退出服务的处理，作为服务启动入口。
等等
虽然该项目在实际应用场景中可能使用不多，但我通过这个项目加深了自己在 Golang 编程方面的能力。
作为初学者，总体来说代码比较浅薄，但希望还是能大家提供一些帮助以及接收一些反馈，持续优化。
项目地址：
github.com项目使用sdk的方式运行项目, 并尽量保持扩展性，可以使用WithOption的方式自定义某些配置。
使用示例：
github.com在项目中，我将我的学习成果应用于实践，并将总结如下：
1. 在 outproxy/internal/pack/pack.go 文件中，使用 Middleware 模式，可以让代码更加优雅。
2. 在 common/logger/logger.go 文件中，使用 logger 抽象技巧，支持后续使用时传入自定义的 logger，例如 logrus、zap、zerolog 和 seelog。默认使用 zap。
3. 在 common/compress/compress.go 文件中，使用数据压缩技术，目前支持 snappy 和 gzip。
4. 在 common/config/config.go 文件中，使用配置抽象技巧，目前内置了 YAML 和 Apollo，当然也可以自定义。
5. 在 common/encrypt/encrypt.go 文件中，使用数据加解密技术，目前支持 AES 算法。
6. 在 common/pool/bytes_pool.go 文件中，使用 sync.Pool 技术，可以复用内存，提高代码性能。
7. 在 common/proto/proxy_payload.proto 文件中，使用 protobuf 协议传输数据，性能和效率都非常高。
8. 在 common/server/server.go 文件中，使用经典的 Option 模式和优雅退出服务的处理，作为服务启动入口。
等等
展开
评论
3
+ 当把任务分解成小块的时候，这些任务就变得更易于完成，对完成任务所需的时间的估算也更精确，你也更有可能正确地完成它们。即使有些小任务没有正确完成，你也有很多机会改正，而不至过多地影响大项目。我发现，把大任务分解成小任务真是一个好主意。
+ 在管控代码的复杂程度问题上，我们也会做一些工作。这就是我们不会将所有的代码都写入一个方法中的原因。我们会将自己的代码分解为方法、函数、变量、类以及其他结构，从而简化代码。
+ 不管编程问题有多难，它总是可以被分解为更小的单元。如果你想要写出一个难度很大的算法，在一头扎进去写代码之前，先把这个问题分解为能够依次独立解决的小模块会更有帮助。无论应用程序多么庞大、多么复杂，它都可以被分解成一行行的代码。单独一行代码的复杂度绝对不会超过任何一位程序员的理解能力和编码水平，所以，如果你愿意将问题分解得足够小，只凭借写出单行代码的能力你就能写好任何应用程序。
--《软技能_代码之外的生存指南》
+ 在管控代码的复杂程度问题上，我们也会做一些工作。这就是我们不会将所有的代码都写入一个方法中的原因。我们会将自己的代码分解为方法、函数、变量、类以及其他结构，从而简化代码。
+ 不管编程问题有多难，它总是可以被分解为更小的单元。如果你想要写出一个难度很大的算法，在一头扎进去写代码之前，先把这个问题分解为能够依次独立解决的小模块会更有帮助。无论应用程序多么庞大、多么复杂，它都可以被分解成一行行的代码。单独一行代码的复杂度绝对不会超过任何一位程序员的理解能力和编码水平，所以，如果你愿意将问题分解得足够小，只凭借写出单行代码的能力你就能写好任何应用程序。
--《软技能_代码之外的生存指南》
展开
评论
5
赞了这篇文章
赞了这篇文章