刚进公司的第一堂培训--[程序猿的结构化思维]
初级程序猿就是用技术给各种问题进行“分类“？
刚进公司的时候，我们老大对我说了这样一句话~，作为一个刚从0基础培训出来，几乎没有什么开发经验的你，要会分类~
当时我心想，分类这么简单的问题，谁不会啊~在以前学习的时候，我知道要把代码进行前后端的分类啊~ 那么问题来了，如果要完全分类的话，分成什么样才算分完了呢？ 当然是分到不能再分的时候~ 代码里面什么时候算作不能再分呢？分类的依据是什么？......
分类之前先要了解的I/O
I/O是什么？
领导说的就是Input和Output,是一个对于我们做分类的时候一个很重要的依据。
比如说，按照软件的各个阶段来说的话，我们总体流程大致有这些：
设计、实现、需求、交付
那么怎么给这几个过程进行排序呢？
这就要来看看各个过程的I/O了
设计：Input（需求文档），Output（概要设计/详细设计）
实现：Input（概要设计/详细设计），Output（可交付的代码）
需求：Input（客户提出的需求），Output（需求文档）
交付：Input（可交付的代码），Output（）
通过整理清楚每个阶段的I/O，我们就能理清楚这个流程是什么样的了~
根据I/O来思考，起码能让我们在开发过程中的思维不混乱~
分类/分层的原则
1.层次不混乱（根据I/O）
因为分类的依据不一样，所以分类的结果也是不同的，但是他们的共同点，就是层次不混乱
比如我们写一些小型项目的时候，在后端开发的分解中，会把后端代码按功能进行区分：
如果是按照模块来进行区分的话~我们又会这样分：
2.单一职责
因为分层的原则是多种多样的，但是分到最后的每一个小模块都是单一职责的，这是因为单一职责的模块或方法，
他们最后产生的结果是必须要有价值可交换的，也就是说，可以被别人调用，而且输出的结果是在整个开发过程中有用的。
同时，分解出来的结果，能把上一级覆盖完全，这样我们的分层就分解完毕了。
先占个坑，未完待续~~