问题
这两天工作相对平静，准备将一些项目中常用的工具类整理出来，放到github上，以后开始项目直接就能拿来用。整理工具类的过程中发现了一些问题，所以记录一下。顺便把上次上线遇到的问题也记录一下
TIPs
1、项目中原来是有一个库叫做 base64 ，用于做base64 解编码，但是在ios7 之后，系统已经提供了，stackoverflow上有问题 http://stackoverflow.com/questions/19088231/base64-decoding-in-ios-7
2、在整理代码中发现了一些槽点。A、对工具类的命名，真的是醉了。作为一个工具类，合适的命名，也就是一看名字就知道这个类可以用来干嘛，那么后边再来的人重复造轮子的概率会极大的降低，很多时候，后来的人是真的很难找到你已经写好了的那个方法，故而以为没有，所以自己才去写一个。这就要求我们自己写工具类的时候，对工具类的命名最好能明确表示它的意义，比如 NSStringURLUtil，NSString+MD5 通过名字就能知道它的功能。同时，在我们自己准备写一个工具类的时候，先看看是否已经有现成的方法，避免自己重复造轮子。B、工具类，顾名思义，它应该就是一个独立的东西，拿过来就可以用。在项目中，我发现部分工具类还依赖其他的类，没法做到独立，别人拿过去，就不能用啦。从代码封装的角度来说，这应该是很失败的，或许是作者赶时间，还没来得及修改，又或许是后来的人慢慢就写乱了。所以从自身出发，我们自己写这些跟业务毫无关系的类时候，应该做到独立，不要引入其他依赖（大环境不算，比如 UIKit、Foundation等）。如果无法避免需要引入，那就放到业务层去，不要放在工具类一起。C 、不要把各个不相干的工具类放在一起。因为我发现项目中有一个工具类里杂合了好多其他功能，简直就是杂货店，处理图片的、清除缓存的、 颜色处理的。想象一下，你家有一个超大工具箱，你要用一套扳手休单车，也要把整个工具箱拿过来，而不是拿扳手套装，那你会有多烦人。所以不要怕分得太细，如果分类分层合适，再细也不会显得复杂。
3、项目审核不通过，原因是提供的截图，在APP中没有发现。我们提供的截图中有4张都是引导图，只会显示一次，所以可能审核人员都忘了有这图了。这也算是坑，所以别去踩。
4、回忆上次项目提审那一天，我们我们把原本支持ipad和iPhone改为只支持iPhone。导致提交的时候，一直出错。查找官方的QA，原来是只能增量支持设备，不能减量。不然会造成已经安装了ipad应用的用户无法使用更新包。所以要求我们在项目开始时候，就确定一个方向，避免出现上面的问题。
总结
碰到不好的代码，我们可以一边抱怨，但同时，也别忘了去修正，让它变得美好。
网友评论