golang 设计模式

设计模式,大概意思就由码神们总结的、解决软件设计中反复出现的问题的、也可以说是一种编码规则

初始编码我们总是按照自己的套路来写代码,项目的代码量庞大了,需求又要改了,突然发现尼玛这个改起来好麻烦,好多文件要动,为了适合新的需求改动这个文件可能会对其他的业务逻辑产生影响,改动这个文件会不会引入bug?一系列的问题摆在了我们眼前,头疼、迷茫,有木有一种重新写一遍的冲动?

假如你遇到了这种情况,设计模式可能会拯救你一部分

发布于 | Tags go pattern

树莓派

raspiberry 3B+

2

发布于 | Tags pi

dubbo

dubbo 源码分析,参考众多文章,经常会更新

发布于 | Tags dubbo java

Redis 源码

阅读代码是很好的锻炼耐心和毅力的机会

发布于 | Tags redis

物联网中几个应用协议

物联网通信各类消息技术(应用层协议),各自特点、特定的物联网应用场景

这类协议都直接用于在无线或有线网络环境下的设备之间、人与设备之间的通信,物联网开发者都会与这些协议打交道

发布于 | Tags iot

java spi

Java SPI 思想

系统里抽象的各个模块,往往有不同实现方案(日志、xml、过滤器等),模块间应基于接口编程

避免在代码中写死服务提供者(或动态指定具体类名),通过 SPI 服务加载机制进行服务的注册和发现,基于接口编程,实现多个模块的解耦

如果基于具体实现类,违反可插拔原则,替换一种实现,就要修改代码

发布于 | Tags java

Web 研发模式演变

一、简单明快的早期时代(Web 1.0)

1

适合创业型小项目,不分前后端,经常 3-5 人搞定所有开发

页面由 JSP、PHP 等在服务端生成,浏览器负责展现。基本上是服务端给什么浏览器就展现什么,展现的控制在 Web Server 层

本地起一个 Tomcat 就能开发,调试什么的都还好,只要业务不太复杂


业务总会变复杂,这是好事情,否则很可能就意味着创业失败了

业务复杂> Service 越来越多,开发的人员从几个 > 速扩招到几十人

典型问题:

Service 越来越多,调用关系变复杂,前端搭建本地环境不再是一件简单的事

团队协作,搭建集中式的开发服务器来解决

对编译型的后端开发来说也许还好,但对前端开发来说并不友好

只是想调整下按钮样式,却要本地开发、代码上传、验证生效等好几个步骤

也许习惯了也还好,但开发服务器总是不那么稳定,出问题时往往需要依赖后端开发搞定

看似仅仅是前端开发难以本地化,但这对研发效率的影响其实蛮大

JSP 等代码的可维护性越来越差

JSP 非常强大,可以内嵌 Java 代码。这种强大使得前后端的职责不清晰,JSP 变成了一个灰色地带

经常为了赶项目,为了各种紧急需求,会在 JSP 里揉杂大量业务代码。积攒到一定阶段时,往往会带来大量维护成本

为提高可维护性 > 前端组件化:

1

理论上,如果大家都能按照最佳实践去书写代码,那么无论是 JSP 还是 PHP,可维护性都不会差

但可维护性更多是工程含义,有时候需要通过限制带来自由,需要某种约定,使得即便是新手也不会写出太糟糕的代码

如何让前后端分工更合理高效,如何提高代码的可维护性,在 Web 开发中很重要

技术架构的演变如何解决这两个问题

发布于 | Tags front evolution

微服务架构实践感悟

微服务由来

著名互联网公司(Amazon、Netflix 等)实践摸索出新的大型系统架构方法论,并取得成功 > 技术理论派人士命名为微服务架构(Microservices)

发布于 | Tags 微服务