我的总结并不会具体到某一种语言、每日具体学了些什么，包括JAVA也好、Android也好、Linux也好，这些都只是工作时会用到的工具，我更多想说的是想记录一下本人在工作里的一些小想法、小念头。

在结束了大多数安排好的大多数轮岗计划后，本月正式步入了更加具体且系统的部门培训，所学内容并不能让我们马上投入到具体项目里面，也并不能让我们能够马上的产出优质的企业级代码，更多的是熟悉包括像gcc等编译环境以及Makefile的编写、C语言、Java等语言开发环境，了解业务逻辑，从阅读MCU代码，到学习Uboot并知道如何在Uboot中嵌入我们编写的代码，到学习并生成动态链接库.so，独立编写Linux内核驱动程序，再到编写JAVA应用程序，通过JNI实现对C语言算法库的调用。整个的一个培训内容囊括了从底层uboot启动到Linux内核到 JNI再到JAVA应用层以及相应编译工具的使用、对应工具链的调用，当然，实际项目里包含的内容要比我们接触到的更加多、也要更加复杂，仅对部门内使用的从内核到Android的框架来说，对于我们就还需要更多的时间去阅读源码、去理解流程、去实践。关于培训的具体内容，平日里的都做有详细的笔记，自己也会定期复习查看，看是否会有新的理解，这里不做过多赘述，更多的仍是一些自己的感悟或者一些平日里的思考。

​ 先讲一点无关紧要的空话，这两个月的部门培训，最重要的，不是说又新学了什么编程语言，也不是说又新会了一种算法，又或者是又新学会了某种特定语言的编程规则，这些都是能够通过在短时间内学习快速掌握的东西。我们这两个月更加值得关注的是培养一种思想，编程思想，而不是具体代码，作为程序员我们不是要去一味埋头苦干做码农，而是要去学习里面包含的更多的内容，要在平日的工作里，从一个小环节开始，逐步对整体开发流程有更系统的认识，在每次完成项目的时候能够注意到这些，才会有收获，代码质量才会有质的提升。

​ 入职两月以来，关于工作内容接触最多的是代码，感触最深的也是代码，和我们在大学里自己写的代码相比，这两月接触的单独一个项目的代码量要多的多，代码逻辑也要更加复杂的多，一本书里看到的一句话，我觉得很贴切，我们在大学里写代码，就像是在写一封信，我们只需要将它从头到尾写完就好了，不需要做太多的计划，根据需求去写代码，需要什么，我们就去添加什么代码、实现对应功能。这是一个更加个人的活动，在整个开发过程中，有相当多的原创内容，有原创当然好，但是就软件开发的效率而言，要低于专注于重用已有项目的一些思想、代码以及测试用例的开发效率。软件开发也并非只是个人的活动，一个软件项目并不会整个的交有一个人去完成，会涉及承担许多不同职责的很多人。就像是在平日里的完成导师安排的任务时那样，我们需要从头到尾的从最底层的设备注册、读取函数的实现、数据的传递、so库的调用怎么是使用工具链去进行编译以及最后应用层的调用去实现一个小的demo，仅仅是一个很简单的demo就花了我们一周的时间，中间一度感到很沮丧，认为自己效率低下，抱怨自己没有安排好时间，以至于需要把上周的任务遗留到下一周去完成，明明已经每天都在电脑面前花费时间，最后的结果确并不能让自己满意，也并没有在规定的一周时间内完成。我们在完成小任务时所做的开发工作太过简单、太过单板了，整个软件开发过程一种需要耗费大量时间的试错过程，而不是规划和设计。我们在完成任务的过程中，自己独立从头到尾的埋头开发、写代码，会面临各种各样的问题，有时候一个很简单的问题就会耗掉半天的时间，明明很多事情在一开始如果能看的更多一点就能直接避免的，比如编写的驱动程序因为编译的工具链使用不对和手里的机器平台不一致无法insmod、编写的so库因为环境配置问题没办法被调用。 虽然这些问题最后都被解决了，但是解决得毫无成就感，甚至觉得是很懊恼的一件事，因为这些问题都是一些如果事先能更多了解就完全可以避免的事情，很不满意自己的进度以及效率。曾经和友人开玩笑说这都是因为侯世达定律：做事所花费的时间总是比你预期的要长，即使你的预期中考虑了侯世达定律。但仍是不满足于自己的时间被这样白白的耗去，极力想找到一种在软件开发过程中能极大提高效率的方法，所以我去读了《人月神话》这本书。

​ 在部门培训的过程，是一个知识积累的过程，我们独立去开发完成一个小的demo，从无到有、从0到1，它并不是像阶跃函数那样在某个时间点一下子就全部掌握，甚至不像是Relu函数一直保存着一个固定的速度，更像是Sigmod，在有的地方会进展非常迅速，但是在某些节点需要花费大量时间。当然完整的走过这样一个过程能够很好的加深我们对整个系统流程的理解，但是对于软件开发来说，这样的过程是及其没有效率的，在以后的工作中当然不可能再像培训期间那样给你这么多的时间和机会去从头到尾的去进行开发、去试错，这样成本太高。我们需要做的是掌握一个整体的框架，学习整个软件系统，知道怎么去为软件系统增加一个小部分，以增量的方式进行设计、编译和测试。在完成任务前，先搭建起我们需要的知识体系及骨架，再逐渐一点点把真实输出的代码替换上去，一次增加一小部分代码直到得到一个完全可以工作的系统。而并不是像我们之前所做的那样，一味的想去完成任务，即便并不知道自己做的是什么。

​ 下个月会被安排进项目组进行更加具体的学习并渐渐开始接触实际工作，希望自己已经对真正的项目有了一个简单的了解和准备，不至于在接触实际工作时太仓促，甚至是没办法完成任务拖整个项目组的后腿。这里写的仅仅是对一些自己在部门培训期间所想的以及一些对于以后实际项目软件开发过程中想要去做到或者认为自己应该怎么做，有很多前后矛盾的地方，也并不是很深刻，词不达意，我也就一个刚入职两月的小年轻，各位前辈如果看到，还望不要过多笑话，有很多稚嫩或者错误的想法，希望能得到指正和建议。