糟糕的 Coding 客户端（iOS）代码质量
今天偶然看了一下 Coding 的 iOS 客户端源码，其代码质量着实让我十分震惊。这里闲来吐槽一下。
1. 工程结构问题
Coding 遵循了标准的 MVC 模式，相比 MVVM、MVP 等模式，MVC 虽古老经典，但仍然实用且应用广泛，尤其是针对企业级的项目，开发人员水平良莠不齐，使用 MVC 更易于开发和协作。但从目录的命名上来看，我已经能够探嗅到糟糕代码的气味了，比如单复数不一致（Models 和 Util），类型重复（Images 应包含在 Resources 中）。
然而当我打开 Controllers 目录后...
毫无分类可言，所有的类全部平坦地列在 Controllers 文件夹，对于超小规模的项目（例如 Sample Code）不加以分类还情有可原，然而这一个 Group 几十个类，找起来都十分费劲。对于这种情况，解决起来也十分简单，将同一类别或相关的一组类放到一个 Group 里，不需要创建 Folder Reference，import 语句也不需要改变。
2. 命名习惯和代码风格
代码风格的问题实际上是一个非常难解决的问题，在 Xcode 这样没有 lint 功能的 IDE 中想统一代码风格更加困难。
我们随便打开一个文件看一下：
- 没有合理换行。Class Extension 声明部分与 Implementation 部分没有换行分开，虽然问题不大，但是看起来十分不适服。
- 括号前缺少空格，这个很明显。
- 变量命名。curMRPRInfo 是什么东西？cur 是 current 还能推出来，那 MRPR 呢？苹果十分不推荐使用缩写来给变量命名，可以看到，公开的 API 全部都通俗易懂，基本都是见名知义，vcWithPath 这样的命名根本不会存在。类似的还有 myTableView，my？？？
- 没有良好的使用 literal number 来声明 NSNumber，这会使代码有很多冗余。
其他文件中还有很多问题，这里就不一一列举了，现在很多大公司都会有 Code Style Guideline，初创公司中这类问题难以避免也没有办法。
3. 组件复用程度低
Coding 整个项目中有许多许多 View Controllers 都存在相当多的重复代码，最常见的就是一个 VC 中就一个 UITableView，有的再多一个 UISearchBar 之类的。然后每个类都会重复实现 Pull to Refresh、Table View 的一些 setup、数据请求逻辑。如果让我来做，我会将所有的 Table View 进行归纳，合并到一个 UITableViewController 中，通过暴露一个 delegate 或者允许设置 block 属性来实现交互。然后将这个 UITableViewController 当作 Child View Controller 加到 Parent View Controller 中，这样一定能减少大量的代码。
类似的问题还有多处实现类似的 UIScrollView 子类，不知道为啥放着 UICollectionView 不用，非要自己实现没有回收机制的低效 View。
4. 分层错误
很多 View 类中包含大量业务逻辑，甚至第三方 API。正确的 UIView 子类不会包含任何产生副作用的代码，可以审查 UIKit 提供的类，都是充当单纯的视图角色。对于这类 View，应该用 View Controller 去替代，然后选择合理的 presentation 方式显示，Coding 开发者这么做可能是为了偷懒不写 Custom Transitioning。总之这样做是非常不好的习惯。
Model 层也有一点小问题，个人认为 Model 层与 API 层应保持一定的分离，也就是说 Model 类自身不应该去做 Server Response 的 Parsing，为了将 Parsing 与 Model 自身关联起来，可以采用 Category 的方式来对 Model 进行扩展。或者采用一些框架，根据 JSON 自动创建 Model。
5. 奇葩做法
更令我大跌眼镜的是，Coding 团队给 NSObject 做了相当多的扩展，现在的 NSObject 几乎是全能王了！
随便拿来一个 object，取一下 class 就能显示 HUD 了，是挺爽的。可哪有这么干的啊？？Category 真是被玩坏了。好好地放到一个 Util 类中不好么？还有一些很奇怪的扩展，这里就不说了。
总之，Coding 整个项目下来，使用了大量的传统技术，颇有外包公司的做法。Apple 的最佳实践应该是没实践几个。Can you believe that? 整个项目中竟然一个 NSOperation 都没用诶！异步任务向来都是开始了就没结束了。
Coding 开源精神是好，但是开源前也一定做好 Code Review 工作，要对 iOS 初学者负责，如果说仅仅为了开源而开源，那么也就一点意义都没有了。
到最后我已无力吐槽，很无聊的一篇文章，就这样～
