前因
过年一回来，iOS小组少了个人，少人的原因，大概算是末位淘汰+精兵简政。然后之前的代码，各种不规范，造成开发速度low，bug出现high。之前的工作，多数由我和同事A完成，老大一般会过代码，确定架构，需求，当然也写代码。虽然一直对我们项目文件结构，资源文件混乱的情况难以释怀，奈何，一边要协作开发，一边做这种大型的修改，着实风险挺高【等着出版本上线有木有】。，于是一直猥琐编码，一拖再拖。如今，我的时代来了，在向老大反应了我们项目的各种问题之后，得到一句”我觉得我们可以大刀阔斧的改一改这些问题“。所以，我准备分别从四个方面稍微说明，重点在第4和第1 这两两点。
- 类结构
- 项目结构
- 资源结构
- 命名规范
命名规范
之所以把命名规范放在第一条讲，足见他在开发中所扮演的角色是多么重要。在我们的项目中约定，命民规范遵循Apple官方的驼峰命名方式。在去年我开始接触这个项目开始，也在积极推动我们的同事使用规范的命名。在此前，你可以想象在 .m 的私有属性列表中，各种 myview、myview1、view1等等，甚至一个控制器的指针竟让是用 ”view“结尾。比如 PayingViewController ，在某A类中，指向它实例的指针会是 PayingViewController *payview 用这样的方式。这如果只是在代码中直接看payview，大概没有人会想到它其实是一个controller的指针，而不是view的。好在从去年十月份开始，因为那个月代码review了几次，情况就好转了些，后面也时常性的整理代码。但这次的清洗行动，确实是彻彻底底去掉了之前这些不规范的命名。大概说说我们对UI方面命名的原则，其余的UI组件，相对用的少，所以都没有简写。
- UIButton ----> XoXoBtn (XoXo 是驼峰命民，表述对应的功能)
- UILabel ----> XoXoLbl
- UIViewController ----> XoXoVC
- UIImageView ----> XoXoImage
- UIGestureRecogniser ---->XoXoTap/Pan/Swipe/...Gesture
曾经多少次，迷失在毫无意义的变量命名上，又有多少次因此而长跪不起，bug频出，又有多少次，在接手别人项目时候，看着那些毫无规则的编程规范而四顾茫然。好的编程风格（包括规范的命名），能让后面接手项目的人更快上手，也让我们自己在代码维护的时候事半功倍，更重要的是，这是作为一个程序员的职责和品质。
另外，也可以参考raywenderlich的编程风格，不管使用那种风格，都需要大家共同支持，而最终的目的都是让代码更好维护。
----------------update 3月26-----------------------
类结构
相信很多开发者在开始阶段，在一个类里定义方法，大概就是在感觉需要调用的地方附近，直接添加一个方法
-(void)func1{
//
[self func2];
}
-(void)func2{
// do something
}
如果一个比较简单还好，如果涉及到了很多的方法，那么，这个在后期维护的时候，就略显忧伤，因为你发现自己要找一个方法，好困难，即便XCode 提供了整个类文件方法明列表（点击类文件上的tabbar最后一项）。很多时候，问题是你知道那个方法就在里边，你也没法很快找出来。更甚的有一大批在类中实现的协议方法，这将让你淹没在茫茫方法中。这个时候，一个好的规范，就派上用场了，配合#pragma mark 编译宏，将类文件中的方法、属性分块呈现在方法列表中。从此，代码维护就轻松不少，也更容易让人找到对应的方法进行维护，毕竟代码是给人看的，而不是给机器看到。
下边说说在我的项目中，类文件组织分类
这是一个普通段落： 这是一个代码区块。
(@interface)
//Private Data member // 定义私有数据成员，
@property (nonatomic,strong)NSMutableArray *infoArray;
...
//Private UI member // 定义的UI 元素
@property (weak, nonatomic) IBOutlet UITableView *dataTable;
...
(@implementation)
#pragma mark - UI Initialization
-(void)setupSubviews{
}
#pragma mark - Data Initialization
-(void)loadData{
}
...
#pragma mark - UI Actions
-(IBAction)modifyBtnClicked:(id)sender{
}
...
#pragma mark - Delegate (eg. #pragma mark talbeView delegate and dataSource)
//实现的datasource 和delegate 方法
#pragma mark - UIAlertViewDelegate
//AlertViewDelegate 方法
...
#pragma mark - Public method
// 公共方法实现，给外部调用的，子类可以覆写，实现自己的特性，如果保留父类特性，调用 [super func]
#pragma mark - Private method
// 私有方法，只有本类可以调用，子类无法调用
...
一般来说，这样的分类差不多了，就我目前来说，差不多。分块之后的结果，差不多会是这样：
即使方法比较多，也依然比较明了，有层次感。当然，并非每个类都要这样分，应该灵活使用，该有的有，不需要的，不强留。所以又回到了那一点，“代码是给人看的，不是给机器看的”。
项目结构
项目的文件结构，应该让人一眼能看出个大概的功能，让人清晰明了，修改功能或者添加功能知道从哪里开始下手。已经有一篇博客写了这方面的知识，我就不重复造轮子啦。传送门
资源文件
这次项目的整理，资源文件的清理，确实耗费了我巨大的时间和精力，即使我用了这个清理无用资源文件的脚本。这个脚本会找出没有在文件中引用到的资源文件，你可以删除，也可以不删除。我们的项目，对资源文件，从来只做加法，所以项目现在3.0了，甚至还留着1.2版本的资源文件，每次打包都是十几兆。所以对资源文件，我们也应该遵循一定的规则来组织。主要的方式，肯定是围绕功能模块划分，有部分可以通用的，比如按钮效果，导航栏图片等，可以分出一个common(通用文件夹)，用来保存公用的资源文件。这样在某一些UI修改的时候，可以快速定位到资源文件，进行替换，从而避免无用资源文件占据空间。
总结
一名合格的程序员，应该是要有一个良好的编程习惯和清晰的思维。对于刚刚走进IT行业的我，养成良好的编程习惯，是对自己负责，也是对别人负责。哪一天，我对自己曾经写的代码都看不懂，那怎么还能指望别人看懂？
