Hiç girilmemiş gibi görünen bir kod parçasını güvenle nasıl silersiniz?

Gereksiz görünen bazı kodlar buldunuz ve derleyici bunu fark etmedi. Bu kodu silmenin regresyona neden olmayacağından emin olmak için (veya olabildiğince yakınına) ne yapacaksınız?

İki fikir akla geldi.

1. "Basitçe", kodun çalışması gerektiği gibi olup olmamasına bağlı olarak kesinti kullanın. Bununla birlikte, bazen bu, ciddi bir iş getirisi olmadan, riskli ve zaman alıcı bir iş olabilir, riskli olabilir (değerlendirmeniz hataya açıktır).

2. Günlük kaydını bu kod bölümüne yerleştirin ve uygulamada ne sıklıkla girildiğini görün. Yeterli uygulamadan sonra, kodu kaldırmak güvenli olduğundan emin olmanız gerekir.

Daha iyi bir fikir veya kanonik bir yaklaşım gibi bir şey var mı?

% 100 ünite test kapsamımın olduğu mükemmel fantastik dünyamda sadece sildim, ünite testlerimi yaptım ve hiçbir test kırmızıya dönmediğinde, bunu taahhüt ederim.

Fakat ne yazık ki her sabah uyanmalı ve birçok kodun birim testinin olmadığı ya da orada olduklarında, olası her olası olayı gerçekten kapsayacaklarına güvenilemediği sert gerçeklerle yüzleşmeliyim. Bu yüzden riski / ödülü göz önünde bulundurarak sonuçta buna değmeyeceği sonucuna varabilirim:

• Ödül: Kod gelecekte bakımı biraz daha kolaydır.
• Risk: Aklıma gelmeyen bazı durumlarda kodları kırın, en azından beklediğimde bir olaya neden oldum ve hatalı olduğum için çünkü kod kalitesini OKB yerine getirmek zorunda kaldım ve işletme değeri algılanamayan bir değişiklik yapmak zorunda kaldım. Kendisi kodlayıcı olmayan herhangi bir paydaş için.

Bu sürecin iki yarısı var. Birincisi, kodun gerçekten ölü olduğunu onaylamaktır. İkincisi, yanlış olmanın maliyetlerini anlamak ve doğru şekilde azaltıldığından emin olmak.

Buradaki pek çok cevabın, eski yarıya harika çözümleri var. Statik analizörler gibi araçlar ölü kodu tanımlamak için mükemmeldir. grepBazı durumlarda arkadaşın olabilir. Sık sık attığım alışılmadık bir adım, kodun asıl amacının ne olduğunu belirlemeye çalışmak. “X artık ürünümüzün bir özelliği değildir ve Y kod özelliği X'i destekleyecek şekilde tasarlanmıştı” diyerek çok daha kolay, “Y kod kodu için hiçbir amaç göremiyorum” demek.

İkinci yarı, kodu kaldırmanız gerekip gerekmediği gibi herhangi bir ızgara kilidini kırmak için önemli bir adımdır. Cevabı yanlış anlamanın ne anlama geldiğini anlamalısınız. Eğer cevabı yanlış alırsanız insanlar ölecekse, dikkat edin! Belki de kod hırsızlığının zamanla geliştiğini kabul etmenin tam zamanıdır ve bunun yerine kendinize daha fazla mazeret yazmamaya çalışın. İnsanlar ölmeyecekse, kullanıcılarınıza ne kadar affedileceğini kendinize sorun. Bir şeyleri kırdıysanız ve müşteri ilişkilerinizi sürdürürseniz onlara bir düzeltme gönderebilir misiniz? Bu gibi sorunları bulmak için ödenen bir soru-cevap ekibiniz var mı? Bu tür sorular, silme tuşuna basmadan önce ne kadar emin olmanız gerektiğini anlamak için çok önemlidir.

Yorumlarda, rmun, kodu çıkarmadan önce kodun asıl amacını anlama kavramının mükemmel bir şekilde ifade edildiğine işaret etti. Alıntı şimdi Chesterton Çit olarak bilinir . Doğrudan bir yorumda alıntı yapılamayacak kadar büyük olsa da, burada doğru şekilde alıntı yapılmasını hak ettiğini düşünüyorum:

Bir şeyleri reform etmek konusunda, onları deforme etmekten farklı olarak, sade ve basit bir ilke vardır; muhtemelen bir paradoks olarak adlandırılacak bir ilke. Böyle bir durumda belirli bir kurum ya da yasa vardır; Diyelim ki, sadelik uğruna, bir yol boyunca dikilen bir çit veya kapı. Daha modern reformcu türü buna şiddetle karşı çıkmakta ve “Bunun kullanımını görmüyorum; açıklığa kavuşturalım. ”Daha akıllı bir reformcu türünün cevap vermekte fayda sağlayacağı şey:“ Eğer kullanımını görmüyorsanız, kesinlikle temizlemenize izin vermeyeceğim. Git ve düşün. O zaman, geri dönüp, bana kullanımını gördüğünüzü söylediğinizde, onu yok etmenize izin verebilirim.

Ayrıca grep, koddaki işlev / sınıf adı için de eğilimim vardır; bu, örneğin bir yorumda veya bir belge dosyasında veya bir komut dosyasında adı belirtilmiş gibi, bir kod çözümleyicisinin sağlayamayacağı bazı ek yararlar sağlayabilir. Grep'i kaynak ağacındaki dosyalar üzerinde çalıştırıyorum ve sonucu bir dosyada saklıyorum; genellikle sonuç yoğunlaşmış bir bilgi verir: dosya adı / yolu, satır numarası ve adın karşılaştığı satır. Fonksiyon / sınıfın nerede çağrıldığı veya herhangi bir anlamsal anlamı olmadan bahsettiği ile ilgili ipuçları verebilir. ) ve dosya uzantılarına bakılmaksızın. Kesinlikle nihai çözüm değil, bir analize güzel bir katkı.

• Ölü görünen kodu tanımlayın (statik analiz, vb.).
• Öldüğü iddia edilen her kod için bir günlük mesajı ekleyin . İşlevler / yöntemlerle kolaydır; Sabitler gibi statik üyelerle daha zorlu. Bazen kodu yalnızca kullanımdan kaldırılmış olarak işaretleyebilirsiniz ve çalışma zamanı sizin için otomatik olarak bir ileti kaydeder. Kodu aksi halde sağlam bırakın.
  • Ölü modül yüklendiğinde bir mesaj günlüğü kaydedin: çoğu dilde yükleme sırasında statik başlatmayı çalıştırmanın bir yolu vardır, bu da piggy destekli olabilir.
  • Günlük mesajınızın makul bir yığın izi içerdiğinden emin olun, böylece iddia edilen ölü kodu neyin adlandırdığını anlayın .
• Değiştirilen kodu tüm test takımlarınızda çalıştırın. Test takımlarınız ayrıca bir gece yarısını geçmek, çeyrek tur çevirmek, bir yıl çevirmek, vb. Özel zamanlar için test etmelidir. Günlüklere bakın, ne öldüğünü anlamanızı güncelleyin. Ünite testlerinin özel olarak ölü kodu test edebileceğini, diğer ünite testleri ve entegrasyon testlerinin ona dokunmadığını unutmayın.
• Üretimde değiştirilmiş kodu birkaç hafta çalıştırın. Her periyodik işlemin, ayda bir kez yapılan ETL cron işleri gibi, bu dönemde gerçekleştirildiğinden emin olun.
• Günlüklere bak. Kaydedilen herhangi bir şey aslında ölü değildir. Çağrı grafiğinin ölü kodun geri kalanı boyunca geçişli olarak kapatılması da , henüz çağrılmamış olsa bile potansiyel olarak ölü değildir. Analiz et. Belki bazı şubeler güvenli bir şekilde ölmüştür (örneğin, artık tükenmiş bir hizmetin API'si ile çalışmak), bazıları henüz değildir. Belki de bütün bir modül / sınıf sadece içinde tanımlanmış bir sabit için yüklenir ve onu kolayca kullanabilirsiniz.
• Geride kalanlar güvenli bir şekilde ölüdür ve çıkarılabilir.

Bahsedilen cevapların yanı sıra, kodu birkaç sürümde yinelemeli olarak kaldırabilirsiniz.

İlk versiyonda, kod bloğu hala çalışıyorken bir kullanımdan çıkarma uyarısı yapabilirsiniz. Bundan sonraki sürümde kod bloğunu kaldırabilir ancak kullanıcılara bu özelliğin kullanım dışı kalmasına ve artık kullanılamamasına izin veren bir hata mesajı bırakabilirsiniz. Son versiyonda, kod bloğunu ve mesajları kaldıracaksınız.

Bu, son kullanıcılar için uyarı vermeden öngörülemeyen işlevselliği belirlemeye yardımcı olabilir. En iyi senaryoda, kod gerçekten hiçbir şey yapmaz ve olan tek şey, gereksiz kodun kaldırılmadan önce birkaç sürümde tutulmasıdır.

Pek çok insan, kullanılmadığını ispatlayamazsanız yapılacak "güvenli" şeyin kodu bırakmak olduğunu öne sürüyor.

Ancak kod bir varlık değildir, bir sorumluluktur.

Neden önemli olduğunu ve testlerine işaret etmediğiniz sürece, "daha güvenli" bir alternatif onu silmek için çok iyi olabilir.

Hala emin değilseniz, en azından zombi kodunu çalıştırmak için testler eklediğinizden emin olun.

Söz konusu kodu tamamen yok saymak için yazılımınızın yürütme yolunu değiştirmek için özellik geçişlerini kullanabilirsiniz.

Bu sayede değişikliklerinizi kullanılmayan kodlar ve geçişler kapalıyken güvenle yapabilirsiniz. Kodla ilgili bazı önemli hataları fark ederseniz, açma / kapatma düğmesini tekrar açın ve olası yolu araştırın.

Bu yaklaşım, uzun süre boyunca herhangi bir sorun yaşamadığınızda ve onu tekrar konuşlandırılmadan canlı duruma getirme becerisi görürseniz size güven vermelidir. Bununla birlikte, daha iyi bir yol, kullanılıp kullanılmadığına dair daha fazla kanıt sağlayacak olan söz konusu alanın çevresinde ekstra günlük kaydı ve test kapsamı uygulamak olacaktır.

Burada geçişler hakkında daha fazla bilgi edinin: https://martinfowler.com/articles/feature-toggles.html

Elbette statik analiz ... ve güzel olan, herhangi bir yeni araca ihtiyacınız yok; Derleyiciniz ihtiyacınız olan tüm statik analiz araçlarına sahiptir.

Sadece yöntemi (örn değişikliğinin adını değiştirmek DoSomethingiçin DoSomethingX) ve daha sonra bir yapı çalıştırın.

Eğer derlemeniz başarılı olursa, yöntem açık ki hiçbir şey tarafından kullanılmıyor. Silmek güvenli.

Yapmanız başarısız olursa, onu çağıran kod satırını yalıtın ve ifnasıl tetikleneceğini belirlemek için aramayı hangi ifadelerin çevrelediğini kontrol edin . Tetikleyen herhangi bir olası veri kullanım durumu bulamazsanız, güvenle silebilirsiniz.

Silme konusunda gerçekten endişeleniyorsanız, kodu saklamayı ama bir ObsoleteAttribute (veya kendi dilinizde) ile işaretlemeyi düşünün . Bir sürüm için böyle serbest bırakın, sonra vahşi ortamda herhangi bir sorun bulunmadığında kodu kaldırın.

• Bunun ölü kod olup olmadığını kontrol etmek için bir kod analizcisi kullanmaya başlarım
• Testlerimi kontrol etmeye ve koda ulaşmaya çalışıyorum. Bir sınama durumu içindeki koda erişemezsem, ölü kod olabilir
• Kodu kaldırır ve bunun yerine bir istisna atardım. Bir sürüm için istisna etkinleştirilir ve ikinci sürümde istisna kaldırılabilir. Güvende olmak için, bir müşteri istisna olduğunda, orijinal kodu etkinleştirebilmek için bir acil durum bayrağı (Java'ya, bir sistem mülkü) yerleştirin. Böylece istisna devre dışı bırakılabilir ve orijinal kod üretim ortamında etkinleştirilebilir.

Ulaşılamaz kodun kaldırılması

İlkeli statik olarak yazılmış bir dilde, kodun gerçekten ulaşılabilir olup olmadığını her zaman bilmelisiniz: kaldır, derle, eğer bir hata yoksa ulaşılamaz.

Ne yazık ki, tüm diller statik olarak yazılmamıştır ve statik olarak yazılan dillerin hepsi ilke değildir. Yanlış gidebilecek şeyler arasında (1) yansıma ve (2) ilklenmemiş aşırı yükleme var.

Dinamik bir dil veya inceleme altındaki kod parçasına yansıma yoluyla çalışma zamanında erişilebileceği konusunda yeterince güçlü bir yansıması olan bir dil kullanıyorsanız, derleyiciye güvenemezsiniz. Bu diller Python, Ruby veya Java'dır.

Baskısız aşırı yüklemeli bir dil kullanıyorsanız, o zaman sadece bir aşırı yüklemeyi kaldırmak aşırı yükleme çözünürlüğünü sessizce başka bir aşırı yüklenmeye değiştirebilir. Bu tür bazı diller, kodun kullanımıyla ilgili bir derleme zamanı uyarısı / hatası programlamanıza izin verir, aksi takdirde derleyiciye güvenemezsiniz. Bu diller Java (kullanım @Deprecated) veya C ++ (kullanım [[deprecated]]veya = delete) içerir.

Bu nedenle, sıkı dillerle çalıştığınız için çok şanslı olmadığınız sürece (Rust akla gelir), gerçekten derleyiciye güvenerek ayağınızı çekiyor olabilirsiniz. Ve ne yazık ki, test süitleri de genellikle eksik kalıyor, bu yüzden fazla yardım da yok.

Bir sonraki bölümü işaretleyin ...

Potansiyel olarak kullanılmayan kodu kaldırma

Büyük olasılıkla, kod aslında referanslıdır, ancak pratikte referans alan kod dallarının asla alınmadığından şüphelenirsiniz .

Bu durumda, dil ne olursa olsun, kod gözle görülür şekilde erişilebilir durumdadır ve yalnızca çalışma zamanı araçları kullanılabilir.

Geçmişte, bu kodu kaldırmak için 3 aşamalı bir yaklaşımı başarıyla kullandım:

1. Alınmaması şüpheli her dalda bir uyarı girin.
2. Bir döngüden sonra, belirli bir kod parçasına girerken bir istisna / hata döndür.
3. Başka bir döngüden sonra kodu silin.

Döngü nedir? Kodun kullanım döngüsü. Örneğin, bir finansal başvuru için kısa bir aylık döngü (ay sonunda maaşlar ödeniyor) ve uzun bir yıllık döngü beklerdim. Bu durumda, yıl sonu envanteri için hiçbir uyarının yayınlanmadığını, aksi takdirde hiç kullanılmayan kod yollarını kullanabildiğini doğrulamak için en az bir yıl beklemeniz gerekir.

Umarım, çoğu uygulamada daha kısa döngü vardır.

Bir TODO yorumunu, tarih atılarak bir sonraki adıma ne zaman geçeceğinizi bildirmenizi öneririm. Ve takviminizde bir hatırlatma.

Kodları üretimden çıkarmak ev temizliği gibidir. Çatı katından bir nesne fırlattığınız an, karınız, büyük büyük annesinin üçüncü yeğeninin mezuniyet hediyesini, 1923'te ölen komşularından attığı için ertesi gün öldürecek.

Cidden, herkesin daha önce bahsettiği çeşitli araçları kullanarak imleçli analizden sonra ve daha önce bahsettiğimiz kademeli amortisman yaklaşımını kullandıktan sonra, fiili kaldırma gerçekleştiğinde şirketten ayrılabileceğinizi unutmayın. Kodun kalmasına izin verin ve yürütmesinin kaydedilmesini sağlayın ve yürütmenin herhangi bir uyarısının kesinlikle size (veya halefleriniz ve atananlarınıza) iletilmesini sağlayın.

Bu yaklaşımı takip etmezseniz, muhtemelen karınız tarafından öldürüleceksiniz. Kodu saklarsanız (her hatıra gibi), Moore yasalarının kurtarılmaya gelmesi ve "ayakkabımdaki rock" gibi görünen kodun kullandığı önemsiz disk alanı maliyetini düşürmesi gerçeğine karşı vicdanınızı dinleyebilirsiniz. Yıl ve koridorlarda birden fazla su soğutucu dedikodu ve garip bakışların merkezi olma riski yoktur.

Not: Bir yoruma cevap olarak açıklığa kavuşturmak için. Asıl soru "Tabii güvenli bir şekilde nasıl silersin .." dir. Tıpkı çöpü kazarken olduğu gibi değerli bulmak için de varsayılır. Hiçbir mantığı olan hiçbir vücut kodu atmaz ve sürüm kontrolü her geliştiricinin titremesinin bir parçası olmamalıdır.

Sorun, gereksiz olabilecek kodlarla ilgilidir. Yürütme yollarının% 100'üne ulaşmadığını garanti etmediğimiz sürece, bir kod parçasının gereksiz olduğunu asla bilemeyiz. Ve bunun, garantinin imkansız olduğu yanında yeterince büyük bir yazılım olduğu varsayılıyor. Ve yanlış soruyu okumadığım sürece, bu konuşma dizisinin tamamını ilgilendiren tek zaman, kaldırılan kodun çağrılabileceği üretim sırasındaki durumlar içindir ve dolayısıyla bir çalışma zamanı / üretim sorunumuz vardır. Sürüm kontrolü, üretim hatalarından dolayı kimseyi geride bırakmaz, bu nedenle "Sürüm Denetimi" ile ilgili yorum, soru veya orijinal noktamla ilgili değildir, yani gerçekten çok uzun bir zaman dilimi içinde gerçekten yapmaktan çekin,

IMHO, yorum gereksiz ve kaldırılması için bir adaydır.

Belki derleyici bunu farketmiştir, sadece yaygara yapmaz.

Boyuta göre ayarlanmış tam derleyici optimizasyonlarına sahip bir derleme çalıştırın. Sonra şüpheli kodu silin ve derlemeyi yeniden çalıştırın.

İkili dosyaları karşılaştırın. Aynılarsa, derleyici kodu fark etti ve sessizce sildi. Kaynaktan güvenle silebilirsiniz.

Eğer ikili dosyalar farklıysa ... o zaman sonuçsuz. Başka bir değişiklik olabilir. Hatta bazı derleyiciler ikili dosyadaki derlemelerin tarihini ve saatini de içerir (ve belki de bu kod yapılandırılabilir!)

Aslında son zamanlarda, "deleteFoo" adlı bir yöntemle tam olarak bu duruma rastladım. Kod tabanının tamamında hiçbir yerde bu yöntem yöntem bildirimi dışında bulunan bir dize bulunmuyordu, ancak yöntemin en üstünde bir günlük satırı yazdım.

PHP:

public function deleteFoo()
{
    error_log("In deleteFoo()", 3, "/path/to/log");
}

Kodun kullanıldığı ortaya çıktı! Bazı AJAX yöntemi "yöntem: delete, elem = Foo" yu çağırır, bu daha sonra birleştirilir ve call_user_func_array () ile çağrılır .

Şüpheniz olduğunda, giriş yapın! Kaydı dolu görmeden yeterli zaman geçirdiyseniz, kodu kaldırmayı düşünün. Ancak kodu kaldırsanız bile, oturumu açık bırakın ve Git'teki taahhüdü bulmayı kolaylaştırması için tarihini belirten bir yorum yapın!

Kullanın grepveya hangi araçlara önce sahipseniz kullanın, koda referanslar bulabilirsiniz. (Aslen benim talimatım / tavsiyem değil.)

Ardından, kodu kaldırma riskini almak isteyip istemediğinize veya önerimin kullanmaya gelip gelmeyeceğine karar verin:

Bir günlük dosyasına kullanıldığını yazmak için kod işlevini / bloğunu değiştirebilirsiniz. Bu tür bir mesaj günlük dosyasına "hiç" kaydedilmemişse, muhtemelen günlük kodunu kaldırabilirsiniz.

İki problem:

1. Günlüğü diğer kullanıcılardan almak. Belki program çıkışta çökecek bir genel bayrak ayarlayabilir ve kullanıcıdan hata günlüğünü size göndermesini isteyebilirsiniz.

2. Arayanın takibi. Bazı yüksek seviyeli dillerde (örn. Python) kolayca geri bildirim alabilirsiniz. Ancak derlenmiş dillerde dönüş adresini kayıt defterine kaydetmeniz ve çıkışta bir çekirdek dökümü zorlamanız gerekir (nokta 1).
   C'de, bu oldukça basit olmalıdır: koşullu bir blok kullanın (örneğin, #ifdef ... #endif), yalnızca çalışacağını bildiğinizde (ve çalıştığını test ettikten sonra) kullanın ve yalnızca dönüş adresini okuyun yığından (satır içi bir montaj dili gerektirebilir veya gerektirmeyebilir).

Argümanları günlük dosyasına kaydetmek yararlı olabilir veya olmayabilir.

Çevreleyen kodun ne yaptığını biliyorsanız, kırılıp kırılmadığını görmek için test edin . Bu, üzerinde çalıştığınız bir kod parçasını yeniden canlandırmanın en basit ve en uygun maliyetli yoludur ve üzerinde çalıştığınız kodda herhangi bir değişiklik geliştirme konusu olarak yapılması gerekir.

Öte yandan, size değil bir kod parçasını üstlenmeden ediyorsanız biliyorum ne yaptığını, bunu çıkarmayın . Önce anlayın, ardından güvenli olduğunu tespit ederseniz, yeniden canlandırın (ve yalnızca yeniden yapılandırmanın zamanınızı uygun şekilde kullanacağını belirleyebilirseniz).

Şimdi, 'ölü' olan kodun aslında hiçbir şeye bağlı olmadığı bazı durumlar olabilir (kendimle karşılaştığımı biliyorum) . Müteahhit tarafından geliştirilen ve uygulamaların teslim edilmesinden hemen sonra kullanılmayacakları için hiçbir yere uygulanmayan kod kütüphaneleri gibi (neden evet, aklımda özel bir örneğim var, nasıl bildiniz?).

Şahsen tüm bu kodları kaldırarak kurdum, ancak hafifçe almamanı tavsiye etmem çok büyük bir risk - bu değişikliğin potansiyel olarak ne kadar kod etkileyebileceğine bağlı olarak (çünkü her zaman bir şeyi göz ardı ettiğiniz potansiyel vardır) Bu eski miras kodunun kaldırılmasının başvurunuzu bozup bozmayacağını belirlemek için olağanüstü dikkatli olmalı ve agresif birim testlerini yapmalısınız.

Şimdi bütün bunlar muhtemelen, söyleniyor olmadığını denemek ve böyle bir kod kaldırmak için zaman ya da aklı değer. Başvurunuzla ilgili ciddi bir sorun olmadıkça (örneğin, uygulama şişmesi nedeniyle güvenlik taramalarını tamamlayamıyorsanız ... neden evet hala aklımda bir örneğim var?) Kodun gerçekten etkili bir şekilde çürümeye başladığı böyle bir durum.

Kısacası - kodun ne yaptığını biliyorsanız, önce onu test edin. Aksi takdirde, muhtemelen onu yalnız bırakabilirsiniz. Eğer biliyorsanız olamaz yalnız bırakın, değişim uygulamadan önce agresif değişikliği test etmek için zaman ayırmanız.

Bu durumda daima endüstri standardı olarak kabul ettiğim yaklaşımım, şu ana kadar tuhaf bir şekilde belirtilmemiştir:

İkinci bir çift göz al.

Farklı "kullanılmamış kod" türleri vardır ve bazı durumlarda silme işlemi uygun olur, bazı durumlarda onu yeniden gözden geçirmelisiniz ve yine de diğer durumlarda elinizden geldiğince kaçarsınız ve asla geriye bakmazsınız. Hangisinin olduğunu bulmanız ve bunu yapmanız için en iyiyi ikinci bir tecrübeyle eşleştirmeniz gerekir! - kod tabanına çok aşina olan geliştirici. Bu, gereksiz bir hata riskini önemli ölçüde azaltır ve kod tabanını sürdürülebilir bir durumda tutmak için gerekli iyileştirmeleri yapmanızı sağlar. Ve bunu yapmazsanız, bir noktada kod tabanına çok aşina olan geliştiricilerin tükendi.

Günlüğe kaydetme yaklaşımını da gördüm - daha kesin olmak gerekirse, günlük kodunu gördüm: 10 yıl boyunca orada kalan daha fazla ölü kod. Tüm özelliklerin kaldırılmasından bahsediyorsanız günlükleme yaklaşımı oldukça iyi, ancak yalnızca küçük bir ölü kod parçasını kaldırmıyorsanız değil.

Sorunuza verilen basit cevap, anlamadığınız kodu güvenli bir şekilde silemeyeceğinizdir; Bazı riskler olacak.

Kaçınılmaz olan bu riski en aza indirmenin en iyi yolunu seçmeniz gerekir. Diğerleri kayıt işleminden bahsetti. Günlük kaydı elbette kullanıldığını ispatlayabilir, ancak kullanılmadığını ispatlayamaz. Ölü kodla ilgili en büyük sorun devam ettiği için, ölü kod olduğundan şüphelenildiğini söyleyen bir yorum ekleyerek kurtulabilirsiniz ve üzerinde herhangi bir bakım yapmamaya başlayabilirsiniz.

Kod kaynak kontrolü altındaysa, ne zaman eklendiğini bulabilir ve nasıl çağrılacağını belirleyebilirsiniz.

Sonunda, ya onu anlarsın, yalnız bırakırsın ya da bir şansın var.

Söz konusu kodun geliştiricisinin hala kullanılabilir durumda olması durumunda, kod kaldırmayı onunla birlikte gözden geçirin . Ayrıca, koddaki yorumları okuyun .

Doğru bir açıklama, bu kodun neden eklendiğini ve hangi fonksiyon için hizmet verdiğini öğreneceksiniz. Belirli kullanım durumları için kolayca destek olabilir veya gerçekten gerekmediği takdirde yargılamak için yeterli uzmanlığınız olmayabilir. Aşırı durumda, bir C programındaki tüm boş ifadeleri kaldırabilir ve yanlış bir şey fark edemeyebilir (hafızasının tükenmesi birkaç dakika alabilir).

Kodun yazarı yanınıza geldiğinde bu gerçekten kötü bir kültürdür, ancak konuşmanız için hiçbir sebep göremezsiniz, çünkü yalnızca kötü kod yazdığından eminsiniz ve sizinki de çok mükemmel. Ve tabii ki, yorumlarda rastgele sözler yazıyor, zaman okumasına gerek yok.

Kodda yorum yazmanın en önemli sebeplerinden biri, Niçin bu şekilde uygulandığını açıklamaktır. Çözüme katılmıyor olabilirsiniz, ancak sorunu dikkate almanız gerekir.

Yazarla yapılan tartışma ayrıca, kodun kaldırılan veya hiç bitmemiş bir şeyin tarihi kalıntısı olduğunu ortaya çıkarabilir, bu nedenle silmek güvenlidir.

Markus Lausberg'in ilk görüşüne kesinlikle katılıyorum: Kod kesinlikle araçlar yardımıyla analiz edilmelidir. Maymun beyni bu tür görevlerde güvenilmez!

Çoğu standart programlama dili IDE'lerde ve “tüm kullanımlar için bulma” özelliğine sahip olan her IDE'de kullanılabilir. (Örneğin Eclipse'deki Ctrl + Shift + G)

Tabii ki: Statik analizör araçları mükemmel değildir. Söz konusu yöntemin çağrılma kararının yalnızca çalışma zamanında gerçekleştiği ve daha kısa bir süre içinde olmadığı (karmaşık dilekçeler, Yansıma yoluyla çağırır, "eval" ifadesini çağırır).

İki olasılık:

1. % 99 + test kapsamına sahipsiniz : Kodu silin ve bununla bitirin.
2. Güvenilir bir test kapsamına sahip değilsiniz: Öyleyse cevap, bir kullanımdan kaldırma uyarısı eklemektir . Yani, aklı başında bir şey yapan o yere bir kod eklersiniz (örneğin, uygulamanızın günlük kullanımıyla çelişmeyen, kolayca görülebilen bazı yerlere bir uyarı girin). O zaman birkaç ay / yıl kaynamaya bırakın. Hiçbir zaman bir olay bulamadıysanız, kullanımdan kaldırmayı istisna atan bir şeyle değiştirin. Bunun bir süre kalmasına izin verin. Sonunda, her şeyi tamamen kaldırın.