T02 ExtractSubject 專案開發總結

皮豪發表於2023-02-12

公縱號: 皮豪
部落格:www.kbug.cn
郵箱:pphboy@qq.com

前言

看來已經是一種習慣,每次寒假都會開發一個專案出來。本次專案使用的是Qt GUI,語言是C++。不得不說,在業務上寫C++和Java區別還是非常大,但我的技術水平非常低,不懂處理指標,所以很大程度上,用的程式碼也不能體現一個成熟的軟體工程。

此次使用QT GUI 開發,第一是為了方便,因為不需要安裝其他依賴,直接開啟就可以使用。第二是為了易用,因為使用WEB,則需要搭建環境什麼的,在使用上,其實不算簡單,不利於普通使用者使用。(顯然我知道怎麼讓普通使用者用的舒服)

其實這個軟體就是個普通的業務型的軟體,不是技術型的,這個軟體的作用第一是幫我練習題目,第二是幫我務實時間,第三是鍛鍊我的軟體工程實踐水平,第四是刻意練習。

技術層面

使用的技術是Qt,協議是GPL 3.0,語言是C++。

這裡我用的了Java方面的處理程式碼的方案,就是把軟體分層。每一層做什麼事。類似於MVC, Model(pojo資料類), View (視窗),Controller(綁在View上的那些函式)。在技術架構上,我沒有去尋找參考,而是自己摸索的。下次開發的時候會選用更成熟的架構方案。

因為C++有指標這個方便的工具,但指標用不好,就會經常出問題。我開發時也經常引用空指標,我的專案裡有很多野指標。所以我把一些常用視窗的指標都以靜態成員變數的方式儲存在一個工具類中。我需要用的時候,我直接引用一下就行。顯然使用C++,在指標管理上還是非常方便。多數會被重複使用的變數,就會被我一次性初始化,然後取地址存到指標裡。後面會一直用這個物件,而且在不同的條件下,僅僅只改變物件的資料。

因為架構分層,所以一開始我就設計了一個不太聰明的工具類,用來做DAO層的query物件提供。整體軟體使用的是都是一個query,這樣的話,缺點就是不能非同步。只能同步。其實有些思路,例如做一個Query池,直接生成十個Query物件放在那裡,用的時候直接拿,像任務佇列一樣,排隊的使用。這樣就不會出問題。這是執行緒池的思考,放在這裡,雖然我不需要多執行緒查詢,但我需要多個查詢視窗。

其實程式碼難度倒不高,重點就是在基礎架構上花了很多時間,一開始沒有理清楚怎麼存這些指標,後面直接採用了我寫Java的工具類的方式。在Java之中是不需要考慮什麼物件的回收什麼的,因為Java吃記憶體太多,也沒有什麼人在意記憶體。而C++,如果你不會回收,那麼這個軟體就會一直越來越大。所以有必要以元件的形式來使用,而不是每一次使用的時候建立一個元件,而是每一次使用的時候只更新元件的資料就行。

元件的初始化佔用的記憶體是不可少的,但不會存在太多大量佔用記憶體的情況。這樣對業務的抽象更為方便,管理和維護起來都非常方便。

為什麼寫得慢
這個軟體架構和模組元件的設計,決定著後面開發軟體是否順利。我們製作題目類和答案類的時候,沒有想到,題目和答案類可以使用同一個類,並且在查詢的時候我也沒有用什麼ORM。這樣我的靈活性非常高的。所以後面的功能寫的非常快就是因為架構和元件都成型了。

如果可以,先要爬到巨人肩膀上,再能站到巨人肩膀上。

總結

第一,我對軟體工程的實踐水平非常低,其實還是源於專案寫的太少。為什麼寫的少?因為我想做一些更有技術水平的,比如做伺服器,做協議開發。顯然世界可不是這麼動作的,我至少需要做一些基礎軟體來提升自己的水平,不然開口就是我要造核彈改變世界了。

哪日我熟練Cpp,Rust,我不是想寫什麼軟體就寫什麼軟體嗎?人人都想做高階軟體,但這些低階的業務型軟體也需要人來做。

技術上,如果這個專案用WEB技術來做,基本上兩天左右應該就可以完成。而且在ORM框架的加持下,開發飛速。

如果都爬不到巨人的肩膀上,我怎麼站得住。用別的人技術就相當於是用直升飛機把你放到自由女神像上面,你以為自己站在巨人上面,其實不過是短暫的自由罷了。當然,這是對於我學習階段來說的。

相關文章