dubbo 源码分析,参考众多文章,经常会更新
clion 、redis 4.0.6
阅读代码是很好的锻炼耐心和毅力的机会
物联网通信各类消息技术(应用层协议),各自特点、特定的物联网应用场景
这类协议都直接用于在无线或有线网络环境下的设备之间、人与设备之间的通信,物联网开发者都会与这些协议打交道

一、简单明快的早期时代(Web 1.0)
适合创业型小项目,不分前后端,经常 3-5 人搞定所有开发
页面由 JSP、PHP 等在服务端生成,浏览器负责展现。基本上是服务端给什么浏览器就展现什么,展现的控制在 Web Server 层
本地起一个 Tomcat 就能开发,调试什么的都还好,只要业务不太复杂
业务总会变复杂,这是好事情,否则很可能就意味着创业失败了
业务复杂> Service 越来越多,开发的人员从几个 > 速扩招到几十人
典型问题:
Service 越来越多,调用关系变复杂,前端搭建本地环境不再是一件简单的事
团队协作,搭建集中式的开发服务器
来解决
对编译型的后端开发来说也许还好,但对前端开发来说并不友好
只是想调整下按钮样式,却要本地开发、代码上传、验证生效等好几个步骤
也许习惯了也还好,但开发服务器总是不那么稳定,出问题时往往需要依赖后端开发搞定
看似仅仅是前端开发难以本地化,但这对研发效率的影响其实蛮大
JSP 等代码的可维护性越来越差
JSP 非常强大,可以内嵌 Java 代码。这种强大使得前后端的职责不清晰,JSP 变成了一个灰色地带
经常为了赶项目,为了各种紧急需求,会在 JSP 里揉杂大量业务代码。积攒到一定阶段时,往往会带来大量维护成本
为提高可维护性 > 前端组件化:
理论上,如果大家都能按照最佳实践去书写代码,那么无论是 JSP 还是 PHP,可维护性都不会差
但可维护性更多是工程含义,有时候需要通过限制带来自由,需要某种约定,使得即便是新手也不会写出太糟糕的代码
如何让前后端分工更合理高效,如何提高代码的可维护性,在 Web 开发中很重要
技术架构的演变如何解决这两个问题
给公司解决问题的时候,基本都是这样的 Pattern
组团之前
团队建设
设计 架构 架构师
需求、想法变成代码前的过程 > 设计
一些经验丰富的程序员执行这个设计过程 > 架构
与之对应的程序员身份 > 架构师