Neden kodu yorumlamak ve daha sonra ne yaptığımı ve yapılması gerekenlerin kaydını tutmak için yavaş yavaş kaldırmak neden yanlış?

Kodumun büyük bir bölümünün değiştirilmesi gerektiğine karar verdiğimde, ya yanlış olduğu ya da diğer nedenlerle gerekli büyük mimari değişikliklere adapte edilmesi gerektiği için, tipik olarak yaptığım şey şu:

1. Değiştirmem gerekebileceğini düşündüğüm tüm kodları yorumluyorum. Yorumlanan kodu TODO listemin bir türü olarak kabul ediyorum.
2. Bu kodun yorumlanan kodunu ve uncomment bölümlerini aşamalı olarak gözden geçiririm veya başka bir yere kopyalayıp yapıştırarak sonra bunları gerektiği şekilde düzenlerim veya bu kodun bölümlerini sıfırdan yeniden yazıp referans koduna bakarım. Ne zaman bir yorum kodunun bir parçası ile bittiğimi sanırım kaldırırım.
3. Artık yorumlanmış kod olmadığını görene kadar devam ediyorum.

Yalnız geliştirdiğim kişisel projede bunu büyük ölçüde yaptığımı not etmeliyim.

Ancak bana bunu yapmayı bırakmam gerektiği söylendi. Bunun yerine, yorum yazıp bırakmak yerine eski kodu görmek için eski taahhütlere atıfta bulunarak git kullanmaya başlamam gerektiği söylendi. Bana söylendi:

Kodu yorumlamak, ortadan kaldırılması gereken kötü bir alışkanlıktır. Tecrübeniz yok, bu yüzden bunu anlayamıyorsunuz. Birkaç yıl içinde, kodu yorumlamayı seven başka bir kişinin kodunu görürseniz, kendinize bu kişide küfür etmeye başlayacaksınız. Ne zaman bir kod yorumladıysam, onu bile bakmadan tamamen kaldırırım, çünkü genellikle bu kod tamamen değersizdir. Küçük, tek kişilik projelerde kod yorumlamanın olumsuz taraflarını kesinlikle göremezsiniz; ama bir iş bulup bu alışkanlığı devam ettirirseniz, çok yazık olur.

Şu an göremediğim şeylerin ne dezavantajları neler olduğunu sorabilir miyim?

Gerçekten geçmiş kodu görmek için sadece git kullanarak merak ediyorum söylemeliyim. Dediğim gibi, kod yorumlamayı bir yapılacaklar listesi olarak ele alıyorum; git bana kodun nasıl kullanıldığını gösterecek olsa da hangi kodun hala gözden geçirilmesi gerektiğini ve hangilerinin daha önce yapıldığını açıkça göstermekte başarısız olacak. Kodun bir bölümünü özleyebileceğim ve hataları ortaya çıkarabileceğimden korkuyorum.

Tamamlanması için, alıntı yaptığım kişinin tecrübeli bir geliştirici ve Bob Amca'nın "Temiz Kod" hayranı olduğunu eklemeliyim.

Sonuçta yorumlanan kodun tümünü kaldırırsanız, bununla ilgili gerçek bir sorun göremiyorum. Yorumlanmış kodu kod tabanınızda bırakmak kötü bir uygulamadır, ancak her şeyi uygularsanız ve ortadan kaldırırsanız yaptığınız şey bu değildir. Konuştuğunuz kişinin ya kullandığınız işlemi anlamadığından ya da dogmatik davrandığından şüpheleniyorum.

Gerçekte, yorumlanan kod zararsızdır. Sorun, dağınık olması ve okumayı zorlaştırmasıdır. Çok daha kötü günahlar var ama ortadan kaldırmak için çok basit bir şey. Kodu yorumlayan kişi olarak, tamamen kaldırılabileceğini belirlemek için en iyi pozisyondasın.

Birçok IDE ve kod editörü yorumlarda bir tür 'TODO' sözdizimini anlıyor. Bu, neyin değiştirilmesi gerektiğini işaretlemenin alternatif bir yoludur. Bunu göz önüne almak isteyebilirsiniz, çünkü işaretlerken ne düşündüğünüz hakkında biraz daha bilgi verir.

Günün sonunda, işleri sizin için en iyi sonuçla sonuçlanan şekilde yapın. Bu bir takım projesi olsa bile, tüm yorum kodlarını kaldırdığınız sürece başka kimseye yük getirmezsiniz.

Şu an göremediğim şeylerin ne dezavantajları neler olduğunu sorabilir miyim?

Muhtemelen, hiçbiri yalnız çalışıyorsanız ve sürüm kontrolü kullanmıyorsanız ve böyle yapmanın bir sorun olmadığını hissederseniz.

Aslında, sürüm kontrolü olmadan, geçerli dosyanın işletim sistemindeki gibi "kaydedildiği" durum her zaman olduğu gibi, "zaman" da herhangi bir noktada ne yaptığınız önemli değildir.

Sürüm kontrolünü kullanıyorsanız ve "yapılacaklar listeniz" olarak bir yorum yükünüz varsa ve bazılarını düzeltip yorumu kaldırırsanız, ardından tekrarlayın, sonra tekrarlayın ... sonra "çalışma devam ediyor" kodunuz ve kaydettiğiniz yorumlar varsa revizyon geçmişinizde. Daha sonra asla başka bir taahhüde geri dönme veya daha sonra "vişne seçimine" geri dönmeniz gerekmiyorsa, bu bir sorun olmayacak (bu, örneğin belirli taahhütleri aldığınız ve onları kullanmak için başka bir şubeye çekeceğiniz yerdir). Ancak aksi takdirde bir sorun olabilir.

Muhtemelen bu, Windows'taki gibi (Geri yükleme özelliği) olduğu gibi, sabit disk yazılımı "ek çekimler" ile karşılaştırılabilir. İçinde virüs bulunan bir anlık görüntü alırsa, virüsü öldürürsünüz, ancak daha sonra geri dönmeniz gerekir, virüsün tekrar bulunduğu noktaya geri dönebilirsiniz.

Bu yaklaşım aynı zamanda olasılıkla sürüm kontrolü kullandığınızda bir sorun ve diğer devs ile çalışmalarını daha sonra görmek zorunda olduğu, sizin onlara hiçbir kullanımı vardır yapılacaklar listesi. Aslında, görmezden gelip çalışmak zorunda oldukları karmaşa. Ekiplerimizde her zaman eski kod veya "notlar" gibi tüm yorumları kaldırırız. Yararlı olmadıkça - ancak bu çok nadirdir çünkü “nasıl çalıştığını” ve ne yapılması gerektiğini izlemeye yönelik yazılımları vardır (aka todo).

Ayrıca, daha büyük bir projede çalışırken, ortak çalışma ve sıkışma ve zorlama eğilimindesiniz, bu nedenle üzerinde çalıştıkları şubelerin, şubenizi kendileriyle birleştirmeleri durumunda TODO listenizin olması mümkündür. O zaman TODO listeniz herkesin işidir: D

Özet olarak, yalnız çalışmazsanız ve özellikle sürüm kontrolünü kullanırken, geçmişi tutar ve diğer cihazlarla karışıklık yaratır.

Ve bu, bazı bakımlardan kişisel bir şeydir, ancak "yapılacaklar listesi" olarak bir kod temeli kullanmak gerçekten ideal değildir. Bir gün bir şeyi tesadüfen bırakabilir ya da yorum yapmayı veya yanlışlıkla yorumlamayı unutabilirsiniz.

Mimarlığa, kodlamaya ve kişisel olarak sizin veya ekibinizin nasıl çalıştığına dair birçok yaklaşımda olduğu gibi, her senaryo farklı bir şey için çağrı yapabilir. Dolayısıyla, bahsedilen olumsuzlukları ve sürüm kontrolünü kullanmanın yararlarını göz önünde bulundurun ve sizin için işe yarayıp yaramadığına karar verin .

Gözden geçiren biraz dogmatik gibi geliyor. Kod yorumlamak için birine küfür emin değilim PC ;-), hatta yararlı ;-)

Fakat daha ciddiyetle, gözden geçiren hak sahibinin haklı olduğunu düşünüyorum, git (veya başka bir kaynak kontrol sistemi kullanmayı düşünmelisiniz, ama git mantıklı bir seçimdir).

Ve bunun yapılması, bazı kodları yorumlama gereksinimlerinizi hafifletebilir.

Ancak kod içinde bir TODO listesine sahip olmak (madde imli listeler veya eski kod) - bence oldukça makul. Ancak, nasıl yaptığınız hakkında biraz düşünmek isteyebilirsiniz. Birincisi, kodunuzu okuyan bir başkasını düşünmenizi öneririm. Bir projeye bırakıp tekrar katılmanızdan bir yıl sonra başka birinin de olabileceğini Veya tamamen başka biri olabilir. SADECE yorum kodunu karşılaştırarak biraz kafa karıştırıcı. Belki bir şey gibi:

/*
 * Need this sort of functionality added back before too long:
 * .... OLD CODE HERE
 */

Şahsen, böyle bir şeye daha fazla eğildim:

 * TODO:
 *      @todo   Possible get rid of intermediate LRUCache_ object.
 *
 *      @todo   Find some reasonable/simple way to get
 *              LRUCache<PHRShortcutSpec, PHRShortcutSpec, PHRShortcutSpecNoAuthCacheTraits_>   sRecentlyUsedCache (kMaxEltsInReceltlyUsedCache_);
 *              Working with ONE T argument
 *              Add(elt2cache).
 ...

ve yararlı olarak eski koddan 'kod parçacıkları' atmak için çekinmeyin.

Git kullanmak zordur (ne yazık ki). Öğrenmesi biraz zaman alacak ve başarmaya çalıştığın şeyin bir parçası olmadığını hissedebilir. Ancak, yararlı bir şekilde program yapacaksanız, bunu bir ekibin parçası olarak yapmayı ve bir ekiple iletişim kurmayı öğrenmeniz gerekecektir ve git bugünlerde böyle yapılır. Ve kullanmaya başladığınızda, yazılım geliştirmenizi kolaylaştıracak ÇOK yardımcı bir araç / koltuk değneği bulacaksınız.

İyi şanslar!

Kodu yorumlamak için birçok neden var: -

• Henüz doğru değil ve hazır olduğunda yorumunu kaldıracaksınız.
• Hata ayıklama sırasındaki davranışı değiştirmek için geçici olarak yorum yapıyorsunuz.
• Kodun gerekip gerekmediğinden emin değilsiniz, ancak biraz daha test edene kadar silmek istemezsiniz.
• Kod, yazılımın bazı sürümleri için gereklidir, ancak bu sürüm için gerekli değildir.
• Kod modası geçmiş, ancak yazması çok uzun sürdü ve duygusal olarak ona bağlısınız. Ayrıca, bir gün faydalı olabilir.

Sorun, kodu yatağa koyduğunuzda, ardından birkaç yıl sonra bir miktar bakım yapmak için tekrar geldiğinizde ortaya çıkar. Yorumlanan kod ile dolu kod temeli bulacaksınız. Neden birisinin orada olduğunu artık belli olmayacak ve şimdi sadece karışıklık.

Herhangi bir yarı-iyi sürüm kontrol aracı kullanıyorsanız, sürüm kontrol sisteminin hala sakladığı bilgisine sahip olduğunuzdan emin olarak, artık gerek duymadığınız herhangi bir kodu cesaretle silebilirsiniz. Sürümler arasındaki bir dosya farkı neyin silindiğini ortaya çıkarır. Sürüm kontrolünü uyguladıktan sonra, yorum yapmanın tek yolu geçici şeyler içindir. Eğer aslında üzerinde çalışmadığınız dosyalarda yorumlanmış bir kod bulursanız, sadece silebilirsiniz.

Neden bir kişi projeler için bile kaynak kontrolünü kullanmanız gerektiğini tekrar söylemeyeceğim, çünkü size bunu söyleyebilecek çok sayıda başka kaynak var. Ancak mevcut yaklaşımınızın bir dezavantajı, kod hakkında yorum yaparsanız, IDE'nizden gizlemenizdir (eğer bir IDE kullanmıyorsanız, muhtemelen düşünmelisiniz).

Örneğin, bir yöntemi veya sınıfı yeniden adlandırmak veya bir yöntemin aldığı parametre sayısını değiştirmek istiyorsanız, IDE'nizin tüm uygun referansları bulabilecek ve bunları buna göre güncelleyecek olan bir refactor seçeneği olmalıdır - ancak muhtemelen kazanmıştır ' Yorumlarda arama yap.

Nerede değişiklik yapmanız gerektiğini tahmin etmeyi denemek yerine, onları onları yapın ve IDE'nizin değişikliklerin nerede parçalanmasına neden olduğunu size söylemesini sağlayın. Daha sonra, kırılanları düzeltmeden önce kodu daha cerrahi ve umarım daha kısa bir süre için yorumlayabilirsiniz.

Bu var kötü ve gereken durdurmak .

Sebep, bir seferde çok miktarda yeniden düzenleme yapmaya çalışmaktan kaynaklanıyor.

Kodun büyük bölümlerini yorumladıysanız, biraz düzeltip teslim alın, sonra işlevsel olmayan kodu kontrol ettiniz. ve başkalarının kabul edeceği yorumlanmış bir sürü şey eski ve görmezden gelinebilir

Sık sık check-in yapmazsanız, birleştirme çatışmalarını biriktiriyor ve adım adım ilerlemeden kaydetmiyorsunuz.

Çalışma pratiğinizi değiştirmelisiniz ki orta yoldan çıkmak zorunda kalırsanız her şey hala çalışır.

Bebek adımlarını atın ve her biri için kontrol

• arayüz çıkarmak
• bir test yaz
• refactor işlevi

Bunları yorumlayarak büyük kod parçalarını 'sizin' olarak işaretlemeyin ve tamamlanana veya başarısız oluncaya kadar kendiniz üzerinde çalışmaya devam edin.

Yapılması gerekenleri takip etmeniz gerekiyorsa, scrum veya trello gibi bir görev tahtası kullanın.