说说入职两日的感受
伙计们，做好准备吧，南尘最近一定不可能日更的，不过不保证后面还会像现在这样熟悉架构熟悉代码到极度困，然后就想到我亲爱的朋友们，然后再和你们吹会儿逼。
前面给大家讲过，选择了待遇相对偏低的咕咚，主要是因为一面的面试官，给了我很强的震撼力，让我如同找到了同路人：同样在为代码质量而疯狂努力。
今天，在他的指引下，总算对咕咚的架构有了较为深刻的理解。
果然，大一点的项目，总需要一个靠谱的架构，不然一定会面临各种各样的问题。
确实很刺激，这会儿公司还有一半多的员工在疯狂干着自己喜欢的事。但丝毫不会影响，南尘会是那个每天来的最早的人~
今天看到致学发的关于我离职的文章，确实挺心酸的，不过好聚好散，还好我选择了咕咚这样一家还算注重技术的公司，我相信每一个致学人，也会饱含祝福。
对我来说，公司不在乎体量，我最在乎的还是团队对技术的饥渴，很幸运在这一点，咕咚让我足够满意！
咕咚强制采用 DataBinding && MVVM && ConstraintLayout 进行编写代码，之前也是一直没有去学习了解 ConstraintLayout 这个神奇的布局，今天一看，真心超赞，但使用文章我就不写了，鸿洋和郭霖已经把拖拽和直接手写代码的方式都讲的很清楚了，感兴趣的到他们的 CSDN 博客去仔细观摩观摩吧~
鸿洋的 ConstraintLayout 文章地址：https://blog.csdn.net/lmj623565791/article/details/78011599
郭霖的 ConstraintLayout 文章地址：https://blog.csdn.net/guolin_blog/article/details/53122387
对于 DataBinding && MVVM，可能小项目感觉不是很明显，但相对体量大一点的项目就真的太有价值了解学习了。这也难怪，咕咚和美团都在面试的时候问了我 MVVM。
然后，KotLin 的话，看了咕咚的代码，大概目前覆盖比例 15%，最近本宝宝也是好好学习了一波 Kotlin，只能说，自从 Google 开始推荐 Kotlin 后，我们就不得不学习了。
Kotlin 中文教程网站：https://www.kotlincn.net/docs/reference/
强烈推荐书籍 《Kotlin for Android Developers》，目前中文版的 PDF 可在公众号后台回复 "kotlin" 获取，但更强烈推荐直接查看原作书籍！！！
大概也没啥好说的，和我亲爱的朋友们交流了一下，感觉状态好了很多，我还是去默默做加班 dog 吧~
额，好像忘了一件事，之前不少小伙伴留言问我面试答案。
在这里再说一下，面试这个东西，真的没有标准答案，不过我可以给大家简单讲一下思路，要是以后有了时间，再详细讲吧。
RecyclerView 到底如何适配多种布局？
我看到问的最多的一个问题是，「RecyclerView 一个适配器如何适配多种布局」。
老实说，这个问题，我第一反应就是网上被人都写烂了的万能适配器，所以回答的就是根据不同的 Type 去设置 ViewHolder，毕竟我们通常设置 RecyclerView 的 Header 和 Footer 就是通过这样的方式来实现的。但这样的方式有一个非常严重的问题，就是其实根本就不万能，当我们遇到各种 Item 布局的时候，我们又得重新维护 ViewHolder，一旦这个布局方式多了起来，就会存在严重的维护问题。
那我们还能有怎样的思路来处理呢？
实际上，我们大多数，甚至是所有页面都可以用 RecyclerView 来实现，只是每一项的 Item 显示方式不一样而已。为了减少维护成本，我们显然不应该把判断是哪种 Type 的代码放在 RecyclerView 的「万能」适配器中。而应该把这个逻辑抽象成一个接口，然后让子类去自由发挥。然后在外面调用的时候，我们就只需要根据 model 的数据进行不一样的布局填充就可以了。
你可能会有点晕，其实我自己也一样，原谅我现在是从早上 7 点半一直干到现在的人，但我还是希望你能多看几遍。
好吧，看了好几遍了，还是一脸懵逼，姑且点到为止吧，时间关系，后面再做详细阐述。
上千个 Shape 文件如何维护的问题。
这是另外一个大家很关注的问题，在咕咚的面试中，提到了 CardView 不利好的一面，并阐述了自己面临成千上万个 Shape 文件无法统一维护管理的僵局。
这个题，其实我认为可能没有标准答案，只是面试官希望看你是否是一个喜欢并且善于思考的人吧。
一个开发人员稍微多一点的项目一定会遇到这样的难题，我们很难统筹所有经手这个项目的小伙伴都能认真先去看一遍别人 Shape 里面的实现，更多的时候会采用 CardView 或者自己新写一个 Shape 文件的方式。
CardView 可能功能没有那么全面，而 Shape 可能面临维护难题。
这是很现实的问题，那到底怎么解决这个尴尬的窘境呢？
经过思考，我们似乎可以通过自定义一个 View，支持各种圆角和其他的 Shape 或者 CardView 具备的功能就好啦~
可能有点投机取巧，不过至少说明我们很爱思考，哈哈。
写在最后
还有不少人问我 API 选择短连接而不是长连接的问题，我觉得这个问题，应该可以 Google 到吧，我就不想多提了。你可以思考一下，且不考虑客户端的性能问题，服务器接受 N 个来自客户端的长连接会怎样巴拉巴拉
差不多了，这下要真的去加班 dog 了，要是大佬们看到错别字，还请见谅，直接指出。我已经检查了 3 遍了，但我这个状态，恐怕难以处理~