"Yorumlanmış" kodun check-in işlemi [kapatıldı]

Tamam, işte şu anki işimde biraz sürtüşmeye neden olan bir şey ve bunu gerçekten beklemiyordum. Kurum içi yazılım geliştirme burada yeni bir kavramdır ve bazı kodlama yönergelerinin ilk taslağını hazırladım.

"Yorumlanmış" kodun hiçbir zaman depoda kontrol edilmemesini önerdim. Bunu belirtmemin nedeni, arşivin dosyaların tam bir geçmişini tutmasıdır. İşlevsel kodu kaldırıyorsanız, tamamen kaldırın. Depo, değişikliklerinizi saklar, böylece neyin değiştiğini görmek kolaydır.

Bu, başka bir geliştiricinin bu rotayı izlemenin çok kısıtlayıcı olduğuna inandığı için bazı sürtüşmelere neden oldu. Bu geliştirici, üzerinde çalıştığı ancak eksik olan bazı kodları yorumlayabilmek istiyor. Bu kod, daha önce hiç kontrol edilmemiş ve daha sonra hiçbir yere kaydedilmeyecektir. TFS kullanacağız, bu yüzden değişiklikleri rafa kaldırmanın en doğru çözüm olacağını önerdim. Ancak, uygulanabilecek veya dağıtılamayacak kısmi değişiklikleri kontrol edebilmek istediği için kabul edilmedi.

Sonunda Sürekli Entegrasyondan tam olarak yararlandığımız ve otomatik olarak bir geliştirme web sunucusuna dağıttığımız bir noktaya gelmek istiyoruz. Şu anda web sunucularının veya veritabanı sunucularının geliştirme sürümü yoktur, ancak bunların tümü yakında değişecektir.

Her neyse, düşüncelerin neler? "Yorumlanmış" kodun arşivde bulunmasının yararlı olduğuna inanıyor musunuz?

Başkalarından bu konuyla ilgili bilgi almakla çok ilgileniyorum.

Düzenleme: Açıklık adına özel şubeler kullanmıyoruz. Yapsaydık, özel şubenizle istediğinizi yapın derdim, ancak yorumlanmış kodu ana hat veya herhangi bir paylaşılan şubeyle birleştirmeyin.

Düzenleme: Özel veya kullanıcı başına şubeler kullanmamamız için geçerli bir neden yok. Katılmadığım bir kavram değil. Henüz bu şekilde kurmadık. Belki de nihai orta yol budur. Şimdilik TFS rafları kullanıyoruz.

Farklı deneyimleri olan başkaları da olabilir, ancak benimkinde yarı bitmiş kodu kontrol etmek korkunç bir fikir, nokta.

İşte öğrendiğim ve izlemeye çalıştığım ilkeler:

• Sık sık kontrol edin - en az bir kez, ancak tercihen günde birçok kez
• Yalnızca tam işlevselliği kontrol edin
• Birinci ve ikinci çatışma (örneğin, işlevselliğin çalışması bir günden fazla sürerse), görev çok büyükse - onu daha küçük tamamlanabilir görevlere bölün.

Bunun anlamı:

• Açıklanan kod, işlevsel olmadığı için asla kontrol edilmemelidir
• Yorum yazmak geçerli bir arşivleme stratejisi değildir, bu nedenle ister henüz bitmiş kod olsun ister kullanımdan kaldırılan kod olsun, yorum yapmak ve kontrol etmek bir anlam ifade etmiyor.

Yani özetle HAYIR! Kod bir sonraki aşamaya geçmeye hazır değilse (hangisi sizin içinse: IntTest / QA / UAT / PreProd / Prod), bir ana hat veya çok geliştirici dalına bağlı olmamalıdır. Dönem.

Düzenleme: Diğer cevapları ve yorumları okuduktan sonra, yorumlu kodu yasaklamanın iyi bir fikir olduğunu düşünmediğimi ekleyeceğim (yine de bunu nasıl uygulayacağınızdan emin değilim). Söyleyeceğim şey, ekibinizdeki herkesi yukarıda anlattığım felsefeye alıştırmanız gerektiğidir. Çalıştığım ekip bunu gönülden kucaklıyor. Sonuç olarak, kaynak kontrolü, işimizi yapmamıza yardımcı olan, sorunsuz bir ekip üyesidir.

Bu felsefeyi benimsemeyen insanlar genellikle camların kırılmasına neden olur ve genellikle kaynak kontrolü yüzünden hayal kırıklığına uğrarlar. Onu en iyi ihtimalle gerekli bir kötülük ve en kötü ihtimalle kaçınılması gereken bir şey olarak görüyorlar; bu da nadiren iade edilmelerine yol açar, bu da değişiklik gruplarının çok büyük olduğu ve birleştirilmesinin zor olduğu anlamına gelir, bu da hayal kırıklığını artırır, check-in'leri daha da kaçınılması gereken bir şey haline getirir, vb. Bu sonuçta bir tutum meselesidir, gerçekten bir süreç meselesi değildir. Ona zihinsel engeller koymak kolaydır; Neden işe yaramayacağına dair nedenler bulmak kolaydır, tıpkı gerçekten istemiyorsanız diyet yapmamak için nedenler bulmanın kolay olması gibi. Ancak insanlar bunu yapmak istediklerinde ve alışkanlıklarını değiştirmeye kararlı olduklarında sonuçlar çarpıcıdır. Etkili bir şekilde satmanın sorumluluğu size aittir.

"Asla" nadiren kılavuzlarda kullanılan iyi bir kelimedir.

Meslektaşınız, açıklaması yapılan kodu iade etmenin ne zaman uygun olabileceğine dair harika bir örneğe sahiptir: Eksik olduğunda ve aktifken iade edilirse uygulamayı bozabilir.

Çoğunlukla, iyi yönetilen, değişim kontrollü bir sistemde ölü kod hakkında yorum yapmak gereksizdir. Ancak, yorumlanan kodların tümü "ölü" değildir.

Yorumlanan kod, geçmişi korumak amacıyla asla iade edilmemelidir . Kaynak kontrolünün amacı budur.

İnsanlar burada birçok idealden bahsediyor. Belki de herkesten farklı olarak, "gerçek dünya" nın ara sıra iş günümü kesintiye uğrattığı birden çok kesinti ile birden çok proje üzerinde çalışmak zorundayım.

Bazen gerçek şu ki, kısmen eksiksiz kodu kontrol etmem gerekiyor. Kodu kaybetme riski veya eksik check-in kodu. Ne kadar küçük olursa olsun, bir görevi her zaman "bitirmeyi" göze alamam. Ama olacak değil kontrol-kodsuz ağdan benim laptop ayırın.

Gerekirse, kısmi değişiklikler yapmak için kendi çalışma şubemi oluşturacağım.

Yorum yaptığım bir durum kodu:

// This approach doesn't work
// Blah, blah, blah

soruna bariz bir yaklaşım bu olsa da, bazı ince kusurlar içeriyor. Elbette, arşiv ona sahip olacaktı, ancak arşiv gelecekte kimseyi bu yoldan gitmemesi konusunda uyarmayacaktı.

Açıklanmış kodu kontrol etmeyi kesinlikle kesinlikle önermem. Bununla birlikte, kesinlikle yasaklamazdım. Bazen (nadiren), yorumlanmış kodu kaynak kontrolüne kontrol etmek uygun olur. "Bunu asla yapma" demek çok kısıtlayıcıdır.

Sanırım hepimiz bu noktalara katılıyoruz:

• Ölü kodu asla kaynak kontrolüne kontrol etme
• Kırık (çalışmayan) kodu asla kaynak kontrolüne, en azından hiçbir zaman ana hatlara ve çok nadiren özel bir şubeye, YMMV'ye kontrol edin.
• Hata ayıklama amacıyla geçici olarak bir şey hakkında yorum yaptıysanız veya bir şeyi bozduysanız, kodu doğru biçimine geri yükleyene kadar kodu kontrol etmeyin.

Bazıları, geçici olarak kaldırılan kod veya daha sonra ne olacağının dokümantasyonu olarak az miktarda yorumlanmış kod içeren artımlı ancak eksik bir iyileştirme veya çok kısa (ideal olarak 1 satır) yorumlanmış bir snippet gibi başka kategoriler olduğunu söylüyor . asla yeniden eklenmemesi gereken bir şeyi gösteren kod . Yorumlanan koda HER ZAMAN neden yorum yapıldığını (ve yalnızca silinmediğini) ve yorumlanan kodun beklenen ömrünü veren bir yorum eşlik etmelidir. Örneğin, "Aşağıdaki kod yarardan çok zarar verir, bu nedenle yorum yapılır, ancak XXX sürümünden önce değiştirilmesi gerekir."

Bir müşterinin kanamasını durdurmak için bir düzeltme yapıyorsanız ve nihai düzeltmeyi hemen bulma fırsatınız yoksa, yukarıdaki gibi bir yorum uygundur. Düzeltmeyi teslim ettikten sonra, yorumlanmış kod, hala düzeltilmesi gereken bir şeyin olduğunu hatırlatır.

Açıklanmış kodu ne zaman kontrol ederim? Bir örnek, yüksek olasılıkla yakın gelecekte bir şekilde yeniden eklenmesi gerekeceğini düşündüğüm bir şeyi geçici olarak kaldırdığım zamandır. Yorumlu kod, bunun eksik olduğuna dair doğrudan bir hatırlatma görevi görmek için oradadır. Elbette, eski sürüm kaynak denetimindedir ve bir FIXME açıklamasını daha fazlasına ihtiyaç olduğunu belirten bir işaret olarak kullanabilirsiniz . Bununla birlikte, bazen (sık değilse) kod daha iyi bir yorumdur.

Ayrıca, bir kod satırını (veya daha nadiren, iki satırını) kaldırarak bir hata düzeltildiğinde, bazen bu kodu bir neden ile asla yeniden etkinleştirmemek için bir yorum ekleyerek satırı yorumluyorum. Bu tür yorumlar açık, doğrudan ve özdür.

Rex M şunları söyledi: 1) Yalnızca tam işlevselliği kontrol edin, 2) [Eğer] görev çok büyükse - daha küçük tamamlanabilir görevlere bölün.

Yanıt olarak: Evet, bu ideal. Bazen üretim kodu üzerinde çalışırken ve düzeltmeniz gereken acil, kritik bir sorun olduğunda her iki seçeneğe de ulaşılamaz. Bazen bir görevi tamamlamak için alana bir süreliğine bir kod sürümü koymanız gerekir. Bu, özellikle bir sorunun temel nedenini bulmaya çalışırken veri toplama kodu değişiklikleri için geçerlidir.

Daha genel bir soruda sorulan belirli örnek için ... geliştirici, yorumlanmış kodu, geliştiriciden başka kimsenin görmeyeceği özel bir şubeye (ve belki de geliştiricinin işbirliği yaptığı birisine) kontrol ettiği sürece, çok az zarar verir. Ancak bu geliştirici, bu tür kodu (neredeyse) hiçbir zaman ana hat veya eşdeğerine teslim etmemelidir. Gövde her zaman inşa edilmeli ve her zaman çalışmalıdır. Bitmemiş kodu ana üniteye teslim etmek neredeyse her zaman çok kötü bir fikirdir. Bir geliştiricinin bitmemiş veya geçici kodu özel bir şubede kontrol etmesine izin verirseniz, o zaman geliştiricinin kodu santrala teslim etmeden önce temizlemeyi unutmamasına güvenmeniz gerekir.

Diğer yanıtlara verilen yorumlara yanıt olarak açıklığa kavuşturmak için, kod yorumlanır ve kontrol edilirse, kodun yorumlandığı süre ile birlikte yorumlanmaması durumunda kodun çalışacağına dair beklentim. Açıktır ki, yeniden düzenleme araçları her zaman yeniden düzenlemelerinde yorumları içermeyecektir. Hemen hemen her zaman, yorumlanmış kodu üretime koyarsam, kod, düzyazıdan daha spesifik bir şey olan ve orada bir şey yapılması gereken rafine bir yorum olarak hizmet etmek için oradadır. Uzun ömürlü olması gereken bir şey değil.

Son olarak, yorumlanmış kodu her kaynak dosyada bulabilirseniz, bir sorun var demektir. Yorumlu kodu herhangi bir nedenle bagaja göndermek nadir bir olay olmalıdır. Bu sık sık meydana gelirse, dağınıklığa dönüşür ve değerini kaybeder.

Bence asla çok güçlü bir durum değil.

Yorum yapma, kontrol etme, testleri çalıştırma, düşünme ve sonraki sürümden sonra yorumları kaldırma eğilimindeyim.

Genel olarak, yorumlanmış kodu iade etmek, orijinal yazar olmayanlar arasında kafa karışıklığı yarattığından ve kodu okuması veya düzeltmesi gerekenler arasında yanlıştır. Her halükarda, orijinal yazar 3 ay geçtikten sonra genellikle kodla ilgili kafası karışır.

Kodun şirkete veya takıma ait olduğu ve meslektaşlarınız için işleri kolaylaştırmanın sizin sorumluluğunuz olduğu inancını benimsiyorum. Yorumlu kodu kontrol etmek, ayrıca neden saklandığına dair bir yorum eklemeden şunları söylemekle aynı şeydir:

Bu şeylerin neden burada olduğu konusunda kafanız karışırsa umurumda değil. Benim ihtiyaçlarım seninkinden daha önemli, bu yüzden bunu yaptım. Bunu neden yaptığımı size veya bir başkasına haklı gösterme gereği duymuyorum.

Benim için yorumlanmış kod, normalde daha az düşünceli bir iş arkadaşının saygısızlığının bir işareti olarak görülür .

ŞİMDİ gibi küçük bir özellik veya hata düzeltmesi eklemeniz gerektiğinde, önümüzdeki 3 dakika içinde ve yarım gelişmiş kodunuz olan bir dosyayı düzeltmeniz gerektiğinde, sorun değil, pratik ihtiyaçlar savaş alanındaki pragmatik ideallere hükmeder.

Açıklanan kodun kontrol edilmemesi gerektiği ilkesine genel olarak katılıyorum. Kaynak kontrol sistemi paylaşılan bir kaynaktır ve meslektaşınız onu bir dereceye kadar kişisel not defteri olarak kullanıyor. Bu, özellikle kod tabanının ortak sahipliği fikrine abone olursanız, diğer kullanıcılar için pek düşünceli değildir.

Yorumlanan kodu gören bir sonraki geliştiricinin, devam eden bir çalışma olduğu konusunda hiçbir fikri olmayacaktı. Değiştirmekte özgür mü? Ölü kod mu? Bilmiyor.

Meslektaşınızın değişikliği kontrol edilebilecek bir durumda değilse, onu bitirmesi ve / veya daha küçük, kademeli değişiklikler yapmayı öğrenmesi gerekir.

"Uygulanabilecek veya yapılamayacak kısmi değişiklikleri kontrol etmek" - muhtemelen bu da test edilebileceği veya yapılamayacağı anlamına mı geliyor? Bu çok ipeksi bir kod tabanına doğru kaygan bir yokuş.

Bu, iki düşünce okulundaki temel bir farkı gösterir: Yalnızca memnun olduklarını ve hissettikleri çalışma kodunu kontrol edenler kurtarılmaya değerdir ve işlerini kontrol edenler, böylece revizyon kontrolü onları veri kaybına karşı geri döndürmek için oradadır.

İkincisini "revizyon kontrol sistemlerini fakir adamın teyp yedeği olarak kullanmak isteyenler" olarak nitelendirirdim, ama bu, hangi kampta olduğum konusunda elimi eğmek olur. :-)

Benim tahminim, sen "iyi kod" kampındasın ve o da "çalışma kodu" kampındasın.

[DÜZENLE]

Yorumlardan, evet doğru tahmin ettim.

Dediğim gibi, sizinle birlikteyim, ama söyleyebildiğim kadarıyla bu, hem burada stackoverflow hem de çalıştığım yerde bir azınlık görüşü. Bu nedenle, onu faaliyet göstermenin tek yolu olarak geliştirme standartlarınıza gerçekten yerleştirebileceğinizi düşünmüyorum. Yine de standartlara uyulmasını istiyorsanız, hayır. İyi bir liderin bildiği tek şey, takip edilmeyeceğini bildiği bir emri asla vermemektir .

btw: İyi editörler eski sürümleri korumaya yardımcı olacaktır. Örneğin, Emacs'ta eski-tutulan-eski-sürümleri ve eski-tutulan-sürümleri 10'a ayarladım, bu da dosyalarımın yaklaşık son 10 kaydını tutuyor. Yedek olarak revizyon-kontrol kalabalığına karşı argümanınıza yardımcı olmanın bir yolu olarak buna bakabilirsiniz. Ancak, tartışmayı asla kazanamayacaksınız.

Deneyimlerime göre, geliştirici anahtarları kod olarak yorumlanıyor.

Bazen yeni arka uçlar paralel olarak oluşturulur ve etkinleştirme anahtarları kaynak kontrolünde yorumlanır.

Mavi ayda bir kez ihtiyaç duyduğumuz ancak hiçbir müşterinin ihtiyaç duymayacağı bazı tuhaf özellikler genellikle bu şekilde uygulanır. Bu şeyler genellikle yüksek bir güvenlik veya veri bütünlüğü atlama riski taşır, bu nedenle geliştirme dışında aktif olmalarını istemiyoruz. İlk önce kodu açıklamasını kaldırmak için kullanacak bir geliştiriciye ihtiyaç duymak, onu elde etmenin en kolay yolu gibi görünüyor.

Eklenmiş kodun teslim edilmesinin bir başka nedeni:

Mevcut kodu değiştiriyorsunuz ve göz ardı edilmesi kolay ve belki de ilk bakışta doğru görünebilecek ince bir hata buldunuz. Yorum yapın, düzeltmeyi yerine koyun ve neler olup bittiğine ve neden değiştirildiğine ilişkin yorumlar ekleyin. Bunu kontrol edin, böylece düzeltmeyle ilgili yorumlarınız bilgi havuzunda olur.

Belki de buradaki asıl soru, geliştiricilerin eksik kodu kontrol etmelerine izin verilip verilmeyeceğidir?

Bu uygulama, belirttiğiniz sürekli entegrasyon uygulama hedefinizle çelişiyor gibi görünmektedir.

Değişir. Örnekleme amacıyla orada bırakılıyorsa, belki. Yeniden düzenleme sırasında muhtemelen yararlı olabilir. Aksi takdirde ve genellikle hayır. Ayrıca, tamamlanmamış kodu yorumlamak hem hataya açık hem de zaman kaybettirici olacaktır. Kodu daha küçük parçalara ayırması ve çalıştıklarında kontrol etmesi daha iyi olur.

Benim görüşüm: geliştiriciler kendi dallarında veya kendi sanal alanlarında çalışıyorsa, istedikleri her şeyi kontrol edebilmeliler. Kodu paylaşılan bir şubeye (bir özellik şubesi veya bir takımın şubesi veya tabii ki ANA / ana hat) kontrol ettiklerinde, kodun olabildiğince bozulmamış olması gerekir (açıklanmış kod yok, FIXME'ler yok, vb.).

"Asla" nın çok güçlü bir kural olduğunu düşünüyorum. İnsanların yorum yapılan kodu havuza girip girmediğini kontrol edip etmeme konusunda kişisel bir boşluk bırakmaya oy verirdim. Nihai hedef, "bozulmamış bir depo" değil, kodlayıcı üretkenliği olmalıdır.

Bu gevşekliği dengelemek için herkesin yorum yapılan kodun bir son kullanma tarihi olduğunu bildiğinden emin olun. Bir haftadır ortalarda bulunuyorsa ve hiç aktif değilse, herkesin yorumlanmış kodu silmesine izin verilir. ("Bir hafta" yı size doğru gelen şeyle değiştirin.) Bu şekilde, insanların kişisel tarzlarına çok fazla doğrudan müdahale etmeden karmaşayı gördüğünüzde öldürme hakkını saklı tutarsınız.

Açıklanan kodun depoda kontrol edilmemesi gerektiğine kesinlikle katılıyorum, bu kaynak kod kontrolü bunun içindir.

Deneyimlerime göre, bir programcı yorumlanmış kodu kontrol ettiğinde, bunun nedeni doğru çözümün ne olduğundan emin olmaması ve alternatif çözümü kaynakta başka birinin bu kararı vermesi umuduyla bırakmanın daha mutlu olmasıdır.

Kodu karmaşıklaştırıyor ve okumayı zorlaştırıyor.

Canlı sistem tarafından çağrılmayan yarı bitmiş kodu kontrol etmekte hiçbir sorunum yok (böylece kaynak kontrolünden faydalanırsınız). Benim sorunum, yorumlanmış kodun bölümlerini açıklama olmadan bulmakla ilgili ikilem, kodun hariç tutulmasıyla sonuçlandı.

Bir kaynak kodu kontrol sisteminde yorumlanmış kodun kontrol edilmesi son derece dikkatli yapılmalıdır, özellikle kodu yorumlamak için kullanılan dil etiketleri bloklar tarafından yazılıyorsa, yani:

/* My commented code start here
My commented code line 1
My commented code line 2
*/

Tek tek hat bazında değil, örneğin:

// My commented code start here
// My commented code line 1
// My commented code line 2

(kaptın bu işi)

Son derece dikkatli davranmamın nedeni, teknolojiye bağlı olarak, kullandığınız fark / birleştirme aracı konusunda çok dikkatli olmanız gerektiğidir. Belirli kaynak kodu kontrol sistemi ve belirli bir dil ile, farklılık / birleştirme aracı kolayca karıştırılabilir. Örneğin, ClearCase'in standart fark / birleştirme, .xml dosyalarını birleştirmek için kötü bir şöhrete sahiptir.

Yorumlama blok satırlarının düzgün bir şekilde birleştirilmemesi durumunda, kodunuz olmaması gerektiğinde sistemde etkin hale gelecektir. Kod eksikse ve yapıyı bozarsa, bu muhtemelen en az kötü olanıdır, çünkü hemen fark edeceksiniz.

Ancak kod yapıyı geçerse, orada olmaması gerektiğinde aktif hale gelebilir ve CM açısından bu bir kabus senaryosu olabilir. QA genellikle orada olması gereken şeyi test eder, orada olmaması gereken kod için test etmezler, bu nedenle kodunuz siz farkına bile varmadan üretime geçebilir ve farkına varıldığında kod oradadır. olmamalıydı, bakım maliyeti birçok kat arttı (çünkü "hata" üretimde veya müşteri tarafından keşfedilecek, şimdiye kadarki en kötü yer veya zamanda).

Kaynak-kontrol geçmişinin bir şeyi yorumlamak ve açıklamanın yanı sıra açıklamayı kontrol etmek yerine yapmanın "eski yolunu" göstermesine izin verme fikri teoride iyi bir fikirdir.

Ancak gerçek dünyada, bir tür resmi inceleme sürecinin parçası olmadıkça (yalnızca periyodik olarak yapılır) veya bir şey işe yaramazsa ve geliştirici, üzerinde çalıştıkları dosyaların kaynak kontrol geçmişine bakmaz. nedenini anlayamıyorum.

O zaman bile, yaklaşık 3 sürümden fazlasına bakıldığında temelde hiçbir zaman gerçekleşmez.

Kısmen, bunun nedeni kaynak kontrol sistemlerinin bu tür sıradan incelemeleri kolaylaştırmamasıdır. Genellikle eski bir sürümü kontrol etmeniz veya eski bir sürüme göre farklılık göstermeniz gerekir, yalnızca iki sürüm görürsünüz ve nelerin değiştiğine dair size bir bakışta bir fikir verebilecek neyin değiştiğine dair iyi ve özlü bir görüş yoktur.

Kısmen, insan doğası ile ekibin ihtiyaçlarının birleşimidir. Bir şeyi düzeltmek zorunda kalırsam ve birkaç saat içinde düzeltebilirsem, kodun bir aydır "yayında" olmayan eski sürümlerini araştırmak için bir saat harcamam (ki bu, her geliştiricinin sık sık, birçok revizyon anlamına gelir), orada bir şey olduğunu bilmediğim sürece (örneğin, şu anda yaptığım şeyle ilgili bir şeyi değiştirmeyle ilgili bir tartışmayı hatırlarsam).

Kod silinir ve tekrar iade edilirse, tüm amaç ve amaçlar için (tam bir geri almanın sınırlı amacı dışında) varlığı sona erer. Evet, yedekleme amacıyla oradadır, ancak kod kütüphanecisi rolünde bir kişi olmadan kaybolacaktır.

Mevcut projemdeki kaynak kontrol ağacım yaklaşık 10 haftalık, sadece yaklaşık 4 mühendisten oluşan bir ekipte ve yaklaşık 200 kararlı değişiklik listesi var. Ekibimin, sağlam ve kullanıma hazır bir şey olduğunda hemen kontrol etmek için yapması gerektiği kadar iyi bir iş yapmadığını biliyorum. Bu, her önemli değişikliği yakalamak için kodun her parçası için kod geçmişini okumaya güvenmeyi oldukça zorlaştırır.

Şu anda, bakım modundaki bir projeden çok farklı olan ilk geliştirme modunda bir proje üzerinde çalışıyorum. Her iki ortamda da aynı araçların çoğu kullanılır, ancak ihtiyaçlar oldukça farklılık gösterir. Örneğin, genellikle iki veya daha fazla mühendisin bir şeyler inşa etmek için biraz yakın çalışmasını gerektiren bir görev vardır (örneğin bir istemci ve bir tür sunucu).

Sunucuyu yazıyorsam, istemcinin kullanacağı taslak arabirim kodunu yazabilir ve istemciyi yazan mühendisin güncelleme yapabilmesi için tamamen işlevsel olmayan bir şekilde kontrol edebilirim. Bunun nedeni, bir mühendisten diğerine kod göndermenin tek yolunun kaynak kontrol sisteminden geçtiğini söyleyen bir politikaya sahip olmamızdır.

Görev yeterince uzun sürecekse, belki ikimiz için üzerinde çalışmamız için bir şube oluşturmaya değer olacaktır (bu benim kuruluşumdaki politikaya aykırı olsa da - mühendisler ve bireysel ekip liderleri gerekli izinlere sahip değil. kaynak kontrol sunucusu). Nihayetinde, bu bir değiş tokuş, bu nedenle çok fazla "her zaman" veya "asla" politika oluşturmamaya çalışıyoruz.

Muhtemelen böyle yorumlanmamış bir kod-hiç politikasına biraz saf olduğunu söyleyerek yanıt verirdim. Belki iyi niyetli, ama nihayetinde amacına ulaşma olasılığı düşük.

Bu gönderiyi görmek, geçen hafta kontrol ettiğim kod üzerinden geri dönecek ve hem asla nihai olmayan (işe yaramış olsa da) hem de bir daha asla istenmeyecek olan yorumlanmış kısmı kaldıracak.

Yorumlanan kodun "israf" olarak kabul edildiğini düşünüyorum.

Takım ortamında çalıştığınızı varsayıyorum. Kendi başınıza çalışıyorsanız ve bir 'yapılacaklar' ile kodu yorumluyorsanız ve ona geri döneceksiniz, o zaman bu farklıdır. Ancak bir ekip ortamında, yorumlanmış kodun kontrol edildiğinde, orada kalacağını ve büyük olasılıkla memnuniyetten daha fazla acıya neden olacağını güvenle varsayabilirsiniz.

Akran kodu incelemeleri yapıyorsanız, sorunuzu cevaplayabilir. Başka bir geliştirici kodunuzu inceler ve "neden 'falan' yapmaya çalışan bu açıklamalı kod var" diyorsa, kodunuz kod incelemesinde başarısız olmuştur ve yine de kontrol etmemelisiniz.

Açıklanan kod, yalnızca diğer geliştiricilere soru soracaktır - bu nedenle zaman ve enerji israfı olur.

Kodun " neden " yorumlandığını sormanız gerekir . Bazı öneriler:

Eğer "iş kurallarından emin olmadığınız" için kod hakkında yorum yapıyorsanız, muhtemelen "kapsam sürünmesi" ile ilgili bir sorununuz var - en iyisi, kod tabanınızı "sahip olmak güzel, ancak zamanımız olmayan gereksinimlerle kirletmemek uygulamak için "- açık bir kodla temiz tutun ve gerçekte orada olanı test edin.

"Bunu yapmanın en iyi yolu olup olmadığından emin olmadığınız" için kod hakkında yorum yapıyorsanız, o zaman kodunuzu meslektaşınızın gözden geçirmesini sağlayın! Zaman değişiyor, bugün yazdığınız koda 2 yıl sonra bakacak ve korkunç olduğunu düşüneceksiniz! Ama daha iyi yapılabileceğini 'bildiğiniz' şeyleri yorumlayamazsınız, ancak şu anda bir yol bulamazsınız. Uzun vadede kod tabanını koruyanın daha iyi bir yol olup olmadığını belirlemesine izin verin - sadece kodu yazın, test edin ve çalıştırın ve devam edin.

Kodu "bir şey işe yaramadığı" için yorum yapıyorsanız, DÜZELTİN ! Yaygın bir senaryo "bozuk testler" veya "yapılacaklar" dır . Bunlara sahipseniz, onları tamir ederek veya sadece onlardan kurtularak çok zaman kazanacaksınız. Bir süre "kırılabilirlerse", büyük olasılıkla sonsuza dek kırılabilirler.

Tüm bu potansiyel senaryolar (ve burada bahsetmediğim senaryolar) zaman ve emek israfıdır. Yorumlanan kod küçük bir sorun gibi görünebilir, ancak ekibinizdeki daha büyük bir sorunun göstergesi olabilir.

Depolar kodun yedeğidir. Kod üzerinde çalışıyorsam ancak tamamlanmadıysa, neden yorum yapıp günün sonunda kontrol etmeyeyim? Bu şekilde, sabit diskim bir gecede ölürse işimi kaybetmiş olmayacağım. Sabah kodu kontrol edebilirim, açıklamasını kaldırabilir ve devam edebilirim.

Bunu yorumlamamın tek nedeni, bir gecede yapıyı bozmak istemememdi.

Açıkça 1) erken kontrol ile 2) arşivi her zaman çalışır durumda tutmak arasında bir gerilim vardır. Birkaç geliştiriciniz varsa, ikincisi artan bir önceliğe sahip olacaktır, çünkü kendi kişisel iş akışı için herkesin üzerine sıçan bir geliştiriciye sahip olamazsınız. Bununla birlikte, ilk kılavuzun değerini küçümsememelisiniz. Geliştiriciler, her türden zihinsel çit direklerini kullanır ve kişiselleştirilmiş iş akışları, harika geliştiricilerin bu ekstra X'leri sıkıştırmasının bir yoludur. Bir yönetici olarak işiniz, bir dahi değilseniz ve tüm geliştiricileriniz aptal olmadıkça başarısız olacağınız tüm bu nüansları anlamaya çalışmak değil, bunun yerine geliştiricilerinizin kendi karar verme süreçleri yoluyla olabileceklerinin en iyisi olmasını sağlamaktır.

Özel şubeleri kullanmadığınızı yorumda belirtiyorsunuz. Benim sorum, neden olmasın? Tamam, TFS hakkında hiçbir şey bilmiyorum, bu yüzden belki iyi sebepler olabilir. Ancak git'i bir yıl kullandıktan sonra, iyi bir DVCS'nin bu gerilimi tamamen dağıttığını söylemeliyim. Bir yedek oluşturduğum için kod hakkında yorum yapmanın yararlı olduğunu düşündüğüm durumlar var, ancak bunu başkalarına uyguladığımda uykumu kaybedeceğim. Yerel olarak şubeleşme yapabilmek demek, geçici karışıklıkların aşağı akış geliştiricileri hakkında endişelenmek (hatta bunları bildirmek) zorunda kalmadan bireysel sürecim için anlamlı taahhütler yapabileceğim anlamına geliyor.

Sadece nakaratın yankılanması. Bunu ne pahasına olursa olsun caydırın. Kodun okunmasını zorlaştırır ve insanları şu anda uygulamanın bir parçası olmayan bu kod hakkında neyin iyi / kötü olduğunu merak etmeye bırakır. Revizyonları karşılaştırarak her zaman değişiklikleri bulabilirsiniz. Büyük bir ameliyat olsaydı ve kod toplu olarak yorumlandıysa, geliştiricinin bunu iade / birleştirme hakkındaki revizyon notlarına not etmesi gerekirdi.

eksik / deneysel kod tamamlanana kadar geliştirilecek bir dalda olmalıdır. baş / gövde, her zaman derleyen ve nakliye yapan ana hat olmalıdır. deneysel dal tamamlandığında / kabul edildiğinde, başlığa / ana hatta birleştirilmelidir. Destek belgelerine ihtiyacınız varsa bunu açıklayan bir IEEE standardı (IEEE 1042) bile vardır.

Muhtemelen bozuk, erişilebilir kodun henüz kullanılmamış, aynı kodun tamamen kullanılamaz olması nedeniyle kontrol edilmesini tercih ederim. Tüm sürüm kontrol yazılımı, bagajdan ayrı bir tür 'çalışma kopyasına' izin verdiğinden, bunun yerine bu özellikleri kullanmak gerçekten çok daha iyi bir fikirdir.

Yeni, işlevsel olmayan kod, yeni olduğu için bagajda iyidir. Muhtemelen zaten çalışan hiçbir şeyi bozmaz. Eğer çalışma kodunu bozarsa, o zaman sadece bir şubeye gitmelidir, böylece diğer geliştiriciler (gerekirse) o şubeyi kontrol edebilir ve neyin bozuk olduğunu görebilir.

" Yara Dokusu " yorumlanmış kod dediğim şeydir. Sürüm kontrol sistemlerinin yaygın olarak kullanılmasından önceki günlerde, Code Monkeys , işlevselliği geri döndürmeleri gerekmesi durumunda dosyada kodu yorum yapmamıştı .

"Skar dokusunu" kontrol etmenin kabul edilebilir olduğu tek zaman

1. Özel bir şubeniz varsa ve
2. Kodun hatasız derlenmesi için zamanınız yok ve
3. Uzun bir tatile gidiyorsun ve
4. Visual Source Safe OR kullanıyormuş gibi VCS'nize güvenmiyorsunuz .
   [DÜZENLE]
5. Yanlış kod hatırlatıcı olarak bırakılmazsa yeniden ortaya çıkabilecek ince bir hatanız var. (diğer cevaplardan iyi bir nokta).

4 numara için neredeyse hiçbir mazeret yok çünkü etrafta ücretsiz olarak kullanılabilen çok sayıda ve sağlam VCS sistemi var, Git en iyi örnek. .

Aksi takdirde, VCS'nin arşiviniz ve kod dağıtıcınız olmasına izin verin. Başka bir geliştirici kodunuza bakmak isterse, ona farklılıkları e-posta ile gönderin ve istediği şeyleri doğrudan uygulamasına izin verin. Her durumda, birleştirme, iki dosyanın kodlamasının neden veya nasıl farklılaştığını umursamaz.

Kod olduğu için yara dokusu, iyi yazılmış bir yorumdan bile daha dikkat dağıtıcı olabilir. Kod olarak doğası gereği, bakım programcısının yara dokusunun değişiklikleriyle bir ilgisi olup olmadığını anlamak için zihinsel işlemci döngüleri harcamasını sağlarsınız. Yara izinin bir haftalık mı yoksa 10 yaşında mı olduğu önemli değil, yara dokusunu şifreli olarak bırakmak, şifreyi deşifre etmek zorunda olanlar için bir yük oluşturuyor.

[DÜZENLE] Ayırt edilmesi gereken iki ana senaryo olduğunu eklemek isterim:

• özel bir geliştirme, kişisel bir projeyi kodlamak veya özel bir şubeye giriş yapmak
• Kontrol edilen kodun üretime sokulmasının amaçlandığı bakım geliştirme.

Sadece yara dokusuna "HAYIR" deyin!

Bilmiyorum - her zaman orijinali yorumlarım değişiklik yapmadan önce satırları yorumlarım - fikrimi değiştirirsem onları geri döndürmeme yardımcı olur. Ve evet onları kontrol ediyorum.

Bununla birlikte, önceki check-in işleminden eski yorumlanmış kodları çıkarıyorum.

Neyin değiştiğini görmek için fark günlüklerine bakabileceğimi biliyorum ama bu bir acı - koddaki son değişiklikleri görmek güzel.

Güzel bir uzlaşma, teslim alınmış / değiştirilmiş dosyalarınızı bir ağ yedekleme sürücüsüne aktaran küçük bir araç yazmaktır. Bu şekilde, kalbinizin içeriğini değiştirebilir ve çalışmanızın yedeklenmesini sağlayabilirsiniz, ancak asla deneysel veya bitmemiş kodu kontrol etmeniz gerekmez.

Yorumlu kodu kontrol etmenin geçerli olması gerektiğini düşünüyorum, çünkü yeni değişiklik testleri geçtiğinden, daha önce ne olduğunu görmek ve yeni değişikliğin gerçekten bir gelişme olup olmadığını görmek daha yararlı olabilir.

Şimdi bir performans artışına yol açan önceki bir değişikliği görmek için birkaç versiyona geri dönmem gerekirse, bu çok can sıkıcı olur.

Bazen açıklamalı kod iyi bir geçmiş olabilir, ancak kodun yorumlandığı zamana göre tarihler koyun. Daha sonra, orada çalışan biri, gerekli olmadığı kanıtlandığı için yorumlanmış kodu silebilir.

Bu kodu kimin yorumladığını bilmek de iyi olacaktır, böylece bir gerekçeye ihtiyaç duyulursa, o zaman sorulabilir.

Yeni işlevler yazmayı, birim testlerinin geçmesini sağlamayı, kontrol etmeyi, sonra başkalarının kullanmasına ve nasıl çalıştığını görmesini tercih ederim.

Henüz sonra, tam bu kod kadar kendine ait ayrı bir dalı tutmak için bu geliştirici için olurdu bu başa doğru "kaynak kontrol" yol değildir, çünkü geliştirici bazı kodunu yorumladı ise ise kontrol etmeye hazır içinde.

Bir DVCS ile (git, çarşı veya mercurial gibi) bu, merkezi depoda hiçbir değişiklik gerektirmediğinden son derece kolaydır. Aksi takdirde, geliştiricilere yeterince uzun zaman alacak belirli özellikler üzerinde çalışıyorlarsa (yani günler) sunucuda kendi şubelerini vermek hakkında konuşabilirsiniz.

Bazı durumlarda yorumlanmış kodu kontrol etmede yanlış bir şey yoktur, sadece bu, bunu yapmanın daha iyi bir yolunun olabileceği bir durumdur, böylece geliştirici hazır olmasa bile kaynağındaki değişiklikleri takip edebilir ana depoya girdi.

Açıkça, açıklamalı kodu kontrol eden geliştiricinin ayrı bir şubede çalışması ve gerekli olduğu üzere ana hat dalındaki değişiklikleri birleştirmesi gerekir.

Geliştiriciye bu iş akışında yardımcı olmak VCS sistemine bağlıdır (git bununla çok iyi çalışan mükemmel bir VCS sistemidir).