山_木
获得徽章 0
赞了这篇沸点
最近有同事跟我说过“你没搞懂原理”这样的对话。
其实对于面向应用的技术人员来说，“原理”基本上是对事物的逻辑关系的理解。
比如我对于“容器与容器是如何通信的？”这个问题，我的理解只停留在容器是什么，有哪些通信方式上。
而进程IPC，内存，共享存储的底层实现又分别有什么逻辑单元，各个逻辑单元之间又是怎么运作的，我就不知道了。
我只是举一个例子，来说明我们广大面向业务应用的技术人员对于“原理”的理解是停留在什么需求层面的。
不管是开发还是运维还是架构师，其实都在处理逻辑关系，各自所需掌握的细分逻辑单元的认知不一样。
这也是计算机是一门综合性科学的体现。
开发人员用框架实现业务需求，可能不需要对框架的实现深入学习。比如我知道web框架把HTTP请求封装了，我熟悉怎么使用就够了。编程语言(我指的是高级语言)的本质是抽象化计算机的运算，比如计算机本来没有面向对象这个概念，那程序员需要对计算机底层实现有多少认知呢？
运维人员对各种中间件的使用熟悉了，敢问一下真正对nginx的底层实现了解的有几个。
编程语言也好，nginx也好，底层实现都跟计算机底层原理有很多共通之处吧。
所以原理这个词，我是很少用的。
我学了那么多技术，无非是搞懂是啥，干啥的，子单元是啥，干啥的。
前段时间看了篇文章，是一个SDN项目的主要成员写的，他同时也是Linux内核的某些模块的编写成员，他提到，对于硬件的运作毫不了解，但丝毫不影响他编写运作于内核的模块。
我的理解是，“原理”这个东西其实也就是个抽象概念，当我只是个面向业务的技术人员时，他这样的理解，当我是面向操作系统的技术人员时又是另一番理解，不同的在于对事物的逻辑子单元的认知的复杂程度。
所以，我的同事跟我说你没搞懂那个原理的时候，我问他，你告诉我原理指的是哪几个东西，他们叫啥名字。因为我只是想知道他在说的是啥，我就可以Google一下就可以判断他说的是不是对的。
顺带一提，经常听见开发团队的人谁也不服谁，其实就是因为技术水平差不多，都想挣机会来负责实现。
其实对于面向应用的技术人员来说，“原理”基本上是对事物的逻辑关系的理解。
比如我对于“容器与容器是如何通信的？”这个问题，我的理解只停留在容器是什么，有哪些通信方式上。
而进程IPC，内存，共享存储的底层实现又分别有什么逻辑单元，各个逻辑单元之间又是怎么运作的，我就不知道了。
我只是举一个例子，来说明我们广大面向业务应用的技术人员对于“原理”的理解是停留在什么需求层面的。
不管是开发还是运维还是架构师，其实都在处理逻辑关系，各自所需掌握的细分逻辑单元的认知不一样。
这也是计算机是一门综合性科学的体现。
开发人员用框架实现业务需求，可能不需要对框架的实现深入学习。比如我知道web框架把HTTP请求封装了，我熟悉怎么使用就够了。编程语言(我指的是高级语言)的本质是抽象化计算机的运算，比如计算机本来没有面向对象这个概念，那程序员需要对计算机底层实现有多少认知呢？
运维人员对各种中间件的使用熟悉了，敢问一下真正对nginx的底层实现了解的有几个。
编程语言也好，nginx也好，底层实现都跟计算机底层原理有很多共通之处吧。
所以原理这个词，我是很少用的。
我学了那么多技术，无非是搞懂是啥，干啥的，子单元是啥，干啥的。
前段时间看了篇文章，是一个SDN项目的主要成员写的，他同时也是Linux内核的某些模块的编写成员，他提到，对于硬件的运作毫不了解，但丝毫不影响他编写运作于内核的模块。
我的理解是，“原理”这个东西其实也就是个抽象概念，当我只是个面向业务的技术人员时，他这样的理解，当我是面向操作系统的技术人员时又是另一番理解，不同的在于对事物的逻辑子单元的认知的复杂程度。
所以，我的同事跟我说你没搞懂那个原理的时候，我问他，你告诉我原理指的是哪几个东西，他们叫啥名字。因为我只是想知道他在说的是啥，我就可以Google一下就可以判断他说的是不是对的。
顺带一提，经常听见开发团队的人谁也不服谁，其实就是因为技术水平差不多，都想挣机会来负责实现。
展开
6
5
赞了这篇文章
赞了这篇沸点
TCP/IP协议报文格式高清珍藏版
TCP Packet Header
IPv4 Packet Header
IPv6 Packet Header
UDP Packet Header
ICMP Packet Header
hauptj.com
TCP Packet Header
IPv4 Packet Header
IPv6 Packet Header
UDP Packet Header
ICMP Packet Header
hauptj.com
展开
2
45
赞了这篇沸点
艹，不想一思辨还真成了react党了。自从自己的mvvm框架的子节点模式引入了一个稍复杂的算法一直耿耿于怀:复杂的东西总意味着易出错与难理解。可是dom节点是实体，不是绘制——操作dom消耗很大，加上virtualdom甚至更难理解了；react模式每次render都要重新生成，这样频繁的变化，太浪费；还有react的状态管理机制太死板。
我试想从新回到gui的实现原理层，浏览器提供出canvas，连measureText这样的方法都有，反正每次修改都只是调整完成后通知重绘，还能实现类似关系图的关联。才明白重绘组件难免生成实体，至少是承接dom事件，即用数据结构去指导绘制。当然以前的dom节点是复用这种结构的面向对象，但绘制总是难免的，性能问题在绘制上，生成节点应该可以忽略不计，对于计算机，时间基本上是唯一评判标准。但路程遥远，连复制文字的功能都没有。
然后恍然大悟，自己只是用canvas重新实现dom，何不直接用dom节点作为对重绘的指导？一切都实现得很好，dom节点消耗跟重绘比起来也不大吧。性能在重绘本身上，而不是dom节点的创建消耗上。所以每次事件重绘一次就行了，甚至没必要用virtualdom，diff出几个不同就要更新几次、重绘几次，mvvm也是一样。为什么innerHtml反而会很快？而且做框架将parseText的步骤都省了。每次就生成一个，从根节点替换。重绘一次。当然这是我的猜想。
至于状态的死板，解决更简单，不需要严格意义的组件，一般模块片段分成状态部分与重绘部分，状态被父组件持有，当状态就是重绘，不就直接退化为传统面向对象模式吗？灵活大大地有，不必认识dom的api。连动画都能缈想出来。
真正的进步是提高程序员的工作效率，减少思考，才能扩大生产面，而不是执着于机器的性能。想来mvvm仍然是过于复杂了。
以前有用java来做web的似乎也是这样的mvc处理。显然服务器端mvc，io才是性能重点。js有了ts等强类型，没必要再处处用java。
我试想从新回到gui的实现原理层，浏览器提供出canvas，连measureText这样的方法都有，反正每次修改都只是调整完成后通知重绘，还能实现类似关系图的关联。才明白重绘组件难免生成实体，至少是承接dom事件，即用数据结构去指导绘制。当然以前的dom节点是复用这种结构的面向对象，但绘制总是难免的，性能问题在绘制上，生成节点应该可以忽略不计，对于计算机，时间基本上是唯一评判标准。但路程遥远，连复制文字的功能都没有。
然后恍然大悟，自己只是用canvas重新实现dom，何不直接用dom节点作为对重绘的指导？一切都实现得很好，dom节点消耗跟重绘比起来也不大吧。性能在重绘本身上，而不是dom节点的创建消耗上。所以每次事件重绘一次就行了，甚至没必要用virtualdom，diff出几个不同就要更新几次、重绘几次，mvvm也是一样。为什么innerHtml反而会很快？而且做框架将parseText的步骤都省了。每次就生成一个，从根节点替换。重绘一次。当然这是我的猜想。
至于状态的死板，解决更简单，不需要严格意义的组件，一般模块片段分成状态部分与重绘部分，状态被父组件持有，当状态就是重绘，不就直接退化为传统面向对象模式吗？灵活大大地有，不必认识dom的api。连动画都能缈想出来。
真正的进步是提高程序员的工作效率，减少思考，才能扩大生产面，而不是执着于机器的性能。想来mvvm仍然是过于复杂了。
以前有用java来做web的似乎也是这样的mvc处理。显然服务器端mvc，io才是性能重点。js有了ts等强类型，没必要再处处用java。
展开
1
3
关注了标签 
Spring
Spring