我的 知识星球 里有人问到 Coding-iOS 这个开源项目值得学习吗，这个开源客户端有着 3500 + stars，看起来很受欢迎。
我把代码下载下来后看了一会，我的结论是：这个项目不值得作为优秀项目进行学习。说明一下，我并不是说这个项目代码写的烂，只是作为一个模范项目来学习的话，这个项目整体水平一般。
这个项目的问题
细节处代码质量差
这个项目里的代码我看到时间比较早的有 2014 年，意味着这是一个已经持续多年的项目。代码的细节质量做的很马虎，小到语法格式，大一点的命名，再大一点到函数的实现逻辑都很普通。
随手举个例子，上面的代码声明了一组 Label，本身 UILabel 缩写成 L 已经不是一个规范的做法了。但是如果团队都约定成 L 表示 Label 也是接受的，但是同一行里，还被缩写成了 T 和 V。团队稍微对代码质量有点要求应该都不会允许这样代码的出现。
落后的资源管理
都 9012 年了，项目里的图片资源没有使用 Assets 管理，还是使用古老的 @2x @3x 图片进行图片管理。可以说因为历史原因，这个项目刚启动的时候没有用 Assets，但是到现在这么简单的迁移都没做，说明开发者对新技术的运用很不敏感。
简单的架构
这个项目里的代码组织非常的单纯。继承了 MVC 的光荣传统，项目主要逻辑分成三个文件夹 Models、Views、Controllers。也许项目刚启动的时候按照这个思路去管理代码文件还能接受，但是项目稍微发展大一点，这个结构就会非常的不利于项目的维护。
比如有一个业务 A，为了实现这个业务你写入了 XModel、YView、CController。过了一段时间后发现业务 A 效果不好，需要对其进行下线。这个时候维护的人需要非常清楚的找到分散在三个文件夹里的三个代码文件将其删除。否则项目里有了无用的多余代码。这么说起来感觉也还好，实际业务中可能一个业务对应了很多个 View、Cell。执行下线任务 A 的开发者很可能不是之前负责的开发者。下线的可能是一个 3 年前的业务，当时负责开发的程序员已经离职了。这个时候维护的人是很难确切的把业务相关的代码都找到的，就算找到了也要花很多时间。尤其是这个项目里 MVC 下一级的层级也没怎么区分，要在几十个 Cell 里找到一个文件还是挺费劲的。
组件化
这个项目没有对业务模块进行组件化划分。所有的业务代码都堆在一个项目里。项目增长的越大，维护成本就越高。新人的理解成本就越高。也不利于多人同时开发。
建议的学习路径
想通过学习优质的开源项目，提高自己的编程水平这个心情可以理解。不过大多数时候学习一个真实的项目性价比是很低的。
一个真实的项目常常会有这样的问题：
- 很多设计是针对具体业务展开的，如果你不了解业务场景，你就不能明白代码为什么这么写。这样就导致你需要先熟悉这个项目的业务，才能看的懂代码。
- 实际开发中大概率会遇到一些 featrue 来不及开发了，先用成本的实现发布一版再说。所以项目里的代码可能有些不错，有些实现的很差。作为项目而言是无所谓的，功能稳定就行，用户使用的时候不管代码实现的好不好。但是对于学习的开发者而言，花时间学习的是很烂的代码，得不偿失。
- 真实项目中的需求是持续迭代的。很多项目本来是按照需求 A 设计的，结果做着做着客户要求再加一个需求 B。那么原来代码的设计没考虑到这点需求，继续在原来的代码上实现就会很蛋疼。如果大家维护一个老的项目也会遇到这样的场景，有个地方命名直接实现就好了，却用了一个蹩脚的方式。其实是因为原来的需要兼顾 另外一块功能，只是后来需求变了，不再需要兼顾了。那么最后看代码的人就觉得为什么不按照直接的方式来实现。
因此即便有一个优质的项目，学习前的成本也是挺高的。
我认为一个优质的项目分为两块：良好的架构和优秀的实现。就像一个大的项目会拆分成很多模块一样，想要提高自己的编程能力也要拆分成很多小模块去达成。比如你的觉得你的命名不好，代码可读性差，你就去找这方面相关的资料去针对性的学习。可以看看《编写可读代码的艺术》《Clean code》。如果你觉得自己模块抽象能力不好，学习一下面向对象、设计模式之类的。如果本身这些具体模块的好坏自己不了解，直接学习一个优质项目也是囫囵吞枣。假设有一个老外只喝过咖啡，没喝过茶。然后你给他一堆好茶叶给他喝，最后让他总结好的茶叶有什么特点，他也讲不出个所以然来。
