做过一些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是主工程目录
  • Common: 主要存放在KP这个项目里可以通用但不对其它项目通用的Project Level的组件。
    • KPCommon ： Project Level逻辑组件。
    • KPUIKit：Project Level UI组件。
    • KPUtility：Project Level的帮助函数。
  • Consts 存放项目范围内公用的常量。 例如：
    • UIConsts.h
    • VendorConsts.h
  • 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组件的头文件加到预编译。

关于猫头鹰团队

像武汉这样的二线城市, 很少有优秀的互联网公司，但是：

• 有很多湖北籍/华中籍的在一线城市/一线互联网公司打拼的优秀人才，他们因为家庭等各种原因，期望回到武汉。
• 不少优秀人才回到武汉后，加入了一些公司，因为没有互联网土壤，因为理念的不一致，处境很尴尬，甚至很多人生活所迫又重新回到一线城市。

我们希望通过各种方式，团聚湖北籍/华中籍的优秀互联网人才，同时我们建立了一个猫友会，都是从一线城市回来的互联网从业人士，更多细节请到文章底部“阅读原文”后点击 http://jimhuang.cn/about。

长按关注猫头鹰技术公众号(mtydev)