这半年经历过十几家的面试，经历过不停的回顾以往总结的面试题。直到离职，直到六月的到来，直到确定入职熊厂。入职后的适应、忙碌、感慨，终于到现在能静下来梳理一下，这几个月的心路历程。
思考
来熊厂已经三个月了，没有大家想的有那么多的争论，可能每个团队之间也都是不一样的，也可能是我之前接触的团队在各方面对于我厂还是有一定差距的。
现在回想一下曾经的三轮技术面，虽然都说面试造航母工作钉钉子，面试官问你一些原理、聊些性能，其实都是有一定原因的，比如说他的项目中就是用到了很多这种框架而你就必须了解它们的原理你才能用得更好，甚至你才能会对他们现在项目中所属的一些东西提出一些建议，怎么去优化怎么去修改，让大家不同的想法碰一碰。而一些自定义View，现在大厂中必备的技能，频率非常非常之高，可能每个人对自定义View的理解也不尽相同，又说可能说有三种可能说有多种，其实在大厂中用的最多的那种叫做自定义组合View。
因为大厂里不建议你直接去画一个View，即自己去绘制的这个控件，而更建议去使用原生的或者现成的优质View，即能去组合就去组合，所以这也体现了自定义组合View的重要。自定义组合View因为可以把自己的逻辑封装到一起，这样可以即简洁又高效。其实有一些部门可能会专门去画一些View，封装这些View以及框架等，或者说有一些专门的人就做一些纯绘制View。这样会避免一些自己画的可能兼容性和通用性不是很好，也可能还会隐藏其他的BUG，所以说大厂中很不建议自己就画一个View（直接继承View和ViewGroup），因此说自定义组合View成了一个大厂的基本的一个要求。
然后性能之类的就是考虑你的编码中代码质量呀之类的一些要求，然后还有些框架的原理啊那就是可能这一个项目他会用的很多很多很多东西，那你真的是必须要知道这些东西才能去了解整个项目的东西。
在大厂中不是说一个项目真的是只是一个简单项目，而是可能在大厂中有一个核心的一个超级APP，而其他的APP所用的什么架构，比如说组件化呀之类的其实都用的是那个超级PP他们团队所研发出来的东西。其它的APP,虽然还没有到达超级App的程度，但其实它已经引用了一些很核心的东西已经具备了这些，只是还没有达到这个体量而已。
所以说需要你的知识面真的需要很广，然后就是你在大厂中所做工作涉及不到说的那么深，但是如果说你能懂这些，那之后的项目中会更快的去，了解整个项目的架构以及业务流程等等。以上这些就是我在这几个月时间里所体验到的一些心得和思考。
建议
平时我们都知道，但是真正编码时容易“忽略”的几点小建议：
1. 不要让别人代码对你的代码有所影响。比如说：上面的代码里进行了判空，然后你这会儿就可以不判空，这样是不对的。因为在某些需求中其他同学或者你自己可能改变前方的代码逻辑，可能导致该字段为null啦，然后如果你之前不判空，此时你的代码就会受到影响。因此不要让前方的代码对你的代码有所影响，即你的代码需要具有一定的独立性。
2. 必要的判空是一定的，还有就是各种数组和集合的越界行为。前期，在编码过程中可能已经进行了一些数组越界或集合越界的一些判断。但是在提测之前如果修改了跟数组和集合相关的任何的逻辑，都需要考虑一下是否会越界。
3. 其实也是响应第一点。在你已编写完一个需求时，这个需求只需要改动部分代码，后面很多代码都没有任何改动，在自己验证呢的过程中也一定要全面的验证，哪怕后面的代码没有修改。比如说：一个界面中，你只是新增了一个View，但是此时数据源在原来基础上多了一个三方的数据源，而可能就是由于这部分数据源的新增，导致某字段的缺失或者类型的改变，就会导致后面的逻辑产生crash。因此提测之前一定要去进行全面的验证，多点点多验验即double check。
4. 大厂中更注重对齐，比如说：Android和ios双端技术对齐，技术对齐指实现某一功能时尽量做到实现思路方式大致相同。这种对齐的好处不言而喻，问题好排查、可避免单端思考欠缺、双端人员不同时在时也可以处理或者分析一些case等等。
5. 代码质量和项目文档。项目文档：项目文档绝不是写写而已，项目文档不是描述需求或草草完成技术评审，也不是需求相关的杂乱信息的堆砌，而应该是需求方案设计思路的管理，应该是需求设计的取舍记录。
- 代码质量实际上包含：代码风格、单元测试和code review。 风格：从变量和方法等的命名，到必要的注释，每个公司要求的都不一致，保证良好的代码编写习惯即可，尽量做到见名知意、简洁易读；
- 单元测试：说到单元测试，实际上Android的单元测试在日常开发中应用是很少的，即便是大厂中，不过大厂中也会鼓励大家去进行单元测试，而以往的单元测试都是各个语言的，比如Java、Python、Go等，而Android的单元测试还是不太一样的，而往往大部分的Android开发是不太了解的，即便是我本人也只是了解一点相关的知识 Google官网的测试相关知识(中文哦) ；
- code review(代码审查)：在开发阶段是很重要的一个环节，尤其是提测到上线前必须做好，code review不仅是提升代码质量最好的方法，还是团队内传递知识的重要途径，以及辅导如何写好代码的最好方式。
什么是bad code： 1. 5分钟内不能看懂的代码。 2. 需要思考才能看懂的代码。 3. 需要来回翻屏才能看懂的代码。 4. 没有空行/注释的代码。
感受
工作三个月以来，每个时间段都有不同的感受，每次的感受都对自己产生一些冲击。
1. 首先，入职第一个月的前半个月，了解项目的过程中发现整个项目是很完善的。
完善包含：业务逻辑部分、性能分析部分、基础组件部分。虽然业务逻辑部分是可以看懂的，但是整个项目是如何运行起来的，一开始是真的没看懂。
后来专门研究了一下，发现整体是通过自定义gradle插件来实现构建的，这也就能证明若你懂一些gradle插件的知识，就能更快、更全的了解项目，虽然了解这些可能对于开发项目来说没有多少帮助，但是至少能知道项目构建或者一些性能检测的原理，然后可以通过学习其实现的思想去提高自己。
2. 然后，进入组内进行需求迭代开发阶段，这个阶段需要细致的了解负责的模块的代码逻辑
此时会发现其代码的复用程度是很高的，业务逻辑也是比以往项目复杂的，因此我们需要设计让自己的代码更具通用性。此阶段结束时，发现此时的同学们自觉性、负责任的态度好的不行。每个人不需要去安排，在发现项目中某部分代码可能存在问题，或者某文档缺失，都会很自觉地就去补全。有优化代码的同学、有去完善文档的同学、有总结小"坑"的同学......此时对于我的感觉就是如此美好。
3.可能是大学毕业，入行以来第一次感觉到身边有如此多的大佬。即便是刚入行时，自己的懵懂，但是在通过两个月的学习也感觉团队技术就这样。后来，由于感觉自己技术实现烂，开始不停的学习，三年来每个团队感觉大佬都不是很多，而且大家学习的积极性也都不高。而现在不一样，大家厉害又好学。
哈哈哈，所以说要更努力啦，好习惯可以是养成的也可以是学来的，向团队各位大佬学习...
4. 大厂和小厂各有优劣。
小厂面广，可能什么技术都能接触到并且用到，但是可能理解不深、思考不深，每天就是迭代迭代，没有一个健全的制度。
大厂"面广"又面深，此"面广"和小厂面广不一样，能接触的多，但是不一定都是你实现，比如说可能用到很多优秀的框架来搭建整个项目架构等，以及性能优化等等，但是这些都不需要你去实现。
面深，指的是编码中需要考虑的更多更全，甚至需要了解其一定的原理，毕竟现在大厂如果不懂一些源码的原理和一定的算法能力，很难进来。
大厂还具有更全的机制，每个版本迭代的周期，需求的等级，各种排期等等，小厂可能老板或者产品、测试一句话就需要改变某需求但是排期不变，但是大厂一般不会出现这种情况，即便需求变更则需要重新评估工作，确定是加班消化还是delay。
5. 大厂更具备成长的环境
不仅可以通过自己学习，团队之间交流学习，还可以通过一些厂内公开课学习。比如：新技术或者新版本出来时，可能都会有相关同学去分享；或者其它技术经验、开发经验的分享等。
面试题
我还能想起来的部分面试题，平均每一面一个小时出头。大家面试时最好自己能每个问题都多说点，从一个问题能扩散开来回答。一方面是体现知识面广，另一方面是自己说的多了这样面试管会对你此问的知识点了解的更深，之后问的问题也会相对较少，毕竟时间有限，哈哈
