模型

基于新学到的内容进行再整合

2017-08-21

首先对于我的知识体系定义几个概念抽象，这些概念抽象可以有交叉的地方，但是尽可能保证交集少且能覆盖所有programing领域

从技术模块的角度整合一般层

2017-08-08

一般层由于是顶层，而且知识是偏应用方向的知识，因此知识和方法论之间的关系更为密切，方法论本身就是关于实践的知识，对于所要用到的方法论和知识体系的描述可以考虑从某些实践的角度来进行切入。比如debug方法论从方法论体系上来看是问题解决方法论的子方法论，但是从实践的角度来看可以从工程实践中引出（其实是从另一个角度归纳这些方法论，这样想就避免了方法论依附在知识上的尴尬，而是知识和方法论共同依附于某种现实中的实践或者其他抽象，前者比如“编程”，后者比如“flask”，会发现这些抽象的内部结构和知识体系非常相似，为什么呢？因为知识体系的构建就是基于这种概念抽象而非像方法论一样从某一个基方法论开始一以贯之的，所以知识体系可以看作是取了广泛概念抽象的某个子集来搭建知识体系，并从概念抽象当中切分了出来，新的归纳方式要求回到概念抽象当中去）这些方法论，这样会更加直观一些。

补充（2017-09-13）：其实是二维树型结构完全不足以描述知识结构这样复杂的结构

这幅图进行了很好的诠释

好好再过一遍我的整个体系

2017-08-06

1. 首先再来回顾一下我的系统，我的系统是为了满足我的需求所建设起来的，因此第一组对应关系是：需求（本我系统）——自我系统，在这组关系当中，逻辑是为了更好地满足本我系统我需求强化自我系统，而自我系统的强化来源于自我系统映射的 建设 和 沉淀 ，因此我要做好两件事情：一是建设，二是沉淀。
2. 而自我系统映射部分可以分为三个层次：

（1）元理论层

（2）自我管理层

（3）一般层

对于我现在而言自我系统的强化方向从原先的产品向转向了开发向，其实对应着自我系统映射部分的建设和沉淀转向了产品向和开发向，结合每一个层次各说一下并且比较有什么不同

3. 比较

（1）元理论层：不管是什么向最大的区别在于上层的知识、方法论的改变，元理论层几乎都是一致的，因此元理论层的建设和沉淀还是没有太大的不同，只是说由于目前时间比较紧可以暂缓

（2）自我管理层：方法论没有什么不一致的，只是方法论的实践的完全不同的，目标管理、时间管理、信息管理、行为管理以及任务管理方面的实践都需要有所变化，沉淀方面还是需要依赖执行

（3）一般层：首先是方法论的大转变（从产品向的方法论转向技术向的方法论，其必然带来实践的改变），其次是知识系统的改变，方法论都换了依赖的知识系统也大变了，这些都需要从无到有重新建构，沉淀方面也要好好思考一下，都是重点

4. 对于整个自我系统映射部分的一个概览

5. 一般层的方法论汇总：

（1）调试、debug

（2）问题解决

（3）项目体系构建

（4）接口设计

（5）业务建模

之后进行整体的体系化

6. 一般层的知识体系

在这个体系当中，没有重点标注出来的都是细枝末节，对于web开发来说最重要的有三条线：

（1）从网络编程的TCP/IP>HTTP协议>HTTP服务器（nginx、http server）>WSGI application（werkzeug、flask）这条线走通基本差不多了

（2）python基础

（3）工程实践基础

先来说一下技术方面我要掌握的东西吧

我计划中的核心能力（按优先级从高到低排序）：

1. Python编程能力
2. Linux系统的能力
3. 联结能力：完成大型项目所必须的一些知识和能力，比如网络编程相关的
4. 未来的Java学习
5. 其他周边能力
6. 工具使用能力

所有的能力，最好是通过实践去进行，实践的最高层次是项目，项目能够加深知识的记忆、理解和联结，是外部存储内部化以及显性记忆结构化的最好方法，也是方法论向底层沉淀的最好手段（这里的很多方法其实是能够抽象出一个方法论，但是它们都在不断地练习过程当中沉淀到底层去了，但这不意味着不需要建立顶层的方法论体系）

伴随着实践的同时，顶层的方法论也必须逐步建立起来，最好的情况是两条线是同步的，这样是话就不会产生底层混乱的情况，也有助于自己去向更高的层面发展。

所以我最理想的联系方式是项目与基础理论同步，不仅要去实践、还要去挖掘理论、更要去深度思考，一个很好的例子是光知道怎么写命令没啥用，只有当我真正理解这条命令之后才能提高它的效用，而光理解也没啥用，缺乏实践一方面使得你的理解是有瑕疵不全面的，另一方面对你的刺激不够，有碍你长时间的记忆，只有理解和实践相互作用才是最高效的。