写在前面

• 工作环境

我加入的是一家创业公司（91分红），我是唯一的iOS。那时我刚刚大学毕业，我所具备的iOS技能可能还不如培训机构出来的多（至少各种第三方库我都不会用），但是公司给了我很大的空间，让我自由成长，这使得我的学习能力得到了充分的发挥。</br>

• 我是如何学习新知识点的

对于一个新的东西，我一般会先google一下，看5-10篇blog，挑一个写得比较好的照着做一遍，这样在两三个小时内，我能有一个感性的认识。接下来我会去扒一下头文件，大致看一下这东西都能怎么用。然后就是上苹果开发者中心下载相关的文档，读读读。这样第一天我能大致把项目中的功能搭起来，第二天做细节填充和优化。接下来如果有时间我还会去简书之类的论坛挖一些优化帖，参照着优化这个部分。</br>

• 入职时项目开发的进度

入职时项目已经开始开发了，安卓端、后台、前端都已经工作了两周。我大致了解了一下这个创业项目是干什么，然后拿到了之前的iOS搭起来的框架，发现很乱。Boss表示可以重新来，我果断重建了项目。那么问题就来了，怎么组织项目的工程结构（目录结构）呢？（至于需求分析、UE设计，根本都没有时间管，后面的章节会用另一个项目谈一谈这两点）</br>

• 正式着手开发之前，我的工程目录结构

关于这个问题，可能初学者根本都没有考虑过。当时我自己学习iOS开发的时候，工程目录简直就是一坨翔。

• 我是如何想到“目录结构”这个问题的

因为第一天拿到手的工程代码有好多文件啊——网络请求、数据库、各种第三方，乱七八糟的，看得我心烦。根据乔帮主的极简主义和我的各种强迫症，我必须让工程目录优雅起来。</br>

如何组织项目的工程目录

这个没有通用的模版，我查阅了其他工程师分享的目录结构，发现与我的并不完全一致，但是有非常多相似的地方，算是一种工程师之间的约定吧。我总结归纳如下：</br>

可以从两个角度来编排目录结构</br>

• 从功能点的角度</br>
  优点：可以降低工程目录中各模块的耦合程度</br>
  缺点：可能会使工程目录</br>

• 从APP使用流程的角度（联系人列表 -> 联系人详情 -> 编辑联系人信息）</br>
  优点：可以根据功能点快速定位代码，工程目录有层次感</br>
  缺点：各功能模块可能使用了相同的东西，这可能会增加目录之间的耦合程度（应用多处用到）</br>

目录结构通常会结合“功能点”和“APP使用流程”来编排。

其他人是如何搭建工程目录的

iOS项目的目录结构和开发流程</br>
知乎上有关于项目目录结构的讨论</br>

我是如何搭建工程目录的

－关于共识</br>

1. 每个项目都会有网络层和数据库层，所以会产生以下目录

   • Tools
     • Network
     • Database

2. 每个项目都可能用到第三方库（SDWebImage AFNetwrok等），用Cocoapods管理第三方库是最佳选择，可以随时将第三方库更新到最新版本
   （小白级的CocoaPods安装使用教程）

   • SupportingFiles
     • ThirdPartyFrameWork
       • AFNetwor
       • SDWebImage

3. 每个项目都可能会使用第三方接口（微信 微博 支付宝等），所以会产生以下目录

   • SupportingFiles
     • ThirdPartInterface
       • wechat
       • weibo
       • alipay
       • gaode
       • ...

4. 每个项目都可能用到图片、音频、视频资源，所以会产生以下目录

   • Resources
     • Image
     • Video
     • Audio

5. 每个项目都会用到系统库，所以会产生以下目录

   • SupportingFiles
     • SystemFramework

－个人偏好</br>

1. 我会把AppDelegate和整个APP的根视图控制器提出来，因为这是整个应用的入口

   • Root
     • AppDelegate.h / .m
     • RootViewController.h / .m
     • (main.m)

2. 有些工程师喜欢把宏定义文件放在MICRO目录里，我偏好于把全局的宏定义文件放在Root中，其余各部分的宏定义文件放在各个模块对应的目录中，方便管理

   • Root
     • Micro
       • MICRO_MAIN
       • ...

－剩下的具体的实现文件（MVC）

我个人偏好于按照APP使用流程编排目录（细分到每一个功能点），譬如说“微信”这个APP，我可能会产生如下目录</br>

* Chats
    * RecentChatsList
        * Micro
        * Model
        * View
        * Controller
    * ...
    * GroupChat
* Contacts
    * ContactList
    * ...
    * RecommendedFriends
* Discover
    * Moments
    * ...
    * Games
* Me 
    * Profile
    * ...
    * Settings

之前提到了如果按照使用流程编排目录，可能会增加目录的耦合度，所以对于应用多处使用到的功能模块，我会把他们抽出来，放到一个Public目录里，譬如说对于“微信”，项目中我可能会产生以下目录
* PublicModule
    * ScanQRCode
    * AddContacts
    *...

当然，根据项目的具体情况可能还会产生其他一级目录，譬如说比较复杂的应用会使用到相当多的自定义控件</br>
* Custom
    * Extension
    * UIKit
    * ...

总结

“如何组织工程目录”并没有统一的说法，但是会有一些共识。譬如目录名要表明这个目录下的文件的作用（文件名也是一样）、数据库层和网络层要抽出来单独建立一个目录。根据工程师的风格最终会产生不同风格的目录结构，但是我认为编排目录是以管理为目的的吧，所以尽可能写得清楚一点。