前面說了整個軟體開發中,目前所處的位置---初級程式員,比起那些上學期間就做了一大堆項目的人來說,我實在慚愧的要命,著實"笨笨地",多麼想回,頭再來~想起白鬍子了,賊哈哈哈```不可能了>.有點慌了--淡靜,淡靜,要淡靜....
需求分析,資料庫設計,架構搭建,靜態頁面,甚至最終的整合測試--都有專人操作,自己的任務呢????---
比如:1:一個c#的cs結構的項目,大致處理流程為:畫面--傳遞參數parameters類(各個可能用到的值的封裝體)--到facade(webserver類完成邏輯處理),調用dao(底層資料的處理,供facade使用);;人員安排:專案經理解決業務疑惑,技術總監負責架構搭建及技術困難,一個小組負責facade的編寫(項目時間太緊,原計劃dao單獨一組負責,沒能實現),一個小組完成畫面的繪製;;;;自己和幾個實習生為最後一組,任務就是照著參考畫面拖控制項,(參考畫面可能是靜態一張圖,或者就是用word畫的一些框框,或者是一些現有軟體的),頁面的名字都已經定義好了,各個參數,控制項命名規則要參照規約,基本上就是來回拖動控制項定義名字,進行參數驗證,格式轉換...最後調用facade(webserver)完成資料處理.
2:一個java的項目cs的,大致流程:採用了spring+struct(說是項目小,就沒用hibernate),jsp頁面 調用action,再調用server介面,再調用dao介面,用到bean類(資料庫表對應的bean);;;;人員安排,一個負責項目,一個搭建架構,一個設計資料庫,一組編寫代碼(因邏輯簡單,就按模組分的任務);;;自己任務:看看模組用到哪些表,熟悉表中各欄位,把表映射為bean類,編寫介面完成對資料庫表所需的基本操作(增刪改查),完成介面的實現,寫service介面,實現介面(就是個dao管理類),再寫個action調用service,再在頁面顯示,還有設定檔,基本上都是照著其他的改下名稱即可;;;;
3,一個.net的bs的門戶網站上的一小項目,現成的後台(不知道N年前寫的另一個項目的後台,沒有原始碼,不過可以使用),基本流程:超簡單,就是查詢類似類似新聞的項,然後顯示<恨死這個爛項目了,拖了這麼久還沒完沒了的>..人員一個美工,4個程式員負責資料讀取與顯示.,..沒有互動性操作,只是靜態顯示,全是repeater(我真服了--)且所有頁面全是查詢的一個表,使用的是一個dao操作類,,,,(我真服了-若不是美工把頁面做的還像回事,真難想象它是一個讓客戶出錢的網站系統,什麼技術都沒用,建立個dao基類,再針對錶寫個類調用基類完成對資料庫操作,其他的都是頁面,超連結-----)
======
說了一堆,忘了想說啥了,,喔,架構,說下架構:<假設需求已經很明確了>::綜合一些經曆,似乎整個項目中技術上最有含金量的就是:架構的搭建了.<架構丫,架構( ⊙ o ⊙ )!>
前面提到了軟體就是完成預定任務的東西..編寫軟體的語言由低級到進階,不斷提高(不斷插入中介層的過程[特殊除外])---當然還沒到理想狀態(直接用語言描述下需求,由代碼產生器啪一下一個新軟體誕生了...[超低需求除外])---在現有狀態下,還得一點點處理,,,且需求不斷複雜,以至於一個人無法完成了,那就得合作了,合作就需要溝通了,就需要分工了,分工後怎麼能夠完美的結合,那就得建立專門的配置程式了.如何分工那就的參照一定的標準了.....哎!!標準確實挺難的呵(最好易理解,最好易複製便於通用,最好能服眾,最好大家都採用,最好都一樣)...慢慢標準出來了....mvc(挺流行的)....感覺就是個分層,插入層的過程,:::::====原本都在一個檔案下,為了分工,把呈現給使用者的頁面與幕後處理分開=====幕後處理時,分工,商務邏輯處理與資料庫操作(業務無關的)處理再分開====這樣就出現了較明顯的分工標準,及職責劃分,也便於維護,重用,及測試..各層只需考慮本層對下層介面的調用,對上層提供所需介面即可,內部實現可自行定義....搭建過程就是定義各個檔案夾以及設定檔的過程,以至於不需要考慮各層如何關聯,只考慮自身即可.....如:java的ssh.架構搭建好以後應該有這樣的狀況,(理想狀況)--各個類都在sping內註冊,頁面只需要調用註冊的action,而action呢能夠完美地調用service得到想要的結果,,service內部做資料處理並調用dao完成對資料庫操作...各人只需在自己負責的模組下建立檔案夾以及對應類即可.<>
做web類,項目..避免不了,總得有頁面,頁面總不能太單一,那就得美工了(什麼css,js,html相關)
再然後就是代碼編寫了以及各個技術上的細節了
再者需要測試了
----- 哎,班門弄斧了,黔驢技窮了----似乎需要很多篇幅來說每一項