今天這篇博文主要講的是項(xiàng)目的一般開發(fā)流程。科學(xué)的開發(fā)流程可以提高效率，減少不必要的加班，由此可見開發(fā)流程在項(xiàng)目開發(fā)中的重要地位。項(xiàng)目開發(fā)流程一般包括以下幾步：
一、需求評(píng)估

產(chǎn)品經(jīng)理、研發(fā)工程師、測(cè)試工程師，要組織需求評(píng)審會(huì)議，講解本次的開發(fā)功能和具體業(yè)務(wù)。

如下2步，需要畫圖、筆記、文字記錄、演算、推理、畫流程圖、畫架構(gòu)圖

1、產(chǎn)品選型

明確產(chǎn)品界面、交互設(shè)計(jì)、功能設(shè)計(jì)、模塊區(qū)分，尋找相仿的產(chǎn)品上手體驗(yàn)、操作，感知功能的使用和交互的體驗(yàn)，目的是為了了解即將要做的產(chǎn)品有大致的模型,對(duì)產(chǎn)品模型了解的越細(xì)致越好

2、分離架構(gòu)

對(duì)產(chǎn)品從各個(gè)維度分離架構(gòu)，從功能，目錄，邏輯拆分，抽象，業(yè)務(wù)流的明確，數(shù)據(jù)流的流向，交互體驗(yàn)的設(shè)計(jì)，從整體拆分成局部，針對(duì)每個(gè)局部再繼續(xù)拆分，從局部整合成系統(tǒng)，考慮整體和局部之間的相互影響關(guān)系

循環(huán)這2步，最終得到一個(gè)產(chǎn)品系統(tǒng)，應(yīng)該對(duì)產(chǎn)品系統(tǒng)非常了解，從整體到局部，從需求到邏輯，端到端的數(shù)據(jù)流向，交互體驗(yàn)設(shè)計(jì)，數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計(jì)

根據(jù)以上，給出開發(fā)工期（X/人/天）。

二、文檔編寫

按照系統(tǒng)的各個(gè)區(qū)域和子系統(tǒng)，編寫對(duì)應(yīng)的文檔注釋，說明此子系統(tǒng)的功能、大致邏輯、含有的接口。

此外，流程應(yīng)該按照先數(shù)據(jù)庫層面 –> 邏輯控制層面 –> 數(shù)據(jù)展示層面 –> 交互體驗(yàn)層面 –> 界面設(shè)計(jì)層面的順序來規(guī)劃和思考。

同時(shí)考慮擴(kuò)展性的問題，子系統(tǒng)是否可插拔，組件之間是否強(qiáng)依賴，必要的時(shí)候完成架構(gòu)層面大的抽象。

文檔需要大概明確此子系統(tǒng)模塊的測(cè)試結(jié)果是什么，提前演算模塊的測(cè)試步驟和結(jié)果，后續(xù)細(xì)化的代碼必須要通過此測(cè)試要求。

三、創(chuàng)建/更改 數(shù)據(jù)庫

根據(jù)公司要求規(guī)范操作數(shù)據(jù)表，確定后郵件抄送相關(guān)開發(fā)。

相關(guān)SQL語句，需要Leader、DBA 審核，方可部署。

四、規(guī)定開發(fā)規(guī)范

規(guī)定代碼規(guī)范，必須要寫注釋

五、前后端分離開發(fā)

目前項(xiàng)目大部分都是使用 前后端分離的方式開發(fā)，一般由后端先給出接口文檔供前端進(jìn)行開發(fā)。

??? 后端 程序邏輯代碼開發(fā)需要考慮：

復(fù)雜的邏輯可以自己先畫流程圖（ProcessOn）。遵循 PHP 代碼規(guī)范（PSR）。代碼注釋（再次提醒這點(diǎn)非常重要）。數(shù)據(jù)驗(yàn)證（對(duì)前端提交的數(shù)據(jù)進(jìn)行二次驗(yàn)證，不能相信任何前端數(shù)據(jù)）。功能邏輯（考慮類庫封裝，代碼復(fù)用）。性能問題（是否需要用到緩存redis等）。安全問題（XSS、Sql注入）。日志問題（記錄相關(guān)日志）。錯(cuò)誤報(bào)警（可供參考）。

??? 前端需要考慮：

????

代碼整潔性（標(biāo)簽元素對(duì)齊，DIV區(qū)塊注釋）。 界面適配（BootStrap 柵格系統(tǒng)）。 Js 相關(guān)驗(yàn)證（不要寫在界面中）。 產(chǎn)品驗(yàn)收（確認(rèn)界面元素是否滿足使用習(xí)慣）。

擼編碼

??? 編碼必須符合偽代碼的邏輯，編碼應(yīng)該多次測(cè)試，慢步前進(jìn)。
??? 注意編碼的版本控制。
??? 編碼應(yīng)該盡量保持優(yōu)美的邏輯和語法使用。
??? 編碼的變量命名應(yīng)該特別注意。
??? 每一次的編碼應(yīng)該最低按照一個(gè)函數(shù)單元，即最小編碼單位是一個(gè)函數(shù)，一旦決定編碼，就至少完成一個(gè)
??? 函數(shù)單元，或者取消本次函數(shù)的編寫。
??? 每個(gè)函數(shù)的完成，都必須要達(dá)到偽代碼對(duì)此函數(shù)的定義和解釋，注意高內(nèi)聚和低耦合的問題。
??? 如果沒有高內(nèi)聚，要適當(dāng)拆分邏輯和代碼。
??? 如果沒有低耦合，要適當(dāng)抽象代碼，合并其他同類函數(shù)。

六、功能自測(cè)

程序開發(fā)完畢后，需要自己先進(jìn)行測(cè)試，走一遍全部流程。

需要考慮：

創(chuàng)建一些測(cè)試數(shù)據(jù)。考慮功能的臨界值。確保功能的可用性。

七、代碼評(píng)審（Code Review）

代碼評(píng)審被公認(rèn)為是一個(gè)很好的提高代碼質(zhì)量的手段。

好處：

加速個(gè)人的成長，讓自己成為一個(gè)更優(yōu)秀的程序員。
可以分享/學(xué)習(xí)到更多的知識(shí)。
保證代碼清晰，容易被別人理解。
提前發(fā)現(xiàn)一些缺陷（代碼檢查者通常比代碼編寫者更挑剔）。
我們可以使用一些開源系統(tǒng)：
Phabricator
ReviewNinja
Codacy
RhodeCode
如果有好的工具幫助我們進(jìn)行codereview，往往會(huì)達(dá)到事半功倍的效果。

八、WIKI 更新

將自己開發(fā)的功能模塊，部署到WIKI上。

寫好需求方、開發(fā)者、使用者、是否用到API、相關(guān)邏輯、流程圖…

九、功能提測(cè)

通知測(cè)試人員，該需求可以提測(cè)啦~

根據(jù)公司要求，可以進(jìn)行郵件提測(cè)，也可以JIRA管理。

以上，只是大概的講述了開發(fā)流程。

其實(shí)每一個(gè)步驟，都可以進(jìn)行詳細(xì)分析，比如代碼注釋，評(píng)審規(guī)范等等。
?

總結(jié)

以上是生活随笔為你收集整理的项目一般开发流程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。