历经半年进大厂后三个月我有些话想对Android程序猿们说，以及那些大佬们隐藏的技能(1)

最新推荐文章于 2024-07-19 11:42:08 发布

2301_78398209

最新推荐文章于 2024-07-19 11:42:08 发布

阅读量252

点赞数 5

分类专栏： 2024年程序员学习文章标签： android log4j

本文链接：https://blog.csdn.net/2301_78398209/article/details/137303089

版权

2024年程序员学习专栏收录该内容

262 篇文章 2 订阅

订阅专栏

**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. 然后，进入组内进行需求迭代开发阶段，这个阶段需要细致的了解负责的模块的代码逻辑

此时会发现其代码的复用程度是很高的，业务逻辑也是比以往项目复杂的，因此我们需要设计让自己的代码更具通用性。此阶段结束时，发现此时的同学们自觉性、负责任的态度好的不行。每个人不需要去安排，在发现项目中某部分代码可能存在问题，或者某文档缺失，都会很自觉地就去补全。有优化代码的同学、有去完善文档的同学、有总结小"坑"的同学…此时对于我的感觉就是如此美好。