期望：
作为一名程序员，我渴望我加入的应该要是一支“30%的时间在写代码，而70%的时间在喝着咖啡讨论着如何将产品做好”的团队。我觉得软件工作应该成为一项技术和艺术融合的高智力活动，我们的项目经理应该是一个高度理解质量、范围和进度客观规律的明白人，“高效工作，快乐生活”才应该是我们的座右铭。
可现实情况却是，团队在一边超负荷的做着需求，一边改着没完没了的Bug。过点前夕，项目经理熬着通红通红的眼睛盯着我们整晚整晚的加班，质量专员一遍一遍的催促质量数据还不够，软件工作已经无可挽回的沦落成了体力劳动，别说快乐生活，生活都没了。
好吧，以上可能都对，项目经理和质量专员是一个不懂客观规律并且毫无同情之心的大魔头，让我们程序员们毫无尊严卑贱的活着。
只是，有句话憋了很久了：“醒醒吧，所有的这些，都是因为你的代码写的太烂，你制造了太多的Bug！”。你可能会抱怨这分明是需求变更太快，领导计划太紧导致的。嗯，听着挺有道理，但是要知道需求变更本身就是软件的客观规律，而领导要求进度，呵呵，你也可以认为是客观规律。
这不是一篇证明谁导致程序员加班太多的论证文，也不想给大家灌鸡汤，让大家一夜之间都变成编程高手，但是至少说一些实实在在的经验和方法。总之让大家多看一点就多获得一点实际的价值。
一：明确需求、且做好需求扩展的准备。
你可能性子急，也可能早已按耐不住跃跃欲试昨天刚学会的一个编程小技巧，我想要告诉你的是，不急，收起你那磨刀霍霍的表情，在你拿到需求准备写出你第一行代码之前还有更重要的事情要做。我想怎么强调这件事情的重要性都不为过，在我以前写的自己非常满意的代码经历中，我都采用了这个方法，它能消灭原来可能会被测试提的90%的Bug单，甚至做到零缺陷，当然做到这点可能需要一个过程。
拿到需求之后你首先要问下自己对需求是不是已经充分理解了，得到肯定的回答之后，我们就可以开始了：
1）先在你忙碌的工作中，找出你能完全掌控的一个小时时间段，这一个小时完全属于你自己，保证这一个小时不会有任何打扰，或者任何能影响到你执行不下去这个方法的打扰。要记住这一个小时非常重要，比你后面要执行的所有活动的时间都重要，它绝对值得。
2）在第一张白纸的上方写下“该需求特性的正常流程和影响范围”，然后在白纸下方逐条开始写下该需求特性正常流程包含的内容，大概会使用到哪些库函数，会提供出哪些接口，是否会影响版本升级，是否影响资源文件，是否影响原有的接口等等。
3）在第二张白纸上方写下“该需求特性所有的异常场景和本人以往经常会犯的一些错误点”，然后在白纸下方一条一条的开始往下写。
4）不断重复第2）、3）步。
你可能会觉得这不就跟写的需求澄清材料差不多吗，我要告诉你的是这是两回事，它不是一项质量专员要求你做的质量过程活动，这是你自己和自己之间的一次深层次对话，这不需要告诉任何人，不需要向其他领域输出任何交付物，这是对自己要写出优秀代码的一次自我驱动。
一开始你可能会觉得很难，写几条就写不出来了，或者闪过“这玩意儿是不是真的有用”的念头，不用着急，起身去窗户边呼吸一口新鲜空气或者去打杯水喝，总之不要中断，除非办公室着火了不要去干让这件事继续不下去的事情。当你慢慢往下写到第20或者第30条答案的时候，你可能突然会有一种“这么隐晦的一个异常点都被我发现了，简直太牛了！”的情感涌出，这个时候你会暗暗惊呼有点难以抑制自己的兴奋，这说明你快要接近成功完成了，后面每写出来的一条都会让自己感动。记住，中间不要放弃，你坚持下去的决定会将这一个小时变成你整个需求实现当中最重要的一个小时。
二：多写工具，多封装。
写代码不是仅仅为了测试，写代码前我们要做好需求随时更改，即UI随时更改，功能模块随时更改，第三方模块随时更换的准备。
1）整体架构，一定要提供UI层级分明、功能全面的框架。同时一定要充分考虑大功能块：支付，安全、音视频、物联网、网络。最好采用TabBarController+NavigationController。 推荐：https://github.com/fenglongteng/MobileProject
2）以数据驱动UI，所以数据请求和UI显示分开。
3）UI事件，建议多用delegate，其次才是block，垮层建议用NSNoticefacton。
4）功能模块，能封装的全部封装。正常情况下ViewController里面一般是不会存在private methods的。这个private methods一般是用于日期换算、图片裁剪啥的这种小功能。这种小功能要么把它写成一个category，要么把他做成一个模块，哪怕这个模块只有一个函数也行。
- 团队合作的话，最好统一代码格式。建议用统一模板：http://www.jianshu.com/p/ba524b5a85d7
6）多写注释，越全越好，这样后期维护、版本更新你就少骂当初的自己。
三：良好的代码风格
所有的属性都使用getter和setter
不要在viewDidLoad里面初始化你的view然后再add，这样代码就很难看。在viewDidload里面只做addSubview的事情，然后在viewDidLayoutSubviews里面做布局的事情(当然写在viewDidLoad也可以啊,所有布局封装到一个方法就行。)，最后在viewDidAppear里面做Notification的监听之类的事情。至于属性的初始化，则交给getter去做。
比如这样：
#pragma mark - life cycle
- (void)viewDidLoad
{
[super viewDidLoad];
self.view.backgroundColor = [UIColor whiteColor];
[self.view addSubview:self.firstTableView];
[self.view addSubview:self.secondTableView];
[self.view addSubview:self.firstFilterLabel];
[self.view addSubview:self.secondFilterLabel];
[self.view addSubview:self.cleanButton];
[self.view addSubview:self.originImageView];
[self.view addSubview:self.processedImageView];
[self.view addSubview:self.activityIndicator];
[self.view addSubview:self.takeImageButton];
}
-(void)viewDidLayoutSubviews
{
[super viewDidLayoutSubviews];
CGFloat width = (self.view.width - 30) / 2.0f;
self.originImageView.size = CGSizeMake(width, width);
[self.originImageView topInContainer:70 shouldResize:NO];
[self.originImageView leftInContainer:10 shouldResize:NO];
self.processedImageView.size = CGSizeMake(width, width);
[self.processedImageView right:10 FromView:self.originImageView];
[self.processedImageView topEqualToView:self.originImageView];
CGFloat labelWidth = self.view.width - 100;
self.firstFilterLabel.size = CGSizeMake(labelWidth, 20);
[self.firstFilterLabel leftInContainer:10 shouldResize:NO];
[self.firstFilterLabel top:10 FromView:self.originImageView];
... ...
}
这样即便在属性非常多的情况下，还是能够保持代码整齐，view的初始化都交给getter去做了。总之就是尽量不要出现以下的情况：
- (void)viewDidLoad
{
[super viewDidLoad];
self.textLabel = [[UILabel alloc] init];
self.textLabel.textColor = [UIColor blackColor];
self.textLabel ... ...
self.textLabel ... ...
self.textLabel ... ...
[self.view addSubview:self.textLabel];
}
这种做法就不够干净，都扔到getter里面去就好了。关于这个做法，在唐巧的技术博客里面有一篇文章和我所提倡的做法不同，这个我会放在后面详细论述。
getter和setter全部都放在最后
因为一个ViewController很有可能会有非常多的view，就像上面给出的代码样例一样，如果getter和setter写在前面，就会把主要逻辑扯到后面去，其他人看的时候就要先划过一长串getter和setter，这样不太好。然后要求业务工程师写代码的时候按照顺序来分配代码块的位置，先是life cycle，然后是Delegate方法实现，然后是event response，然后才是getters and setters。这样后来者阅读代码时就能省力很多。
每一个delegate都把对应的protocol名字带上，delegate方法不要到处乱写，写到一块区域里面去
比如UITableViewDelegate的方法集就老老实实写上#pragma mark - UITableViewDelegate。这样有个好处就是，当其他人阅读一个他并不熟悉的Delegate实现方法时，他只要按住command然后去点这个protocol名字，Xcode就能够立刻跳转到对应这个Delegate的protocol定义的那部分代码去，就省得他到处找了。
event response专门开一个代码区域
所有button、gestureRecognizer的响应事件都放在这个区域里面，不要到处乱放。
关于private methods，正常情况下ViewController里面不应该写
不是delegate方法的，不是event response方法的，不是life cycle方法的，就是private method了。对的，正常情况下ViewController里面一般是不会存在private methods的，这个private methods一般是用于日期换算、图片裁剪啥的这种小功能。这种小功能要么把它写成一个category，要么把他做成一个模块，哪怕这个模块只有一个函数也行。
ViewController基本上是大部分业务的载体，本身代码已经相当复杂，所以跟业务关联不大的东西能不放在ViewController里面就不要放。另外一点，这个private method的功能这时候只是你用得到，但是将来说不定别的地方也会用到，一开始就独立出来，有利于将来的代码复用。
为什么要这样要求？
我见过无数ViewController，代码布局乱得一塌糊涂，这里一个delegate那里一个getter，然后ViewController的代码一般都死长死长的，看了就让人头疼。
定义好这个规范，就能使得ViewController条理清晰，业务方程序员很能够区分哪些放在ViewController里面比较合适，哪些不合适。另外，也可以提高代码的可维护性和可读性。
关于View的布局
业务工程师在写View的时候一定逃不掉的就是这个命题。用Frame也好用Autolayout也好，如果没有精心设计过，布局部分一定惨不忍睹。
直接使用CGRectMake的话可读性很差，光看那几个数字，也无法知道view和view之间的位置关系。用Autolayout可读性稍微好点儿，但生成Constraint的长度实在太长，代码观感不太好。
Autolayout这边可以考虑使用Masonry，代码的可读性就能好很多。如果还有使用Frame的，可以考虑一下使用这个项目。
这个项目里面提供了Frame相关的方便方法(UIView+LayoutMethods)，里面的方法也基本涵盖了所有布局的需求，可读性非常好，使用它之后基本可以和CGRectMake说再见了。因为天猫在最近才切换到支持iOS6，所以之前天猫都是用Frame布局的，在天猫App中，首页，范儿部分页面的布局就使用了这些方法。使用这些方便方法能起到事半功倍的效果。
这个项目也提供了Autolayout方案下生产Constraints的方便方法(UIView+AEBHandyAutoLayout)，可读性比原生好很多。我当时在写这系列方法的时候还不知道有Masonry。知道有Masonry之后我特地去看了一下，发现Masonry功能果然强大。不过这系列方法虽然没有Masonry那么强大，但是也够用了。当时安居客iPad版App全部都是Autolayout来做的View布局，就是使用的这个项目里面的方法。可读性很好。
让业务工程师使用良好的工具来做View的布局，能提高他们的工作效率，也能减少bug发生的几率。架构师不光要关心那些高大上的内容，也要多给业务工程师提供方便易用的小工具，才能发挥架构师的价值。
统一模板
团队合作的话，最好统一代码格式。建议用统一模板：http://www.jianshu.com/p/ba524b5a85d7
总结：
** 项目架构的时候一定要考虑需求全面，且考虑到需求扩展，更改。
写代码的时候要考虑代码复用，代码易读，代码易扩展、修改。面向对象7原则。
团队的话，一定要统一代码风格。**
