為什么代碼保護，重構比較難

代碼保護，代碼重構是件很令人不爽的一件事。以下幾種狀況，會讓代碼保護和重構變得很困難。

1，項目開端時，我們規(guī)則好一些代碼標準，在必定的標準下進行開發(fā)，可是人的思維是不一樣的，也便是說每個功用不同的人完結的邏輯或許會有這樣那樣的不同，導致了一些人不愿意去看他人代碼，要改他人代碼，首要要了解這個人其時是怎么想的，他的邏輯是怎么樣的。所以有許多人的想法是有那看他人代碼的時刻，我就從頭做好了。這種想法不要有，看他人代碼也能學到不少東西。假設都這樣想，我想冗余代碼會越來越多，后期重構會變的越來越困難。

2，做程序的一般換崗都比較頻頻，項目開端的時候，是5個人（項目開創(chuàng)人）開發(fā)的，等項目上線了，或許有人離職了。人手不夠，公司招人。項目開創(chuàng)人呢，對新招的人，不太信認，怕修正原代碼會導致上線的功用出問題，所以就出了新規(guī)則，最好不要修正上線過的程序，假設需求變化，最好從頭寫class或許是function，這樣的話，代碼會變的越來越多?；蛟S會出現(xiàn)幾個class都差不多，或許多個function的功用差不多。

3，數(shù)據(jù)庫冗余字段，冗余表過多，也會讓代碼保護變的十分困難。由于功用優(yōu)化，或許新需求，導致原有表結構根本不能滿足新需求，這個時候，就會去表里增加字段，或許掛接另一個表，長期以往，數(shù)據(jù)庫變的很臃腫，數(shù)據(jù)庫一大，代碼必定就不用說了，程序都是圍繞著數(shù)據(jù)來的，冗余字段，冗余表都要保護的，不然數(shù)據(jù)就不統(tǒng)一了。必要的冗余可以削減數(shù)據(jù)庫查詢，假設過多，只會事得其返。所以在修正數(shù)據(jù)庫時更要考慮清楚，考慮將來數(shù)據(jù)庫和代碼要重構的狀況。

4，個人原因是最主要的原因，首要要有分塊思維，也可以說是oop思維，這種思維是在實戰(zhàn)中養(yǎng)成的，這個是要必定時刻的。不要為了急著去完結功用而忽視了整體考慮。假設來了一個新需要，我會首要考慮怎么完結這個需求，有了思路后，我也不會急著去開發(fā)這個功用，我還會在考慮這個功用模塊，會不會用在其他當?shù)?？假設其他當?shù)赜?，怎么樣讓其他當?shù)赜弥憷?。我會讓所以調用這個功用模塊的當?shù)?，接口只要一個。然后我才會著手去開發(fā)。還有一點，不要信任需求定下來就不會變了，不會的。人的想法許多，開發(fā)代碼的時候，這一點也要考慮進去，所以統(tǒng)一的接口在需求變化時，我只要修正一個當?shù)兀渌數(shù)囟伎梢愿牡?。假設這樣考慮了，前期開發(fā)時，時刻會多一點，可是后期保護就快許多。

小結一下，有了上面4點，重構數(shù)據(jù)庫，重構代碼將是必然的

1，人的思維不或許一樣，我們都在盡量往一處想，可是總會有這樣，那樣的不同。

2，急于要完結功用，而不深入了解他人代碼。研討他人代碼不如從頭開發(fā)快，這種思維欠好。

3，數(shù)據(jù)庫冗余，這個我個人覺得必然會出現(xiàn)的，一個項目做大，做強，必定是在不斷的生長，生長過程中，數(shù)據(jù)庫不或許是一成不變的。

4，短少分塊思維，我覺得一個項目，便是許多功用獨立的小塊通過必定線串起來的，代碼重構也便是把這些小塊的從頭組合，當然各個小塊，在重構前后完結的功用會不一樣，但它還是為了完結必定的功用，只不過由舊變新罷了。

網(wǎng)頁標題：為什么代碼保護，重構比較難
本文URL：http://muchs.cn/news48/70248.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供外貿建站、移動網(wǎng)站建設、Google、網(wǎng)站設計公司、網(wǎng)站收錄、網(wǎng)站設計

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)