技术都是相通的

技术都是相通的



从毕业以来，一直都会不间断的学习。来给自己能力做个提升，但是发现，工作几年下来，跟别人的差距越来越大，自己以后的路越来越窄。中间也有过一些反思，反思自己的学习方法和学习途径。总结下来，就是学习比较盲目，没有一个系统性的规划，今天翻下这本书，明天看下那个技术点。而且看了别人的东西以后，并没有转化为自己的知识。有一些知识点当时似懂非懂了，然后就放下了，然后就一直对某些知识处于模棱两可的状态。就这样浑浑噩噩的走着。

中间也看了很多的学习方法论，也有实践过一些方法。但都没有总结出来适合自身的学习方法。不过到目前为止，发现了两点能够拉开差距的方法（有天赋的除外）。第一点，耗子哥在极客时间上说的，大概意思是，知识会在与别人分享的过程中得到加深印象，在与别人分享的过程中，首先要把知识点讲给别人听，在这个过程中，其实就是一个知识的转换过程，把知识转换成了自己的知识，这种途径包括写博客、技术分享等，在这个过程中，很多的知识都在无形中被自己进行了整理，形成了自己的知识体系，有个良性的循环，让自己的技术能力不断地得到提高。第二点就是，对某一个难理解的知识点进行死磕。这是在李智慧老师的训练营总结得到的。李智慧老师的大概意思是技术都是相通的，还举了很多的例子，我在学习的过程中也发现了这个道理，如果遇到某个很难理解的知识点，能够死磕下去，弄懂那个知识点。那么下次遇到类似的问题，就会触类旁通，慢慢的，思路就会很开阔，这样也会达到一个良性循环，相反，遇到困难就绕过了，那很多东西学习起来就会很吃力，会一直很吃力。

我相信能做到以上两点，就能超出大多数程序员了。

学会使用图来表达自己的思想



作为一个技术，在日常开发中，经常会为某个需求说不清楚，和产品或者测试扯皮。有一些业务流程，可能用一张嘴很难解释的清楚。这种情况下，就可以尝试使用工具来表达自己的思路。

并且可以尝试从多个维度来描述自己要阐述的思想。

4+1架构视图，

• 逻辑视图（Logical View），设计的对象模型

• 过程视图（Process View），捕捉设计的并发和同步特征。

• 物理视图（Physical View），描述了软件到硬件的映射，反映了部署特性。

• 开发视图（Development View），描述了在开发环境中软件的静态组织结构。

• 场景视图(scenarios)，描述用例

同时还有一些其他的UML图分别针对不同的场景和不同的角色。

UML-静态图 － 通过描述类、对象和数据结构以及它们之间存在的关系，来描述软件要素中不

变的逻辑结构。

• 用例图（Use Case Diagrams）

• 对象图（Object Diagrams）

• 类图（Class Diagrams）

• 组件图（Component Diagrams）

• 包图 (Package Diagrams)

• 部署图（Deployment Diagram)

动态图 － 通过描绘执行流程或者实体状态变化的方式，来展示软件实体在执行过程 中

的变化过程。

• 协作图（Collaboration Diagrams）

• 序列图（Sequence Diagrams）

• 活动图（Activity Diagrams）

• 状态图（State Diagrams）

机会是给有准备的人



机会总是给有准备的人的，当你的知识储备足够了，就差一个机会的时候，机会来了，就有可能会从一个边缘人物转变成一个团队的核心人物，反之，机会来了但是知识储备不足，就会变得更加沉寂，后边的机会就会更少。