中科院自动化所实习总结（完）

实习单位

中国科学院自动化所

工作内容

项目涉密，不便介绍

负责内容

负责完善文档，画流程图，UML类图之类的
写小模块的代码

实习感悟

大概的整个过程

其实在这段实习中，我得到的最多的并不是技术上的成长，而是业务上的成长。
我先简述一下我来实习后的流程：

初到工位的时候，导师把文档给我，让我熟悉项目，接下来1周时间都在了解项目在做些什么
给我代码文件，让我熟悉代码，从头文件开始，输入输出，各种结构体，各种enum，define的结构，然后就是所用到的函数。
让我结合代码文件和文档，对文档中一些比如流程图画的不清晰的之类的问题进行修改—就是改文档
熟悉完项目后，对我自己负责的这个模块的文档进行修改，看看是否有一些没有明确的需求，结构体的定义之类的有没有什么字段缺失或者多余等等问题。
前期和导师一起去和相当于产品经理的角色的一个人沟通需求，确认怎么做，后面大体没有问题了我自个儿去和产品经理battle。
写代码

总的来说，文档大体没有问题，但是这个项目有一些需求并未确定，所以文档常常需要进行改动。
也因此，和产品经理的battle以及理清项目逻辑以获得一个完整清晰的项目文档这件事是占用整个实习时间最多的。

获得了什么

对团队协作沟通能力的提升
由于非科班，从对计算机感兴趣到走上这条路再到现在，一直是一个人。大家都知道团队协作这个词，但是真的碰着了就会知道还是挺麻烦的。
最深的体会就是：两个头头因为某一个问题，一个人觉得这么考虑可以，一个人觉得这么考虑不可以，于是俩人就争了有1个来小时，我躲在电脑后边笑。后面自己在做实习总结的时候回想这件事情，发现两个人争执的过程中，都非常有礼貌，哈哈，没吵起来，每一句话我听着都有道理（当然也有可能是因为我听不懂），然后讲完自己观点之后，说：我觉得这么考虑挺好的，你觉得嘞。虽然这个东西最终两人没争出个结果，但是两个人整个的思维碰撞过程，学到了学到了，争一个来小时不急躁，有条理有礼貌，这个沟通能力不是谁都有的。
当然也有我自己的例子，由于我自己负责的是一个小模块，和其他小模块有关联，所以时常需要和对方对接，其中就碰到过实际并不应该是我这个模块负责的内容被划分到了我这儿。我当时觉得我在项目中的任务和目标挺明确的，这绝对不应该是我这个模块该干的活儿，所以就去找了导师，导师让我自己去跟对应模块去沟通，哈哈哈，这个就跟和产品battle一样，但是比后者简单多了，因为大家都是开发嘛。
总之对于团队协作，个人认为最重要的一点不是得出多么完美的结论，而是保持和气，各退一步，保证项目的顺利推进。如果想要项目进度停滞，双方都无法继续进行工作，那可以多battle试试
教训

每一次的沟通都需要留下问题交流清单：用来秋后算账，当时谈的东西过两天可能就忘了，后面再谈到这块儿，人家可能会说：啊，是这样的吗，我当时不是这样说的呀！惨痛教训！！！
对于不确定的模糊的东西，甚至可能已经确定的东西，都要在下一次的battle前汇总好，提出来，讲清楚，防止某些东西变了而你还在吭哧吭哧写无效代码。

灵活性
因为项目需求和情况可能会发生变化，所以，你的代码必须要留下余地进行修改，达到尽量少的改变原有代码结构的目的。也因此，良好的编码习惯非常重要，心中要对设计模式，代码设计原则有数，像低耦合高内聚，单一职责等等超级重要，正是因为项目需求不明确，我手里的代码也改了一版又一版。但索性，在开始写代码的时候就很详细的把自己想怎么写，类怎么设计，接口怎么写怎么调用都写的清清楚楚，哈哈哈，所以没有对代码大改，不用各个文件的找有没有依赖。
及时和产品经理沟通
为啥要跟他沟通，因为你会不会累成牛马取决于他。如果不和他沟通，你就不晓得需求变没变，就不晓得你对于需求的理解和他的有什么不一样。他不了解里程碑的达成情况，不晓得你的进展，如果前边你错了，后面就会在这条路上渐行渐远。
写完代码后花尽量花时间去重构代码
因为你在写代码的时候肯定会产生头脑不清晰的情况，虽然逻辑出来了，算法是对的，但不代表它不是一坨大便。
学生思维的转变，应对压力
尽管说大学是小型社会，但是实际的社会和学校还是区别很大的，这更多是一种感觉。就像你小升初，初升高，高升大学，每个阶段明明没有相隔俩月，可是好像大家都两个月就变了。这是身份带来的转变，好像一夜之间要你懂得所有这些身份附加的要求并做到它们。
这会倒逼你很快的学习，很快的适应环境，说实话，虽然感觉不大对劲，但是我挺享受这种忙碌的感觉，很充实，搞出来了东西也会很有成就感，累了的时候去打打羽毛球唱唱歌，别提多滋润，这也是我当初喜欢上计算机这条路的关键，哈哈哈哈。
当然，可能因为我是实习生所以对我比较好。