曾经有那么三个月，我成为了一个iOS开发者，如果让我对那三个月做个评价，那就是两字：噩梦。在那之前，我对于iOS开发的认识几乎为零，对于苹果设备也可以算是从未使用过，所以一开始还满怀新奇，毕竟是学了一门新技能。可之后的变化可以用峰回路转来形容。作为一个创业公司，前厂充满了一种糙、快、猛情节，贫僧作为一个新手又经常犯过分乐观的错误，导致整个开发过程为了赶进度而变得混乱不堪，代码更是毫无节操的胡乱堆砌。那段时间加班成了家常便饭，直接导致贫僧腰背肌劳损，坐下的时间一长就疼痛难忍。虽然最后勉强完成了功能，可心神俱疲，最后也离开了前厂。
那段时间让我明白了很多事情：
1. 不要过分乐观，软件开发无小事儿，不管看起来多么简单的功能，开发过程总是充满各种变数，千万不要胡乱估计开发周期，给自己挖坑。
2. 磨刀不误砍材功。如果你像我一样没有考虑第一条，导致开发周期看起来很紧张，也千万不要在认真了解一门技术之前动手，不管看起来是多么紧迫，老板的眼神多么期待。充分了解一门技术能够让你绕过很多弯路，最终会提高工作效率，提升工程质量。
3. 加班并不光荣，而且很有可能是可耻的，效果很可能也会适得其反。如果你频繁加班，无非是两种原因：技术不行，时间不够。不管哪种情况都不要硬扛，身体健康很重要，还是早点投降为妙。
4. 作为一个开发人员，会测试很重要，虽然不要求你精通，但最起码的单元测试还是要会的，很惭愧，我现在也是个门外汉，正因如此，我才能体会到因为测试差而导致的bug不断，频繁返工的痛楚，有时候感觉一个项目没完没了，想死的心都有了。
5. 最后一条写给创业公司的老板，别招新手，特别是公司里现有人员对要使用的技术都不精通的时候，结果最后很可能是两败俱伤，新手无成长，养成很多坏习惯，公司产品质量无保证。还有就是，没有人是全能的，在开发方面，产品经理，会测试的开发高手，UI，UX一个都不能少。虽然开会追求群策群力看起来很美好，但专业是装不出来的。
做完这个iOS的项目之后，贫僧就离开了前厂，一晃三个星期过去了，最近好好的反思了一下这个项目，觉得有必要总结一下这个最失败的作品，虽然其他作品也没多好。
### ViewController不是百宝箱，不要啥都往里装 ###
由于我此前从未做过GUI相关的开发，也不了解什么MVC，所以犯了很致命的错误，几乎所有代码都堆砌在Controller中，导致整个代码结构非常混乱。如果没有离开前厂，肯定要对这块进行大改造。
1. 分离出data source：和大多数iOS应用一样，UITableView和UICollectionView是最常用的两个UI容器。使用这两个容器，需要设置delegate和data source。作为一个菜鸟，我天真的把代码逻辑都放到了ViewController中，只是在我离职之前，没有出现要在多个ViewController中共享的data source，也就没有把这部分独立出来。
2. 自定义View：诸如UITableViewCell之类的，如果系统自带的几种类型不能满足你的需求，尽量通过继承添加需要的控件、动画效果，如果你习惯Interface Builder，也可以使用IDE定义。千万不要在Controller中直接操作。
3. 独立的网络通信：前厂的这个APP是针对越狱用户的，起初是发布在BigBoss和WeiPhone上的DEB包，后来考虑提供应用内直接升级的功能。这就涉及到查询更新和下载更新的网络通信。起初这部分也是放到Controller中，后来由于另外的同事需要这部分功能，所以就独立了出来，通过Block和Callback与调用者进行交互。
4. 不要滥用Dictionary：创建合适的Model类，并将相关的逻辑封装在类中，诸如存储、序列化等。Dictionary虽然好用、直观，但是创建独立的Model，有利于重用，而且如果Model有变化，修改一处就可以了。
### 设计模式是良药，但是别乱吃药 ###
设计模式在软件开发中是个很常见的名词，虽然面向对象异常红火的那段时间让很多程序员养成了过度使用的坏习惯，但是这丝毫不能影响设计模式的重要性，对于我来讲，过分使用设计模式进行设计除了耽误时间之外，还很容易把简单事情搞复杂。我认为最好的方式是刚开始不需要太过分设计，做好模块划分就可以了，只有后期发觉整个项目扩展起来很困难，再考虑重构，通过更好的设计解决问题。
常见的iOS设计模式，由于本人手头没有苹果设备，对于Objective-C其实也是半瓶子水平，下面的代码肯定有问题，请注意。
#### MVC ####
把这个单拿出来有点无厘头，但是却是非常重要的，不管如何强调他的重要性都不为过。
Model：对应于数据以及相应的操作。例如你要做个社交软件，里面用户就对应一个Model，用户的年龄、性别以及如何加为好友等，都应该在Model中进行具体操作，而外部只需要调用相应的接口就行了。在iOS中，Model都有一个相应的类，例如这里的用户，就可以对应一个Objective-C中的类User，值得注意的是，尽量将类中的成员的声明以及定义放到.m文件中，避免外部调用者直接操作成员变量，因为如果后期成员变量的命名、类型出现改变，这些外部调用者的代码都要重新修改，简单一句话就是多用接口调用，减少直接操作。
// User.h
@interface User: NSObject {
}
-(NSUInteger)age;
-(void)setAge:(NSUInteger)age;
@end
// User.m
@interface User ()
property (nonatomic, assign) NSUInteger age;
@end
@implementation User
...
@end
View：主要负责Model的展示以及用户的交互。在iOS对应与UIView及其子类。
Controller：作为一个中间人，Controller访问Model数据，并通过View展示出来，同时根据用户在View上的操作，对Model做相应的更新。
#### 单例模式 ####
单例模式的作用是保证某个类只能拥有一个实例对象，iOS中最常见的诸如·NSFileManager defaultManager]等。单例模式还是比较容易实现的，要做到这一点一般需要三点：
1. 构造函数设置为私有
2. 定义一个类静态成员，用于指向这个实例
3. 定义一个类静态函数，用于初始化这个实例
@interface Singleton: NSObject
+(Singleton *)sharedSingleton;
@end
@implementation Singleton
+(Singleton *)sharedSingleton
{
static Singleton *sharedInstance = nil;
// Ensure only execute once
static dispatch_once_t once;
dispatch_once(&once, ^{
sharedInstance = [[Singleton alloc] init];
});
return sharedInstance;
}
@end
#### Delegation ####
这个在Cocoa中简直太常见了，主要是接口设计要好，贫僧无经验，不乱给意见。
设计模式还有非常多，而且每一个都有其特定的用途，作为一个菜鸟，上面三个是我在开发中用到的三个，建议大家还是找本书常备，用到时候在仔细研究，脱离实践的理论毫无用处。
### 知其然更要知其所以然 ###
Google和StackOverflow是程序员的好朋友，所以疑难杂症几乎都能在这两个站点内找到答案。但是作为一个程序员，如果你还有点积极向上的小理想，就不应该满足于找到了解决方法，更要理解为什么这样能够解决问题。