才疏学浅, 但也想和大家分享一下，比较抽象，如果有不懂请自行bing.com

使用【单例】代替【静态类】 和【静态变量】

静态类, 静态变量创建方便, 但是管理起来就麻烦了, 而且单例可以比静态函数高明的是, 可以对共用变量进行判断和初始化, 让变量更加灵活, 可以进行更灵活的适配。可以使用宏来封装单例，这样写起来简化了很多。

使用【枚举】代替【布尔值】和【数字】

当你需要通过判断来实现条件时，有时创建布尔值是相对方便的，但是扩展就麻烦了些。我的观点是通过缜密的构思，确定是否使用布尔值，像一些enable， selectable， visible这类只有两种状态的用布尔值，而包含意义更多的变量像isVideoMp4，这样就最好设置为枚举，因为这只能判断mp4或者不是mp4， 而枚举就可以扩展它的判断
枚举还有个功能可以在switch上被提示是否已书写过（objc）

使用【开关】代替【布尔组】

使用方式和上面提到的类似，不一样的是，像单片机开发一样，对32位单个数值的每一位当做一个开关，这样可以做到浓缩管理， 缺点是只支持0~31 共32个开关，不过扩展也好弄，某些平台支持把它扩展得更多个开关（c#貌似专门提供一个对应开关的类）

使用【宏判断】代替【静态常量】判断

开发应用和游戏的时候，会有大量的测试条件和管理调试内容，用到【单例】【静态常量】来判断测试的执行与否尚可，但是宏判断可以让语句在不满足的情况下并不参与编译，相当于注释掉了没用的代码，非常方便，使用【宏开关】混合【宏判断】和【开关】来实现快速的测试、上线切换，非常之实用。

使用【子线程】代替【主线程】

某些处理例如jpg压缩，视频编译，处理gif等需要短时大量cpu、gpu操作时，在主线程影响到了用户的体验，那么就需要把处理移到子线程，而在合适的时候回到主线程更新。灵活的学习子线程调用和主线程协作还是挺有趣的。

使用【习惯命名】代替【随心所欲命名】

自己的代码从类名，变量名到函数名和资源文件名，都保持一致的风格，这样在搜索查找的时候得心应手。

【时用时创】、【复用对象】代替【随意创建】

创建对象对于我们来说再简单不过了。不过当我们需求变得需要高效的时候，就需要利用好每个字节的资源。像objc的UITableView就是个很好的例子，只会需要显示个数的cell，无论数据有多少。
另一些则是当你创建很多对象的时候，内部的某些变量可能不需要随时出现，那么在需要的时候去创建，以减少耗时和运算。

【相似归宗】代替【对象个性】

创建的对象多了起来后，发现都有相似的功能，比如都为场景scene的功能，那么他们可以归类统一来管理起来，创建一个父类，让这些类都继承于它。这样既约束了子类，也能将类传递时使用父类来描述这个类的基本功能

【代理】、【通知】代替【类变量】

• delegate使用接口来弱化传递信息对象的耦合
• 通知则可以完全剥离开对象与对象之间的关系，但因为机制原因，效率不如delegate和变量
• 变量直接指名了类型，不够灵活

尽量避免更多的使用第三方类库

第三方库很多时候会给我们带来方便，省掉很多底层的思考，但是不要一味的追求第三方库多就是好的观点：

• 第三方库对于系统更新并不能快速适配，某些第三方库甚至几年没有维护
• 第三方库增多也会增大软件和游戏的体积
• 它的功能并不和我的需求吻合，有的地方是我想要的，有些地方并不需要，这时候你就要去粗取精了。
• 更新迭代快的第三方库对于你来说也是个麻烦，比如cocos2d、cocos2dx，很多时候某个版本的框架都是由大神级老外帮忙指出问题的解决办法
• 选择更为成熟，更为活跃的第三方库，反馈问题也会被大家快速解答
• 选择开源的第三方库，这样查询问题时也能知道具体原因和解决方法

希望大家会喜欢【通知】、【枚举】、【单例】、【开关】、【宏】，有时候可能会很难用，甚至是晦涩，但是相信在大型项目上会让你的项目更加灵活。我们的项目目的性和功能性从来都不是在一开始就注定好的，应付这些挠头的改变，需要你将code的根基砸结实。