距离上一篇文章到现在已经过了3个多月，这3个多月，我没有写一篇文章，也没有制定学习计划。天知道这3个月我经历了什么。~~~
进了鹅厂之后的这3个月，前2个月，每天我都是在度日如秒的状态下度过。还记得第一次发版本，我居然有点失眠（当时是有多激动和多紧张）。每天感觉时间不够用，每天有看不完的代码，每天有学不完的新业务点。测试完一块地方，又有一块新的系统业务需要了解。这3个月看的C++代码，肯定比之前毕业4年加起来还多好几倍。几乎熟悉每个系统，都是靠走读代码去熟悉，然后再看一些文档进行辅助理解。没进鹅厂之前，虽然我也会偶尔看下业务代码，自己写一些代码，但是这还真不是一个等级的事情。后面1个月慢慢的习惯了这样的节奏和怎么跟同事相处，在版本不紧急的情况下，稍微能控制下进度了。
在这边工作跟以前在小公司工作，我有以下几点不同的感触：
第一：公司牛人真多，KM上的技术文档看得眼花缭乱，包括上面测试人员写的阅读开源测试框架的文档，看着让我觉得自己写的东西都是~~~~
第二：高效沟通很重要，怎么跟组长和测试负责人反馈测试进度，让大家都清楚当前项目的版本，风险，进度呢？
第三：快速熟悉一个系统，看代码能力急需提升。
第四：公司很多小福利，班车啊，食堂啊，这些小福利虽然不值多少钱，但是却觉得很暖心。
第五：每天都加班的生活，晚上8点钟就下班真不叫加班。
其实我不是很喜欢这样的生活和工作节奏，并不是神马老加班这种原因，是因为感觉自己每天都处于无法自控的状态，这滋味不好受。那问题来了？为什么每天我都处于这种状态呢？其实原因自己是心知肚明的。我想应该有以下几个原因：
原因一：c++编程基本功底不够；看c++代码很吃力，一些复杂的数据结构+一些复杂的语法，看不懂，导致业务理解速度慢。对于一个入门级别的我来说，一两天看完一个系统确实是很不容易的一件事。
原因二：总结的知识点不到位；每天学习不同的知识，遇到一些零碎的知识点，没有集中的总结，有时候偶尔会犯毕业生的错误，同一件事，问了2遍，这种事情不应该发生多次。
原因三：刚入职时，收集的资料不全面；这也有可能是由于当时能力的不足导致的收集资料的局限性。除了导师给的资料，应该主动跟部门老同事咨询资料库，部门文档SVN路径等地方。至少应该弄清楚有哪些DB，有DB相关文档；有哪些系统，系统大致介绍的文档等。
这几个月多多少少估计看了快几万行代码了吧，最深刻的感想就是对代码的阅读能力需要快速提升，思考下自己看代码和开发看代码的方法，还真是有点不一样。一方面：感觉我认识一部分测试人员看代码跟我看代码一样，都是拿着代码后，狂看业务逻辑，然后再总结下业务流程，然后等着测试了；但是开发似乎不是这样的，他们一般都是拿到版本后，先部署，然后一边断点调试，一遍查看代码逻辑。还有一方面：我看代码容易一开始就局限在一个功能点上不断深入的看，而开发哥哥更有那种纵观全码的气概。还有一个被灌输的理念在我脑子里，我觉得也挺对的：提高编程能力万无一失的方法就是阅读别人的代码。阅读那些经常用的库，编程框架的源代码，大牛的源代码。我觉得以下阅读代码的方法是可行的：
进了鹅厂之后的这3个月，前2个月，每天我都是在度日如秒的状态下度过。还记得第一次发版本，我居然有点失眠（当时是有多激动和多紧张）。每天感觉时间不够用，每天有看不完的代码，每天有学不完的新业务点。测试完一块地方，又有一块新的系统业务需要了解。这3个月看的C++代码，肯定比之前毕业4年加起来还多好几倍。几乎熟悉每个系统，都是靠走读代码去熟悉，然后再看一些文档进行辅助理解。没进鹅厂之前，虽然我也会偶尔看下业务代码，自己写一些代码，但是这还真不是一个等级的事情。后面1个月慢慢的习惯了这样的节奏和怎么跟同事相处，在版本不紧急的情况下，稍微能控制下进度了。
在这边工作跟以前在小公司工作，我有以下几点不同的感触：
第一：公司牛人真多，KM上的技术文档看得眼花缭乱，包括上面测试人员写的阅读开源测试框架的文档，看着让我觉得自己写的东西都是~~~~
第二：高效沟通很重要，怎么跟组长和测试负责人反馈测试进度，让大家都清楚当前项目的版本，风险，进度呢？
第三：快速熟悉一个系统，看代码能力急需提升。
第四：公司很多小福利，班车啊，食堂啊，这些小福利虽然不值多少钱，但是却觉得很暖心。
第五：每天都加班的生活，晚上8点钟就下班真不叫加班。
其实我不是很喜欢这样的生活和工作节奏，并不是神马老加班这种原因，是因为感觉自己每天都处于无法自控的状态，这滋味不好受。那问题来了？为什么每天我都处于这种状态呢？其实原因自己是心知肚明的。我想应该有以下几个原因：
原因一：c++编程基本功底不够；看c++代码很吃力，一些复杂的数据结构+一些复杂的语法，看不懂，导致业务理解速度慢。对于一个入门级别的我来说，一两天看完一个系统确实是很不容易的一件事。
原因二：总结的知识点不到位；每天学习不同的知识，遇到一些零碎的知识点，没有集中的总结，有时候偶尔会犯毕业生的错误，同一件事，问了2遍，这种事情不应该发生多次。
原因三：刚入职时，收集的资料不全面；这也有可能是由于当时能力的不足导致的收集资料的局限性。除了导师给的资料，应该主动跟部门老同事咨询资料库，部门文档SVN路径等地方。至少应该弄清楚有哪些DB，有DB相关文档；有哪些系统，系统大致介绍的文档等。
这几个月多多少少估计看了快几万行代码了吧，最深刻的感想就是对代码的阅读能力需要快速提升，思考下自己看代码和开发看代码的方法，还真是有点不一样。一方面：感觉我认识一部分测试人员看代码跟我看代码一样，都是拿着代码后，狂看业务逻辑，然后再总结下业务流程，然后等着测试了；但是开发似乎不是这样的，他们一般都是拿到版本后，先部署，然后一边断点调试，一遍查看代码逻辑。还有一方面：我看代码容易一开始就局限在一个功能点上不断深入的看，而开发哥哥更有那种纵观全码的气概。还有一个被灌输的理念在我脑子里，我觉得也挺对的：提高编程能力万无一失的方法就是阅读别人的代码。阅读那些经常用的库，编程框架的源代码，大牛的源代码。我觉得以下阅读代码的方法是可行的：
首先：在宏观上对代码有所了解。拿到代码前，最开始能对项目本身的大体功能有所了解，可以阅读一些开源代码简介，项目文档类似这种非代码本身的任何资料。对整个功能大致了解后，再开始从宏观层面对代码进行了解。比如：了解项目部署后文件的层次结构；项目的配置文件；项目的源代码层次结构等。
然后：阅读代码，断点调试，记录业务逻辑。如果项目部署在windows平台上，可以直接在vc上部署项目并调试，不过现在c++编写的后台程序基本都是在linux下的，在linux下就可以用GDB进行调试；
接着：改变入参内容，继续调试，总结业务逻辑。不断调试，熟悉业务逻辑，熟悉到一定的程度，除了画出业务逻辑流，还能画出UML的类图之类的应该可以更进一步加深对代码本身的理解。
一股劲的只看代码，虽然有时也能看懂，但是养成一个看代码的好习惯才是最终的目的。17年已经开始了，加油吧骚年！