做过一些iOS的项目，不同项目的沉淀没有积累到一起，目录的管理都在后期随着人员的增加越来越混乱，因此在这里做一些梳理，希望达到两个目的。
-
一套相对通用的目录结构，作为后续项目的模版。
-
积累相应的基础库，在后续的项目里不断打磨，最后开源。
几个基本的原则：
-
一个合理的目录结构应该是清晰的，让人一眼就能了解目录职责，并且是容易扩展的。
-
不管是第三方库还是自己的库，尽量用CocoPods来管理。
-
区分不同层次的通用组件。
-
General Level, 最通用的组件，可以在不同项目里复用。
-
Project Level, 可以在该项目里复用。
-
Section Level, 可以在某个功能模块里复用。
-
对于General Level的组件，以Library的形式分出来，不要放在主工程。
-
对于基础库，保证质量，通用性，可扩展性，易用性，可以不断迭代
目录结构
下面是我建议的项目目录结构：(公司名为NB, 项目名为KP, General Level 组件都会以NB打头，Project Level组件以KP打头 )
KP_iOS | |--KP | |--Common | | |-- KPUIKit | | |-- KPCommon | | |-- KPUtility | | | |--Consts | |--Models | |--Sections | |--Vendors | |--Resources | |--Pods | |--NBFoundation | | | | -- NBUIKit | | -- NBCommon | | -- NBUtility | | |--ThirdParty1 | |--ThirdParty2
主目录下分为KP 和 Pods两个一级目录。
-
KP是主工程目录
-
UIConsts.h
-
VendorConsts.h
-
KPCommon ： Project Level逻辑组件。
-
KPUIKit：Project Level UI组件。
-
KPUtility：Project Level的帮助函数。
-
Common: 主要存放在KP这个项目里可以通用但不对其它项目通用的Project Level的组件。
-
Consts 存放项目范围内公用的常量。 例如：
-
Model：各个功能模块数据逻辑相关的文件。
-
Sections：各个具体的功能模块UI及交互相关文件。 如果某个Section有一些Section Level的通用组件，可以在具体的Section下有一个Common目录。
-
Vendors： 存放没有被CocoaPods管理的第三方组件
-
Resources
-
Pods是CocoaPods的根目录, 所有CocosPods管理的库都在该目录下。
-
NBFoundation: 可以在所有项目里通用的General Level 的组件（跟KP/Common里的内容及结构类似，但更通用)。
* NBCommon 通用的逻辑组件。 * NBUIKit 通用的UI组件。 * NBUtility 帮助函数。
通用组件
-
设计通用组件跟设计UI一样，要做到优雅而简洁。
-
直观性 。接口清晰，跟系统API风格一致，用户一看就知道怎么使用。
-
易用性 。我们的设计需要使最经常被用到的的功能简单易用，不需要过度的配置，在默认配置下API就应该是可用的。
-
容错性。 考虑到不同的使用场景，对于复杂场景，通过配置或者API接口，用户可以达到目的。
-
解偶。 设计组件库另外一个要注意的就是解偶， 组件之间尽量做到不要互相依赖，这就需要每一个组件职责清晰。同时也需要组件库的层次是清晰的，基础库，帮助库，UI库 有层次界线，低层的库不要倒置依赖高层的库。
其它
-
关于预编译 预编译是双刃剑，它可以加快编译速度，但经常被滥用，很多人图方便把很多头文件都加到预编译，容易导致头文件依赖混乱。 我的建议是只把General Level组件的头文件加到预编译。