认识达内从这里开始

相信大家在进行代码优化的时候也发现了，有些软件的代码问题很少，有些软件的代码可以说是一团糟，今天我们就一起来了解一下，引起这些问题的原因都有哪些。

1、避免滥用单例

单例作为一种设计模式应用非常广泛，在移动端开发中，有些开发者利用它来实现非缓存传值，笔者认为这是一个错误的做法，使用单例传值的时候你需要管理单例中的数据何时释放与更新，可能会引发数据错乱。

单例存在的意义应该是缓存数据，而非传值，切勿为了方便滥用单例。

2、避免滥用继承

继承本身和解耦思想有些冲突，代码设计中要尽量避免过深的继承关系，因为子类与父类的耦合将无法真正剥离。过深的继承关系会增加调试的困难程度，并且若继承关系设计有缺陷，修改越深的类影响面将会越广，可能带来灾难性的后果。

可以使用分类的方式做一些通用配置，然后在具体类中简洁的调用一次方法;也可以使用AOP思想，hook住生命周期方法无侵入配置(比如埋点)。

比如iOS开发中，可能会有开发者喜欢写一套基类，实际上只是基于系统的类做了小量的配置，比如BaseViewController、BaseView、BaseModel、BaseViewModel，甚至是BaseTableViewCell。控制器基类可以对栈和导航栏做一些配置，还是有一点使用意义，至于其它的笔者感觉就是过度设计，其实很大意义上BaseViewController也没有存在的必要。

记住：过多的基类并不是代码规范，那是你囚禁其他开发者的牢笼。

3、避免过度封装

提取方法的原则是功能单一性，但若功能本身就是很少的一两句代码可能就没必要额外提取了。在保证代码清晰的情况下，很多时候提取逻辑也是需要酌情考虑的。

有见过开发者使用一套所谓的简洁配置UI的框架，不过就是将UI控件的属性封装成链式语法之类的，用起来有种快一些的错觉，殊不知这就是过度封装的典范。

封装的意义在于简洁的解决一类问题，而非少敲那几个字母，过度封装只会增加其他开发者阅读你代码的成本。

比如业界知名的Masonry，使用它时比原生的layout快了不止10倍，而且代码很简洁易懂，极大的提高了开发效率。

4、避免过多代码块嵌套

比如代码中大量的if-else嵌套判断，大量的嵌套循环，大量的闭包嵌套。

出现这种情况先要考虑的是分支结构处理是否多余?循环是否可以优化时间复杂度?当排除这些可优化项过后，可以做一些方法提取减少大量的代码块嵌套，方便阅读。

5、时刻注意空值和越界

写某块代码中，要时刻注意空值和越界的处理，比如给NSDictionary插入空值会崩溃，从NSArray越界取值会崩溃，这些情况要时刻考虑到。

当然，可能有人会说有方法可以全局避免崩溃。实际上笔者不是很赞同这种做法，这可能会让新手开发者永远发现不了自己代码的漏洞。

6、时刻注意代码的调用时机和频率

当你写一块代码时，需要习惯性的思考两个问题：这块代码的共有变量会被多线程访问从而存在安全问题么?这块代码可能会在一个RunLoop循环中调用很频繁么?

对于一个问题，可能需要使用“锁”来保证线程安全，而锁的选择有一些技巧，比如整形使用原子自增保证线程安全：OSAtomicIncrement32();调用耗时短的代码使用dispatch_semaphore_t更高效;可能存在重复获取锁时使用递归锁处理...

对于二个问题，只需要在合适的地方加入自动释放池(autoreleasepool)避免内存峰值就行了。

7、减少界面代码复用、增加功能代码的复用

对于大前端来说，界面是项目中重要的组成部分，而有时候设计师给的图中，不同界面有很多相同的元素，看起来一模一样，所以很多工程师偷懒直接复用界面了。

在这里，笔者建议尽量少的复用界面，宁愿选择复制一份。

试想，目前版本两个界面相同，你复用了它，当下个版本其中一个界面要调整一下，这时你继续偷懒，加入一些判断来区分逻辑，下一次迭代又增加了差异，你又偷懒加入判断逻辑......终你会发现，这个界面里面已经逻辑爆炸了，拆分成两个界面将变得异常困难。

而对于功能代码，笔者是提倡多提取，多复用，切记命名规范和适当的注释。

8、组件的设计技巧

在封装一些小组件时，一定要形成习惯，不想暴露给使用者的属性和方法不要写在接口文件中，同时，在多人开发中，组件的开放方法名好加入一些前缀，便于区别，也避免方法重名，容易导致方法重名的情况就是各种分类里面的方法重复，会带来意想不到的错误。

9、缓存机制的设计

不管是任何技术栈的缓存机制设计，都需要一套缓存淘汰算法，使用广泛的淘汰算法就是LRU，即是近少使用淘汰算法，开发者需要严格的控制磁盘缓存和内存缓存的空间占用。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。