最近有师弟面试iOS开发，他很吃惊地跟我说，面试官竟然问他怎么分目录结构的，还具体问每个子目录的文件名。
目录结构确实非常重要，面试官这么问他，无疑是想窥探他的开发经验。清晰的目录结构，可让人一眼明白相应的业务和职能，这也能体现开发者的经验和架构水平。
目前，我接触过的项目中，比较常规的两种结构：
1.主目录按照业务分类，内目录按照模块分类(主目录按照MVC架构分类，内部根据项目模块分类)
优点：相对比较快定位对应的业务。
缺点：模块相关类太过分散，需要来回切换寻找文件，不方便开发。
2.主目录按照模块分类，内目录按照业务分类
优点：对模块的类集中化，方便管理与开发。
缺点：当几个模块共用一些类时，不太好归类。
假设对简书iOS应用目录分类(非官方)：
- 1.主目录按照业务分类，内目录按照模块分类
- 2.主目录按照模块分类，内目录按照业务分类
注意: 以上�两种分类不是绝对的，具体还得按照业务需求去归类。如果公司多项目的话(指外包公司，哈~)，可以尝试按照自己的逻辑去归类，或可以多观察下身边大牛搭建的项目，会吸取到其中的奥秘。代码也一样，多看看大神写的，甚至可以直接模仿大神的代码风格，别人也会把你当做大神！
ps：有评论说，目录备注中文名感觉就lo了。确实开发中，一些非常有经验的程序员，不会这么干，甚至在代码中也很少中文注释。但个人觉得，普通或中高级工程师真滴很有必要多些注释，由于经验少，变量和方法名可能都命名不好，很多用googl翻译直译，甚至自己到审查代码时都不能直译出来。多谢注释好处就是就算你看不懂我写的代码，也一定能让你知道这是干什么滴(万不得己时，哈~)，方便自己也方便别人！最后，目录没有真正的好坏之分，只要适用于自己的业务，就是好的目录！
文章同步到微信公众号：hans_iOS 有疑问可以在公众号里直接发
网友评论
在CocoaChina上回复的有些不同的声音，这才科学，学术、技术本就需要多样化的嘛。
虽然贴主对两个结构优劣作对比分析，但并没有抛出自己对两者的主观判断，楼主倾向哪个？
至于说哪个更好，仁者见仁，智者见智了。
公共类可以专门在外面搞个Common文件夹嘛。
示例：
Classes
|
|-- Common -- Model
| |-View
| |-Controller
|
|-- Home -- Model
| |-View
| |-Controller
|
|-- Message -- Model
| |-View
| |-Controller
|
|-- Discover -- Model
| |-View
| |-Controller
|
……
另外推荐一个终端插件，名叫synx，可以通过xcode的虚拟文件目录构建实体文件目录，直接在xcode中建文件夹，然后拉终端里跑一遍就生成了对应的实体文件夹。支持svn和cocoapods
今天用MVC，明天可能就用MVVM，而需求不会变。
这样,看目录结构,更高效.
这里的“既然”应该是“竟然”吧。。。。。。
既然表示先提出前提,而后加以推论,常用“就”、“也”、“还”等配搭
竟然表示出乎意料或常情常理以外
我改...