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

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

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

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

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

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

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

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

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

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