十個月的時間,輾轉六七個專案,雖以普通開發人員的視角管中窺豹,但專案中的問題弊病依然可見一斑.從幾個方面寫寫自己的見聞和淺析吧
1. 人天問題
軟體開發專案最大的成本就是人.人天預估的高了不容易中標,人天預估的低了又難以保證質量,其中的權衡拿捏不是我一個小技術能涉及的.但是真正落地實際情況并不理想,在許多專案的承包上,專案預估的人天與實際所需嚴重不符,甚至有專案剛開始做需求分析的時候,工期已經過去了一半多.所以即使已經瘋狂壓榨開發人員(個別專案整月整月的加班到12點),很多專案還是不得不延期,倉促趕工的專案質量不行與延期之后帶來的成本提升都在降低甲方的滿意度,同時也降低了乙方的利潤
2. 業務能力不足
多數專案中缺少能從整體角度輔助客戶完成業務功能設計的出色業務顧問.很多專案中,甲方業務需求自己想方案完成方案設計,乙方業務能起到的作用小.
3. 盲目推行新模式
趕鴨子上架推行DDD,領域驅動設計的確要求與業務加強溝通,雙方共同設計出領域模型.但是在雙方對領域驅動設計都缺乏了解的情況下強行推進DDD很容易弄巧成拙.
一方面業務人員容易落入原本瀑布式開發的窠臼中(視各種需求分析檔案\開發檔案為專案進度的里程碑)(這也有甲方的領導很難轉變思維的原因:有時候業務角色接受了新型的軟體開發方法,而他們的領導卻不能緊跟這種變化)
另一方面,DDD要求技術人員也要轉變思維,系統的設計,尤其domain層的實作,與原本的mvc模式完全不同.而且,領域模型驅動代碼的實作要求保證領域模型的設計是正確的.否則我們無法確定領域模型可以解決領域中的核心問題
這就導致,甲方因為缺乏專案產出(特別是在專案前期,DDD因為重產品而輕檔案,缺少能向甲方說明的專案進度的標的)會開始懷疑乙方的進度,而雙方對領域的不擅長導致遲遲不能推演出正確領域模型設計又繼續加重這種不信任,然后因為時間有限,倉促趕出一個領域模型并進行開發,以至于模型無法符合實際業務需要反而增加了開發難度...而專案的延期又會導致甲方進一步懷疑乙方能力...
總而言之,我認為在實施DDD的程序中,我們缺乏一個領域專家的角色帶領我們向DDD過渡.
4. 技術與業務之間的隔閡
在專案中,業務在完成了專案前期業務模型設計之后的主要角色就變成了監工和功能測驗人員.
許多業務顧問除了催進度之外就只會甩鍋,說什么什么問題是開發的問題,是他們寫的bug.而技術人員同樣會把鍋甩給其他:比如設計的時候沒寫清楚,比如這個代碼不是我寫的而是之前的人寫的等等.
互相甩鍋導致乙方內部都無法通力合作,大把的時間用來互相扯皮推脫任而不是解決問題.
5. 規范與標準化的缺失
-
代碼倉庫管理分散,各個專案組有各個專案組的svn服務器.雖然很早就在客戶部署了統一的gitlab服務,但是專案遷移缺乏動力,進展緩慢
-
專案檔案管理混亂,這個比代碼管理還要混亂,代碼最差的情況也至少有svn中央倉庫,而檔案要么直接缺失,要么就只保存在個別幾個人的本地電腦中.
-
專案檔案沒有標準化,每個專案的檔案都使用不同的模板,而且當代碼功能變更時,檔案通常沒有跟著變更.這給后續接手運維或者升級的人員帶來了非常多的困難.
-
缺乏代碼審計流程.大多數專案沒有代碼review環節,代碼質量完全依賴開發人員自查,關于安全性的缺陷檢查與編程規范基本無從談起.
-
缺乏測驗,大多數專案沒有規范的測驗流程,大多數開發人員不寫測驗類.單元測驗無從談起.測驗人員通常由甲乙雙方的業務人員兼任,通常也只是在頁面上點點點的黑盒測驗.
-
缺乏開發規范,包\類\方法\欄位的命名沒有規則,資料庫設計欄位命名隨意,對如何拆分資料表缺乏清楚的邏輯.
6.人員變動大
專案成員表來源復雜,組織結構復雜,專案成員來自公司內不同的事業部,直接匯報的領導各自不同.而且,因為壓力福利種種原因,專案內持續有人離職,所以專案組不得不從公司的其他部門調人同時從外面招人,而新招聘的員工質量無法保證,從企業內其他部門調來的員工又因為跨部門,帶來了管理上的麻煩
嘗試的改變與局限
-
推行容器化,因為容器化的推進依賴gitlab的CI/CD功能,容器化倒逼各個專案組向統一的gitlab遷移代碼,而容器化也同時簡化了發布流程,提高了標準化.而推行容器化的局限在于以下幾點:
-
很多老專案部署在weblogic環境中,遷移難度大,而且部分老專案長期沒有技術人員維護,從接手到升級成本很高.
-
即使是使用了gitlab管理代碼的專案,但是很多專案沒有嚴格執行gitflow的流程,導致分支管理混亂,各個分支代碼不統一,部署版本不確定等等問題依然存在
-
-
推行敏捷開發,在一些新專案中使用敏捷工具如看板等推進專案進展取得了不錯的成效,客戶可以通過看板直觀的看到專案的進展,開發上的進度也更容易掌握. 局限性在于推行敏捷需要有懂敏捷的人員參與,而很多專案人員沒有敏捷的培訓對敏捷工具不熟悉,也不了解敏捷方法.這就意味著敏捷開發難以大規模推廣.(頻繁的人員更迭也加劇了這一點,因為新加入專案的同事普遍并不了解敏捷)
-
成立了測驗小組專職進行自動化測驗.這肯定是一件好事,但是目前的測驗還是依舊停留在表面,使用的是eggplant模擬點擊網頁操作的測驗工具做黑盒測驗,雖然在一定程度上節約了測驗時間成本.但是局限性依舊很大:
-
一方面是軟體學習成本高,原本做功能測驗的業務人員很難學會使用.
-
一方面這種測驗依舊是黑盒測驗,而且難以測驗邊際值,只能測驗正確的流程能否完整執行. 另外據我了解,測驗人員在專案中地位不高,而且通常還需要兼職做開發作業.
-
-
安排開發人員互審代碼. 這項作業初衷很好,但是實際執行中,代碼審計的優先級遠遠低于功能開發,在開發進度壓力大的情況下沒有人在乎功能是如何實作的,因為能按期交付就已經用盡全力了.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/224493.html
標籤：其他
上一篇：idea Maven專案找不到相關依賴包（紅色波浪線）
下一篇：測驗設計的初探