APP 开发模式，架构，代码规范记录

        几年来，开发过若干项目，有单工程的小项目，也有若干组件组成的大一点的项目，对APP架构有一些自己的理解。

        首先说单工程项目。开发前期，要对整个项目有全面的了解，对未来趋势有一个大致的预计。如果业务不多，未来扩展要求也不高，可以直接写成单工程项目。单工程项目适合单人开发维护，能快速的解决问题，扩展功能。但是，一旦多人维护，就会经常遇到代码冲突的问题。项目小，建议用单工程。

        现在大多数公司都是多人团队，多人维护同一个项目。一般都是采取模块化，组件化开发模式。个人负责自己的组件，相互之间很少会有代码冲突问题。而且，个人负责自己的技术或者业务模块，能对相关知识有很深的了解。不过，有利有弊。这样不利于团队同事对其他模块业务技术的了解，若有同事离职等问题，会造成响应业务线短期的真空状态。不过，模块化开发，可以很方便的增加，减少业务线，在技术支持足够的情况下，业务的开关过程会很迅速，代码会很简洁，还是很好的。当然，模块化开发也是会有一些问题的，以我们公司的为例。

问题：

        1.代码冗余较严重。组件开发完成后会做静态代码走查，单个组件的代码冗余控制的很好。但是由于业务划分不明确，以及为了兼容性，稳定性考虑，组件与组件之间的代码冗余，资源冗余较严重。

        2.组件定位不明确。开始的时候没有业务层，技术层的明确划分，导致很多组件不伦不类，既有技术的功能，又有业务的功能。

        3.团队内部对优秀组件的使用不积极。  我们后期为兼容崩溃开发了若干个优秀组件，但是只有各自的开发者使用，别的同事很少使用。

        4.第三方组件更新不及时。  一直担心兼容适配问题，工程内部的第三方组件，AFNetworking,SDWebImage等更新缓慢。

        5.引用第三方SDK有时候会有库的冲突问题。有一些相近功能的SDK，会使用同一个framework，而且有的是直接把framework打到SDK里面，使用时就会造成库冲突。而且，有时候SDK内部类命名不规范，也会造成冲突。

解决方案：

        1.推行人工代码走查与静态走查相结合机制，坚决杜绝不必要的代码冗余问题。

        2.明确项目层级。将组件明确为业务层组件和基础层组件。.业务层组件负责实现APP业务需求，基础层组件为业务层组件提供技术支持。像电商的秒杀模块，活动模块，购物车模块，商品详情模块等，都属于业务层，像网络引擎，数据管理等都属于基础层。

        3.定期进行技术讨论，分享优秀组件。

        4.时时关注第三方优秀组件更新，即使更新版本。

        5.要多多使用继承，工程中所有控制器一定要有一个相同的父类，这样如果需要做一些特殊的处理，埋点啦，崩溃记录啦，就会很方便。

        6.减少对第三方SDK的使用，即使使用，也要多做技术预言，选择合适的SDK。

对项目架构设计的记录：

        1.大的项目使用组件化开发架构，合理定义组件，技术类基础组件优先开发，业务类组件开发过程中，不断优化基础组件功能和API接口。

        2.开发过程中，发现相同功能模块，一律抽成公共模块。譬如大图浏览，上传下载等。

        3.工程内部一个功能的代码要放到一个业务文件夹中，便于查找修改，或者替换。

        4.功能文件夹内要划分Controller,View,UIViewController,Cell,Model等文件夹，同时每个文件夹内部如果有需要还要创建一个Base文件夹。

        5.最好工程要有自己的统一的Base类，譬如BaseUIViewController,BaseUIView,BaseNsobject等，如果要统一改一个东西，或者统计数据什么的，会很有用。