基于微信的學(xué)生文具選購(gòu)小程序——畢業(yè)設(shè)計(jì)從選題到答辯要解決的那些事每年畢業(yè)設(shè)計(jì)季都會(huì)看到一批類(lèi)似微信小程序 電商的題目其中學(xué)生文具選購(gòu)這個(gè)方向出鏡率相當(dāng)高。別覺(jué)得它不起眼這類(lèi)項(xiàng)目看著簡(jiǎn)單但要把前臺(tái)選購(gòu)、后臺(tái)管理、訂單狀態(tài)流轉(zhuǎn)、數(shù)據(jù)庫(kù)設(shè)計(jì)、論文排版、源碼整理全部串起來(lái)還是有很多細(xì)節(jié)容易翻車(chē)。我這里就把這個(gè)項(xiàng)目從功能拆解到技術(shù)選型、再到答辯準(zhǔn)備一條線講清楚給打算做這類(lèi)題目的同學(xué)一個(gè)相對(duì)完整的參考。這個(gè)題目的本質(zhì)并不只是寫(xiě)個(gè)小程序賣(mài)文具它是在考查一個(gè)計(jì)算機(jī)專業(yè)學(xué)生能不能完成一套完整的電商業(yè)務(wù)閉環(huán)用戶通過(guò)微信小程序?yàn)g覽文具 → 加入購(gòu)物車(chē) → 提交訂單 → 后臺(tái)管理員管理商品/訂單/數(shù)據(jù)統(tǒng)計(jì)。在畢業(yè)設(shè)計(jì)的語(yǔ)境下它還要額外產(chǎn)出源碼、LW文檔設(shè)計(jì)文檔、演示視頻和答辯PPT。下面我從幾個(gè)容易被忽略的維度來(lái)拆解。1. 這個(gè)題目到底在考什么不止是寫(xiě)小程序1.1 一個(gè)合格畢業(yè)設(shè)計(jì)的四項(xiàng)交付物很多人拿到類(lèi)似題目第一反應(yīng)是我會(huì)寫(xiě)小程序前端這事穩(wěn)了結(jié)果做到中期才發(fā)現(xiàn)畢業(yè)設(shè)計(jì)要的東西比想象中多得多。按我見(jiàn)過(guò)的大多數(shù)學(xué)校要求這個(gè)題目至少要交付四樣?xùn)|西完整可運(yùn)行源碼小程序前端代碼WXML、WXSS、JS、JSON以及后端接口代碼如果走云開(kāi)發(fā)模式就是云函數(shù)如果走傳統(tǒng)模式就是Java/Spring Boot或Node.js的接口工程。源碼還要有清晰的目錄結(jié)構(gòu)而不是一個(gè)壓縮包扔在那里沒(méi)有說(shuō)明。LW設(shè)計(jì)文檔通常又叫畢業(yè)設(shè)計(jì)說(shuō)明書(shū)或者項(xiàng)目設(shè)計(jì)文檔包含需求分析、系統(tǒng)設(shè)計(jì)、數(shù)據(jù)庫(kù)設(shè)計(jì)、功能測(cè)試、總結(jié)等章節(jié)一般要求1.5萬(wàn)字到2萬(wàn)字圖比字重要。演示視頻三到五分鐘的操作演示從登錄、瀏覽商品、加購(gòu)、下單到管理端修改商品狀態(tài)視頻里要能看出系統(tǒng)是真實(shí)跑起來(lái)的。答辯PPT核心講背景意義、技術(shù)架構(gòu)、本人完成的工作、系統(tǒng)演示和測(cè)試結(jié)果。這四樣?xùn)|西的權(quán)重經(jīng)常被低估。我見(jiàn)過(guò)有學(xué)生代碼寫(xiě)得挺好但文檔里連數(shù)據(jù)庫(kù)關(guān)系圖都沒(méi)有老師直接一句話頂回去你這項(xiàng)目不是你自己做的吧所以這個(gè)題目的第一關(guān)是擺正心態(tài)它不是編程題而是一個(gè)系統(tǒng)設(shè)計(jì) 工程實(shí)現(xiàn) 文檔沉淀的綜合項(xiàng)目。1.2 難度定位中低偏上但能拉開(kāi)差距單論開(kāi)發(fā)難度這類(lèi)小程序電商題屬于中低難度比算法類(lèi)、底層系統(tǒng)類(lèi)、大數(shù)據(jù)平臺(tái)類(lèi)題目容易出成果。但是想拿高分反而難在有沒(méi)有把簡(jiǎn)單的東西做完整。同樣叫文具選購(gòu)小程序A同學(xué)只做了首頁(yè)展示、分類(lèi)、加購(gòu)、下單B同學(xué)多做了庫(kù)存不足提示、訂單倒計(jì)時(shí)取消、銷(xiāo)量排行榜、后臺(tái)數(shù)據(jù)統(tǒng)計(jì)圖表、圖片懶加載、支付模擬狀態(tài)機(jī)——兩人的完成度和答辯評(píng)價(jià)立刻拉開(kāi)差距。所以題目是同一個(gè)做出來(lái)什么水平完全取決于你自己。1.3 為什么這類(lèi)題目的通過(guò)率反而高因?yàn)樗臉I(yè)務(wù)邊界非常清晰。文具商品的屬性相對(duì)固定分類(lèi)明確筆、本冊(cè)、美術(shù)用品、辦公耗材、書(shū)包等價(jià)格范圍穩(wěn)定沒(méi)有復(fù)雜的營(yíng)銷(xiāo)邏輯或售后邏輯。相比做生鮮、做服裝、做二手交易文具選購(gòu)把電商閉環(huán)濃縮得恰到好處特別適合在幾個(gè)月內(nèi)完整開(kāi)發(fā)并寫(xiě)出規(guī)范文檔。這也是很多選題庫(kù)把它列為常規(guī)選項(xiàng)的根本原因。2. 功能模塊與業(yè)務(wù)閉環(huán)先畫(huà)清楚了再動(dòng)手2.1 用戶端六個(gè)頁(yè)面撐起完整購(gòu)買(mǎi)流程小程序端的核心頁(yè)面我建議按下面的結(jié)構(gòu)來(lái)設(shè)計(jì)每一頁(yè)解決一個(gè)明確的用戶訴求頁(yè)面核心功能關(guān)鍵交互首頁(yè)輪播圖、熱門(mén)商品、秒殺/特價(jià)區(qū)、搜索入口下拉刷新、上拉加載分類(lèi)頁(yè)左側(cè)分類(lèi)導(dǎo)航右側(cè)商品列表分類(lèi)切換、篩選排序搜索頁(yè)/結(jié)果頁(yè)按關(guān)鍵字搜索文具、歷史搜索記錄關(guān)鍵詞高亮、空狀態(tài)提示商品詳情頁(yè)商品圖片、價(jià)格、庫(kù)存、規(guī)格、詳細(xì)介紹加入購(gòu)物車(chē)、立即購(gòu)買(mǎi)購(gòu)物車(chē)頁(yè)已選商品、數(shù)量增減、單選/全選、結(jié)算金額實(shí)時(shí)計(jì)算、庫(kù)存校驗(yàn)訂單中心待付款/待發(fā)貨/待收貨/已完成 四個(gè)Tab取消訂單、確認(rèn)收貨、刪除訂單除了購(gòu)物流程用戶側(cè)還要有個(gè)人中心微信授權(quán)頭像昵稱、地址管理、瀏覽歷史。如果你為了省事把地址做成下單時(shí)手填輸入框也可以但體驗(yàn)就會(huì)弱一些而且文檔里少了一張地址管理用例圖。2.2 管理端不要讓管理員在小程序里點(diǎn)點(diǎn)點(diǎn)管理端是畢業(yè)設(shè)計(jì)里最容易被做薄的地方很多學(xué)生只在數(shù)據(jù)庫(kù)里手動(dòng)改數(shù)據(jù)或者勉強(qiáng)做了一個(gè)只有訂單列表的管理頁(yè)面。這里踩一個(gè)關(guān)鍵認(rèn)知管理端一定是要有獨(dú)立入口的哪怕只是小程序里的管理員登錄隱藏入口。管理端模塊建議拆成四塊商品管理新品上架、下架、編輯價(jià)格庫(kù)存、上傳封面圖、設(shè)置分類(lèi)。這里直接對(duì)應(yīng)數(shù)據(jù)庫(kù)商品的增刪改查。分類(lèi)管理補(bǔ)充/刪除文具分類(lèi)分類(lèi)排序。訂單管理查看全部訂單、按狀態(tài)篩選、發(fā)貨操作、備注。發(fā)貨操作在演示里很有畫(huà)面感老師會(huì)看到訂單狀態(tài)從待發(fā)貨變?yōu)榕渌椭?。?shù)據(jù)概覽統(tǒng)計(jì)商品總數(shù)、總銷(xiāo)售額、訂單量存量少的時(shí)候可以用條形圖展示TOP5熱賣(mài)商品。如果不想接圖表庫(kù)就用小程序原生的canvas畫(huà)一個(gè)簡(jiǎn)單柱狀圖或者直接把統(tǒng)計(jì)數(shù)據(jù)做成數(shù)字卡片效果也夠。有些學(xué)生會(huì)問(wèn)要不要做用戶管理。我的建議是保留一個(gè)簡(jiǎn)單的用戶列表即可不要做刪除功能因?yàn)檠菔緯r(shí)把同學(xué)頭像弄消失不太好而且對(duì)主流程沒(méi)有幫助。2.3 數(shù)據(jù)庫(kù)與狀態(tài)機(jī)設(shè)計(jì)最見(jiàn)功底的位置文具選購(gòu)小程序的表不需要很多但每張表都要經(jīng)得起推敲。我下面列出一套比較常見(jiàn)的庫(kù)表結(jié)構(gòu)字段做了精簡(jiǎn)用戶表openid唯一標(biāo)識(shí)、昵稱、頭像、角色、創(chuàng)建時(shí)間分類(lèi)表分類(lèi)名、排序值、圖標(biāo)商品表名稱、描述、價(jià)格、原價(jià)、庫(kù)存、銷(xiāo)量、封面圖、詳情圖、分類(lèi)ID、是否上架、瀏覽量購(gòu)物車(chē)表用戶ID、商品ID、數(shù)量、選中狀態(tài)訂單表訂單號(hào)、用戶ID、總金額、實(shí)付金額、狀態(tài)、收貨人、電話、地址、創(chuàng)建時(shí)間、支付時(shí)間、發(fā)貨時(shí)間訂單明細(xì)表訂單ID、商品ID、商品名稱、快照價(jià)格、商品圖片、購(gòu)買(mǎi)數(shù)量地址表用戶ID、收貨人、電話、省市區(qū)、詳細(xì)地址、默認(rèn)標(biāo)記這里有一個(gè)容易被答辯老師抓住的點(diǎn)為什么要有訂單明細(xì)表而且明細(xì)表里要冗余保存商品名稱、價(jià)格、圖片因?yàn)樵谫?gòu)買(mǎi)完成后商品可能被下架、改價(jià)甚至刪除訂單不能跟著變。所以明細(xì)表保存的就是下單那一刻的商品快照。文檔里把這個(gè)設(shè)計(jì)邏輯寫(xiě)清楚評(píng)委很難挑出毛病。訂單狀態(tài)的流轉(zhuǎn)是另一個(gè)答辯高頻點(diǎn)。建議用一張表或者狀態(tài)圖表達(dá)待付款 → 待發(fā)貨 → 待收貨 → 已完成 ↓超時(shí)未支付 已關(guān)閉如果要加分還可以設(shè)計(jì)一個(gè)售后/退款狀態(tài)但需要注意工作量控制。有些學(xué)生給自己加了一個(gè)退貨退款流程結(jié)果做到后面時(shí)間不夠反而把主流程的穩(wěn)定性拖垮了。對(duì)于畢業(yè)設(shè)計(jì)來(lái)說(shuō)做好正向狀態(tài)流轉(zhuǎn) 超時(shí)關(guān)閉已經(jīng)足夠完整。3. 技術(shù)選型對(duì)比微信云開(kāi)發(fā)還是自建后端 API3.1 云開(kāi)發(fā)模式快速出成果的首選現(xiàn)在微信小程序最流行的后端方案是微信云開(kāi)發(fā)CloudBase它天生集成了云數(shù)據(jù)庫(kù)、云函數(shù)、云存儲(chǔ)。對(duì)畢業(yè)設(shè)計(jì)來(lái)說(shuō)這個(gè)方案有幾個(gè)非?，F(xiàn)實(shí)的優(yōu)點(diǎn)不用自己申請(qǐng)服務(wù)器不用配置域名備案。你在微信開(kāi)發(fā)者工具里點(diǎn)幾下環(huán)境和數(shù)據(jù)庫(kù)就建好了。不用實(shí)現(xiàn)微信登錄的完整后端邏輯。云函數(shù)側(cè)一個(gè) login 函數(shù)接收前端傳過(guò)來(lái)的 code然后調(diào)用鑒權(quán)接口就能拿到 openid流程非常短。圖片直接傳到云存儲(chǔ)拿到的URL就能當(dāng)商品封面圖使用省去圖片服務(wù)器的搭建。數(shù)據(jù)權(quán)限可以配置成僅創(chuàng)建者可讀寫(xiě)或者所有人可讀非常適配電商場(chǎng)景商品表所有人可讀訂單表只有本人和管理員可讀。這個(gè)模式的代價(jià)是你寫(xiě)的大部分邏輯都在云函數(shù)里沒(méi)法體現(xiàn)傳統(tǒng)后端的分層結(jié)構(gòu)比如Controller、Service、DAO那一套。如果學(xué)校老師特別老派只看重Java SSH/Spring Boot那么你需要在文檔里把云函數(shù) 業(yè)務(wù)邏輯層這個(gè)映射關(guān)系寫(xiě)清楚。3.2 自建后端模式更學(xué)院派但周期更長(zhǎng)傳統(tǒng)方案是小程序前端 Spring Boot后端 MySQL數(shù)據(jù)庫(kù) Redis可選。到位的話還可以加個(gè) Nginx 部署、HTTPS 證書(shū)、服務(wù)器域名。這個(gè)方案的優(yōu)點(diǎn)顯而易見(jiàn)技術(shù)棧主流答辯時(shí)老師比較熟悉對(duì)分層架構(gòu)的理解也更直觀。它的痛點(diǎn)是部署鏈路長(zhǎng)。我見(jiàn)過(guò)某學(xué)生把Spring Boot接口在本地跑得好好的結(jié)果要在云服務(wù)器上部署時(shí)捅了幾天MySQL版本不一致、防火墻端口沒(méi)開(kāi)、小程序 request 合法域名沒(méi)配置、JAR包內(nèi)存不夠。最后光是解決部署問(wèn)題就花了一個(gè)多星期。如果選擇這種方式建議至少提前一個(gè)月買(mǎi)服務(wù)器并把環(huán)境裝好域名也要早點(diǎn)備案因?yàn)樾〕绦蛘桨嬉?request 域名必須是 HTTPS 且已經(jīng)備案?jìng)浒笇徍艘话阋粌芍堋?.3 面對(duì)這兩種方案我給出的實(shí)用建議如果現(xiàn)在時(shí)間緊張只剩兩三個(gè)月或者你的Java功底一般我強(qiáng)烈推薦云開(kāi)發(fā)方案。它的交付速度至少比自建后端快一倍而且可以讓你把精力留在體驗(yàn)優(yōu)化上比如商品圖片、界面整潔度、演示流程。如果學(xué)校明確要求用Java/Spring Boot做后端或者你的選題需要體現(xiàn)前后端分離那就老老實(shí)實(shí)走傳統(tǒng)方案。我可以給一個(gè)折中的做法前端用微信小程序后端用Spring Boot但數(shù)據(jù)庫(kù)可以先用支付寶云或者騰訊云的云數(shù)據(jù)庫(kù)MySQL這樣省去自己裝MySQL的時(shí)間。3.4 技術(shù)方案對(duì)比表對(duì)比維度微信云開(kāi)發(fā)Spring Boot自建后端開(kāi)發(fā)速度快環(huán)境零配置慢環(huán)境搭建較多項(xiàng)目結(jié)構(gòu)云函數(shù)即服務(wù)前后端分層清晰域名/備案基本不用管必須HTTPS備案支付能力仍需要商戶號(hào)通常模擬同樣需要商戶號(hào)通常模擬答辯契合度需要解釋云開(kāi)發(fā)概念傳統(tǒng)架構(gòu)更易被認(rèn)可適合人群趕時(shí)間/后端基礎(chǔ)一般有Java基礎(chǔ)/要求嚴(yán)格4. 小程序端核心實(shí)現(xiàn)登錄、商品列表與訂單狀態(tài)流轉(zhuǎn)4.1 登錄鑒權(quán)不要讓每次請(qǐng)求都重新登錄小程序登錄的核心邏輯是前端調(diào)用wx.login拿到臨時(shí) code把它發(fā)給后端或云函數(shù)后端通過(guò)該 code 換取 openid然后返回一個(gè)自定義登錄態(tài)。云開(kāi)發(fā)模式下我把登錄函數(shù)寫(xiě)得很短// 云函數(shù) login const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) exports.main async () { const wxContext cloud.getWXContext() const db cloud.database() const users db.collection(users) const res await users.where({ openid: wxContext.OPENID }).get() if (res.data.length 0) { await users.add({ data: { openid: wxContext.OPENID, nickname: , avatar: , createTime: Date.now() } }) } return { openid: wxContext.OPENID } }前端把這個(gè)返回的 openid 存到wx.setStorageSync后續(xù)的請(qǐng)求直接攜帶 openid 作為用戶標(biāo)識(shí)。注意不要每次頁(yè)面加載都調(diào)一次wx.login否則云函數(shù)會(huì)頻繁查庫(kù)。我見(jiàn)過(guò)有的學(xué)生在首頁(yè) onLoad 里調(diào)登錄接口在詳情頁(yè)又調(diào)一次不僅慢還容易被云開(kāi)發(fā)資源限制狙擊。4.2 商品列表和購(gòu)物車(chē)數(shù)據(jù)流向要清楚商品列表大多長(zhǎng)這樣onLoad里請(qǐng)求 cloud functionproduct或者直接查products集合按分類(lèi)過(guò)濾、按銷(xiāo)量排序。要注意的是不要把整個(gè)商品詳情的大圖字段也塞進(jìn)列表否則小程序首屏加載很慢。列表查詢只取必要的字段比如_id, name, price, cover, sales詳情頁(yè)再單獨(dú)查 full content。購(gòu)物車(chē)是另一個(gè)容易寫(xiě)亂的模塊。我建議不要把購(gòu)物車(chē)完全放本地緩存因?yàn)閾Q手機(jī)、清理緩存后數(shù)據(jù)就沒(méi)了答辯時(shí)容易露怯也別把每一項(xiàng)都實(shí)時(shí)寫(xiě)數(shù)據(jù)庫(kù)因?yàn)轭l繁操作會(huì)導(dǎo)致請(qǐng)求次數(shù)暴漲。折中方案是選中狀態(tài)和臨時(shí)數(shù)量放在本地 storage最終點(diǎn)擊去結(jié)算時(shí)把勾選的數(shù)據(jù)一次性寫(xiě)入訂單表和購(gòu)物車(chē)表清理。4.3 下單與庫(kù)存處理這里藏著最大的并發(fā)坑很多學(xué)生寫(xiě)的提交訂單接口邏輯是這樣// 偽代碼庫(kù)存不足情況 const product await db.collection(products).doc(productId).get() if (product.data.stock quantity) { await db.collection(products).doc(productId).update({ stock: product.data.stock - quantity }) // 創(chuàng)建訂單... }這個(gè)寫(xiě)法在單人測(cè)試、單機(jī)部署時(shí)完全沒(méi)問(wèn)題但答辯老師只要問(wèn)一句兩個(gè)人同時(shí)買(mǎi)最后一個(gè)庫(kù)存怎么辦你就會(huì)被戳到。正確的處理方式至少應(yīng)該是在數(shù)據(jù)庫(kù)層做庫(kù)存扣減的條件更新update({ stock: _.gte(quantity) })然后判斷更新結(jié)果影響行數(shù)是否為1再?zèng)Q定是否創(chuàng)建訂單。在云開(kāi)發(fā)事務(wù)里執(zhí)行檢查庫(kù)存扣減庫(kù)存創(chuàng)建訂單三個(gè)操作確保原子性。如果用了傳統(tǒng)MySQL則使用SELECT ... FOR UPDATE或悲觀鎖加樂(lè)觀鎖版本號(hào)。我見(jiàn)過(guò)有學(xué)生在答辯時(shí)對(duì)這個(gè)點(diǎn)對(duì)答如流老師當(dāng)場(chǎng)就點(diǎn)頭了。這說(shuō)明復(fù)雜技術(shù)不一定真的寫(xiě)很多代碼但一定要在邏輯上說(shuō)得通。5. 真機(jī)運(yùn)行與演示階段最容易踩的坑5.1 合法域名和 HTTPS 問(wèn)題選云開(kāi)發(fā)模式時(shí)如果你用wx.cloud.callFunction調(diào)用云函數(shù)是不需要配置 request 合法域名的。但如果你的項(xiàng)目里用了wx.request請(qǐng)求自建后端就必須在微信公眾平臺(tái)配置 HTTPS 合法域名。開(kāi)發(fā)時(shí)可以在開(kāi)發(fā)者工具里勾選不校驗(yàn)合法域名可一旦到了演示那天如果還是在本地開(kāi)發(fā)者工具里點(diǎn)那個(gè)勾再跑老師印象分會(huì)掉。所以演示前我強(qiáng)烈建議用真機(jī)預(yù)覽模式用微信掃小程序碼在手機(jī)上完整走一遍流程。你要提前確認(rèn)云環(huán)境是本地的還是線上的數(shù)據(jù)是否夠看手機(jī)上字體大小會(huì)不會(huì)把按鈕擠出屏幕。5.2 微信支付個(gè)人開(kāi)發(fā)者號(hào)大概率開(kāi)通不了這個(gè)項(xiàng)目名叫文具選購(gòu)老師默認(rèn)會(huì)有支付流程但現(xiàn)實(shí)是個(gè)人主體的小程序申請(qǐng)微信支付幾乎都會(huì)被駁回因?yàn)樗笃髽I(yè)資質(zhì)、對(duì)公賬戶、法人身份信息。畢業(yè)設(shè)計(jì)階段最好的處理方式是模擬支付訂單創(chuàng)建后狀態(tài)為待付款頁(yè)面展示一個(gè)確認(rèn)支付按鈕點(diǎn)擊后調(diào)用一個(gè)模擬支付云函數(shù)將訂單狀態(tài)更新為待發(fā)貨。在文檔和答辯PPT里要主動(dòng)說(shuō)明本項(xiàng)目采用模擬支付流程已預(yù)留官方支付接口位置后續(xù)接入只需替換支付云函數(shù)內(nèi)部實(shí)現(xiàn)。千萬(wàn)不要在演示時(shí)真的跳到收銀臺(tái)然后尷尬地發(fā)現(xiàn)沒(méi)有商戶號(hào)。提前在演示腳本里注明模擬支付四個(gè)字反而顯得你考慮周全。5.3 云開(kāi)發(fā)的環(huán)境和數(shù)據(jù)權(quán)限配置云開(kāi)發(fā)有幾個(gè)高頻翻車(chē)點(diǎn)數(shù)據(jù)庫(kù)權(quán)限默認(rèn)是僅創(chuàng)建者可讀寫(xiě)商品表如果所有人都不能讀那前端商品列表一定是空白的。需要把商品表權(quán)限調(diào)成所有用戶可讀僅管理端可寫(xiě)。云函數(shù)默認(rèn)超時(shí)時(shí)間是3秒如果你在云函數(shù)里做了商品圖片壓縮或者批量寫(xiě)入很容易超時(shí)。把超時(shí)時(shí)間調(diào)到10秒或更長(zhǎng)比較穩(wěn)。云開(kāi)發(fā)環(huán)境有免費(fèi)額度限制但云函數(shù)調(diào)用次數(shù)、數(shù)據(jù)庫(kù)讀寫(xiě)次數(shù)都有上限。演示時(shí)不要頻繁刷新頁(yè)面否則請(qǐng)求數(shù)會(huì)漲得很快有些同學(xué)碰上限后數(shù)據(jù)庫(kù)直接被停掉整個(gè)人都懵了。這些坑不是技術(shù)多深而是你沒(méi)有提前在測(cè)試環(huán)境里跑足量數(shù)據(jù)。我建議寫(xiě)一個(gè)測(cè)試數(shù)據(jù)初始化腳本一次性在數(shù)據(jù)庫(kù)里插入幾十條文具商品數(shù)據(jù)包括分類(lèi)、價(jià)格、銷(xiāo)量、圖片鏈接保證演示不卡殼。5.4 文具商品的數(shù)據(jù)與圖片不做土味頁(yè)面電商項(xiàng)目能不能拿高印象分很大程度看視覺(jué)。很多學(xué)生的項(xiàng)目圖片是從搜索引擎直接抓來(lái)的分辨率不一致、背景花花綠綠、甚至帶水印整個(gè)頁(yè)面看起來(lái)非常廉價(jià)。建議用一套風(fēng)格統(tǒng)一的商品圖比如牛皮紙背景的文具擺拍圖實(shí)在沒(méi)有圖就在云存儲(chǔ)里放純色底加商品名文字也比亂七八糟的水印圖強(qiáng)。商品名稱和描述也要擬得認(rèn)真比如晨光0.5mm黑色中性筆 12支裝、國(guó)譽(yù)Campus活頁(yè)本 B5 40頁(yè)這樣答辯老師看一眼就覺(jué)得項(xiàng)目是認(rèn)真在做。6. 把代碼沉淀成 LW 文檔并準(zhǔn)備一份能打答辯的PPT6.1 論文結(jié)構(gòu)按老師習(xí)慣的套路走LW是畢業(yè)設(shè)計(jì)文檔的常見(jiàn)縮寫(xiě)一般包含這幾個(gè)部分不同學(xué)校章節(jié)叫法略有差異但內(nèi)容大同小異緒論項(xiàng)目背景、國(guó)內(nèi)外現(xiàn)狀、研究意義、本文主要工作相關(guān)技術(shù)概述微信小程序開(kāi)發(fā)框架、云開(kāi)發(fā)/Spring Boot、WXML/WXSS/JS、數(shù)據(jù)庫(kù)技術(shù)需求分析可行性分析、功能性需求用例描述、非功能性需求性能、安全、兼容性系統(tǒng)設(shè)計(jì)總體架構(gòu)圖、功能模塊劃分、業(yè)務(wù)流程圖、數(shù)據(jù)庫(kù)設(shè)計(jì)E-R圖、數(shù)據(jù)字典系統(tǒng)實(shí)現(xiàn)分模塊貼核心代碼并解釋邏輯注意只貼關(guān)鍵片段不是整頁(yè)整頁(yè)貼代碼系統(tǒng)測(cè)試測(cè)試環(huán)境、功能測(cè)試用例表、性能測(cè)試、結(jié)論總結(jié)與展望不足和后續(xù)改進(jìn)方向頁(yè)數(shù)上不用刻意湊到100頁(yè)把圖表做清楚比空話強(qiáng)得多。我見(jiàn)過(guò)一份文檔內(nèi)容只有40頁(yè)但每個(gè)模塊都有截圖、有流程說(shuō)明老師給的評(píng)價(jià)比堆了80頁(yè)廢話的要高得多。6.2 畫(huà)圖的技巧能用一張圖說(shuō)清楚的別用三段話設(shè)計(jì)文檔里幾張圖是必考題系統(tǒng)總體架構(gòu)圖從下往上是 云數(shù)據(jù)庫(kù)→云函數(shù)/后端服務(wù)→小程序前端→微信用戶層次越清晰越能體現(xiàn)設(shè)計(jì)感。業(yè)務(wù)流程時(shí)序圖可以從用戶點(diǎn)擊立即購(gòu)買(mǎi)出發(fā)畫(huà)一條線穿過(guò)前端頁(yè)面、購(gòu)物車(chē)邏輯、下單接口、數(shù)據(jù)庫(kù)、訂單狀態(tài)。這里推薦用文字加箭頭的形式不要用特別復(fù)雜的UML工具套件夠用就行。E-R圖把上面提到的七八張表的關(guān)系連清楚重點(diǎn)標(biāo)出訂單表與用戶、商品明細(xì)表之間的關(guān)系。界面原型圖直接用小程序真機(jī)截圖放在系統(tǒng)實(shí)現(xiàn)里比用原型工具畫(huà)的更真實(shí)也省時(shí)間。6.3 答辯高頻問(wèn)題提前準(zhǔn)備答案參照我這些年看到的問(wèn)題以下這幾個(gè)高頻點(diǎn)如果都能答上來(lái)項(xiàng)目基本不太可能掛為什么選微信小程序而不是手機(jī)App回答框架方便分享、無(wú)需下載、開(kāi)發(fā)成本低、符合學(xué)生購(gòu)買(mǎi)習(xí)慣。訂單狀態(tài)是怎么流轉(zhuǎn)的要把待付款、待發(fā)貨、待收貨、已完成、已關(guān)閉之間的觸發(fā)條件說(shuō)清楚。庫(kù)存超賣(mài)如何避免原子更新、事務(wù)、數(shù)據(jù)庫(kù)鎖選一個(gè)你實(shí)際用到的講透。用戶登錄態(tài)怎么維護(hù)說(shuō)清楚 code、openid、前端本地存儲(chǔ)之間的關(guān)系。整個(gè)系統(tǒng)哪個(gè)部分是你自己做的最核心的一定要挑一個(gè)真正自己寫(xiě)過(guò)的功能不要背概念。文檔里的產(chǎn)品分類(lèi)截圖為什么只有三條因?yàn)闇y(cè)試數(shù)據(jù)不夠答辯前建議至少錄入8個(gè)分類(lèi)、每類(lèi)10個(gè)商品。另外一個(gè)小技巧準(zhǔn)備一份“演示腳本”把每一步操作在什么時(shí)候做、預(yù)期看到什么結(jié)果列清楚提前預(yù)演三遍。真正上臺(tái)時(shí)不要按著腳本僵硬地念但心里始終有底。最后再分享一點(diǎn)個(gè)人經(jīng)驗(yàn)這類(lèi)小程序畢業(yè)設(shè)計(jì)程序?qū)懲曛凰阃瓿闪艘话牒竺娴囊话朐谟诎盐臋n里的邏輯圖、界面截圖、測(cè)試表格補(bǔ)到位。你代碼里那些跑通了的流程同樣要在紙上畫(huà)出來(lái)、在文檔里講明白。文檔和代碼對(duì)齊了答辯的通過(guò)率就穩(wěn)了。至少我身邊的例子反復(fù)驗(yàn)證這件事希望講完這些準(zhǔn)備做這個(gè)題目的同學(xué)能少走幾段彎路。