帮别人填坑到心累

[kuyuzhiqi]

11 月底换工作，Android 开发，另外一个小伙伴兼职(同时做两份工作)，我全职，进去后发现他的代码很乱，各种耦合，变量名定义不规范，签名文件的密码 123456，我的简历在 git 仓库里面(滑稽)，还一直丢自己的 bug 让我改，这个项目是他开发的，现在是各种小问题不断。

进去的时候耐着性子看完代码，并花了一个星期简单重构了下，想着以后代码结构什么的弄好点，但昨天发生了两件事让我彻底心累了：1.做的 app 没有适配 Android8.0，导致在有的手机上图标显示默认 logo，他和我说是第三方的 sdk logo 覆盖了系统的 logo，将 ic_launcher 换个名字，我的想法是为什么是第三方 sdk 覆盖 app 的呢？不想下这个问题就去换名字？我的做法是创建一个 image asset，最后证明我的是对的； 2.原来的项目中 mimap-xhdpi,mimap-xxhdpi...和 drawable-xhdpi,drawable-xxhdpi...两种文件夹同时在用，我想着这样很混乱，他还一直坚持要采用原来的结构，好不容易得到他的默认许可后，就全部将图片素材移动到 mimap-xxx 类型的文件夹，我是在 develop 分支上开发的，他说我不该提交这么大的改动，我在 develop 分支上提交，又不是 release 分支上提交的，而且这个素材改动在编译期间出现的问题就可以发现，然后在 qq 讨论组和我争论了半天。

以前的代码还出现过在启动的时候有几百次登录请求，在讨论组里面问后台为啥拒绝请求，想想也是挺搞笑的。哎，你代码那么乱，别人帮你重构，不感谢不说，还各种阻挠，公司的人也说让他拍板，我前面也有个 Android 开发在试用期间就走了，我现在还没过试用期。

[whileFalse]

前面的那个小哥是你的榜样啊。
工作不仅仅是 make money，也是生活的一部分。
我完全理解那个兼职小伙伴是怎么搞出来这一坨的，但理解不等于应该承受。

[huclengyue]

mimap 是存档 luncher 的 drawable 存档资源群的这两个文件夹功能不同。本来就是要一起用的啊。

[huclengyue]

@huclengyue 存放。

[kuyuzhiqi]

@huclengyue 刚开始的时候只是用来存放 launcher 的，但 as2.1.2 将 mipmap 分成多个文件夹，方便适配。都可以放吧，只是一起用比较混乱

[d3vil]

有能耐去 bat 享受工作，没能耐就在这公司拿钱做事别想那么多，然后自己暗中酝酿，酝酿出一定实力跳槽走人，老板都说了让人家拍板，道不同不相为谋，人家根本不愿意去想你说的东西，你何必和自己过不去？到头来搞得你和那个能够拍板的人关系不好，老板也觉得你怎么这么多事？挺简单的事，没有必要给自己添堵，徒增烦恼。

[hjw45611]

一开始没看懂 mimap 是啥，看了半天才知道是 mipmap，Google 官方是推荐除了启动图标以外的图片资源都要放到 drawable 的。

[huclengyue]

mipmap 文件夹下的图标会通过 Mipmap 纹理技术进行优化。android 中的 mipmap 技术主要为了应对图片大小缩放的处理，在 android 中我们提供一个 bitmap 图片，由于应用的需要（比如缩放动画），可能对这个 bitmap 进行各种比例的缩小，为了提高缩小的速度和图片的质量，android 通过 mipmap 技术提前对按缩小层级生成图片预先存储在内存中，这样就提高了图片渲染的速度和质量。

api 中通过 Bitmap 的 public final void setHasMipMap (boolean hasMipMap) 方法可以让系统渲染器尝试开启 Bitmap 的 mipmap 技术。但是这个方法只能建议系统开启这个功能，至于是否正真开启，还是由系统决定。

res 目录下面 mipmap 和 drawable 的区别也就是上面这个设置是否开启的区别。mipmap 目录下的图片默认 setHasMipMap 为 true，drawable 默认 setHasMipMap 为 false。

google 建议大家只把 app 的启动图标放在 mipmap 目录中，其他图片资源仍然放在 drawable 下面。

其他的资源图片放在这里面，可能因为会压缩导致显示问题吧，毕竟分辨率奇葩的手机一大堆。

[zcljy]

@huclengyue 正解

[kuyuzhiqi]

@huclengyue 现在创建项目都是只有 mipmap 文件夹

[kuyuzhiqi]

@d3vil 确实啊，很多时候与技术无关

[UIXX]

关于填坑，我觉得是个学问，有几点跟 LZ 分享一下，与君共勉。

0、不花心思去理解别人的业务代码。

1、除非重构，永远不去修改能正常运行的代码。

2、除非我已经跟他平级了，永远不主动修改上级 /前辈的代码。

3、永远不要在旧系统的需求上想当然。

4、即使重构，新的技术也需要试验了再上。

5、如果你今天不能说服他，就尝试去理解他，关系缓和后再说服他。

6、老板在技术上是傻 x，但是他能看到的东西绝对比自己多。

[coderluan]

1.不要重构代码，看着难受可以写好接口，打包成库。
2.重构代码前和人打声招呼是基本的流程和礼貌啊。
3.不要去小作坊。

[kuyuzhiqi]

@UIXX @coderluan 谢谢，学到了

[sebga]

这个属于管理问题，很难解决，不行真的要走。
他的代码乱，但是有权力拍板，你没有。
他和你的工作配合不和谐，价值观不知道一不一致，不一致的话，就很麻烦，长期下去，不是你走就是他走。
价值观一致的话，还可以努力沟通一下，就是会心累。

解决办法：
自己走；
价值观一致的话，努力说服。
搞定老板，让你拍板，搞走他。

[kuyuzhiqi]

@sebga 搞走他不太可能，我开始以为他工作经验少，后来发现，差不多 30 多岁了，有两个孩子，和我们老大还是好朋友，只可能我走呀

[sebga]

那就换吧，没得说了

[huclengyue]

@kuyuzhiqi 并不是啊。drawable 还是有的

[kuyuzhiqi]

@huclengyue 这个 drawable 用来放 xml 的

[petelin]

@UIXX 何必呢，这样最后的结果就是互相推锅 /代码垃圾的不行。
我 codereview 从来看见不爽的就委婉的问能不能改

[UIXX]

@petelin 每一条都是血与泪的教训，只想说，人的精力是有限的，根本没必要花在别人的错误上面。

1、考虑自己的时间成本与改动后收益。一堆垃圾只改其中一点还是垃圾，你永远不知道你的正确代码会不会被他人的 BUG 所影响。除了重构。

2、按流程说，填坑跟 codereview 是完全错开的。填坑是修改别人的遗留代码，锅也是之前的 review 跟 dev 背。你说的完全是开发期的事情，而不是二次开发或者运维的事情。

3、看到垃圾代码就想改...我想说除了技术层面的因素，这是谁写的代码 /服务于谁 /新技术、架构验证 /测试成本都同样重要，所以...