入坑iOS已经百年有余... 期间一直都在创业公司修炼，此处天地资源匮乏导致修真者数量非常稀有，在此地修炼几乎都得靠自己。不仅如此，创业公司的项目十分不稳定，经常需要进行需求变更，小如图标文字，大至功能业务，更甚者还会直接销毁重构。
许多经验不足的年轻程序猿在各种压力下经常会选择速度而放弃掉最基本的代码规范，经过各种更新迭代之后就会发现其内部代码越来越乱，项目黯淡无光再无逼格。
没有了逼格的项目就如肥皂泡♂般只剩一层薄膜，对手看了之后内心毫无波动，除了想笑以外，还会略带鄙视的追加一句...“你这个彩笔”。
于是..心魔缠身...我就真的成了一个彩笔。 彡(-_-;)彡................
那个现在接手我项目的哥们儿...你现在还好吗？....有没有特别想打死我呀...
(;￢＿￢) <好了...不瞎扯了..>
你们可能觉得上诉↑有些夸张，但既然在看我瞎扯，相信你们已经体会到被自己/别人项目支配的恐惧，下面我就把个人认为挺棒的规范进行整理，并结合自己实际经历，给大家分享一下如何提升代码逼格：
首先是目录结构
一个优秀的目录结构应该是清晰易懂的，让人一眼便能明白目录的职责甚至了解到项目大概业务功能。而且必须要容易扩展和维护，不能因为几次更新迭代就面临重构。
对外来说，在不懂代码的人装逼，我们只需要拿出部分酷炫的功能演示一遍就可以了，但是在程序猿面前装逼...就得拿出代码，目录结构便是最先呈现的。一个糟糕的目录会让人对你的项目瞬间失去兴趣，连装逼的机会都没有。
我曾经有过很长一段外包的经历...看到过如下各种别人项目的目录结构：
这些目录除了有的太过复杂或者命名不规范以外，其实都还...‘能看’，抛开这些，归纳一下就可以发现，常见的基本就是以下两种结构:
- 主目录按照MVC架构分类，内目录按照项目模块分类。
- 主目录按照项目模块分类，内目录按MVC等架构分类。
这也是现在度娘最容易搜出来的方案，详细的可以参考一下这篇：怎样创建一个好的App目录结构
大多数人也都偏向第二种，因为第一种项目稍大，就会发现很明显的问题：
各个模块太过于分散，经常会需要跨目录找文件，开发和维护都不太方便，而且也不符合我们高内聚低耦合思想。
上文作者也是比较偏向第二种，并且还对其进行了详细的分析和升级。
（但个人认为还有所欠缺，推荐另一篇iOS工程目录结构的思考的整理结果）
这样的目录结构是我目前看到做得比较好的了，应该可以满足大部分开发者的需求。
_ (:3」∠) _ 重点来了：
假设这么一个场景：
1. 现在Home(首页)需要改版，原来的Home并不会删，他会作为另一个模块Topic(主题)来展示...
2. Discover(发现)模块要改为圈子，原Discover移到圈子的二级界面。
3. 这个是我自己的原因了，我习惯把每个界面的View拆分，而且我几乎是用的xib，所以文件出来一个view就.h .m .xib三个文件。这样下来View文件会非常多..
是不是很有意思呢？以前遇到的某个创业公司就经常会这么玩儿.. tabbar那几个模块根本不固定...随时会变的。
遇到这种情况就上面的目录结构，最直接也可能是最根本的办法就是，新建改名重新归类一下原文件，前提是时间充足你也不觉得麻烦并且足够勤奋..（
但是我们也可以运用邪教分类艺术来重新设计一下目录结构，使我们的目录结构具有更好的扩展性和包容性。
大家肯定都有疑问，接着我就讲一讲为什么这么来设计：
- 对于
Configurations(全局配置)、Tools(工具)、Categories(分类)、Vendors(第三方)，就算不整合成External(外部的)也不会很大程度增加一级目录数量，而且这些都是经常要用到的，没必要单独放一个文件夹来增加点击次数。 -
Resources(资源文件)这个应该都有的，它子目录下的东西，大家根据自己的习惯来即可，这里值得提醒的就是...我比较习惯于直接在这里管理图片资源文件，很多博客都会推荐大家使用Images.xcassets进行管理，我也推荐大家不要学我...（ -
FoundationModules(基础模块)、SuxCommonModule(通用)这两个其实就是类似之前的Common(各通用模块)、Base(基类)，之所以加了个Sux前缀，主要是因为这是我的项目名称(关于命名大家可以先看看这篇代码规范，后面我也会单独写一篇) -
BusinessModules(业务模块)这是和之前区别最大的，之前的主要问题是在于tabbar模块的分类不能很好的适应版本的改变。所以我按照业务功能来划分，一个产品不管怎么迭代，核心的一些业务功能总是不会有太大变化的（如果真的改变很多，那也就可以直接重构了） -
OtherModule(其它模块)主要是用来放一些不容易归类或者内容比较杂的界面，为了方便开发SectionViewControllers专门来归类按照tabbar来命名的界面。 - 我没有在我的Module类文件下分出一个
ViewControllers，因为我的ViewController每个都单独了一个文件夹，也就没必要再增加一次点击次数了。 - 关于
Views，前面说了...因为我每个Controller下View文件数量比较多，而且多数是和对应Controller耦合度很高的，所以我在XxxVC下单独增加了View文件夹。（如果有Module下的通用View，我们也可以在Module文件夹下增加一个XXXModuleViews）
补充说明一下：
以上方法还有一点核心的地方就是必须要先了解项目，只有对自己的项目有了一定的了解，你才能搭建出更好也更适合自己或团队的项目工程。
（直接接手一个项目就不要太纠结这个了，除非你也和我一样正在创业公司或外包公司新建/重构项目，不过你既然在看这篇文章了......应该用得上）前面其实关于按模块划分中
业务和功能这两个名词的理解我个人是有歧义的，按tabbar模块来分到底算不算是按业务模块分类？我那种又算是按什么分的？邪教？（原谅我当初软件工程挂科...也没有找到特好的解释，倒是找到了一篇APP组件化与业务拆分）
在此留下一个讨论区，欢迎大家在评论解惑，有了好的答案我将直接引用到这儿，谢谢大家
- 很多人觉得命名有中文很辣鸡，我以前也是这么认为的，上图加中文本来也只是作为一个提示的，但我后来仔细一看... 好像有了中文还挺棒的，你既然在天朝做开发为什么就不能用中文呢？看得懂不就是最重要的吗...(我的非程序媛女票是这么说的，好像很有道理）
最后说几句
虽然吾似彩笔，但上诉目录结构已通过吾实际项目体验...如果实在觉得这个是邪教做法也无法提升你项目任何逼格，也可以参考前面推荐的另一种。
同时欢迎留言讨论，如果有好的看法，我也会在前面合适的地方引用~
目录没有真正的好坏之分，只要适用于自己的业务，就是好的目录！
