有時(shí)候一些奇怪的想法會(huì)突然出現(xiàn)在腦海中，那一瞬間仿佛有所領(lǐng)悟

概況

本篇中所分析的所有內(nèi)容都是以中小型項(xiàng)目為前提的，iOS，Android，Server這3端開(kāi)發(fā)人數(shù)不超過(guò)20人。由于我本身是做iOS的，因此，會(huì)從一個(gè)iOS開(kāi)發(fā)者的角度來(lái)剖析問(wèn)題。不一定百分百正確。

設(shè)計(jì)

產(chǎn)品經(jīng)理已經(jīng)設(shè)計(jì)了app的大部分功能，一些交互上的細(xì)節(jié)肯定不可能完全設(shè)計(jì)出來(lái)。往往這些被忽略的交互設(shè)計(jì)會(huì)在程序員編碼過(guò)程中，造成很大一部分時(shí)間的浪費(fèi)。

因此，需要有一個(gè)方案上的設(shè)計(jì)，這個(gè)設(shè)計(jì)的主要目的就是處理項(xiàng)目中產(chǎn)品方面的臨時(shí)變更。

在真實(shí)開(kāi)發(fā)中，最經(jīng)常出現(xiàn)的一個(gè)場(chǎng)景就是遇到這訪問(wèn)的問(wèn)題去問(wèn)產(chǎn)品，產(chǎn)品當(dāng)時(shí)記住了，可能過(guò)段時(shí)間就忘了。這些產(chǎn)品方面的問(wèn)題最少喲通知到跟該項(xiàng)目開(kāi)發(fā)相關(guān)的所有人，如果到了測(cè)試階段，還需要修改交互設(shè)計(jì)，那么上述的設(shè)計(jì)就是有問(wèn)題的。

產(chǎn)品設(shè)計(jì)是開(kāi)發(fā)前期最重要的一個(gè)環(huán)節(jié)，假定我們已經(jīng)有了一個(gè)良好的設(shè)計(jì)，那么接下來(lái)，需要讓項(xiàng)目開(kāi)發(fā)的相關(guān)人員對(duì)必須對(duì)產(chǎn)品有一個(gè)清楚的了解。

還是那句話，在這個(gè)階段，讓開(kāi)發(fā)人員把問(wèn)題精確到每一個(gè)if上，肯定不現(xiàn)實(shí)，但通過(guò)大家的頭腦風(fēng)暴后，大部分隱藏的問(wèn)題和沖突都能被發(fā)現(xiàn)。

對(duì)于app界面的設(shè)計(jì)人員，需要制定一套統(tǒng)一的設(shè)計(jì)方案，方案中應(yīng)該包含整體設(shè)計(jì)的風(fēng)格，統(tǒng)計(jì)出有多少需要設(shè)計(jì)的界面。后續(xù)的分工會(huì)在任務(wù)分解中給出解釋。

后臺(tái)開(kāi)發(fā)應(yīng)該和移動(dòng)端開(kāi)發(fā)共同制定一份數(shù)據(jù)交互規(guī)則。

說(shuō)點(diǎn)題外話，我一直覺(jué)得不管是寫(xiě)后臺(tái)還是移動(dòng)端，整體框架的良好設(shè)計(jì)能夠給程序帶來(lái)巨大好處。每個(gè)人寫(xiě)代碼的風(fēng)格千差萬(wàn)別，有的時(shí)候同一份數(shù)據(jù)需要?jiǎng)?chuàng)建好幾個(gè)模型，這幾個(gè)模型大部分的屬性都是相同的，想想，這對(duì)于開(kāi)發(fā)和代碼優(yōu)化會(huì)帶來(lái)多大的阻力。

我個(gè)人認(rèn)為，如果后臺(tái)開(kāi)發(fā)，以模型為單位組織數(shù)據(jù)，會(huì)給移動(dòng)端開(kāi)發(fā)帶來(lái)極大的便利性。最好有一個(gè)人能夠?qū)ｉT(mén)維護(hù)一個(gè)屬性池，大家所有的屬性都在這個(gè)池子里獲取，從而就能夠避免各種沖突了。

簡(jiǎn)單說(shuō)說(shuō)iOS端的設(shè)計(jì)，基本的文件目錄結(jié)構(gòu)的設(shè)計(jì)，咱們就不提了，這都是最最基本的要求。網(wǎng)絡(luò)層的設(shè)計(jì)也不提，每個(gè)公司都會(huì)有這方面的封裝庫(kù)。我們首先來(lái)探討下模型的設(shè)計(jì)：

最單純的模型就是用來(lái)存儲(chǔ)數(shù)據(jù)和提供數(shù)據(jù)的。如果控制器中的邏輯很復(fù)雜，最好寫(xiě)一個(gè)處理控制器與數(shù)據(jù)模型邏輯的管理類(lèi)，數(shù)據(jù)的處理全都封裝在這個(gè)管理類(lèi)之中，控制器拿到處理好的處理，去輕松的完成他的任務(wù)。上邊的管理類(lèi)是一個(gè)核心思想，相信有經(jīng)驗(yàn)的開(kāi)發(fā)者應(yīng)該明白。

對(duì)于存儲(chǔ)的設(shè)計(jì)應(yīng)該有一個(gè)統(tǒng)一的類(lèi)去管理，數(shù)據(jù)的持久化不應(yīng)該隨隨便便的散落在代碼中的各個(gè)角落。這個(gè)管理類(lèi)負(fù)責(zé)了數(shù)據(jù)存儲(chǔ)的讀取和寫(xiě)入，以及穩(wěn)定性的考驗(yàn)。

除了網(wǎng)絡(luò)，模型，存儲(chǔ)，就剩下控件的設(shè)計(jì)了，控件的設(shè)計(jì)就一句話，把你寫(xiě)的每一個(gè)控件都當(dāng)做一個(gè)小的組件來(lái)寫(xiě)。每一個(gè)控件都不應(yīng)該是僅僅基于當(dāng)前的一個(gè)小的需求考慮的，最起碼從其他開(kāi)發(fā)人員也會(huì)使用這個(gè)角度去考慮問(wèn)題。

在真實(shí)開(kāi)發(fā)中，我發(fā)現(xiàn)一個(gè)小小的問(wèn)題，即使組件的接口寫(xiě)的很簡(jiǎn)單，別人也不一定會(huì)用，因此，這些組件應(yīng)該需要一份文檔來(lái)描述它的使用方法，一個(gè)很好的例子就是github。

上邊描述的種種都是基于理論方面的內(nèi)容，需要在開(kāi)發(fā)中慢慢體會(huì)。

任務(wù)分解

任務(wù)分解同樣是一份很有技術(shù)含量的活，對(duì)于一個(gè)大型的建筑項(xiàng)目，中小app的開(kāi)發(fā)真的不算什么。

根據(jù)每個(gè)人的個(gè)人能力，把不同的模塊，不同的功能指定給合適的開(kāi)發(fā)人員。

最難的事情

我個(gè)人認(rèn)為能夠處理好上述的問(wèn)題的人選一定是架構(gòu)師，一個(gè)良好的設(shè)計(jì)，一個(gè)高度可維護(hù)的設(shè)計(jì)都應(yīng)該是架構(gòu)師必備的技能包。

但我認(rèn)為，在開(kāi)發(fā)中讓所有的人的技術(shù)提高是一件很難的事情，正是由于技術(shù)水平的不一樣，才產(chǎn)生了開(kāi)發(fā)中的各種障礙，這里就不多說(shuō)了。

總結(jié)

通過(guò)這個(gè)項(xiàng)目，我個(gè)人得到的領(lǐng)悟就是設(shè)計(jì)非常重要。