小结
入职新的公司已经有快一个月的时间了，前两周的工作主要是进入对公司日常考勤、沟通等制度方面的熟悉。熟悉团队的版本控制系统，项目开发进度流程工具以及项目中的框架和常用的封装组件使用。因为整个项目在逻辑层全部使用Lua语言进行开发，所以第一周和第二周的时间熟悉语言然后是框架项目。
个人第一点很直观的感受，项目中leader布置的任务都很具有针对性。任务重包含了90%的工作使用场景，可以在没有项目实际压力的情况下去熟悉整个开发流程并且帮助你去发现一些你可能注意不到的一些微小地方。第二点，越是体量大的项目，对工具的二次开发和封装使用就越多。有时候你甚至不需要懂得Unity的使用依然能够完成正常的开发任务。同样的，你也要去单独花时间去熟悉所有封装好的工具、脚本等。对于不太熟悉Unity API的话，就需要花时间去辨别工具是原生组件还是封装过的组件，对我个人而言有时候通过看文档或者是询问同事相关工具的使用之后还是要去自己过一遍源码了解一些原理机制，这样才能够在BUG出现的时候第一时间找到问题点，不然就只能对着自己写的代码一脸蒙蔽。第三点，身边同事的帮助确实很大，问题一抛出的时候基本都可以得到热情的回复。
文档反复看！文档反复看！文档反复看！
很多问题的解决方法都在文档中，包括怎么用，怎么改，原理啥的。
问题
- 从第一周需求的完成中还是发现了对项目需求的不熟悉，不单单是当下需求中的内容。整个游戏中的流程和连带的一些游戏内容。对于同任务的其他人来说没有什么gap，所以有时候会默认忽略掉。但是这些细节都会阻碍我需求的准确完成。每个新需求的提出都会通过宣讲会进行一个讲解，但是由于还没有熟悉内容就进行了宣讲所以会错过很多提问的机会。这确实会对后续开发有些阻碍。所以还是要加强对项目的熟悉包括玩法流程、测试方法、实现细节等。
- Unity + Lua的开发环境会不像纯C#开发那样依靠IDE帮助自己理清所有的代码流程。Lua会在中间出现断层，依靠一些经验和调试工具去理清这个脉络。包括Lua语言上的一些机制，在阅读代码中有时会不如C#代码看的简洁明了。Lua这种脚本语言在没有类型判断的时候确实是在写方面有优势，但对于读熟系业务流程不如有类型提示的语言看起来方便。自己目前对Lua数据结构的判断还不够熟系。
- 在之前实习的过程中，对于需求总是很快的开始动手写代码开干了，缺少了对需求中要完成的内容的整体规划。有时候写着写着就感觉不对劲了，改之前写的接口，重新确认数据结构。或者是写着写着觉得整体规划不合理了，继续写就是能跑的烂代码了，但是修改就需要花额外时间了。自己还需要在开始写代码进行一个清晰的规划，提前预判或者测试解决可能会出现的难点。
