?????? 最近越來(lái)越感到進(jìn)階之路的困難，和發(fā)展之路的不明確，值此之際，特想寫(xiě)一篇文章，來(lái)總結(jié)下，結(jié)束這種混亂狀態(tài)。
?????? 由于目前在團(tuán)隊(duì)中角色的轉(zhuǎn)換，管理團(tuán)隊(duì)的重任也落在自己身上了，除了技術(shù)方面之外，現(xiàn)在任務(wù)更重了，不能只關(guān)注單點(diǎn)的技術(shù)細(xì)節(jié)了，更多地應(yīng)該從全局 ，從整體方面去思考,提高團(tuán)隊(duì)整體的規(guī)范性和開(kāi)發(fā)效率。
有三大主要的任務(wù)：
（1）團(tuán)隊(duì)管理：任務(wù)分配和溝通
（2）技術(shù)：指導(dǎo) 規(guī)范? 工程結(jié)構(gòu)和架構(gòu)
（3）審核：code review，規(guī)范。
在這其中呢，也是困難重重啊，一時(shí)還難以適應(yīng)，經(jīng)常會(huì)因?yàn)樾薷腷ug，而導(dǎo)致團(tuán)隊(duì)管理方面溝通的欠缺，以及沒(méi)有時(shí)間去好好設(shè)計(jì)工程結(jié)構(gòu)，導(dǎo)致一時(shí)間的混亂狀態(tài)，今天突然想到了也許可以寫(xiě)一篇文章來(lái)好好思考一下。
? 鑒于排版還不是很熟，將就著看吧。
首先呢，就是iOS app開(kāi)發(fā)的 工程結(jié)構(gòu)問(wèn)題。
一般呢，我現(xiàn)在這樣劃分：
BaseClass： ?? BaseView，BaseModel，BaseController?
UIComponent: 基本的UI組件，與項(xiàng)目 業(yè)務(wù) 和界面無(wú)關(guān)的 快速開(kāi)發(fā)組件，最常見(jiàn)的就是? TableView CollectionView? 高度集成化的組件。
Resources ：? 本地一些資源文件，txt plist 音頻等等
ThirdLibrary:? 三方庫(kù)
WebService：網(wǎng)絡(luò)請(qǐng)求以及網(wǎng)絡(luò)層 ，這一層里面會(huì)有涉及一些設(shè)計(jì)設(shè)計(jì)模式運(yùn)用，以及dataModel的引用，交付給 Controller
Utils：里面包括各大組件的 工具方法，常用的小功能的封裝方法，三方分享，三方支付，三方地圖定位，等等以及一些category 方法，工程配置的Macro，配置文件，這些都是工具
Modules ：模塊化。每個(gè)大的功能模塊，這個(gè)一般基于 tabbar+navigation的結(jié)構(gòu)，每個(gè)模塊中 可能會(huì)有定義Mediater，每個(gè)模塊 ViewModel的交付， 跨模塊調(diào)用的話，ModuleMediator的使用，統(tǒng)一管理配置。
Hybird：基于WebView 的OC js雙向交互，以及html文件及時(shí)下載到本地的插件化。先這么交吧?？赡苄枰?調(diào)用Util里面的 類(lèi)來(lái)實(shí)現(xiàn)操作。 這個(gè)里還可能包含 html css js等文件，接口提前定義好。
總原則呢：就是 可維護(hù)，可讀，然后就是盡量 模塊化，組件化，功能性的小模塊 高內(nèi)聚，低耦合。
工程結(jié)構(gòu)講完了，下面說(shuō)說(shuō)我所認(rèn)為的對(duì)開(kāi)發(fā)項(xiàng)目有所幫助，也就是對(duì)代碼可讀性，可維護(hù)性有幫助的一些共識(shí)。
（1）肯定就是命名了， 常量統(tǒng)一 static? xx? const? xx ，變量命名駝峰命名，首字母小寫(xiě)，例如settingBtn，通知 如kNotificationSwitchLogin，
（2）對(duì)于我們經(jīng)常運(yùn)用的 UIViewController ，代碼組織如下：
#pragmamark-Lifecycle
-(instancetype)init{}
-(void)dealloc{}
-(void)viewDidLoad{}
-(void)viewWillAppear:(BOOL)animated{}
-(void)didReceiveMemoryWarning{}
#pragma mark–Create UI
-(void)createUI{
}
#pragmamark–Load Data
-(void)loadData{}
-(void)request{}
#pragmamark-CustomAccessors
-(void)setCustomProperty:(id)value{}
-(id)customProperty{}
#pragmamark–Event Response
#pragmamark-Protocolconformance
#pragmamark-UITextFieldDelegate
#pragmamark-UITableViewDataSource
#pragmamark-UITableViewDelegate
（3）基本的多處用到的 公共view，例如選擇，提供統(tǒng)一的接口，和回調(diào)接口，給定指定數(shù)據(jù)格式，選擇完即可返回我們所需要的東東，這個(gè)問(wèn)題呢，封裝的view 提供對(duì)外的接口一定要簡(jiǎn)單易用，其他顯示，收起使用者不需要管理， 這點(diǎn)很關(guān)鍵。就比如
+(void)showWithArr:(NSArray*)arr pickType:(PickType)pickType picked:(AddressPickerControllerBlock)block;
命名不太規(guī)范啊,但是大概意思是這樣，arr，為結(jié)構(gòu)化的數(shù)據(jù)，里面可能是 dict，model，寫(xiě)接口的時(shí)候，數(shù)據(jù)格式自定義完，約束相關(guān)者給定指定的數(shù)據(jù)格式。
pickType 為 single和double，
block 回調(diào)給我們需要的數(shù)據(jù)。id and name。
（4）基本的操作硬件類(lèi)的東東，比如拍照，選圖片， 隱藏內(nèi)部細(xì)節(jié)，高內(nèi)聚，外觀模式的運(yùn)用，提供一個(gè)高度簡(jiǎn)化的接口，調(diào)用完回調(diào)，等等，而不是重復(fù)作業(yè)哦。 勁酒雖好，可不要貪杯噢。
（5）盡量做到 少if? else 的判斷邏輯，能細(xì)化成可配置，可替換的最好。 小技巧，就是 用字典來(lái)配置，其他就是策略模式的運(yùn)用，替換類(lèi)了。不同邏輯，不同類(lèi)了。
（6）針對(duì)接口編程，而不是針對(duì)實(shí)現(xiàn)，這可是很有學(xué)問(wèn)的，多定義接口，這樣很靈活，只要做到 替換一個(gè)包裝一定行為的對(duì)象即可。很多時(shí)候就可以做到一定的可擴(kuò)展性，而不用修改邏輯代碼，修改細(xì)化的類(lèi)即可。/繼承和組合的取舍
???????? 說(shuō)完基本的結(jié)構(gòu)和共識(shí)，就輪到下面的 主題了。其實(shí)上面說(shuō)的也已經(jīng)體現(xiàn)出了一定的架構(gòu)了，組件化的思想嘍。哈哈。
目前市面上的架構(gòu)通常是這樣的，天下架構(gòu)出自MVC，子MVC基礎(chǔ)之上衍生出來(lái)一些架構(gòu)。
????? 例如 MVVM? 三層架構(gòu)?? MVP架構(gòu)?? CDD架構(gòu)，眼花繚亂啊。這就需要我們 自己結(jié)合自己公司的業(yè)務(wù)和項(xiàng)目類(lèi)型，總結(jié)一套屬于自己的架構(gòu)了。
