设计原理自考代码怎么看不懂

1、找人教，找资料

新接手一个代码，怎么看最快？看书？自己调试？都不是，是找之前写这个代码的人耐心讲给你，不过工作了就发现大家不一定都这么好心。不过万一呢，万一你遇到好人了呢，先找人，再找文档。

怎么找人？查看git历史，查看代码中的注释。看开源代码怎么办呢？这个是另一个神奇技能---社会工程学，想办法通过注释和社工找到开发者的邮箱和联系方式。找到人找人教你如何运行或者发给你文档什么的。找uml设计图。

2、跑起来

想办法先把代码跑起来。为什么跑起来这么重要。跑不起来的代码没办法调试和打log。

3、断点调试，单步调试

上学的时候写hello world，当时实在没懂得gdb什么的是干什么用的，但是上了班发现模块很多会遇到一些理解不了的bug，不过断点调试然后单步调试查看当时的变量就清楚了。断点调试就是设置一个断点让代码运行到指定的地方，单步调试就是运行到你想要的地方的大概位置开始让程序一步一步跑。

4、打印各种日志

看控制台log

写文件log自己做一个控制台安利应该看看Effective Debugging这本书。

5、历史

大树不是一天长成的，罗马不是一天建成的。拖进source tree，查看提交代码的历史更改。git log会告诉你为什么这行代码这么写。git blame for line会告诉你这个代码是谁写的。当项目非常大的时候出于学习目的可以找最早的tag来进行理解。100.0的tag看不懂就先把tag切换到0.0.1的代码来读。

可以除非你是超级天赋选手，否则学习都会有一个从易到难，从难懂到理解，而且编程本身就是一个学习门槛比较高的领域，要想明白代码必须要在语言、数学、物理等领域了解，否则就很难进入实操，不过通过一些比较专业的教学机构和一些科学的学习方式可以很快的就能进去该领域工作，然后在工作中学习。

许多灵活用工就是这样，一开始不是很懂，有些是才有转型的想法，通过一些灵活用工的机会让自己慢慢尝试慢慢适应，最终成为技术大牛。

简单说先从需求分析（首先要搞清楚看的代码是用来做什么的），解然后是系统分析，最后是块的理解。如果反过来行行的代码猜它的组合逻辑，这有没有什么价值。

看懂代码其实不难大抵不过是选择分支循环。

语法如果看不懂那就需要补补基础，先要弄清楚这段代码要做什么，如果有说明最好，可以帮助理解，没有说明就试着过一下代码流程。

看懂代码小技巧：

1.哪里不懂就输出哪里

通常代码看不懂，是不知道变量代表什么含义，对应于文章中的哪一个概念，只要print即可。

如 print(‘a:’,a)

2.在一段代码中，可能同一个变量值会发生变化，可以在变量后面加上标号。

如：

print(‘a1:’,a)。

print(‘a2:’,a)。

初学者要看懂代码首先从要需求分析了解，然后是系统分析，最后是块的理解。看懂代码其实不难，大抵不过是选择，分支，循环。语法如果看不懂，那就需要补补基础，先弄清楚这段代码要做什么，有说明最好，可以帮你理解，没有说明就自己试着过一下代码流程。

采取一种可称之为“反推法”或是“逆向法”的方式，这个问题就迎刃而解了。要知道，代码的目的是实现功能。无论你用那种代码，有一点完全相同的就是“实现功能”这个最终结果。了解到这一点，我们就可以通过结果（功能）去反推过程（代码），代码的思路、流程、用途就抽丝剥茧清晰的显露出来。

程式码是别人写的，只有原作者才真的了解程式码的用途及涵义。许多程式人心里都有一种不自觉的恐惧感，深怕被迫去碰触其他人所写的程式码。但是，与其抗拒接收别人的程式码，不如彻底了解相关的语言和惯例，当成是培养自我实力的基石。

对大多数的程式人来说，撰写程式码或许是令人开心的一件事情，但我相信，有更多人视阅读他人所写成的程式码为畏途。许多人宁可自己重新写过一遍程式码，也不愿意接收别人的程式码，进而修正错误，维护它们，甚至加强功能。