做过一些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 帮助函数。
- Common: 主要存放在KP这个项目里可以通用但不对其它项目通用的Project Level的组件。
通用组件
- 设计通用组件跟设计UI一样,要做到优雅而简洁。
- 直观性 。接口清晰,跟系统API风格一致,用户一看就知道怎么使用。
- 易用性 。我们的设计需要使最经常被用到的的功能简单易用,不需要过度的配置,在默认配置下API就应该是可用的。
- 容错性。 考虑到不同的使用场景,对于复杂场景,通过配置或者API接口,用户可以达到目的。
- 解偶。 设计组件库另外一个要注意的就是解偶, 组件之间尽量做到不要互相依赖,这就需要每一个组件职责清晰。同时也需要组件库的层次是清晰的,基础库,帮助库,UI库 有层次界线,低层的库不要倒置依赖高层的库。
其它
- 关于预编译 预编译是双刃剑,它可以加快编译速度,但经常被滥用,很多人图方便把很多头文件都加到预编译,容易导致头文件依赖混乱。 我的建议是只把General Level组件的头文件加到预编译。
关于猫头鹰团队
像武汉这样的二线城市, 很少有优秀的互联网公司,但是:
- 有很多湖北籍/华中籍的在一线城市/一线互联网公司打拼的优秀人才,他们因为家庭等各种原因,期望回到武汉。
- 不少优秀人才回到武汉后,加入了一些公司,因为没有互联网土壤,因为理念的不一致,处境很尴尬,甚至很多人生活所迫又重新回到一线城市。
我们希望通过各种方式,团聚湖北籍/华中籍的优秀互联网人才,同时我们建立了一个猫友会,都是从一线城市回来的互联网从业人士,更多细节请到文章底部“阅读原文”后点击 http://jimhuang.cn/about。