iOS开发笔记

项目结构&规范分析

2016-10-26  本文已影响74人  陈胜华

摘抄:http://www.cocoachina.com/ios/20161026/17850.html

从代码的整洁度上就可以看出一个程序员的实力，规范其实就是让你养成一种良好习惯的标杆，在此面前我们应该顺从。本篇我们以OC为例，统计了一些在编写程序中需要注意的事项，共有20条，当然还有更多的规范，此处只是做个示例。

#pragma mark - **********View lifeCycle******

#define PI 3.1415926

- (void)testMethod {
   if (![testSome boolValue]) {// 不合适就返回，下面做处理
   return;
  }
 //Do something important
}

NSError *error;
if (![self trySomethingWithError:&error]) {
  // Handle Error
}

- (void)aboutFisrtNumber:(NSString *)oneStr
          withNextNumber:(NSString *)twoStr
          withLastNumber:(NSString *)threeStr{
// do something
}

self.productsRequest = [[JSProductsRequest alloc] 
  initWithProductIdentifiers:productIdentifiers];

 #pragma 与方法之间空1行

着手一个新项目条理

在着手一个项目前先读文档（如果有文档的话）。尽管读了文档你不一定知道每一个代码的细节，但是如果你了解那个问题的话，你一定知道怎么写可以写出一个满足文档的内容。这个时候大脑里面就可以有个框架，先猜一猜，然后看代码，事半功倍。找不到好的文档，就看他的测试用例，也是有一样的功效的。因为测试都是从文档出发编写的，而不是从代码出发编写的。找不到文档和测试用例？那就直接Gank吧。

读代码要层次化、带着问题去阅读。首先整体了解这个软件是干什么？解决什么问题？包含哪些大的模块，各个模块的作用是什么，各个模块的调用关系怎么样？然后对于每一个模块，这个模块是干什么的？为什么要有这个模块？这个模块怎么实现的？最后细化到每一个包，每一个类，每一个函数方法。从上到下，一一击破每一个问题，认真去思考他这样设计、写代码的好处，因为好的软件都会满足这种从抽象->具体的原则的。

在开始读具体代码前定位好所有要读的文件，知道他们的位置和名字，设计良好的工程光看工程的目录结构和文件名就能知道个大概功能了。事实上阅读代码的难易程度70%取决于代码书写的规范程度，写乱掉的代码，大师也读不懂。之后根据你对目录结构的理解确定文件阅读的顺序（我反正都是从main函数开始读的）。你最好对设计模式有一定了解，否则你读面向对象的code时会经常无法理解code为啥要弄得这么层层嵌套。阅读代码一个最重要的提升水平的地方就是理解好的代码如何合理使用设计模式。基本的阅读起点都会选择main函数或者类的构造函数。然后把自己想象成cpu执行程序那样去阅读你的代码。遇到需要跳转函数时，不要急于跳转，以了解函数功能和输入输出为目标，读代码最忌讳的是不抓结构抓细节，只见树木不见森林，比起某个函数具体功能来说对结构的全局把握更重要。功能了解清楚后继续跳回来（这里就可以区分代码写的优不优秀，优秀的代码光看函数名字就知道功能，连跳转都不用）。结构弄清楚了，知道程序怎么跑了，source code的精华你已经读了60%了，之后根据需要再对具体函数深入分析，到这里整个代码已经被你扒光了，没什么神秘了。

阅读代码有两种模式：top-down 和 bottom-up。Top-down 模式，就是先设定一个 use case，比如说打开一个文件。然后静态跟着代码看，或者用 debugger 跟着看。每次出现函数调用的时候，把函数的执行层次纪录下来。大致如下：

func1( )
   func2(  )
       func(  )
   func3(  )

这种图表很随意，你可以根据自己的需要增加信息，可以把重要的「实际参数」一直标下来，画函数调用图，然后标注每个函数在干什么。不过这个图无法清楚地表明一个变量的轨迹，需要另外的图来标示变量的变化轨迹。要是想提高阅读代码的速度，归根结底要多读多写。熟悉程序的基本构成单元（例如循环、分支）的常见写法，各种lib, api的调用方式。这样阅读深层次代码不用再回头查形式参数到底指什么。这个图的基本作用是防止在阅读深层次代码时忘记总体执行层次。Top-down 模式进行到一定层次，往往会发现虽然图画了出来，但还是无法了解程序在干什么。这时需要转入 bottom-up 模式，一直深入到最底层，给能了解作用的底层函数一个一个的写文档。当然这时的文档是完全底层的观点。bottom-up的阅读方法，有时候会一头扎进去，出不来了。这种方式适合读一些比较优秀的开源项目的代码，也会很好地提高内功。然后就是不断在两个模式之间转换，不断的细化两种模式的理解。

最后，对于OC工程可以去GitHub找UIViewController-Swizzled这个库，拉下来放到项目里，他有什么用呢？他可以把每个页面的类名打出来。而且有层次结构，也就是说你只需要打开项目点点点，就知道这个App运行的顺序了。

iOS开发的细节及全局观

"好代码是廉价的"，这句话没有歧义。中国的语言博大精深，其实这句话的真实含义是，优秀的代码使用起来毫不费力。通常我们对好代码的定义是优雅的使用各种设计模式，兼顾各种情况（异常或是正常），有效而且合理的使用优化算法等。很好，这在开发中帮我们做了很多事，这也是在开发中值得发扬的。但是，这难免的会增加实现的复杂性，如果对某些技巧认识不清极有可能成为一种开发的阻碍。实际上，在日常的开发中，我们大多是为了实现功能，很多的都是在写“廉价的代码”，以功能优先，先实现功能然后再根据需要在后期进行优化，这没什么不好。

其中一个误区是，我们需要从逻辑着手而不是功能，这样固然很好，但却会影响开发的效率。好的程序员和伟大的程序员之间的区别就在于伟大的程序员理解他们的模式，让代码廉价。当模式能够给你带来好处，而且为你省时时才去使用它们，如果不是这样就不要使用它们。当框架能够帮你提高开发速度时才使用它们，

在必要的时候重构，不要做一些超前性的开发。这些只是针对于日常开发，编写SDK或框架是另一套逻辑，总之就是不要抱残守缺，固守一种形态，学会因地制宜。

一个不好的现实是大多数程序员都是业务性程序员，每天重复着一样的工作，写着功能不同但形式上是一样的代码，这就是普通程序员的宿命，因此上面才会为了快速构建而选择“廉价的代码”。但是，这不是有进取精神的程序员所想要的，所以我们才会有进步，即使是一个小工也要像专家一样思考。

那么，所谓的专家们，在看一个项目时是如何思考的呢，我们下面做一些分析。

优秀的开发者会从架构的视角来看问题，一般而言，软件系统的架构（Architecture）有两个要素：

它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
架构是一个约定，一个规则，一个大家都懂得遵守的共识。需要强调的是“架构因未来而存在”。架构的最终体现是一个软件，是模块化，简洁，可维护，可任意替换，人性化设计，可以把它全部打碎了重新从一个模型自由的再去组装成另一个模型。是高内聚，低耦合，既可以作为一个完整的可交付模块，也可以“打碎”重组。架构需要考虑的是扩展性，安全和性能，如此才算是合理的架构。

在构建项目时，不管采用什么方法，全局观、高度的代码审美能力、灵活使用各种设计模式一定都是贯穿其中的。首先，搞清楚业务逻辑，这决定了你的架构是否足够易用。另外，传的参数越少，耦合度相对而言就越小，你替换模块或者升级模块所花的的代价就越小。搞清楚业务之间的依赖关系，建立好模块交流规范并设计模块，关键在于建立一套统一的交流规范。推演预测一下未来可能的走向，必要时添加新的模块，记录更多的基础数据以备未来之需。软件是有生命的，多一点考虑便会多一分健壮。

好的架构需要下面几点：

上一篇 下一篇

猜你喜欢

热点阅读