iT邦幫忙

2021 iThome 鐵人賽

DAY 30
0
Modern Web

誤打誤撞學了Spring Boot 還當了後端工程師系列 第 30

Day 30 - 開發流程(下) Web 開發流程 & 鐵人賽心得

上一篇Day 29 - 開發流程(上) 瀑布式(Waterfall Model) & 敏捷式(Agile Model)了解了整個專案的開發流程,而這篇要講的是自己後端開發一個功能的流程,當開發有個固定的流程在進行時,功能才可以做得完整,也可以早一點發現問題。

實體關係模型

實體關係模型(Entity-Relationship Model, E-R Model) 是設計資料庫的重要方法,常用於資訊系統設計,這邊主要根據網站的功能性與資料需求詳細的規劃SQL 資料庫的關聯性結構。

一般來說,必須先畫好E-R Model 才會進行功能的開發,不然缺少欄位或是關聯結構複雜,容易導致當下開發與後續維護困難。

持久層

在進行一個功能的開發前,應該先寫好該功能會對資料庫的操作檢查是否有可用的方法,再開始寫功能的邏輯判斷。

舉例來說,在執行一個註冊功能的開發時,可以先寫好根據帳號查詢用戶以及寫入用戶資料兩個方法,這樣在註冊的業務邏輯實作時,除了可以快速的取用已完成的方法進行資料的判斷、處理,還可以提前了解前個步驟設計的資料庫結構是否有問題。

業務邏輯層

完成持久層的開發後就可以進行業務邏輯的實作,這裡需要做的是寫好註解,先好寫業務邏輯所需要的判斷、處理並依照執行順序排列,再開始業務邏輯的編程,最後回傳處理結果。

先列出業務邏輯的註解的好處是為開發時確認功能的完整性以及幫助後續維護人員可以快速了解該功能的邏輯

控制器層

完成上述業務邏輯層和持久層的實作,再來進行控制器層的開發,這邊就是設定這個功能的請求路徑、參數、調用的業務邏輯層以及回應結果或頁面。

頁面

資料有了,路徑也有了,最後就是請求路徑將資料完整呈現在頁面上,就看依照個人習慣,看是使用JSP、Thymeleaf 或是其他工具作為視圖解析器,若是API 則是測試API 串接,完成這一步才算是將整個功能開發完成。

總結

當然,除了開發流程外,還需要制定統一程式風格,有統一的風格可以讓團隊在進行合作開發的時候,不會每一個部分的風格都不一樣,。

心得

終於結束了這難熬的30天,心情從一開始的游刃有餘到後來的黔驢技窮,有看完整個系列文的讀者應該有發現從15天之後的文章內容越來越少,這是因為我原本的心態就是寫成一個完整的教學文章,所以我幾乎每篇文章都會查閱了數十篇教學文章,綜合許多前輩的知識來做成一篇文章,但要查閱的知識點實在太多了,寫到最後實在是力不從心。

不過學習的路途是無止盡的,近期會繼續更新系列文章的內容,目前正在著手進行Spring Security 的研究,有碰過的應該都會知道Spring Security 是一個大坑,在查閱資料的時候就覺得很多文章內容不夠完整,或是實作的地方太少,所以打算閱讀官方文件進行最完整的學習,但我的英文並沒有很好,翻譯跟理解都需要一點時間,還請有興趣的讀者耐心等候。

再來就會是中間文章的更新,當時候是處於放棄邊緣,導致文章品質急速下降,但後來回去看覺得還有很多不足的地方想要補充,不僅是因為要給讀者學習不能誤人子弟,也是因為要給未來的我進行複習,畢竟未來要接觸的技術肯定越來越多,當一個技術不常用就一定會忘記,這時候就需要拿出自己的筆記複習。

最後,感謝這段時間的讀者,有你們的瀏覽給了我很大的支持,因為我對自己有一定的要求,希望自己能把文章打到最好,但其實有想過如果瀏覽數很低,應該就會很容易放棄了,畢竟嘔心瀝血的作品沒人注意到很打擊士氣,謝謝各位讀者,也請放心我會持續更新內容,把這個系列的文章都寫到自己能滿意的程度。


上一篇
Day 29 - 開發流程(上) 瀑布式(Waterfall Model) & 敏捷式(Agile Model)
系列文
誤打誤撞學了Spring Boot 還當了後端工程師30

尚未有邦友留言

立即登入留言