1. 程式人生 > >關於web開發中的規範流程

關於web開發中的規範流程

1. 不知不覺中做web開發將近5個月了,其實真正的web程式碼我寫的並不多,之前寫過一段時間的Python專案,但是最近在寫web專案的時候感覺各自的程式碼風格都不一樣,我屬於那種簡潔風格流派的,基本是受到了之前公司專案經理(悟空)的影響,在他手下做了4個月感覺學會了不少東西,有些知識結構以及新視野方面的東西當時並不是很理解,但是走過來回想那些知識發現都是些非常受益的東西,我一般寫程式碼能用一個方法複用的話是堅決不會寫2個方法或者介面的,因為我覺得那樣子很奇怪,我不喜歡這麼幹。

2. 對於前端傳參,一般不用多說,現在主流的都是json,到controller層接收引數,我之前的習慣是直接用實體物件去接收引數,因為這樣做有一個很好的地方就是我這一個介面可以接收的引數有很多,之前做商品管理專案的時候無非做的最多的就是對spu和sku的操作,這樣我直接用實體去接收,然後到service層去做相應的操作,我個人覺得這麼做會讓程式碼很簡潔,而且介面儘量可以做到複用,相反的我很反對的寫法就是下面這種
這裡寫圖片描述

我覺得這種做法讓程式碼的擴充套件性性非常的差,下面是我的程式碼習慣。

這裡寫圖片描述

   當然我這裡寫的是get請求方式的列子,其實post請求也應該是這樣的,用請求體傳參,後臺使用實體物件接收。

   另外這裡我需要介紹一個restful測試client,postman是一個很多開發人員熟知的restful測試外掛,可以在谷歌瀏覽器中直接安裝這個外掛,方便測試。

這裡寫圖片描述

postman可以幫助web開發人員完成各種介面的測試,非常方便有效。所有推薦給大家。拿走不謝,說到這裡我想不得不吐槽一番,現在公司架構思想非常傳統,要求我針對每一個service層和controller層的每一個介面和方法都寫完整的測試用例,我個人感覺這個根本沒必要,系統開發到最後會發現大把的測試用例,讓工程顯得非常的臃腫,我很不喜歡。不過這個也跟我們現在這套傳統蒸籠式的架構設計有關,詳細的就不多說,其實現在網際網路的崛起,這種傳統模式的架構已經淘汰很久了,現在一般再小的網際網路公司都會把業務進行垂直拆分,大的網際網路公司業務複雜的,都在做微服務架構,就是根據業務分表分庫,把業務微服務化。介紹大家看一本書《微服務設計》,有中文版的。

3.再說說我對後臺MVC的理解,從前端發出一個restful請求,首先就是請求到controller層介面,介面層的話,一般情況最常用的也就是get請求和post請求。
3.1、get請求一般用於查詢請求,也就是沒有涉及到資料庫記錄的更新操作。
3.2、post請求一般涉及到資料庫的增刪改操作都用post請求。
3.3、controller層的職責就是完成請求接收及資料傳輸的工作,我個人的開發習慣最開始很不好,習慣在controller層做大量的資料資料處理工作,開始工作的時候也是受了他人程式碼的影響,後來被悟空多次糾正之後,我開始慢慢的轉向正規寫法,正規的controller介面層其實工作應該很少,程式碼越簡潔越好,這樣也有力於後期的程式碼維護。下面是我最近寫的一個介面層,程式碼很少,但是完成了分頁查詢。其實這段程式碼還可以寫得再簡潔些。

這裡寫圖片描述

3.4、service層的理解 service層也就是邏輯業務層,一般而言這一層會負責一個業務流水線的所有業務工作,從controller層拿到業務需求和相應的資料,在service通過呼叫dao層來做資料的操作,這裡我需要強調的一點,也是目前開發中很多公司都沒有做到規範化,對於資料庫的操作儘量是單表操作,不管是查詢還是增刪改操作,都使用單表操作,這樣做可以使得dao層分工明確,而且可以做到把一個業務細分,這樣做也有利於程式碼維護等好處,比如現在要從兩張表或者三張表拿資料欄位,那麼我建議單表查詢,然後在記憶體中做資料整理。然後將相應的資料欄位放到資料傳輸Dto中返回。單表操作還有一個好處就是有利於後期系統的分表分庫,這樣你的後端程式碼根本不用重複修改。而且也有很高的複用性,所以我提倡這種做法。根據業務不同做不同的邏輯處理,service邏輯層特別能看出一個程式設計師的思維邏輯和嚴密性,以及對於一些常用的設計模式的理解程度,這方面我也一直在成長中,我個人感覺我做的一直都不夠好。這裡給大家推薦一下,可以去看看設計模式方面的書籍,會大大提升你的程式碼質量,另外就是出來已久的Java8,我個人最近也在學習Java8的新特性和使用方法,很慚愧的是沒能在專案中使用過,因為公司線上環境還是7的哎很無語,其實用過Java8的人應該都知道Java8的stream流式處理和lambda表示式是非常好用的,作為一個Java程式設計師我也建議能用盡量用8來寫程式碼,寫多了你會發現其中的奧妙。Java8方面的書籍我個人在看的是《Java8 in action》,能學習儘快學習,畢竟Java9都要釋出了,不然真的很out了。

這裡寫圖片描述

3.4、dao層的理解資料持久層,現在基本都是用的第三方orm框架,目前最為流行的應該屬於mybatis或者ibatis,後者沒用過,但是我覺著應該都差不太多。這裡我需要給大家介紹一個外掛的使用,mybatis-generator是一個很好用的外掛,能夠完成把你指定的資料表完成對映成dao層以及model和mapperXML檔案,並且自動生成基本的增刪改查的方法和對映。外掛的用法我之前又在部落格中介紹過,這裡就不羅嗦了,我也是在摸索中學習的。
說到dao層,之前談到的程式碼簡潔問題,對於我個人的做法是儘量做到高可用性和程式碼可擴充套件性。由於現在公司使用的是hibernate,這裡無法向大家展示我的風格。載談談我個人對於hibernate的看法,這個框架之前最早接觸的orm框架,不過我本人一直用不習慣,這個框架的唯一好處就是不用自己動手寫sql,不過我倒是覺得這是一種不正確的做法,作為一名後端程式設計師,不會寫sql那可真是一件不太好的事情。所以能不用就不用的,而且現在市場上也都慢慢的放棄了這種寫法。
還是跑去之前做的專案中拷了點程式碼來。
這裡寫圖片描述
這幾個方法基本可以完成對這張表的所有的操作了。看起來程式碼是不是很簡潔了,而且複用性也很高。

4、然後就是程式裡面的一些其他的技術 對於一些其他的新技術,我目前在開發中還是很少接觸到的,比如一些併發快取和RateLimiter併發訪問這些我也只是聽說,沒接觸過。包括現在很多的web系統也對接大資料框架比如Hbase這些。我也是自己閒的時候在摸索學習。