Tensorflow源码学习经历（二）

前言

接上篇，编译成功之后进度停滞了很长时间，不知道从何入手，期间寻找了大量Tensorflow源码级的教程，虽然折腾的都没啥结果但是也算对tf有了一点基本的认识。直到得到了老师的一些点拨之后，才使得对Tensorflow源码的研究能够进一步的进行。
首先，老师指出了我在操作中的一些问题，并给我讲解了对不熟悉的内容操作时需要遵守的几点原则。

保持系统干净

老师指出我的第一个问题，在于系统不够干净。这边不够干净的意思，是指装了许多重复、冗余的东西。这些东西会使得Linux系统变得很乱。

例如，我在tensorflow编译的过程中，尝试了git直接下载tensorflow源码，也尝试了在github上下载tf代码后再解压。两者虽然大同小异，但是前者是把整个tf的源码都存在了本地，可以方便版本控制和更新；后者仅仅是下载了某个特定版本的tensorflow。

再比如，因为经过了多次失败的尝试，bazel的版本、python的版本、jdk的版本都已经乱的自己都搞不清了。虽然最后是成功了，但是如果保持系统的干净可以少走很多的弯路。这些版本的控制问题对我们这些刚入门的新手来说可不是什么简单事。

所以对于新手来说，越简洁越好。

保存系统的快照

我们需要保证系统的简单、干净，但是新手在操作时不可避免的会发生错误。这时候我们再重新进行时，很有可能会出现卸载不到位，部分软件有所遗留，会与之后继续尝试时产生冲突从而发生各种奇怪的问题。

所以，我们应该及时的保存系统的快照。快照即是记录系统当前的状态，之后可以随时将系统恢复到该状态。如图所示，可在Vmware中找到快照管理器，并且当前系统的快照保存。

当创建了一个快照后，在之后的操作中，若发生了失败，便可以随时恢复到这一保证系统整洁、干净的状态下。

仅跟着一个向导走

因为无人指导，并且没有基础，所以我们在完成不熟悉的领域的操作时一定是按照向导走的。这个向导可能是官方文档，也可能是CSDN或者简书上别人成功的经验，也可能是github上issue的解决方案。

在完成同一个目标时，不同向导所给出的解决方案往往是不同的。这里的原则是，我们选择一个与我们本机环境和当前状态最接近的一个向导，然后在之后的一步步操作中，仅仅跟着这一个向导走
。如果发生了错误无法顺利进行，这时候我们不应该去参考另一个向导操作我们当前的向导中并没有进行的操作。这种所谓的“查漏补缺”，综合两个甚至多个向导的方法有时也许能够解决当前的错误，但是往往会带来更大的隐患，在之后再遇到问题时，这时候解决所要花的力气可比原来大多了。

仅跟着一个向导走，当出现了问题时，尝试去解决，如果实在解决不了，这时候我们在转向另一个向导前，应该恢复快照，回到之前那个向导一步还没有操作的状态。

弄懂问题并及时记录

出现问题时，我会习惯性的去搜索这个问题，百度不行了再转去谷歌，然后将各种大神那种说不清原理所在的偏方一一尝试。运气好试个几次就试出来了，运气不好时一两天也解决不了一个小小的报错。

需要注意的是，在使用网上的某种方案解决问题时，我们必须要确保自己弄清楚这个解决方案大致的策略，并且及时的记录遵循该解决方案你所需要进行的操作。更保险的甚至可以在使用解决方案前保存快照。

这一原则也是尽量的保证你的系统不会发生奇怪的改变，这种奇怪的改变往往是我们这些新手难以理解的。就算你通过解决方案解决了当下的问题，但是你不懂原理，不知道进行了怎样的改变，并且不及时记录下你的解决方案的话，之后大概率你会忘了你曾经对系统操作过什么。这一小问题的解决可能会导致连锁反应，导致新的问题，你并不知道你之前做的意味着什么，甚至记不得你做了什么。

总结

新的问题不一定立刻会出现，但是迟早会出现的。所以我们必须了解我们每一步操作的意义，并且确保我们能记住我们曾进行过的操作。当发生路走不通的时候，我们应及时回退到还处于正确的路上的状态，而不是随便找个岔路解决当下的问题，却使得与目标越来越远。

有了这些概念之后，才能在不熟悉的领域进行探索，不然就像我一样，所有的时间都花在解决莫名奇妙的问题上了，并且一个接着一个，完全不知道自己在干什么。