发布于
raspiberry 3B+
发布于
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
发布于
组团之前
团队建设
发布于
设计 架构 架构师
需求、想法变成代码前的过程 > 设计
一些经验丰富的程序员执行这个设计过程 > 架构
与之对应的程序员身份 > 架构师