天天看點

結對項目總結----已部署上線

學生自主考試系統(Auto-Generate TextPaper System)

前端開發:肖宇

後端開發:陳文康

一. 通路項目

此次制作的項目是一個Web項目,并且成功在華為雲伺服器部署上線,您可以在浏覽器位址欄輸入以下位址來通路和使用該項目:

114.116.234.151:8099

初次登入該系統需要使用手機号進行注冊賬戶

二. 項目說明

該Web項目是基于前端網頁+後端+伺服器完成的,前後端技術如下:

前端:原生三件套+jquery

html

css

js

jquery

後端:SSM架構

Java8

Spring

SpringMVC

Mybatis

Maven

伺服器:

華為彈性雲伺服器

資料庫:

MySQL8.0

應用伺服器:

tomcat9

三. 項目結構

結對項目總結----已部署上線

四. 項目預覽

結對項目總結----已部署上線
結對項目總結----已部署上線
結對項目總結----已部署上線
結對項目總結----已部署上線

五. 代碼複用

在我和結對隊友一起制作該項目時,我們明顯地感覺到此次制作時間十分緊張,即使是複用了個人項目代碼

由此看來,代碼複用是十分重要且必要的工作。下面我就分享一下如何進行代碼複用:

1. 清晰的代碼結構

在編寫個人項目時,時間比較充裕。于是在個人項目完成之後,花費了大量的時間在整理代碼結構上。例如下圖:

結對項目總結----已部署上線

上圖中,generator包中包含了三個Generator類,用于生成各種Product。而其中包含了一個AbstractGenerator,即抽象生成器,所有的Generator實作類都需要繼承該類并實作抽象方法。

其結構樹如下:

結對項目總結----已部署上線

AbstractGenerator有兩個子類,分别用于生成需要生成試卷的路徑和相應檔案(FileGenerator)、生成試題(TestPaperGenerator)

這樣做有什麼好處呢?

在結對項目中,需要生成試題的答案,那麼就可以通過AnswerGenerator繼承AbstractGenerator,實作AbstractGenerator的代碼複用

2. 子產品化的方法

在TestPaperGenerator類中,我并沒有将所有的代碼邏輯直接寫在一個方法中,而是盡可能地将代碼功能進行分割,直到原子方法再進行實作:

在上圖中,最終的生成方法是generate。而generate方法會根據目前試卷的難度,調用generatePrimaryTest、generateJuniorTest、generateSeniorTest;

這三個方法本質地不同就在于運算符的不同,是以可以都調用generateTest方法而傳入不同的參數,實作不同的試題生成:

這樣做的好處就是我可以很輕松地在結對項目中修改和複用代碼:

在結對項目中的需求發生改變,需要生成答案,是以相應的方法也改變,可以觀察到所有的傳回值都是ArrayList。

雖然讀者看起來所有的代碼都進行了更改,但其實不然:因為所有的方法根源都來自于generateTest方法,其實我隻是修改了一下generateTest方法,而其餘的方法并沒有作大的改動,隻是修改了一下傳回值類型罷了

由此看來,這種子產品化的方法利于代碼地複用

六. 結對程式設計交流

在結對程式設計,特别是像Web這種前後端互動的項目中,隊友之間的溝通是十分重要的。

1. 錯誤的經曆

在一開始結對的過程中,我和隊友是分開寫前後端的,隻是大緻交代了下兩個人的工作,需要做哪些頁面、需要背景提供哪些接口通路等等。

這樣一直持續了2~3天,最後在兩個人再次交流、合并代碼、測試代碼的時候就發現,雖然我提供的接口功能是完備的,但是頁面上的請求通路完全對不上(例如一些請求參數、請求名等等);

于是花費了很長的時間去統一接口、統一請求參數和請求名。當一切完成時,項目可以正常啟動,并且不出意外地出現了bug,于是開啟了漫長的改bug之路……

這時候我才意識到,我們花費了2~3天編寫的代碼量太大了,沒有測試的地方太多了,是以導緻出現bug時,完全不知道bug出現在哪。是以後面花費了一整天來找和改bug。

2. 走上正軌

a. 接口文檔

後面我們吸取了教訓,對于接口和前端的互動,我會在編寫接口之前,将想法寫成一份接口文檔交給前端。其中包括了每個請求的請求名、請求參數、傳回參數,如下:

請求名:/login

請求參數:name:使用者名、password:密碼、phoneNumber:手機号

傳回參數:當資料庫中存在該使用者時傳回"true";否則傳回"false"

b. 一次送出一小部分代碼

我們不會再像一開始那樣,一次性編寫大量的代碼,然後集中起來進行測試。

而是每次隻寫1~2個功能,然後立即測試,這樣可以使得bug無處遁形——如果出現bug,那麼肯定在這兩個功能的代碼中

至此我們後面的程序十分迅速和緊湊,基本的邏輯和顯示很快就完成了,最後花費一定的時間美化頁面、優化代碼、編寫注釋、購買伺服器和部署項目等等。

七. 總結

總的來說這是一次十分不錯的合作程式設計經曆,我和隊友都受益匪淺。不隻是代碼能力的提升,更多地是學會如何與人交流、如何提高項目進行地速度、如何多線程地完成一個項目,

以及如何盡可能地避免bug(将bug地産生控制在一個小範圍的代碼内)。

最後項目也是成功上線了,十分開森

繼續閱讀