想自学计算机，希望从宏观了解计算机各部分知识之间的关系？ 第1页

哎呦喂！这个问题问的好有前瞻性和与时俱进啊！惊得我都忘了泻药了！不开玩笑了。

首先

1. 数学

特别是离散数学，必须要学好。我不是开玩笑，离散学的好不好直接决定了你在IT领域的层次和发展级别。除非你走管理路线，只要你将来发展和技术要靠一点边，这个绝对是你事业发展的基础。

因为将来不管你搞开发，研究技术，做架构，或从事业务分析，方法论很重要。方法论这个词被用烂掉了，但我发现那些整天把方法论挂在嘴边的人没一个懂的。都是在糊弄领导，客户和其他不专业的同事。（好了，不吐槽了，我又愤怒了。）

方法论说的通俗一点就是一个解决问题的总方针和问题分析和解决思路。从广义上说，面向对象，复杂度分析，复杂问题分解，数据建模等等都可以算是方法论。是不是很晦涩难懂？不要紧，你学计算机将来会一点点遇到的。

先举个例子吧（交通问题）

颜色代表交通流量，路段ABCD是驶入，EFGH是驶出，123456789是路口，请问怎么优化个路口的红绿灯以分散流量，让各路段和路口能得到充分利用不让个别路段和路口流量过高。这个上手怎么做呢？几乎找不到有效的计算方式吧。我举的例子和条件按还是很抽象和理想化的，实际的问题还要复杂的多的多的多。

这类复杂问题几乎没有什么万能的解决方案和计算方法，因为修改任何一个路口的红绿灯的设置，都会对连接到他的其他路段的流量造成影响，而每个路段的变化会对这个路段的另外一头的路口造成影响，而这个影响会继续传播到该路后的其他链接路段上。而如果这种变动的后续多个影响传播到同一个后续路口时，影响会叠加或互相作用。比如上图中1路口的变化会通过路段逐步向下传递最后会在8号路口上回合。1->2->7->8和1->5->6->8。改动一个1号红绿灯且不考虑其他外在因素的影响就会有如此复杂的变化，可想而知想找到一个算法或者公式来解决这个问题是绝对不可能的。

有一种解决方法已经在很多大学被提出用来寻找交通问题的解决方案：元胞自动机。细节我就不说了，毕竟还在研究和理论阶段。基本的概念就是把每个路段和路口都想象成一个单独独立的个体（元细胞），这些个体不必知道这个系统的大局，它们只知道有哪些其他的个体与之相连并了解与之互动的机制。每一个个体有自己的状态（比如交通流量），每一个时间段他接受外部对他的影响（流入该路段/路口的交通流量），并同时做出相应的反应和互动（流出该路段/路口的流量）。如果元细胞个体（路段/路口的数据模型）设计的好，在经过足够长的时间后，整个（交通）系统的状态（交通流量）就会趋向于平衡。

可以看出用这种方式来解决问题不需要考虑整个系统，只需要设计每个单元即可。然后让这些单元互动，并让这种互动持续进行，最终得到解决方案。问题的复杂度马上变得可以接受，这个过程中动用到
- 数据建模（设计元细胞）
- 自动机理论（设计元细胞的状态机器变化规则）
- 建立图Graph（利用设计出来的元细胞搭建和模拟整个交通网络）
其中的“图”就是离散数学中最重要的分支理论之一：图论（Graph Theory）。
而万恶的“自动机理论”更是很多大学计算机专业的杀手课程，但也是通向IT领域技术精髓的必经之路。它的学习前提之一就是需要你完全掌握离散数学。那它有什么用呢？大家知道图灵吗？图灵机？图灵测试？

饶了一大圈，终于绕回离散数学中了。累啊！

所以作为计算机专业最坑爹的课程离散数学为什么是各个大学计算机专业基础必须课，道理就在这里。你一个加减乘除都不会的人能做会计吗？一个不会几何的人能做机械/建筑工程师吗？

/* ------------------------10月3日跟新-----------------------*/

第二部分就是编程。

有一个需要绝对明确的是，编程应该是IT人的一个技能，而不仅仅是一个饭碗。在工作的时候你会发现IT领域是及其广泛的，程序员只是IT领域的一个小专业分支罢了。虽然我很喜欢编程，也是靠着编程的技术在两家公司里都获得了一席之地，但是从我开始工作后没多久我就发现了一个不能否认的事实，即使有程序员看完后要喷我，我也要说：做纯的程序员能出头的少之又少，而且地位真的不高。虽然钱多，但是死得早！我最早写程序，后来坐需求分析，做方案，现在正在有意识的往顾问IT方向发展。原因就是我觉得我能混的更好，干嘛还要累死累活的干体力活，而且还不被人理解。

究其原因我觉得无非就一个：程序员无法单独创造价值，且编程是生产不是创新。

首先：无法单独创造价值
IT本身在各个行业中就是技术含量最高也最抽象的，而编程又是在IT领域里最抽象的。它对程序员的抽象理解力和逻辑思维能力要求极高，而且要求做事要及其严谨。看似要做程序员得有这些优点。但这些优点却造成了程序员思维单一，不知变通，（与非专业人员）沟通能力差等各种问题。程序员是一个出直男癌的领域。本人就是一个活例子。
所以当一个客户需要做一个IT系统时，一般客户是没办法直接和程序员进行交流的，需要有专门的产品经理，需求分析员等人对客户的需求进行分析最后拿出产品的方案和设计，最后让程序员写代码。这些中间人士把客户的需求翻译成程序员能干活的方案。这份工作我敢负责任的说，没有一个纯的程序员能胜任，他们非得和客户打起来不可，原因就是程序员的性格和沟通能力，以及程序员不懂实际的业务。因此程序员如果不配套相应的中间层，是无法直接为客户解决问题的。

其次：编程是生产不是创新
一个程序员再拿到设计开始工作的时候就应该严格按照设计来进行开发，不能随意按照自己的意愿写代码，因为这个设计首先是需要需求分析人员进行需求分析，架构师选择技术并设计的架构，最后主程或其他高级程序员设计的模块后再开始写代码。每一个设计都是有其原因的。绝大多数情况下，成本原因要高于技术原因。加上现在开发基本大量采用模块，所以只需要程序员付出体力即可，不需要有自己的想法。久而久之，底层的程序员在多年工作后基本也不会有很大的发展，除了代码写得越来越溜，已经很难锻炼成独当一面的人才。

所以说，我不建议当程序员就是这个道理。

但是我坚决反对一个IT不会写代码。不会写代码的IT，不管你是哪个领域的，我个人认为都是渣渣。因为写程序不但能培养你的逻辑思维能力，更重要的是，你知道IT开发工作的成本和代价。类似“这有那么难吗？”“有个需求，实现起来很简单！”这种话如果是非IT人员说，我只能无奈，如果是IT人员说这话，我就觉得你就是个废物。

所有的需求（软件需求）最后都会让程序员来实现。如果你是负责分析需求的，你如果写过程序你就知道这个需求能否实现，代价会多大，让客户不要抱有幻想。如果你是架构师，写过程序会让你知道哪个架构技术上可行，哪种不行。如果你是做解决方案的，那更是需要会写代码，因为不会写代码的解决方案设计者做出来的方案就是放屁，最终只能讨好和糊弄客户。因为程序员做不出来的话，你这方案有任何意义吗？写程序不是流水线工作，加班加点的压榨，反而效果会更差。

所以，怨气十足的我还要再大声疾呼！
不会写代码的IT，都是渣渣！

不会写代码的IT，都是渣渣！

不会写代码的IT，都是渣渣！
坐等渣渣来喷我！

好了，那代码需要写到什么程度呢？这个我就给不了答案了！这个得看你的工作性质。理论上代码写得越好，你转型的时候，代码能力给你的加成会越大。但是同样，你付出的代价也会越大！不但是时间上的，写程序对你思想上的禁锢也会越来越明显。所以自己看着办咯。

有一点非常重要！怎么判断代码写得好？绝对不是看你的代码是不是写的非常快！不是看同样的功能是不是你用的代码量最小！下面我给几个我个人认为的标准：
1.代码是否简捷？ 不能像老太婆的裹脚布一样又臭又长！
2.是否高度模块化？凡是一个略微复杂的子功能在多个功能中会重复用到的，就应该写成函数进行重复调用。
3.代码对于其他程序员是否容易维护和修改？这样做会大大减少代码的开发和维护成本，特别在大项目中多名程序员合作的情况下。
4.会不会设计和使用算法及数据结构。你别说什么冒泡算法或者双链List这种教科书上的东西。好的程序员应该会根据实际的场景，利用学过的一切算法及数据结构的原理进行新的变种算法和数据结构的设计和开发。会用已经现成的，只是及格而已。这个就需要程序员熟练掌握离散数据的知识了。（参见第一部分）

/* --------------- 编程这部分我就写到这里了 后面看有时间或者有赞的话的话继续咯------------------*/