隨著手機(jī)APP的普及，越來(lái)越多的企業(yè)希望做屬于自己的APP項(xiàng)目，用APP來(lái)創(chuàng)新與客戶的交流。企業(yè)希望客戶能及時(shí)了解到公司產(chǎn)品的信息，也希望能與客戶建立密切的關(guān)系，而APP可以很好的滿足這兩個(gè)特點(diǎn)。今天和大家分享一下APP項(xiàng)目開(kāi)發(fā)中遇到的問(wèn)題及解決思路，希望對(duì)大家有所幫助。北京木奇移動(dòng)技術(shù)有限公司，專業(yè)的軟件外包開(kāi)發(fā)公司，歡迎交流合作。

接著上一篇文章講，上一篇講了軟件需求怎么做以及要注意的問(wèn)題，今天繼續(xù)講一下軟件在開(kāi)發(fā)的過(guò)程當(dāng)中需要注意的問(wèn)題。

1.需求的變動(dòng)，在開(kāi)發(fā)過(guò)程中程序員最痛恨的應(yīng)該是需求的頻繁變動(dòng)，前幾天剛完成的功能現(xiàn)在又要做大的改動(dòng)，導(dǎo)致前幾天的工作白做了。如果是偶爾一次的變動(dòng)還可以接受，如果變動(dòng)比較多，不但會(huì)延誤開(kāi)發(fā)計(jì)劃，而且從情緒上會(huì)引起程序員的不滿。單從這點(diǎn)也可以得出需求分析是多么的重要，如果需求分析做不好，后續(xù)會(huì)引發(fā)一系列的問(wèn)題。

2.開(kāi)發(fā)計(jì)劃的制定和執(zhí)行，在需求確定好以后需要開(kāi)發(fā)人員制定開(kāi)發(fā)計(jì)劃并行，開(kāi)發(fā)計(jì)劃一般由項(xiàng)目經(jīng)理和開(kāi)發(fā)人員共同討論后確定。在2-3月的項(xiàng)目開(kāi)發(fā)計(jì)劃里，需要詳細(xì)列出每個(gè)功能點(diǎn)的開(kāi)發(fā)時(shí)間，最小人天為2-3天，如果功能點(diǎn)的開(kāi)發(fā)時(shí)間超出2-3天，那需要拆解功能點(diǎn)，再去分配每個(gè)子功能的開(kāi)發(fā)時(shí)間。這樣做的好處是可以比較準(zhǔn)確的跟蹤項(xiàng)目進(jìn)度，如果某個(gè)功能點(diǎn)的開(kāi)發(fā)時(shí)間偏離了計(jì)劃時(shí)間，可以具體分析一下原因是什么，需要及時(shí)解決問(wèn)題，而不是等到若干天后才發(fā)現(xiàn)問(wèn)題，這肯定會(huì)耽誤整體項(xiàng)目時(shí)間。

3.開(kāi)發(fā)人員之間的配合，現(xiàn)在的軟件系統(tǒng)分為前端和后端，相互之間配合比較多，后端需要出接口，前端需要調(diào)用后端接口數(shù)據(jù)填充界面，實(shí)現(xiàn)具體功能。因此這是一個(gè)聯(lián)系非常緊密的工作，在開(kāi)發(fā)計(jì)劃的制定中需要考慮這個(gè)關(guān)系，在后端開(kāi)發(fā)接口的時(shí)候前端可以預(yù)先做界面開(kāi)發(fā)的工作，等接口好了再對(duì)接數(shù)據(jù)。在這個(gè)過(guò)程當(dāng)中，如果后端接口開(kāi)發(fā)任務(wù)延誤了時(shí)間，前端相應(yīng)也會(huì)受到影響，因此要求后端接口開(kāi)發(fā)人員可能有延時(shí)情況需要提前說(shuō)明。

二者之間的配合是通過(guò)接口文檔來(lái)進(jìn)行，文檔一定要與實(shí)際代碼同步，不能出現(xiàn)文檔是舊的，而代碼是新的情況，這非常重要，需要強(qiáng)調(diào)開(kāi)發(fā)人員進(jìn)行實(shí)時(shí)更新。現(xiàn)在有很多的工具可以根據(jù)接口代碼的注釋生成相應(yīng)接口文檔，有經(jīng)驗(yàn)的開(kāi)發(fā)人員會(huì)利用這個(gè)特性來(lái)減輕工作量，同時(shí)也可以規(guī)范代碼和注釋的編寫(xiě)。

4.測(cè)試人員的介入，測(cè)試人員在軟件項(xiàng)目中與開(kāi)發(fā)人員一樣重要，一個(gè)軟件系統(tǒng)中不重視測(cè)試人員帶來(lái)的后果可能是軟件系統(tǒng)的問(wèn)題非常多，質(zhì)量低下，用戶反饋很差。開(kāi)發(fā)人員在開(kāi)發(fā)過(guò)程中的測(cè)試是遠(yuǎn)遠(yuǎn)不夠的，尤其涉及到多流程的業(yè)務(wù)或管理系統(tǒng)，開(kāi)發(fā)人員考慮的情形往往比較簡(jiǎn)單，而且自己測(cè)試自己的代碼找出的問(wèn)題也不全面，這些問(wèn)題都是需要有經(jīng)驗(yàn)的測(cè)試人員去發(fā)現(xiàn)。

那測(cè)試人員在什么時(shí)候介入軟件呢？一般來(lái)講，如果有條件的話讓一個(gè)或多個(gè)測(cè)試人員從頭跟到尾最好，在這個(gè)過(guò)程當(dāng)中考慮成本，也可以在軟件前期的時(shí)候減少測(cè)試人員，但一定要有一個(gè)主要的測(cè)試人員一直留在項(xiàng)目組里，這樣可以確保測(cè)試用例是全面的，質(zhì)量比較高。

5.軟件質(zhì)量和代碼bug的關(guān)系，先不考慮需求分析本身的質(zhì)量，單從代碼質(zhì)量考慮軟件系統(tǒng)質(zhì)量，這也需要管理好開(kāi)發(fā)團(tuán)隊(duì)。項(xiàng)目開(kāi)發(fā)的時(shí)候，規(guī)范代碼書(shū)寫(xiě)、做好架構(gòu)、做好模塊劃分，這些都是確保代碼質(zhì)量的前提。在具體寫(xiě)代碼的過(guò)程中，每周末做一次code review，可以是開(kāi)會(huì)的形式，也可以是專家團(tuán)隊(duì)介入的形式，這樣可以在一定程度上確保代碼質(zhì)量。有獎(jiǎng)有罰，開(kāi)發(fā)人員做的好得到項(xiàng)目獎(jiǎng)金，做的不好需要整改。

6.軟件質(zhì)量和測(cè)試，測(cè)試是軟件上線前的最后一步，先好測(cè)試用例，開(kāi)會(huì)評(píng)審測(cè)試用例，在測(cè)試用例寫(xiě)好后可以發(fā)給開(kāi)發(fā)人員審查，看看測(cè)試用例是否全面，不全面的需要及時(shí)補(bǔ)充。需要說(shuō)明的一點(diǎn)是，大多數(shù)測(cè)試人員偏重單個(gè)功能測(cè)試，業(yè)務(wù)流程測(cè)試不夠重視，需要強(qiáng)調(diào)這點(diǎn)的重要性，在涉及到多個(gè)模塊的流程測(cè)試時(shí)更需要重視。