iOS应用架构谈 开篇

[https://casatwy.com/iosying-yong-jia-gou-tan-kai-pian.html]有些观点比较赞同；

什么样的架构师是好架构师？

1. 每天都在学习，新技术新思想上手速度快，理解速度快

做不到这点，你就是码农

1. 业务出身，或者至少非常熟悉公司所处行业或者本公司的业务

做不到这点，你就是运维

1. 熟悉软件工程的各种规范，踩过无数坑。不会为了完成需求不择手段，不推崇quick & dirty

做不到这点，你比较适合去竞争对手那儿当工程师

1. 及时承认错误，不要觉得承认错误会有损你架构师的身份

做不到这点，公关行业比较适合你

1. 不为了炫技而炫技

做不到这点，你就是高中编程爱好者

1. 精益求精

做不到这点，（我想了好久，但我还是不知道你适合去干什么。）

什么样的架构叫好架构？

1. 代码整齐，分类明确，没有common，没有core
2. 不用文档，或很少文档，就能让业务方上手
3. 思路和方法要统一，尽量不要多元
4. 没有横向依赖，万不得已不出现跨层访问
5. 对业务方该限制的地方有限制，该灵活的地方要给业务方创造灵活实现的条件
6. 易测试，易拓展
7. 保持一定量的超前性
8. 接口少，接口参数少
9. 高性能

以上是我判断一个架构是不是好架构的标准，这是根据重要性来排列的。客户端架构跟服务端架构要考虑的问题和侧重点是有一些区别的。下面我会针对每一点详细讲解一下

简而言之，不建议开Common的原因如下：

1. Common不仅仅是一个文件夹，它也会是一个Pod。不管是什么，在Common里面很容易形成错综复杂的小模块依赖，在模块成长过程中，会纵容工程师不注意依赖的管理，乃至于将来如果要将模块拆分出去，会非常的困难。
2. Common本身与细粒度模块设计的思想背道而驰，属于一种不合适的偷懒手段，在将来业务拓张会成为阻碍。
3. 一旦设置了Common，就等于给地狱之门打开了一个小缝，每次业务迭代都会有一些不太好分类的东西放入Common，这就给维护Common的人带来了非常大的工作量，而且这些工作量全都是体力活，非常容易出错。

那么，不设Common会带来哪些好处？

1. 强迫工程师在业务拓张的时候将依赖管理的事情考虑进去，让模块在一开始发展的时候就有自己的土壤，成长空间和灵活度非常大。
2. 减少各业务模块或者Demo的体积，不需要的模块不会由于Common的存在而包含在内。
3. 可维护性大大提高，模块升级之后要做的同步工作非常轻松，解放了那个苦逼的Common维护者，更多的时间可以用在更实质的开发工作上。
4. 符合细粒度模块划分的架构思想。