MVC的實(shí)現(xiàn)思路是：用戶操作View，在Controller層完成業(yè)務(wù)邏輯處理，更新Model層，將數(shù)據(jù)顯示在View層。
創(chuàng)新互聯(lián)公司專注于連云企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè),商城建設(shè)。連云網(wǎng)站建設(shè)公司,為連云等地區(qū)提供建站服務(wù)。全流程按需搭建網(wǎng)站，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)
在MVC中，每個(gè)層之間都有關(guān)聯(lián)，耦合比較緊，在大型項(xiàng)目中，維護(hù)起來(lái)比較費(fèi)力。
View把控制權(quán)交給Controller層，自己不執(zhí)行業(yè)務(wù)邏輯；Controller層執(zhí)行業(yè)務(wù)邏輯并且操作Model層，但不會(huì)直接操作View層；View和Model層的同步消息是通過(guò)觀察者模式進(jìn)行，而同步操作是由View層自己請(qǐng)求Model層的數(shù)據(jù)，然后對(duì)視圖進(jìn)行更新，觀察者模式可以做到多視圖同時(shí)更新。
Person.h
Person.m
TestView.h
TestView.m
ViewController.m
MVVM和MVP的最大區(qū)別是采用了雙向綁定機(jī)制，View的變動(dòng)，自動(dòng)反映在ViewModel上。
MVVM結(jié)構(gòu)如圖：
模型層：
Person.h
Person.m
視圖層：
TestView.h
TestView.m
PersonViewModel.h
PersonViewModel.m
ViewController.m
iOS的項(xiàng)目架構(gòu)一般是使用這兩種模式構(gòu)建出來(lái)：MVC模式、MMVM模式。
MVC模式使用還是非常常用和普遍的，而對(duì)于MMVM模式則是一般會(huì)在項(xiàng)目考慮頻繁View-Model交互情況下使用。
有必要，遵循mvc的設(shè)計(jì)模式就可以
MVC是構(gòu)建iOS App的標(biāo)準(zhǔn)模式。然而，最近我已經(jīng)越來(lái)越厭倦MVC的一些缺點(diǎn)。在本文，我將重溫一下MVC是什么，詳述它的缺點(diǎn)，并且告訴你一個(gè)新的方式來(lái)架構(gòu)你的App：Model-View-ViewModel。拿出你的流行語(yǔ)bingo card(賓果卡，一種游戲卡片-譯者注)，因?yàn)槲覀兗磳⑦M(jìn)行一次范式轉(zhuǎn)變。
Model-View-Controller
Model-View-Controller是一個(gè)用來(lái)組織代碼的權(quán)威范式。Apple甚至是這么說(shuō)的。在MVC下，所有的對(duì)象被歸類為一個(gè)model，一個(gè)view，或一個(gè)controller。Model持有數(shù)據(jù)，View顯示與用戶交互的界面，而View Controller調(diào)解Model和View之間的交互。
在上圖中，view將用戶交互通知給controller。view controller通過(guò)更新model來(lái)反應(yīng)狀態(tài)的改變。model（通常使用Key-Value-Observation）通知controller來(lái)更新他們負(fù)責(zé)的view。大多數(shù)iOS應(yīng)用程序的代碼使用這種方式來(lái)組織。
模型model的對(duì)象通常非常非常的簡(jiǎn)單。很多時(shí)候，他們就是Core Data managed objects，或者避免使用Core Data，就是其他流行的數(shù)據(jù)模型層。根據(jù)Apple的文檔，model包括數(shù)據(jù)和操作數(shù)據(jù)的業(yè)務(wù)邏輯。在實(shí)踐中，model層往往非常薄，不管怎樣，model層的業(yè)務(wù)邏輯被拖入了controller。
視圖view通常是UIKit控件（component，這里根據(jù)習(xí)慣譯為控件）或者編碼定義的UIKit控件的集合。進(jìn)入.xib或者Storyboard會(huì)發(fā)現(xiàn)一個(gè)app、Button、Label都是由這些可視化的和可交互的控件組成。你懂的。View不應(yīng)該直接引用model，并且僅僅通過(guò)IBAction事件引用controller。業(yè)務(wù)邏輯很明顯不歸入view，視圖本身沒(méi)有任何業(yè)務(wù)。
還有控制器controller。Controller是app的“膠水代碼”：協(xié)調(diào)模型和視圖之間的所有交互?？刂破髫?fù)責(zé)管理他們所擁有的視圖的視圖層次結(jié)構(gòu)，還要響應(yīng)視圖的loading、appearing、disappearing等等，同時(shí)往往也會(huì)充滿我們不愿暴露的model的模型邏輯以及不愿暴露給視圖的業(yè)務(wù)邏輯。這引出了第一個(gè)關(guān)于MVC的問(wèn)題...
厚重的View Controller
由于大量的代碼被放進(jìn)view controller，導(dǎo)致他們變的相當(dāng)臃腫。在iOS中有的view controller里綿延成千上萬(wàn)行代碼的事并不是前所未見(jiàn)的。這些超重app的突出情況包括：厚重的View Controller很難維護(hù)（由于其龐大的規(guī)模）；包含幾十個(gè)屬性，使他們的狀態(tài)難以管理；遵循許多協(xié)議（protocol），導(dǎo)致協(xié)議的響應(yīng)代碼和controller的邏輯代碼混淆在一起。
厚重的view controller很難測(cè)試，不管是手動(dòng)測(cè)試或是使用單元測(cè)試，因?yàn)橛刑嗫赡艿臓顟B(tài)。將代碼分解成更小的多個(gè)模塊通常是件好事。
遺失的網(wǎng)絡(luò)邏輯
蘋果使用的MVC的定義是這么說(shuō)的：所有的對(duì)象都可以被歸類為一個(gè)model，一個(gè)view，或是一個(gè)controller。就這些。那么把網(wǎng)絡(luò)代碼放哪里？和一個(gè)API通信的代碼應(yīng)該放在哪兒？
你可能試著把它放在model對(duì)象里，但是也會(huì)很棘手，因?yàn)榫W(wǎng)絡(luò)調(diào)用應(yīng)該使用異步，這樣如果一個(gè)網(wǎng)絡(luò)請(qǐng)求比持有它的model生命周期更長(zhǎng)，事情將變的復(fù)雜。顯然也不應(yīng)該把網(wǎng)絡(luò)代碼放在view里，因此只剩下controller了。這同樣是個(gè)壞主意，因?yàn)檫@加劇了厚重View Controller的問(wèn)題。
那么應(yīng)該放在那里呢？顯然MVC的3大組件根本沒(méi)有適合放這些代碼的地方。
較差的可測(cè)試性
MVC的另一個(gè)大問(wèn)題是,它不鼓勵(lì)開(kāi)發(fā)人員編寫單元測(cè)試。由于view controller混合了視圖處理邏輯和業(yè)務(wù)邏輯，分離這些成分的單元測(cè)試成了一個(gè)艱巨的任務(wù)。大多數(shù)人選擇忽略這個(gè)任務(wù)，那就是不做任何測(cè)試。
定義模糊的“Manage”
之前我提到了view controller可以管理試圖的層次結(jié)構(gòu)；view controller有一個(gè)“view”屬性，并且可以通過(guò)IBOutlet訪問(wèn)視圖的任何子視圖。當(dāng)有很多outlet時(shí)這樣做不易于擴(kuò)展，在某種意義上，最好不要使用子視圖控制器（child view controller）來(lái)幫助管理子視圖（subview）。
要點(diǎn)在哪？驗(yàn)證用戶輸入的業(yè)務(wù)邏輯應(yīng)歸入controller還是model呢？
在這里有多個(gè)模糊的標(biāo)準(zhǔn)，似乎沒(méi)有人能完全達(dá)成一致。貌似無(wú)論如何，view和對(duì)應(yīng)的controller都緊緊的耦合在一起，總之，還是會(huì)把它們當(dāng)成一個(gè)組件來(lái)對(duì)待。
Hey！現(xiàn)在有個(gè)點(diǎn)子...
Model-View-ViewModel
在理想的世界里，MVC也許工作的很好。然而，我們生活在真實(shí)的世界。既然我們已經(jīng)詳細(xì)說(shuō)明了MVC在典型場(chǎng)景中的問(wèn)題，那讓我們看一看一個(gè)可供替換的選擇：Model-View-ViewModel。
MVVM來(lái)自微軟，不過(guò)不要堅(jiān)持反對(duì)它。MVVM和MVC很像。它正式規(guī)范了視圖和控制器緊耦合的性質(zhì)，并引入新的組件。
在MVVM里，view和view controller正式聯(lián)系在一起，我們把它們視為一個(gè)組件。視圖view仍然不能直接引用模型model，當(dāng)然controller也不能。相反，他們引用視圖模型view model。
view model是一個(gè)放置用戶輸入驗(yàn)證邏輯，視圖顯示邏輯，發(fā)起網(wǎng)絡(luò)請(qǐng)求和其他各種各樣的代碼的極好的地方。有一件事情不應(yīng)歸入view model，那就是任何視圖本身的引用。view model的概念同時(shí)適用于于iOS和OS X。（換句話說(shuō)，不要在view model中使用 #import UIKit.h）
由于展示邏輯（presentation logic）放在了view model中（比如model的值映射到一個(gè)格式化的字符串），視圖控制器本身就會(huì)不再臃腫。當(dāng)你開(kāi)始使用MVVM的最好方式是，可以先將一小部分邏輯放入視圖模型，然后當(dāng)你逐漸習(xí)慣于使用這個(gè)范式的時(shí)候再遷移更多的邏輯到視圖模型中。
使用MVVM的iOS app是高度可測(cè)試的；因?yàn)関iew model包含了所有的展示邏輯并且不會(huì)引用view，所以它可以通過(guò)編程方式充分測(cè)試。雖然有眾多的hack技術(shù)參與到測(cè)試Core Data模型，但使用MVVM寫的app可以進(jìn)行充分的單元測(cè)試。
以我的經(jīng)驗(yàn)，使用MVVM會(huì)輕微的增加代碼量，但總體上減少了代碼的復(fù)雜性。這是一個(gè)劃算的交易。
你可以使用KVO，就像MVC那樣，但這很快就會(huì)變得難以管理。事實(shí)上，使用ReactiveCocoa會(huì)是更好的方式來(lái)組織各個(gè)部分。
基礎(chǔ)
一定的編程經(jīng)驗(yàn)
這里說(shuō)的編程經(jīng)驗(yàn)是至少熟練一門編程語(yǔ)言，對(duì) OOP 有一定的了解，最好熟悉一些基本的設(shè)計(jì)模式。遇到過(guò)的好多 iOS 開(kāi)發(fā)，大多是從別的語(yǔ)言轉(zhuǎn)過(guò)來(lái)的，所以有一定的編程基礎(chǔ)，學(xué)起來(lái)會(huì)更容易 get the point.
如果是第一次接觸編程，當(dāng)然也是沒(méi)問(wèn)題的，只是要做好心理準(zhǔn)備，可能會(huì)比想象的難。
英語(yǔ)
發(fā)現(xiàn)不少開(kāi)發(fā)對(duì)于英語(yǔ)似乎有點(diǎn)接受不能，通常都是中文優(yōu)先，除非迫不得已，才硬著頭皮看看 StackOverflow，英文文章，文檔等。忘了是誰(shuí)說(shuō)過(guò)「難走的路越走越好走」，通常如此。其實(shí)只要稍微 push 一下自己，那些技術(shù)文章啃下來(lái)應(yīng)該不會(huì)有太大的問(wèn)題，有過(guò)幾次成功的體驗(yàn)后，這種恐懼感就會(huì)減少很多。優(yōu)質(zhì)的文章、視頻、書籍，多是英文的，不邁過(guò)這個(gè) 坎，將來(lái)要么成為瓶頸，要么花更大的成本去填補(bǔ)。
入門
書籍
要學(xué)習(xí) iOS 開(kāi)發(fā)，自然要先學(xué) Objective-C （當(dāng)然現(xiàn)在也可以直接上 Swift，不過(guò)如果多人協(xié)作的話，OC目前還是主流），因?yàn)?OC 是 C 語(yǔ)言的超集，所以了解 C 語(yǔ)言對(duì)于學(xué)習(xí) OC 肯定會(huì)有幫助，不過(guò)就算不了解，直接學(xué) OC 也沒(méi)太大問(wèn)題。
這里推薦 BNR (Big Nerd Ranch) 的這本 Objective-C Programming The Big Nerd Ranch Guide，講解地比較細(xì)致，能幫助你更好的理解 OC，更重要的是教你遇到問(wèn)題時(shí)，如何去解決問(wèn)題，以及這個(gè)問(wèn)題對(duì)應(yīng)的一些知識(shí)點(diǎn)，如何使用文檔等等。
來(lái)到一個(gè)新的世界，肯定會(huì)對(duì)這個(gè)世界充滿好奇，想訂閱一大堆博客，買一堆書，看各種教程和視頻，然后就變得浮躁，不知該從哪下手，這會(huì)導(dǎo)致拖延癥。 我渴了，給我倒一杯水，這個(gè)很直接，馬上就可以做，但如果是給我買一瓶飲料，而自己對(duì)那些飲料又不怎么熟悉時(shí)，就糾結(jié)了，不如刷會(huì)微博，看看朋友圈，玩?zhèn)€小游戲先。
所以一本好的入門教材很重要，要契合自己當(dāng)前的水平，且常常會(huì)有收獲，這種成就感會(huì)激勵(lì)著你繼續(xù)學(xué)下去。
在看書的過(guò)程中，往往會(huì)有這樣的經(jīng)歷：書中提到某個(gè)人、觀點(diǎn)、知識(shí)點(diǎn)、書、文章，然后就順著它提到的這些東西出去了，可能某個(gè)知識(shí)點(diǎn)又牽扯到另一些內(nèi)容，然后就這樣越走越遠(yuǎn)。想起了一個(gè)故事——
三只獵狗追一只土拔鼠,土拔鼠逃跑時(shí)鉆進(jìn)了一個(gè)樹(shù)洞。這個(gè)樹(shù)洞只有一個(gè)出口,不一會(huì)兒,忽然從樹(shù)洞里跑出一只兔子。兔子飛快地向前跑,并爬上另一棵大樹(shù)。兔子因?yàn)榛艁y在樹(shù)上沒(méi)站穩(wěn),掉了下來(lái),砸暈了正仰頭看的三只獵狗,最后,兔子終于逃脫。
對(duì)于這個(gè)故事可以從不同的角度去解讀，我更愿意以初心去解讀。兔子為什么會(huì)爬樹(shù)？為什么能砸暈三只獵狗？這不是重點(diǎn)，重點(diǎn)是，之前追趕的土撥鼠哪去了？看書時(shí)難免會(huì)有延伸閱讀，這個(gè)深度我覺(jué)得不宜超過(guò) 2 層，不然很容易就回不來(lái)了。
還有就是如果有可能，最好每天都看點(diǎn)，這其實(shí)是很難的，因?yàn)榭偸菚?huì)有優(yōu)先級(jí)更高的事，或者之前的某些習(xí)慣在干擾。一旦斷了幾天，就不想再拿起來(lái)了。
還有，蘋果官方的 Start Developing iOS Apps Today 也是很不錯(cuò)的入門材料。
視頻
推薦斯坦福老頭子(Paul Hegarty)的 Developing iOS 7 Apps for iPhone and iPad ，當(dāng)初也是看的這個(gè)（那時(shí)還是更老的版本），Paul 是資深的 Mac/iOS 開(kāi)發(fā)（前蘋果員工？），很多知識(shí)點(diǎn)講得很到位，學(xué)生們的提問(wèn)也大都在點(diǎn)上，同時(shí)配有Demo，總之聽(tīng)下來(lái)會(huì)對(duì) iOS 開(kāi)發(fā)有比較全面的了解。
同時(shí)推薦一本小冊(cè)子：objc-zen-book，花不長(zhǎng)時(shí)間就能看完，里面是一些 Best Practices，對(duì)于編寫優(yōu)質(zhì)代碼會(huì)很有幫助。
筆記
這是一個(gè)持久的過(guò)程，任何階段都適用。以前也沒(méi)太在意這個(gè)，覺(jué)得概念性的東西，腦子過(guò)一遍，就大概知道了，然后就去啃其他的東西了，現(xiàn)在看來(lái)，如果有記筆記的話，會(huì)更有助于消化概念、知識(shí)點(diǎn)，也可以記錄自己的思考過(guò)程。達(dá)芬奇就記錄了10000多頁(yè)的筆記。
記筆記可以加深對(duì)知識(shí)點(diǎn)的理解，而成為編程巨星的唯一秘訣就是：對(duì)所做的事情理解地越深，就會(huì)做得越好。同時(shí)如果遵循遺忘曲線去復(fù)習(xí)的話，效果更佳。對(duì)知識(shí)點(diǎn)了解地足夠透徹后，Debug 時(shí)才更有可能知道問(wèn)題出在哪，解決問(wèn)題也更容易有思路。
筆記不僅可以記知識(shí)點(diǎn)，也可以記錄調(diào)試過(guò)程，比如這篇筆記，有一種調(diào)試方法：小黃鴨調(diào)試法
許多程序員都有過(guò)向別人（甚至可能向完全不會(huì)編程的人）提問(wèn)及解釋編程問(wèn)題，就在解釋的過(guò)程中擊中了問(wèn)題的解決方案。一邊闡述代碼的意圖一邊觀察它實(shí)際上的意圖并做調(diào)試，這兩者之間的任何不協(xié)調(diào)會(huì)變得很明顯，并且更容易發(fā)現(xiàn)自己的錯(cuò)誤。
生活中我們可能不會(huì)真的這么去做，這時(shí)抽離出另一個(gè)自己，記錄下跟ta的對(duì)話，也是個(gè)發(fā)現(xiàn)問(wèn)題的好方法。
練習(xí)
這也是一個(gè)持續(xù)的過(guò)程，知道了些概念或原理后，總是會(huì)想著去驗(yàn)證下是不是這樣，無(wú)論結(jié)果是否如自己預(yù)期，實(shí)踐的過(guò)程會(huì)降低對(duì)語(yǔ)言的陌生感，慢慢地培養(yǎng)一種駕馭這門語(yǔ)言的自信，如果出了錯(cuò)，正好可以重新梳理一下。
目標(biāo)
如果靜下心來(lái)看完了 BNR 的這本書，以及斯坦福的 iOS 開(kāi)發(fā)視頻，那么對(duì) OC 應(yīng)該比較了解了，一些常用的 UIKit 用起來(lái)也沒(méi)什么問(wèn)題了，比如 UIViewController / UIView / UIScrollView / UIImageView / UITableView。也熟悉一些概念，如 KVO / MVC / Delegate / DataSource。
這個(gè)階段下來(lái)，應(yīng)該會(huì)有：哦，iOS 開(kāi)發(fā)也就這樣嘛，多翻翻文檔，熟悉 Cocoa Touch 的一些 Class，差不多也能做出一個(gè)簡(jiǎn)單的 App 了。
進(jìn)階
入門之后，接下來(lái)可以折騰的東西還會(huì)有不少。
書籍
Effective Objective-C 2.0，里面提到了 52 種提高 iOS App 質(zhì)量的途徑。涉及了 API 設(shè)計(jì)、protocols / category 的使用、寫出更模塊化的代碼等，讀下來(lái)應(yīng)該會(huì)有不少收獲。
iOS Programming: The Big Nerd Ranch Guide (4th Edition)，又是一本 BNR 的書，這本書的特點(diǎn)是通過(guò) Demo 來(lái)引出知識(shí)點(diǎn)，然后提一些問(wèn)題，并且會(huì)細(xì)說(shuō)解題思路?？磿倪^(guò)程中，對(duì)于元學(xué)習(xí)能力的提升也會(huì)有一定幫助。
--- update ---
發(fā)現(xiàn)巧哥的 iOS開(kāi)發(fā)進(jìn)階 已經(jīng)可以在京東買到了，雖然沒(méi)有細(xì)看，但巧哥出品質(zhì)量肯定有保障。
其他資源
進(jìn)入這個(gè)階段后，可以去探索更大的世界了，現(xiàn)在的資源已經(jīng)很豐富了，但還是要遵循「少而精」的原則。以下是我覺(jué)得挺不錯(cuò)的資源
iOS Dev Weekly 每周一期，內(nèi)容多為這一星期里值得關(guān)注的Github項(xiàng)目、文章、工具等。
iOS 移動(dòng)開(kāi)發(fā)周報(bào) 這是唐巧大大整理的每周不錯(cuò)的 iOS 開(kāi)發(fā)相關(guān)的內(nèi)容，多為中文。
RayWenderlich 很多詳細(xì)又全面的教程，不容錯(cuò)過(guò)。
iOS Dev Slack 國(guó)內(nèi)不少 iOS 開(kāi)發(fā)（包括大大們）都在這里，不過(guò)現(xiàn)在好像不怎么能拿到邀請(qǐng)了。
中文 iOS/Mac 開(kāi)發(fā)博客列表，打開(kāi)工具訂閱吧。
還有，如果可能的話，多去分享自己學(xué)到的東西，教是最好的學(xué)，我試過(guò)幾次，效果真的很不錯(cuò)。
目標(biāo)
這個(gè)階段下來(lái)，對(duì)于常用的設(shè)計(jì)模式、內(nèi)存管理、Blocks 的使用、圖像操作、網(wǎng)絡(luò)請(qǐng)求和管理、多線程應(yīng)該比較熟悉了。對(duì)于 CALayer、Animation、UIScrollView、UITableView、UICollectionView、 ViewController Container 則非常熟悉，對(duì)「非常熟悉」的定義是：不打開(kāi) Xcode，腦子里就能把相應(yīng)的知識(shí)點(diǎn)復(fù)述出來(lái) 80% ，比如這個(gè)類有哪些方法，Delegate / DataSource 有哪些方法，怎么使用，如果要實(shí)現(xiàn)某個(gè)效果，應(yīng)該怎么做（好吧， UICollectionView 除外）。
高級(jí)
其實(shí)高級(jí)、進(jìn)階、入門并沒(méi)有嚴(yán)格的界限，在入門階段也可以探究高級(jí)階段的一些東西。我覺(jué)得支撐我們不斷探索和前進(jìn)的動(dòng)力不是興趣，而是永不滿足的好奇心，和對(duì)優(yōu)雅代碼的追求。
If your standards are low, you're going to stop pretty early on in the process.
BNR 的這篇 Leveling Up 已經(jīng)講得很好了，也更加細(xì)致。
書籍
iOS 7 Programming Pushing the Limits 這本書對(duì) iOS 7 的一些特性會(huì)講解地比較深入，當(dāng)然也不僅僅是 iOS 7。只嘆 iOS 更新實(shí)在太快，書籍往往跟不上，一本好書往往需要很長(zhǎng)時(shí)間來(lái)撰寫，等書可以出版了，iOS 又出新版本了。
源碼
看優(yōu)秀的源碼，可以學(xué)到很多東西，使用過(guò)程中遇到問(wèn)題也更容易解決。這些是我覺(jué)得值得細(xì)看的源碼：AFNetworking(NSOperation, HTTP, Block), SDWebImage(Image Handle, Cache, NSOperation, Block),SVPullToRefresh(UIScrollView, State Handle), JSONModel(runtime)
如果有興趣，也可以翻翻 CoreFoundation / OC runtime 的源碼。
資源
oleb
NSHipster
objc.io || objcio.cn
WWDC 視頻
工具
chisel Facebook 出品的 LLDB 助手，用于調(diào)試很方便
Reveal 每當(dāng)好奇某個(gè) App 的實(shí)現(xiàn)時(shí)，都會(huì)打開(kāi)它一窺究竟，用于調(diào)試自己的 App 也很方便
Aspects steipete 大大出品的一款方便使用 method swizzling 的工具，可以在運(yùn)行時(shí)動(dòng)態(tài)添加代碼到某個(gè)方法
class-dump 從 Mach-O 文件生成 OC 頭文件，有時(shí)想看看某個(gè) App 大概是如何組織的會(huì)比較方便
Hopper 可以對(duì)二進(jìn)制文件進(jìn)行反編譯，甚至可以生成偽代碼！有時(shí)想看看 UIViewController 里某個(gè)方法大概是怎么實(shí)現(xiàn)的，就可以用它。
Instruments 這個(gè)內(nèi)置的工具對(duì)于發(fā)現(xiàn) App 的各種問(wèn)題很有幫助，如內(nèi)存占用、泄露，渲染問(wèn)題等。
目標(biāo)
這個(gè)階段，對(duì)于底層的實(shí)現(xiàn)會(huì)有更深入的了解，各種 Core 開(kāi)頭的 Framework 至少可以說(shuō)出個(gè)大概，工具也能熟練使用，「正經(jīng)的代碼」寫過(guò)數(shù)萬(wàn)行，可能天天在翻 Dash。如果別人讓你實(shí)現(xiàn)某個(gè)功能，能在較短的時(shí)間內(nèi)給出不錯(cuò)的實(shí)現(xiàn)方案，并且足夠細(xì)致，甚至精細(xì)到如何使用 Core Graphic 去畫某個(gè)圖像。
其他
我覺(jué)得無(wú)論學(xué)習(xí)什么，「速成」的心態(tài)是最要不得的，這只會(huì)讓自己變得浮躁，一知半解，整個(gè)過(guò)程也很難讓自己的元學(xué)習(xí)能力得到提升。慢慢來(lái)，攻占一個(gè)城后，再去打下一個(gè)，這時(shí)心態(tài)也會(huì)平和許多。
重慶分公司
重慶分公司
