云溪的 blog
  • Archive
  • Media
  • Search
  • Tags
  • About

golang 简洁架构介绍

在 go 开发中,首先遇到的一个问题,应该怎么设计开发架构。一个好的架构可以在后续的项目开发中能够更好的使用项目的推进,同时能够让团队的配合更加的顺利。 一个简洁的架构应该具有如下几个特点: 不依赖框架:好的架构应当是独立的,不依赖框架可扩展的 不依赖 UI:UI 应该很容易修改,而不需要改业务部分代码 独立于数据库:不绑定数据库,可以在不改动业务代码的情况下,更换其他数据库 可测试的: 能够比较方便测试用例的编写 下面目录结构引自 《go 整洁模板》 ├─cmd 应用入口 │ └─app ├─config ├─docs // 存放文档 ├─internal │ ├─app │ ├─controller // 控制器 │ │ ├─amqp_rpc │ │ └─http │ │ └─v1 │ ├─entity // 实体层 │ ├─middleware // 中间件 │ └─usecase │ ├─repo // 数据库操作 │ └─webapi // RESTful API ├─migrations ├─pkg //以被外部程序安全导入的包 │ ├─crypto │ ├─httpresponse │ ├─httpserver │ ├─logger │ ├─mysql │ ├─postgres │ ├─rabbitmq │ └─redis 分层介绍 ...

June 29, 2022 · 1 min · 云溪

golang 接口(interface)最佳实践

接口定义 应该定义在接口所使用的包中,而非接口实现的包中。 以io包中的io.Reader/io.Wirter为例,接口定义在io包中,而他的实现bytes.Buffer、os.File等都是在不同包中。 接口实现应该返回具体类型 应该返回对应的结构体或指针,这样实现类如果扩展新的方法就可以直接添加,无需改动接口定义部分,更加灵活。 //为了方便演示,本实例代码未遵循「接口需要在使用包中声明」规范 package demo import "fmt" type Demo interface { show() error } type MyDemo struct { } //这里的返回值应该是 `MyDemo` 或 `*MyDemo` 而非 `Demo` func NewMyDemo() *MyDemo { return &MyDemo{} } func (md *MyDemo) show() error { fmt.Println("show") return nil } 接口应该什么时候定义 在当前模块有依赖外部服务的时候,这时候就会定义一个接口,来对外部的依赖资源进行抽象解耦,屏蔽接口的实现。相反,依赖的提供方在不知道使用方需求的时候,定义接口也就没什么意义。

June 11, 2022 · 1 min · 云溪

如何学习一门新编程语言  [draft]

概括了解 首先在学习一门新的编程语言之前,需要对语言进行一个整体的了解。该语言与其他编程语言相比有什么特别之处。 在了解语言的同时也是一个确立边界的过程,每个语言都有自身的优势与劣势。我们只有清楚的了解各个语言的特性,才可以在技术选型的过程中更有把握选择更为合适的语言推进项目的进行。 了解了语言边界之后,需要做的就是了解一下语言层面一些常见的问题。这样能够在开发前避免一些常见的坑,也能在一些问题出现后,能够更好的把握问题的出现原因。 通过上面方法,基本上就可以完成对一个新编程语言的了解,以及常见的一些开发问题,也可以在后续的选型和开发中做到了然于胸。 熟悉语法 语法学习有两种方式: 文档学习(信息获取快,一般适合经验比较丰富的老手) 视频学习(更为直观,更适合新手) 两种方式各有优劣,选择更适合自己的方式就好。语法学习的过程中最重要的就是去敲代码,仅仅看是不够的,动手去敲出学习的代码,是高效掌握语法的关键。 熟悉规范 学习规范 规范在编程开发中是十分重要的,在写代码之前一定要了解语言的开发规范。一个良好的编程规范,是优雅开发的开始,也是团队合作的基石。如果一个团队每个人都有自己的开发风格,可想而知后续的项目维护将会是怎样的噩梦。 规范学习不需要一开始就对规范有很深入的了解,只需要有一个大概的了解即可,后续如果在开发中遇到疑惑,可以再去查找相关规范。对规范的应用应该像查字典,你不需要会背诵,但是你要知道去查找。 最佳实践 我之所以比别人看得远一些,是因为我站在巨人的肩膀上 学习最佳实践。每个编程语言都会有一些最佳实践(best practices)。这些最佳实践(best practices)是行业开发人员在进行大量开发验证和思考后做出的总结。并且最佳实践(best practices)也是在迭代的,社区会在前人的最佳实践的基础上,加上自己的一些总结,因此最佳实践(best practices)一般质量都非常的高。 最佳实践(best practices)的学习中,需要不断的思考和辩证,要做到知其然知其所以然。只有这样你才能够在最佳实践(best practices)的基础上梳理出自己的最佳实践,更好的服务后续的项目开发。 最佳实践(best practices)可以让你快速的梳理出一套项目架构,也能让你快速的写出非常高质的代码。 总结 学会一门编程语言,不仅仅是会语法,会开发就可以了。还需要了解语法和最佳实践(best practices),只有这样才能开发出高质的代码,也能在开发的过程中减少一些问题的出现。 在生活中也经常能够遇到两种人: 一种是:我学习完基础的语法,能开发出来功能就可以了,不在乎架构的合理性和编程规范。 另一种则是:学习完基础语法,能开发的基础上,去了解规范,学习最佳实践,不断思考和验证的人。 其实两种思想恰好也是对应的「短期主义」与「长期主义」。短期看两种思想看不出差距,在长期看,两种思想的发展是天差地别的。

June 10, 2022 · 1 min · 云溪

树莓派变身旁路由,扩展家中网络

由于家中网络覆盖存在死角,手中有一个树莓派,就准备刷入「openwrt」作为旁路由,扩展家中的无线网络。 整体思路如下,用树莓派的自带网口桥接主路由网络,然后通过树莓派无线网卡发射无线网络,从而达到扩展网络的目的。 如果你也正巧有类似的需求可以通过下面清单,准备所需材料: 树莓派 读卡器 TF 卡 台式机/笔记本(用于调试网络) 网线一根 下载镜像 镜像推荐:OpenWrt-Rpi ,这款镜像支持绝大多数的常见设备,并且镜像集成了很多很好用的功能,也免去了刷官方固件,后续自己折腾安装软件的过程。 进入固件下载 页面能够看到支持设备的列表,找到自己的设备,点击固件下载,进入你设备的固件下载页。 我这边是树莓派 3B 下载的为: immortalwrt-bcm27xx-bcm2710-rpi-3-ext4-factory.img.gz 到此镜像就已经下载好了,下面就是将下载好的镜像,写入树莓派的 TF 卡。 写入镜像 将 TF 卡插入读卡器,并将读卡器插入电脑上,镜像写入工具使用的为: Win32 Disk Imager 如果没有的话可以自行下载。打开 Win32DiskImager 软件,选择下载好的 「openwrt] 镜像和对应 TF 卡的盘符,点 Write 按钮开始写入镜像。 看到写入完成的提示后,将 TF 卡拔出插入树莓派,将准备的网线插入树莓派网口,并网线的另一端连接到电脑上,将树莓派开机。 openwrt 配置 接口配置 树莓派开机后,电脑端输入 192.168.1.1 可以看到路由器的登录页面。 镜像的默认密码为: password ,输入密码后进入系统后,点击「网络-接口」进行接口设置,系统默认已经创建好了 LAN 接口,点击 LAN 接口的修改,进行配置,具体配置如下: 传输协议:静态地址 IPv4 地址: 前三位与主路由地址相同,最后一位写一个内网中没有分配的地址即可。我这里为:192.168.1.100,需要注意的是此地址也是后续登录路由器管理界面的地址。 IPv4 子网掩码: 255.255.255.0 IPv4 网关: 主路由网关,我这里为 192.168.1.1 ...

May 3, 2022 · 1 min · 云溪

读《黑客与画家》  [draft]

产品发展路径 搭建原型 上线运营(别管bug) 搜集反馈 成长壮大 在产品发展中最避讳的就是闭门造车,不能陷入自嗨式精益求精。产品最终使用者是客户,只有客户才是检验产品设计是否优秀的试金石。如果产品研发早期过度注重所为的精益求精,极大的可能就是所有的功能不是客户真正在意的,这就会很大的浪费了成本和精力。 互联网发展多年,不管是产品设计领域还是产品开发领域都涌现出很多相似的理论。例如:小步快走,快速迭代、敏捷开发…… 好的产品应该引入用户的参与,让用户参与产品的设计,这样开发的产品才是更符合使用者的需求,更好的满足市场的需要。 适合的才是最好的 对于编程语言的选择:流行的不是最好的,适合的才是最好的。现如今各种语言层出不穷,要对各个语言的特性有所了解,对于编程语言的选择应该以业务为核心而非以编程语言的流行程度为核心。 并非所有的业务都适合用来作为衡量选择语言的因素,应该以关键业务的关键部分,作为衡量的选择。也有可能整个项目都对语言没有过多的要求,可以根据补充条件(招聘难度,开发效率)作为选择语言的标准。 对于选择的语言可能会存在招聘不到相关语言的开发人员,书中说可能所在城市并非适合创业。我个人并不是很认同此观点,因为有些情况下,并不能换城市开展业务,那就必须面对招聘不到开发人员的实际问题。 对于上述问题我个人有下面一些思考:可以将项目的核心业务和周边业务做区分,周边业务,本身对语言要求不是很高,可以选择招聘相对容易的语言做开发。核心业务可以从内部组织一个小组学习新语言,进行开发。 可能会有人有疑问重新学变成语言,不是更浪费时间吗?关于此问题可以阅读我的《我们是如何使用一门新语言一周上线一个程序的》 优秀成于细节 达•芬奇在作品《女性肖像》中在少女头后摆了一片树枝。他很仔细的画出了树枝上的每一片叶子。许多画家也许会觉得,那不过是背景里的衬托,没有人会仔细看,不妨简单处理下就可以了。 但达•芬奇不这么想,他对作品的每一部分认真程度完全不取决于会不会有人仔细看这部分。 君子慎独,不欺暗室。做人与做事道理是一样的,不管所做的事情是否有人能够看到,都应该认真对待。 在开发过程中经常会遇到类似的情况,因为各种原因,将程序算法设计的过于简陋,短期看能够满足需求,但从长期看,无论是维护和可靠性都存在很大的问题,最终导致用户丧失信心,放弃继续产品。 开发过程中应该时刻保持敬畏之心,注重开发过程中的每一个细节。这样才能够在一个比较久的时间跨度上取得优异的成果。 代码是给人读的,其次是机器 写程序,一定要时刻提醒自己代码是给人读的,这个非常重要。所以在开发程序算法的时候应该首先考虑别人阅读起来是否能够更容易读,而不是考虑机器是否更容易读。 让代码更易读,并非就是放弃程序性能和架构完整。大多数情况下考虑代码可读性并不会带来过多的性能损耗和架构设计的牺牲。 至于少数情况则需要开发人员花更多的时间去考虑如何去取得一个平衡,在代码易读性和性能与架构完整性之间取得一个平衡。这是平衡的艺术,虽然次数不会很多,但每一次的取舍和考量都能让我们对程序开发的理解有所提升,也会让我们更少的遇到这类需要平衡抉择的问题。 总结 理想很丰满,现实很骨感。在很多情况下,都不得不面对各种各样的客观因素,而在这种客观因素下面所做出的选择拉开了人与人的差距。 有些人会心生抱怨,把问题归结于客观因素,最终不仅自己不能取得职业上的进步,也会给团队氛围带来一定的负面影响。 有些人则是积极主动,主动考虑在客观因素存在的前提下,如果通过主动做功,让事情进最大程度的取得好的结果。 每个选择都是因,在未来也一定会有相应的果。在一个团队中大家一定都喜欢那些给团队带来希望的人。希望我们能在被别人点亮的同时,也能够点亮别人。

April 15, 2022 · 1 min · 云溪
« Prev  Next  »
© 2025 云溪的 blog