很多人在進行軟件開發(fā)和軟件維護的時候會發(fā)現(xiàn)一個嚴重的問題，需要對軟件代碼進行重構，讓系統(tǒng)更加穩(wěn)定的運行。
成都創(chuàng)新互聯(lián)公司是一家專注于網(wǎng)站建設、做網(wǎng)站與策劃設計,南湖網(wǎng)站建設哪家好?成都創(chuàng)新互聯(lián)公司做網(wǎng)站,專注于網(wǎng)站建設十多年,網(wǎng)設計領域的專業(yè)建站公司;建站業(yè)務涵蓋:南湖等地區(qū)。南湖做網(wǎng)站價格咨詢:028-86922220
那么在進行代碼重構的過程中有哪些常見的問題呢？下面遼寧電腦培訓為大家具體介紹。
1、任務管理問題和離線模式問題。
我們的線服務是眾所周知的,我們往往容易受到網(wǎng)上商業(yè)邏輯守則的約束,這些守則往往忽略了在線規(guī)則的管理和維護。
然而,在現(xiàn)場,在線規(guī)則和守則也很重要。
因此,遼寧IT培訓發(fā)現(xiàn)有效維護守則和離線任務是我們面臨的問題。
2、特征日志問題在推薦系統(tǒng)中，我們經(jīng)常遇到特征的拼寫和特征的“穿越時間”問題。
特征時間穿越是指，使用在模型訓練時無法預測無法得到的“未來信息”，這主要是因為訓練label與特征的連接時間不嚴格。
3、服務監(jiān)制問題一個通用的推薦系統(tǒng)應當在基礎監(jiān)視上盡可能通用地再利用，具體的業(yè)務應當減少對監(jiān)視的開發(fā)量，并且遼寧IT培訓發(fā)現(xiàn)這樣更加方便業(yè)務定位問題。
4、離線任務的管理問題在包含推薦系統(tǒng)的算法方向上，需要構建大量的脫機任務，支持各種數(shù)據(jù)計算業(yè)務，需要支持模型的定時訓練工作。
但是在實際工作中，我們往往忽略了離線任務代碼管理的重要性，當時間變長時，遼寧電腦培訓發(fā)現(xiàn)各種數(shù)據(jù)和特征的質量往往是不能保證的。
代碼重構（英語：Code refactoring）重構就是在不改變軟件系統(tǒng)外部行為的前提下，改善它的內部結構。
軟件重構需要借助工具完成，重構工具能夠修改代碼同時修改所有引用該代碼的地方。在極限編程的方法學中，重構需要單元測試來支持。
java重構：指程序員對已有程序在盡量不改變接口的前提下，進行重新編寫代碼的工作，一般有以下幾方面：
1、去除已知bug。
2、提高程序運行效率。
3、增加新的功能。
重構舉例：（簡化代碼、提升效率）
重構前：
if(list != null list.size() 0){
for(int i = 0; i list.size(); i++){
//skip...
}
}
重構后
if(list != null){
for(int i = 0, len = list.size(); i len; i++){
//skip...
}
}
何時著手重構（Refactoring）
新官上任三把火，開始一個全新??、腳不停蹄、加班加點，一支聲勢浩大的千軍萬"碼"夾裹著程序員激情和扣擊鍵盤的鳴金奮力前行，勢如破竹，攻城掠地，直指"黃龍府"。
開發(fā)經(jīng)理是這支浩浩湯湯代碼隊伍的統(tǒng)帥，他負責這支隊伍的命運，當齊桓公站在山頂上看到管仲訓練的隊伍整齊劃一地前進時，他感嘆說"我有這樣一支軍隊哪里還怕沒有勝利呢？"。但很遺憾，你手中的這支隊伍原本只是散兵游勇，在前進中招兵買馬，不斷壯大，所以隊伍變形在所難免。當開發(fā)經(jīng)理發(fā)覺隊伍變形時，也許就是克制住攻克前方山頭的誘惑，停下腳步整頓隊伍的時候了。
Kent Beck提出了"代碼壞味道"的說法，和我們所提出的"隊伍變形"是同樣的意思，隊伍變形的信號是什么呢？以下列述的代碼癥狀就是"隊伍變形"的強烈信號：
·代碼中存在重復的代碼
中國有118 家整車生產(chǎn)企業(yè)，數(shù)量幾乎等于美、日、歐所有汽車廠家數(shù)之和，但是全國的年產(chǎn)量卻不及一個外國大汽車公司的產(chǎn)量。重復建設只會導致效率的低效和資源的浪費。
程序代碼更是不能搞重復建設，如果同一個類中有相同的代碼塊，請把它提煉成類的一個獨立方法，如果不同類中具有相同的代碼，請把它提煉成一個新類，永遠不要重復代碼。
·過大的類和過長的方法
過大的類往往是類抽象不合理的結果，類抽象不合理將降低了代碼的復用率。方法是類王國中的諸侯國，諸侯國太大勢必動搖中央集權。過長的方法由于包含的邏輯過于復雜，錯誤機率將直線上升，而可讀性則直線下降，類的健壯性很容易被打破。當看到一個過長的方法時，需要想辦法將其劃分為多個小方法，以便于分而治之。
·牽一毛而需要動全身的修改
當你發(fā)現(xiàn)修改一個小功能，或增加一個小功能時，就引發(fā)一次代碼地震，也許是你的設計抽象度不夠理想，功能代碼太過分散所引起的。
·類之間需要過多的通訊
A類需要調用B類的過多方法訪問B的內部數(shù)據(jù)，在關系上這兩個類顯得有點狎昵，可能這兩個類本應該在一起，而不應該分家。
·過度耦合的信息鏈
"計算機是這樣一門科學，它相信可以通過添加一個中間層解決任何問題"，所以往往中間層會被過多地追加到程序中。如果你在代碼中看到需要獲取一個信息，需要一個類的方法調用另一個類的方法，層層掛接，就象輸油管一樣節(jié)節(jié)相連。這往往是因為銜接層太多造成的，需要查看就否有可移除的中間層，或是否可以提供更直接的調用方法。
·各立山頭干革命
如果你發(fā)現(xiàn)有兩個類或兩個方法雖然命名不同但卻擁有相似或相同的功能，你會發(fā)現(xiàn)往往是因為開發(fā)團隊協(xié)調不夠造成的。筆者曾經(jīng)寫了一個頗好用的字符串處理類，但因為沒有及時通告團隊其他人員，后來發(fā)現(xiàn)項目中居然有三個字符串處理類。革命資源是珍貴的，我們不應各立山頭干革命。
·不完美的設計
在筆者剛完成的一個比對報警項目中，曾安排阿朱開發(fā)報警模塊，即通過Socket向指定的短信平臺、語音平臺及客戶端報警器插件發(fā)送報警報文信息，阿朱出色地完成了這項任務。后來用戶又提出了實時比對的需求，即要求第三方系統(tǒng)以報文形式向比對報警系統(tǒng)發(fā)送請求，比對報警系統(tǒng)接收并響應這個請求。這又需要用到Socket報文通訊，由于原來的設計沒有將報文通訊模塊獨立出來，所以無法復用阿朱開發(fā)的代碼。后來我及時調整了這個設計，新增了一個報文收發(fā)模塊，使系統(tǒng)所有的對外通訊都復用這個模塊，系統(tǒng)的整體設計也顯得更加合理。
每個系統(tǒng)都或多或少存在不完美的設計，剛開始可能注意不到，到后來才會慢慢凸顯出來，此時唯有勇于更改才是最好的出路。
·缺少必要的注釋
雖然許多軟件工程的書籍常提醒程序員需要防止過多注釋，但這個擔心好象并沒有什么必要。往往程序員更感興趣的是功能實現(xiàn)而非代碼注釋，因為前者更能帶來成就感，所以代碼注釋往往不是過多而是過少，過于簡單。人的記憶曲線下降的坡度是陡得嚇人的，當過了一段時間后再回頭補注釋時，很容易發(fā)生"提筆忘字，愈言且止"的情形。
曾在網(wǎng)上看到過微軟的代碼注釋，其詳盡程度讓人嘆為觀止，也從中體悟到了微軟成功的一個經(jīng)驗。
相信大家在開發(fā)軟件和進行軟件維護的時候也會發(fā)現(xiàn)，有時候我們會針對一些軟件的功能進行代碼重構來讓系統(tǒng)運行更加的穩(wěn)定。
今天天津java培訓就一起來了解一下，在代碼重構的過程中都會遇到哪些問題。
1、離線任務和模型的管理問題。
我們做在線服務的都有體會，我們經(jīng)常容易對線上業(yè)務邏輯代碼更關注一些，而往往忽視離線代碼任務的管理和維護。
但離線代碼任務和模型在推薦場景中又至關重要。
因此如何有效維護離線代碼和任務，是我們面臨的一個問題。
2、特征日志問題。
在推薦系統(tǒng)中，我們常常會遇到特征拼接和特征的『時間穿越』的問題。
所謂特征時間穿越，指的是模型訓練時用到了預測時無法獲取的『未來信息』，這主要是訓練label和特征拼接時時間上不夠嚴謹導致。
如何構建便捷通用的特征日志，減少特征拼接錯誤和特征穿越，是我們面臨的二個問題。
3、服務監(jiān)控問題。
一個通用的推薦系統(tǒng)應該在基礎監(jiān)控上做到盡可能通用可復用，減少具體業(yè)務對于監(jiān)控的開發(fā)量，并方便業(yè)務定位問題。
4、離線任務和模型的管理問題。
在包括推薦系統(tǒng)的算法方向中，需要構建大量離線任務支持各種數(shù)據(jù)計算業(yè)務，和模型的定時訓練工作。
但實際工作中，我們往往忽略離線任務代碼管理的重要性，當時間一長，各種數(shù)據(jù)和特征的質量往往無法保證。
為了盡可能解決這樣的問題，我們從三方面來做，一，將通用推薦系統(tǒng)依賴的離線任務的代碼統(tǒng)一到一處管理;二，結合公司離線任務管理平臺，將所有任務以通用包的形式進行管理，這樣保證所有任務的都是依賴新包;三，建設任務結果的監(jiān)控體系，將離線任務的產(chǎn)出完整監(jiān)控起來。
5、特征日志問題。
AndrewNg之前說過：『挖掘特征是困難、費時且需要專業(yè)知識的事，應用機器學習其實基本上是在做特征工程。
』我們理想中的推薦系統(tǒng)模型應該是有干凈的RawData，方便處理成可學習的Dataset，通過某種算法學習model，來達到預測效果不斷優(yōu)化的目的。
但現(xiàn)實中，我們需要處理各種各樣的數(shù)據(jù)源，有數(shù)據(jù)庫的，有日志的，有離線的，有在線的。
這么多來源的RawData，不可避免的會遇到各種各樣的問題，比如特征拼接錯誤，特征『時間穿越』等等。
這里邊反應的一個本質問題是特征處理流程的規(guī)范性問題。
那么我們是如何來解決這一點呢，先，我們用在線代替了離線，通過在線落特征日志，而不是RawData，并統(tǒng)一了特征日志Proto，如此就可以統(tǒng)一特征解析腳本。
重慶分公司
重慶分公司
