Yedekli dosyaları doğrudan VCS'den silmemek, ilk önce bunları yorumlarla “silinmek” olarak işaretlemek kötü bir uygulama mıdır?


53

Sürüm kontrolünden silinmesi gereken kaynak dosyalarla uğraşmanın kötü bir uygulama olarak kabul edilip edilemeyeceğini bilmek istedim.

Bu örneğe dayanarak size açıklamak istiyorum:

Son zamanlarda çok kızmıştım, çünkü Java sınıflarını temelde ölü kod olan bir programda sıkıcı bir şekilde çözmek zorunda kaldım, ancak hiçbir yerde belgelenmedi ve bu Java sınıflarında yorumlanmadı. Tabii ki silinmeleri gerekiyordu ama bu kadar fazla şeyi silmeden önce elimde - garip diyebilirim - alışkanlık:

Bu tür gereksiz dosyaları derhal SVN-> Delete ile silmiyorum (tercih ettiğiniz sürüm kontrol sisteminizin sil komutuyla değiştirin) ama bunun yerine bu dosyalara (başından ve altbilgiden bahsettim) yorumlar yazdım. silinecek + ismim + tarih ve ayrıca - daha önemlisi - NEDEN SİLİLDİ (benim durumumda, çünkü onlar öldü, kodları karıştırıyorlardı). Sonra onları kontrol edip sürüm kontrolüne adadım. Bir dahaki sefere projede sürüm kontrolüne bir şey teslim etmem / kontrol etmem gerektiğinde, SVN-> Sil tuşlarına basarım ve sonra Sürüm Kontrolünde silinirler - yine de elbette revizyonlar yoluyla geri yüklenebilirler ve bu yüzden bu alışkanlığı benimsedim.

Bunları hemen silmek yerine neden yapıyorsunuz?

Sebebim şu ki, en azından bu gereksiz dosyaların bulunduğu son revizyonda açıkça belirteçlere sahip olmak istiyorum, neden silinmeyi hak ettiklerini. Onları hemen silersem silinirler ancak neden silindikleri hiçbir yerde belgelenmez. Bunun gibi tipik bir senaryodan kaçınmak istiyorum:

"Hmm ... bu dosyalar neden silindi? Daha önce de iyi çalıştım." ('Geri alma' tuşuna basar -> sonra geri dönen adam sonsuza dek gider veya gelecek haftalarda kullanılamaz hale gelir ve bir sonraki devralan bu dosyaların ne hakkında olduğunu benim gibi sıkıcı bir şekilde bulmak zorundadır)

Ancak bu dosyaların işlem iletilerinde neden silindiğini not etmiyor musunuz?

Tabii ki yapıyorum ama taahhüt mesajı bazen meslektaşlarım tarafından okunmuyor. Tipik bir durum değildir (benim durumumda ölü olan) kodunu anlamaya çalıştığınızda, ilk önce tüm ilgili taahhüt mesajlarıyla Sürüm kontrol günlüğünü kontrol etmeniz gerekir. Kayıt defterinde gezinmek yerine, bir meslektaşım bu dosyanın faydasız olduğunu hemen görebilir. Zamanını kurtarır ve bu dosyanın muhtemelen kötü bir şekilde geri yüklendiğini bilir (veya en azından bir soruyu gündeme getirir).


120
Esasen sürüm kontrol sisteminizin işini doğrudan dosyaya kopyalamaya çalışıyorsunuz. Böyle bir şey yapmak kesinlikle kafamda bir bayrak açacaktır. Meslektaşlarınız işlemek mesajları okumak yoksa ve onlar haklı silinmiş olan bir dosyayı diriltmek ve orada sizin takımda yanlış bir şey kesinlikle var ve daha iyi öğretmek için çok büyük bir fırsat, kod İncelemeye geçer.
Vincent Savard

6
@GregBurghardt Kötü bir fikir hakkında iyi bir soru gibi görünüyor. Belki de insanlar bunun ikinci kısmına dayanarak aşağı yönlendiriyorlar (IMO ne zaman birincisi için ısrar ediyor olmalıydı)?
Ben Aaronson

13
“Bir dahaki sefere projemdeki bir şeyi sürüm kontrolüne teslim etmem / kontrol etmem gerektiğinde, SVN-> Sil düğmesine basarım” Bunları (potansiyel olarak) tamamen alakasız bir taahhütte silmenizi mi söylüyorsunuz?
Kevin,

21
Tabii ki yapıyorum ama taahhüt mesajı bazen meslektaşlarım tarafından okunmuyor. - taahhüt mesajını kontrol etmiyorlarsa, dosyanın neden kaldırıldığı ile ilgilenmediğini varsaymak güvenlidir, aksi halde taahhüt mesajını kontrol etmeleri gerekir.
Karınca P

9
Bir dosya benim VCS kasada kayboldu neden bilmek istiyorum, ben değişiklik geçmişinde bakacağız ilk ve bu şeyleri açıklamak etmezse, ben silme gözden geçirilmiştir ne oldu tartışmayı okuyacaktır. (Eğer her değişiklik geçer bir kod gözden geçirme süreci yoksa, sen. Büyük sorunlarımız var) Ve eğer o hala unenlightening olduğunu ben dosyayı silinmiş kim konuşacaktır. Ne işe yaradığını keşfetmeye çalışmak için eski dosya içeriğine bakabilirim, fakat silme hakkında bir açıklama yapmayabilirim.
zwol

Yanıtlar:


110

Bir dosyaya, kaynak kontrolünden silmek ve oraya açıklama yapmak yerine, silinmesi gereken bir yorum ekleme sorunu, geliştiriciler okumazsa, kesinlikle kaynak koddaki yorumları okuyacaklarını taahhüt ettiği varsayımıdır.

Bir yabancı perspektifinden bakıldığında, bu metodoloji kaynak kontrolü çok muhafazakar bir bakış açısına dayanıyor gibi görünmektedir.

"Kullanılmayan bu dosyayı silip sonra birinin ihtiyacı varsa ne yapmalıyım?" Birileri sorabilir.

Kaynak kontrolü kullanıyorsunuz. Değişikliği geri alın veya daha iyisi henüz dosyayı silen kişi ile konuşun (iletişim kurun).

"Ölü dosyayı silersem, biri yeniden kullanmaya başlar ve değişiklikler yapar?" başka biri isteyebilir.

Yine, kaynak kontrolü kullanıyorsunuz. Bir kişinin çözmesi gereken bir birleştirme çatışması alırsınız. Buradaki cevap, son soruda olduğu gibi, takım arkadaşlarınızla iletişim kurmaktır.

Bir dosyanın gerçekten kaldırılması gerektiğinden şüpheleniyorsanız , kaynak kontrolünden silmeden önce iletişim kurun. Belki de sadece son zamanlarda kullanılmayı bıraktı, ancak yaklaşan bir özellik gerektirebilir. Bunu bilmiyorsun, ama diğer geliştiricilerden biri olabilir.

Çıkarılması gerekiyorsa, çıkarın. Yağları kod tabanından çıkarın.

Bir "oopsie" yaptıysanız ve aslında dosyaya ihtiyacınız varsa, dosyayı kontrol edebilmeniz için kaynak kontrolünü kullandığınızı unutmayın.

Vincent Savard, soru üzerine yaptığı açıklamada, şöyle dedi:

... Eğer meslektaşlarınız taahhüt mesajlarını okumazlarsa ve doğru bir şekilde silinmiş bir dosyayı diriltirlerse ve kod incelemesini geçerse, ekibinizde kesinlikle yanlış bir şey var ve onlara daha iyi öğretmek için harika bir fırsat.

Bu sağlam bir tavsiye. Kod incelemeleri bu tür bir şeyi yakalamalıdır. Geliştiricilerin bir dosyada beklenmeyen bir değişiklik yapıldığında veya bir dosya kaldırıldığında veya yeniden adlandırıldığında mesaj verme danışmanlığı yapmaları gerekir.

Taahhüt mesajları hikayeyi anlatmıyorsa, geliştiricilerin de daha iyi taahhüt mesajları yazmaları gerekir.

Kod silmek veya dosya silmek korkmak, işlemle ilgili daha derin ve sistemik bir sorunun göstergesidir:

  • Doğru kod incelemelerinin olmayışı
  • Kaynak kontrolünün nasıl çalıştığı hakkında bir anlayış eksikliği
  • Takım iletişimi eksikliği
  • Geliştiriciler adına kötü taahhüt mesajları

Bunlar çözülecek sorunlardır, bu nedenle kod veya dosyaları silerken camdan bir taşa taş attığınızı hissetmezsiniz.


3
"Eğer geliştiriciler okumazsa, kesinlikle kaynak koddaki yorumları okuyacaklarını taahhüt ederler." Bence bu oldukça iyi bir varsayım. Bir dosyayı değiştiren bir geliştiricinin görevi gerçekleştirmek için gerçekten dosyaya bakması gerekirken, birisini kaynak kontrol geçmişine bakmaya zorlayan hiçbir şey yoktur.
ASHelly

7
@AShelly: Bir geliştirici görevi nadiren yorum değiştirir. Görevler, kod değiştirmeyi içerir; geliştiricinin odaklandığı şeydir - yorumları değil.
Greg Burghardt,

21
@AShelly Sadece bir dosyayı açmaları gerektiği için en üstte özel bir yorum okuyacakları anlamına gelmez. Bu değişimin hedef kitlesi en habersiz geliştirici türüdür, ihtiyaçlarını düşünen türler tek ihtiyaçlardır ve her şey onların etrafında dönmelidir. Bunlar kibar yorumunuzu okumak için olası değildir. Daha da kötüsü, muhtemelen okuyacaklar ve bir sonraki en eski sürüme dönecekler.
Cort Ammon

5
@AShelly - Örnek olarak dosyaları bir yere açıyorum. VS'de, üst kısımdaki açılır pencereleri kullanarak veya doğrudan "tanımlamaya git" bağlam menüsünü kullanarak doğrudan bir metoda açılabilir. Dosyanın tepesini asla görmem. Ayrıca Sublime Text'de sık sık bir satıra açılırım. Açık diyalog kullanıcıları users.rb: 123, users.rb'yi direkt olarak 123 satırına açar. Pek çok kod düzenleyicisinin de benzer seçenekleri vardır.
coteyr

2
Yukarıdakilere ek olarak, bunun gibi temizlik işlerini yapmak ne kadar karmaşıksa, insanlar bunları düzenli olarak yapmak o kadar az olasıdır. Daha basit bir şekilde yapmaktan kurtulursanız, sizin ve diğer herkes için "aktivasyon enerjisini" azaltır. Diğer ekip üyeleri için uygulama değişikliğini teşvik etmeye çalışıyorsanız, bu özellikle önemlidir. Prosedür ne kadar karmaşık olursa, katılımın zorlaşması o kadar zor olur.
xdhmoore

105

Evet bu kötü bir uygulamadır.

Silme işlemine ilişkin açıklamaları, dosyaları silme işleminde taahhüt mesajına yazmalısınız.

Kaynak dosyalardaki yorumlar kodu göründüğü gibi açıklamalıdır . Taahhüt mesajları, taahütteki değişikliklerin neden yapıldığını açıklamalıdır , bu nedenle dosyadaki taahhüt geçmişi onun tarihini açıklar.

Doğrudan kaynağın içindeki değişiklikleri açıklayan yorumlar yazmak kodun takip edilmesini zorlaştıracaktır. Bir düşünün: Her kod değiştirdiğinizde veya sildiğinizde dosyaya yorum yaparsanız, yakında dosyalar değişiklik geçmişi ile ilgili yorumlar ile değiştirilecektir.


6
Belki de soruya cevap ekleyin: Kötü bir uygulama mı? Evet, çünkü ....
Juan Carlos Coto,

1
Bazen aynısını (OP olarak) yapıyorum, çünkü rahatsız edilmek geri dönmekten daha kolay. Nadir durumlarda, kod otomatik testi derlese ve geçse bile, bu kodun varlığının bir nedeni, manuel test cihazının tespit edeceğini göz ardı ettim. Bu nadir senaryoda, büyük bir acıdan geçmek ya da birkaç işin ardından bazı şeyleri geri almak yerine, sadece kodu geri getiriyorum (ve nasıl geliştirilebileceğini tekrar gözden
geçiriyorum

2
@AndrewSavinykh Farklı, kodunu yorumluyorsun, silmek istediğinden hala emin değilsin.
Goyo

6
@AndrewSavinykh “büyük acılar ya da birkaç işin ardından bazı şeyleri geri döndürmek” - Hangi sürüm kontrolünü kullandığınızı merak ediyorum; bu büyük bir acı olmamalı. Kesinlikle Git'te değil, en azından birkaç kez yaptıktan ve nelere dikkat etmeniz gerektiğini öğrendikten sonra ... ve tarihinizin size vereceğiniz gereksiz yere geri ödeme taahhütleri ile örtüşmemesi şartıyla birbirleriyle birleşirler. Ve sadece bir şey hakkında yorumda
bulunmayı taahhüt edenlerin

4
@AndrewSavinykh evet, ve bu sorunları yaşamamışım gibi değil - bakıcıları sürüm kontrolü ile gerçekten hiç çalışmadı ve gerçekten çok fazla el koyma-yerine bırakma- lı sözler eklenmiş olan yorumlarda çok fazla bilgi koyan projeler. Düzgün geri dönme, vb. Deponun sonuçta ortaya çıkan durumu, her büyük rebase'de çok sayıda çatışmaya neden oldu ... Ama, ve benim açımdan, bu problemler genellikle burada savunduğunuz gibi geçici çözümlerden kaynaklanıyor .
leftaroundabout

15

Kanımca, her iki seçeneğin de kötü uygulama yerine , en iyi uygulama olmadığını düşünüyorum :

  1. Yorum eklemek, birileri bu yorumları okuyacak olursa herhangi bir değer katar.
  2. VCS'den basitçe silmek (değişiklik açıklamasındaki bir sebeple), kritik bir teslimatı etkileyebilir ve birçok kişi, özellikle baskı altındayken değişiklik açıklamasını okumaz.

Benim tercih uygulama -, yılda birkaç kez ısırıldı yapılmış olması nedeniyle büyük ölçüde her zaman bilmiyorum nerede ve kimler tarafından kodunuzu kullanıldığını göz önünde bulundurarak - etmektir:

  1. Silinmek için aday ve olduğunu belirten bir yorum ekleyin kullanımdan kaldırılması #warning veya benzeri, (dillerin çoğu örn böyle bir mekanizma çeşit var Java en kötü durumda, bir printaçıklama veya benzeri yeterli olacaktır), ideal olarak zaman ölçeği çeşit ve iletişim bilgileri ile. Bu, hala kodu kullanan herkesi uyaracaktır . Bu uyarılar normalde, eğer böyle şeyler varsa, her bir işlev veya sınıfın içindedir .
  2. Bir süre sonra uyarıyı standart bir dosya kapsamına yükseltin #warning(bazı insanlar kullanımdan kaldırma uyarısını yok sayar ve bazı takım zincirleri bu uyarıları varsayılan olarak göstermez).
  3. Daha sonra dosya kapsamını #warningbir #errorveya eşdeğeriyle değiştirin - bu, derleme sırasında kodu kırar, ancak kesinlikle gerekirse kaldırılabilir ancak onu kaldıran kişi bunu görmezden gelemez. (Bazı geliştiriciler herhangi bir uyarı okumaz veya çözmezler veya önemli olanları ayıramayacakları çok sayıda vardır).
  4. Son olarak, dosyaları VCS'de silindiği gibi (son tarihte veya sonrasındaki) işaretleyin.
  5. Uyarı aşamasında vb bir bütün paket / kütüphane / silme ben benzer bir README.txt veya README.html veya eklersiniz zaman & o paketin kurtulmak için planlanan neden hakkında bilgi ve sadece o dosyayı bırakın bir ile içeriğin geri kalanını çıkardıktan sonra bir süre için yalnızca paketin içeriği olarak silindiğinde söylenecek şekilde değiştirin .

Bu yaklaşımın bir avantajı, bazı versiyonlama sistemlerinin (CVS, PVCS, vb.) VCS'de silinmişse , kasadaki mevcut bir dosyayı kaldırmayacağıdır. Ayrıca, tüm uyarılarını düzelten , konuyu ele almak ya da silmeye itiraz etmek için çok zaman ayıran vicdani geliştiricilere de verir . Ayrıca kalan geliştiricileri en azından silme bildirimine bakmaya ve çok şikayet etmeye zorlar .

Not #warning/ #errorolduğunu derleyici olduğunu kodu java / java-doc karşılaşır sağlanan metnin ardından bir uyarı / hata neden olan bir C / C ++ mekanizması @Deprecatedaçıklama kullanımına & uyarı yayınladı @deprecatedvb vardır, bazı bilgiler vermekten python benzer yapmak için tarifler ve gerçek dünyada assertbenzer bilgiler sağlamak için kullanılan gördüm #error.


7
Özellikle, bu soru Java'dan bahsettiği için, @deprecatedJavaDoc yorumunu ve @Deprecatedek açıklamasını kullanın .
200_success

8
Halen kullanımda olan bir şeyden kurtulmak istediğinizde bu daha uygun görünmektedir. Uyarı, tüm kullanımlar bitene kadar yapışabilir, ancak kod bittiğinde derhal silinmelidir.
Andy,

6
Kütüphane tipi kodu ile sorunların One @Andy özellikle Açık Kaynak veya büyük kuruluşlarda, sen olabilmesidir düşünüyorum kod öldüğünü ancak birine veya birkaçına şahsen asla hayal yerlerde aktif kullanımda olduğunu bulmak kullanımda olduğu zaman, bazen kodun kaldırılması gerekebilir, çünkü bu gerçekten kötüdür veya güvenlik riskleri içerir, ancak nerede ve ne kullanıldığını bilmiyorsunuz.
Steve Barnes

1
@ 200_success teşekkürler - C / C ++ ile gösterilen geçmişim - cevaba eklendi.
Steve Barnes

1
@SteveBarnes Belki ama OP'nin sorduğu şey bu değil. Kodun öldüğünü doğruladı.
Andy,

3

Evet, bunun kötü bir uygulama olduğunu söyleyebilirim, ancak bu, mesajın aksine, dosyada olduğu için değil. Sorun, ekibinizle iletişim kurmadan değişiklik yapmaya çalışıyor olmanızdır.

Bagajda herhangi bir değişiklik yaptığınızda (herhangi bir şekilde dosya ekleme, silme veya değiştirme) - bagaja geri dönmeden önce, doğrudan değişiklikler yapacak olan ekibin bir üyesiyle (üyeleriyle) doğrudan bu değişiklikler hakkında konuşmalısınız. onlar hakkında bilgili (aslında, bu başlıklara ne koyacağınızı doğrudan ekip arkadaşlarınızla tartışınız). Bu, (1) sildiğiniz kodun gerçekten silinmesi gerektiğini ve (2) ekibinizin kodun silindiğini bilme olasılığını artıracağını ve böylece silme işlemlerinizi geri almaya çalışmadığını garanti eder. Ayrıca eklediğiniz kod için hata tespiti ve benzeri işlemlerden de yararlanacağınızdan bahsetmiyorum.

Tabii ki, büyük şeyleri değiştirdiğiniz zaman, bunu aynı zamanda taahhüt mesajına da koymalısınız, ama zaten konuştuğunuz için önemli duyuruların kaynağı olması gerekmez. Steve Barnes'ın cevabı , kodunuz için potansiyel kullanıcı havuzunun çok büyük olması durumunda kullanılabilecek bazı iyi stratejilere de hitap eder (örneğin, dosyaları ilk başta silmek yerine dilinizin kullanımdan kaldırılmış işaretlerini kullanarak).

Taahhüt etmeden o kadar uzun gitmek istemiyorsanız (yani, değişiklikleriniz birkaç revizyon gibi en mantıklı olanıdır), gövdeden bir dal oluşturmak ve şubeye taahhüt etmek iyi bir fikirdir. değişim hazır. Bu şekilde, VCS dosyayı sizin için hala yedekliyor, ancak değişiklikleriniz bagajı hiçbir şekilde etkilemiyor.


1

Birden fazla platformda ve yapılandırmada inşa edilen projelerden kaynaklanan bir sorun. Çünkü ben o ölü olduğunu tespit yapar doğru bir tespit olduğu anlamına. Kullanımda ölülerin hala, hala ayıklanması gereken ve bazılarının kaçırılmış olabileceği, bağımlı bağımlılık anlamına gelebileceğini unutmayın.

Böylece (bir C ++ projesinde) ekledim

#error this is not as dead as I thought it was

Ve bunu kontrol ettim. Tüm normal platformların yeniden inşasını geçmesini ve kimsenin bundan şikayet etmesini bekleyin. Birisi onu bulmuşsa, eksik bir dosyayla şaşırtılmak yerine bir satırı kaldırmak kolay olacaktır.

Prensip olarak, bahsettiğiniz yorumların versiyonlama yönetim sisteminde yapılması gereken özelliği kopyaladığını kabul ediyorum . Ancak, bunu desteklemek için özel nedenleriniz olabilir . VCS aracını bilmemek onlardan biri değil.


-1

Kötü Uygulamaların sürekliliği üzerine, bu oldukça küçük. Bir şubeyi kontrol etmek ve eski kodu görmek istediğimde bunu zaman zaman yapacağım. Bu, değiştirme koduyla karşılaştırmayı kolaylaştırabilir. Genelde "cruft" kod inceleme yorumu alırım. Küçük bir açıklama ile kod incelemesi geçer.

Ancak bu kod uzun süre yaşamamalıdır. Genellikle bir sonraki sprintin başında silerim.

Mesaj okumayan ya da size projede kodu neden bıraktığınızı sormayan iş arkadaşlarınız varsa, sorununuz kötü kodlama stilinden biri değildir. Farklı bir problemin var.


bu, önceki 6
cevapta

-3

ayrıca sınıfınızı yeniden düzenleyebilir ve dublörünüzü çekmeden önce UNUSED_Classname için bir önekle yeniden adlandırabilirsiniz. Öyleyse, doğrudan silme işlemini de yapmalısınız.

  • 1. Adım: sınıfı yeniden adlandırın, yorumunuzu ekleyin, kabul edin
  • 2. Adım: dosyayı silin ve onaylayın

Ölü kod ise, silin. Herkes ihtiyacı olursa geri dönebilir, ancak yeniden adlandırma adımı doğrudan düşünmeden kullanmalarını engelleyecektir.

Ayrıca insanlara bir dosya için tüm taahhüt mesajlarına nasıl bakacaklarını öğretin, bazı insanlar bunun mümkün olduğunu bile bilmiyorlar.


6
"Yeniden düzenleme" aslında ne düşündüğün anlamına gelmiyor
Nik Kyriakides

6
Kullanılmadığından emin olmak için sınıfı / yöntemi yeniden adlandırmaya gerek yoktur, silme işlemi de çalışır. Bunun yerine, prosedür diğer değişikliklerle aynıdır: 1) ölü kodu silin , 2) testleri yapın , 3) geçerse, yorum yaparak kesinleştirin .
Schwern

1
@ user275398 Ayrıca dosyaları yeniden adlandırmanın gerçekten çok fazla olduğunu düşünüyorum. Ayrıca teknolojik açıdan da, SVN, dosya silinmiş ve yeni bir adla oluşturulmuş gibi yeniden isimlendirmeyi kabul ediyor, böylece tarihte bir mola veriyorsunuz. Yeniden adlandırılmış dosyayı geri yükler ve SVN günlüğüne bakarsanız, yeniden adlandırmadan önceki geçmiş kullanılamaz. Bunun için eski adı olan dosyayı geri almalısınız. Yeniden düzenleme, başka bir şey yapmanın yanı sıra, yeniden düzenleme, mevcut kodu yeni bir yapıya dönüştürüyor.
Bruder Lustig

@ BruderLustig: İyi yazılım kesinlikle bunu yapmayacak. Git, git mvgeçmişi izliyor . Mercurial aynı şekilde vardır hg mv. Görünüşe göre svn moveSVN için de çalışmalı mı?
wchargin

@ wchargin Hayır, git mvsadece dosyayı taşır ve bir dosyayı silme ve bir dosya oluşturma aşaması yapar. Tüm hareket takibi koşarken git log --followve benzer olduğunda gerçekleşir . gitisimleri takip etmenin bir yolu yoktur, aslında değişiklikleri hiç izlemez ; bunun yerine taahhüt sırasındaki devletleri izler ve tarihi incelerken o sırada nelerin değiştiğini bulur.
maaartinus
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.