請教個問題，專案已經發布了，客戶在使用一段時間(1年)后，需要在原基礎上進行業務功能的擴展(這里資料庫的業務表中需要增加表欄位)，
并且客戶亦需要保留歷史業務資料的查詢與統計，基于業務功能的擴展，我現在的專案需要修改資料庫訪問模塊中的代碼、界面顯示模塊中的代碼、資料查詢模塊中的代碼、資料統計模塊中的代碼等。
這樣代碼修改量好大，有沒有好的設計方法？
各位一般如何處理這樣的業務功能修改?
是否用框架設計的軟體在進行該型別功能擴展修改時會很容易？
uj5u.com熱心網友回復：
自己先冒個泡
uj5u.com熱心網友回復：
單獨開發一個歷史資料查詢系統。當前系統繼續維護開發。
需要考慮新資料跟歷史資料是否需要一起統計。
你這種多半是專案開啟之前跟客戶沒對接好，所以要常與用戶溝通，先把需求設計盡量做足做好。
沒其他的好辦法，大家對你具體業務也不了解。
uj5u.com熱心網友回復：
資料庫表要增加欄位，那么界面顯示肯定要改了（比如多個按鈕、文本框），界面顯示的修改肯定也得牽連到后臺代碼（比如原先只需要根據姓名進行模糊查詢，現在多加了一個時間欄位，需要根據姓名和日期進行模糊查詢），所以資料庫表的結構修改有時候是牽一發動全身，只能一處處改uj5u.com熱心網友回復：
專案開啟之前沒有和客戶溝通好，這是扯淡的，沒法完全溝通好，客戶做一期專案的時候估計都不知道要有二期，1年后他們才想起來要做新的功能，怎么可能提前溝通好?現在能做的就是盡量不動原先的表結構和代碼,按你說的，這新功能不是對原有功能的修改，而是新的功能，那就盡量不要動原來的表結構，建新表，代碼盡量用新增類，而不是改原有的類。uj5u.com熱心網友回復：
我做過一個專案，用戶連基本的功能都反復變來變去，他們自已都沒定好，說好了一定不變的底層的業務規則，還是要改回原來的，你能怎么辦？uj5u.com熱心網友回復：
選擇框架類別庫有一點作用，但是通常是比較初級的程式員才主要依靠的作用，一旦專案復雜、有創造性、比較多自己的核心技術，那么這條路其實也就不是什么主要的選擇不大了。回到編程本質，編程目的不是為了發布，編程的目地是為了通過測驗。而測驗的目的才是發布。發布以及培訓的目地才是讓用戶良好地使用。那么當你感覺“作業量好大”的時候，往往是因為你沒有一套長期積累的自動化測驗機制，無法保證產品質量。
撰寫軟體最基本的專業特征，初級的就要寫大量的斷言，高級的就是要寫幾百個甚至上千個自動測驗。每當程式代碼修改了，就要跑一下自動測驗，每天重復、隨機、并發地測驗幾萬次，才敢提交發布。這樣即使突發重大的事件需要修改代碼中突發的幾百個甚至上千個bug，也會非常從容。你看一個程式員此時是否有勇氣，就知道是業余的還是職業的了。
uj5u.com熱心網友回復：
“盡量不動原先的表結構和代碼”說實在的，這對程式員來說也許算是比較高級的東西，對用戶和戰略投資人來說則是糞土！程式員不能永遠活在自己的孤芳自賞的象牙塔中，而是要跟自己所服務的組織保持平衡。而這種平衡就是用需求檔案和作業日志的具體化、可操作化、精煉無廢話、可以作為法律糾紛的證據來保證的。程式員又一大優勢，未來社會幾乎99%的行業的人都會失業，但是程式員的需求越來越多，這就是程式員的優勢。所以程式員要學會把需求寫成測驗代碼，學會測驗驅動開發，不要永遠只做最低級的拼湊“別人拿來的代碼”的小工。uj5u.com熱心網友回復：
代碼量大？客戶給你多長時間？給你多少錢？比如：給你一年時間，100萬，一個人的作業量，這樣代碼量大嗎？程式員要先講錢，并且付出要和錢成正比，要讓自己感覺爽才有動力做事情。將客戶的資料庫復制過來，然后在原來的資料庫升級，每一次對資料庫更改或者增加什么洗掉什么，用東東記錄下來，然后程式升級完了，再拿你記錄的東東再更改客戶的資料庫，資料庫改完了，然后再升級程式。
uj5u.com熱心網友回復：
首先代碼肯定會改的，越復雜的專案修改的地方越多，選擇框架有用那是肯定的，但對于大型專案來說，用處不大，因為這框架也是人提出設計出來的，對于大專案來說都有自己的框架，這套框架是基于自己專案的業務邏輯來的。uj5u.com熱心網友回復：
基本原則就是不修改老代碼，可以用繼承的方式增加新類處理轉載請註明出處，本文鏈接：https://www.uj5u.com/net/19469.html
標籤：分析與設計