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

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

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

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

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

4，個人原因是最主要的原因，首要要有分塊思維，也可以說是oop思維，這種思維是在實戰中養成的，這個是要必定時刻的。不要為了急著去完結功用而忽視了整體考慮。假設來了一個新需要，我會首要考慮怎么完結這個需求，有了思路后，我也不會急著去開發這個功用，我還會在考慮這個功用模塊，會不會用在其他當地？假設其他當地用，怎么樣讓其他當地用著更便利。我會讓所以調用這個功用模塊的當地，接口只要一個。然后我才會著手去開發。還有一點，不要信任需求定下來就不會變了，不會的。人的想法許多，開發代碼的時候，這一點也要考慮進去，所以統一的接口在需求變化時，我只要修正一個當地，其他當地都可以改掉。假設這樣考慮了，前期開發時，時刻會多一點，可是后期保護就快許多。

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

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

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

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

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

網頁標題：為什么代碼保護，重構比較難
本文URL：http://m.kartarina.com/news48/70248.html

成都網站建設公司_創新互聯，為您提供外貿建站、移動網站建設、Google、網站設計公司、網站收錄、網站設計

廣告

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