前言
2018年底，对于已经从事软件开发工作了4年多的我，经历从辗转深圳、流浪贵阳的颠簸，由于多年的开发经验，自我审视的时候发现自己业务能力不错、项目经验丰富，但对计算机底层缺乏较深的认识，对设计模式也没有深刻的理解。当然，这是我接下来一段时间工作的重点。
为什么说这么多废话，因为之前我并没有打算在本文中探讨太专业的东西，而本文目标也是面向像我一样深处迷茫探索中的小白，主要从宏观上聊聊工程结构、从微观上聊聊类的设计。
本文构思基础
之前在公司开发遇到几个问题
1.项目太大，运行调试太慢，感觉降低了开发效率
2.项目由于底层库的原因不能模拟器调试，只能真机，进一步降低效率
3.工程文件结构复杂，开发人员较多，相关模块分离不明显，难以寻找
4.类似滴滴打车这样的项目，需要开发多个客户端，但功能、网络接口等基本相同，如果使用多个工程导致大量重复代码，将来也不容易同步维护相同逻辑的代码
探索思路
1.组件化探索、插件化设计思路
2.多target模块设计思路，新建target包装较复杂的模块，一方面可以分离业务逻辑，另一方面也可以使得单个模块运行速度更快、解决不能真机调试问题
新问题
1.公共模块内部引用了其它无关模块的逻辑，当分离出target以后发现target并不单纯，还是需要引入编译大量无关逻辑的代码，为达到编译效率最大化
2.如果需要开发一个项目多个客户端，达不到逻辑清晰可辨，还是会带来维护上的问题
最终
1.花了大量时间重构了公共模块代码，分类模块之间业务逻辑
2.基本类似的功能业务迁移重构，达到解耦复用目的
3.只做了项目中一小部分的工作，难以达到理想中的效果，不过：一直在路上
思考：不忘初心
- 宏观上最初的工程架构
- 微观上具体到每个类的设计
- 中观上建立自己的公共代码仓库
关于工程结构
在开发新项目前，你首先应该有一个清晰的工程结构，无论做什么事情之前我们都应该有一段长长的思考，多对自己提一些疑问，多像自己谈谈“为什么？”。
iOS开发工程目录结构
在我们熟知的设计模式中，以MVC名头最响，MVVM更像是另辟蹊径或者说别出机杼，或许有人会说这是标新立异、故意显摆，关于孰优孰劣再次不做讨论，开发上的各种思路见仁见智，我个人更推荐MVVM。
根据个人习惯有所不同，有些人喜欢整个项目结构中就是一个巨型MVC或者MVVM，即外层结构+内部模块，然后再在“Models/”或者“Views/”、“Controllers/”等目录下分模块，如GitHub优秀APP源码Coding-iOS客户端。
而有些人喜欢这样分，外层模块+内部结构，如下图方式
具体宏观上用什么目录结构见仁见智，记住没有最好只有更好，对我来说我推荐第一种，可能是习惯亦或是对大神的仰慕。
不管什么方式，只要在自己心目中设计的时候按照清晰的MVC或者MVVM设计，就非常容易理清逻辑，但对于一个工程来说，微观上的架构可能才是最重要的，因为我们在花几天时间建立好工程后，接下来的所有日志都主要集中在微观逻辑架构的开发维护上，因此我说微观上的架构更重要，而最初的架构设计确实无与伦比的，将决定了项目未来的代码如何发展、是否易于扩展、开发和维护等。
关于类的设计
我们常说到低耦合、高内聚思想，基本任何开发人员都知道这个概念，但在设计上却鲜有人能熟练驾驭。我们总在不知不觉中被方便的思想左右，不愿意去写接口协议、不愿意去做回调hook处理，这都是通病，以下通过实例谈谈看法
1.设计一个通用类：图片展示器 ImageBrowser
// ImageBrowser应该向外提供如下接口
- images/imageURLs接收方法
- show方法（打开）
- close方法（关闭）
- block/delegate回调
// 注意事项
// 1.该类不应该使用项目中定义的一些Define、Models、Views等
// 2.该类不应该引用项目中某些类的头文件，不应该和项目中某些类的逻辑相关联，只能向外提供访问接口
// 3.该类的总体思路应该是单向的，即项目中类可以访问它，而它不能直接访问项目中的类
// 4.设计为插件式模块，引入和抽离只需少量代码，大量初始化工作应在内部完成，向外提供的应该是非常简洁的接口
2.第三方库桥接文件，我们在项目中接入第三方库的时候一般不会直接使用，应该是简历桥接文件去和第三方库对接，将来如果第三方库更换也不用变动项目代码，只需维护桥接文件即可。如设计一个AFNetworking的管理类
// 应该向外提供如下接口
- get:(参数) block:(回调结果)
- post:(参数) block:(回调结果)
- upload:(参数) progressBlock:(回调进度) block:(回调结果)
...
// 注意事项
// 1.该类只与AFNetworking关联，不应该关联项目中的Define、Models、Views等
// 2.遵循单向访问逻辑原则
// 3.遵循接口简介原则
3.设计UITableViewCell
// 1.向外暴露需要变动展示数据的property
@property (nonatomic, weak) UILabel *titleLabel;
@property (nonatomic, weak) UIImageView *imageView;
...
// 向外提供hook接口
- block/delegate回调
// 注意事项
// 1.该类不应该引直接引用Model，不应该在内部处理交互事件，应hook到controller处理
// 2.该类若必须处理大量内部逻辑，考虑绑定viewModel或者为其添加分类Category
// 3.该类不应该引用其他模块的头文件
4.此外设计Tools、Category、Helper等工具类的时候也尽量保持相互间的独立性
好处
1.不同模块角色明晰，代码均衡分布于这些模块上
2.由第1点带来的可测试性
3.易用性，维护成本低
4....
