“Değişmez” olarak işaretlenmiş kodu tekrar gözden geçirmeli miyim?


148

Oldukça büyük bir kod temeli ile uğraşıyorum ve var olan kodu yeniden düzenlemek için birkaç ay verildi. Refactor işlemi gereklidir, çünkü yakında ürünümüze birçok yeni özellik eklememiz gerekecek ve şimdi olduğu gibi artık başka bir şey kırmadan hiçbir özellik ekleyemiyoruz. Kısacası, çoğumuzun kariyerlerinde gördüğü dağınık, kocaman, hata kodu.

Yeniden düzenleme sırasında, zaman zaman şöyle yorumlar yapan sınıf, yöntem veya kod satırları ile karşılaşıyorum.

Modül A'ya bazı şeyler yapması için zaman aşımına uğradı. Böyle zamanlanmış değilse, kopacak.

veya

Bunu değiştirmeyin. İnan bana, işleri kıracaksın.

veya

SetTimeout'u kullanmak iyi bir uygulama değil biliyorum ama bu durumda kullanmak zorunda kaldım

Sorum şu: yazarlardan bu tür uyarılarla karşılaştığımda kodu değiştirmeli miyim (hayır, yazarlarla iletişim kuramıyorum)?


157
Tebrikler! Artık kodun yazarı sizsiniz.

12
Hem ne yapılması gerektiğini hem de gerçekte ne yaptığını bilene kadar düzeltemezsiniz (değişikliklerin tüm sonuçlarını anlamak için ikincisini bilmeniz gerekir.) Sorun senkronizasyonda gibi görünüyor ve bu tür sorunları gideriyor gibi görünüyor. 1 numaralı işi yeniden düzenlemeli olmalı, yoksa işler her değişiklikle daha da kötüleşecek. Sormanız gereken soru bunun nasıl yapılacağıdır. Bu soruda oldukça fazla dil ve platform bağımlılığı var. örneğin: stackoverflow.com/questions/3099794/finding-threading-bugs
sdenham

14
@ Sdenham'ın yorumuna uymak: kod tabanınızı kullanan otomatik birim testleriniz yoksa, zamanınızı AFAICT ile "refactoring cadı avı" na harcamak yerine, bu tür birim testleri oluşturmak için harcamanızı öneririm akılda. Kod tabanınızı tamamen kullanan bir birim testler paketine sahip olduğunuzda, kodları hala yeniden yazmak zorunda kalırsanız / ne zaman çalıştığını bilmek için objektif bir yönteminiz olacaktır. İyi şanslar.
Bob Jarvis

17
Eğer yazarlar o kadar paranoyaksa, birileri ona yaklaşacak kadar nefes alırsa kodu kıracak, muhtemelen zaten kırılmış ve tanımsız davranış şu anda istedikleri şekilde çalışacak şekilde gerçekleşir. Bu ilki, özellikle kudret ettikleri bir ırk koşulu varmış gibi göründüğü için geliyor, bu yüzden çoğu zaman işe yarıyor. sdenham hak etti. Ne yapması gerektiğini anlayın ve aslında onun yaptığını varsaymayın.
Ray

7
@Ethan O kadar basit olmayabilir. Kodu değiştirmek, hemen görünmeyen şekillerde bozabilir. Bazen, bu mevcut refactorun buna neden olabileceğini unuttuktan uzun süre sonra kopar, bu yüzden tüm sahip olduğunuz gizemli sebeple "yeni" bir hatadır. Bu özellikle zamanlamayla ilgili olduğunda olasıdır.
Paul Brinkley

Yanıtlar:


225

Yeni özellik geliştirmenin gerçekleştiği zaman kod üssünün hangi kısımlarının ayrıntılı olarak değiştirileceğini tam olarak bilmeden "tam olarak" yeniden düzenlemekte olduğunuz anlaşılıyor . Aksi takdirde, kırılgan modüllerin yeniden yapılandırılması için gerçek bir ihtiyaç olup olmadığını veya onları olduğu gibi bırakıp bırakamayacağınızı bilirsiniz.

Bunu açıkça söylemek gerekirse: Bunun mahkum bir refactoring stratejisi olduğunu düşünüyorum . Hiç kimsenin gerçekten fayda sağlayamayacağının bilmediği bir şey için şirketinize zaman ve para yatırıyorsunuz ve hataları çalışma koduna sokarak işleri daha da kötüleştiriyorsunuz.

İşte daha iyi bir strateji: için zamanınızı kullanın

  • risk altındaki modüllere otomatik testler (muhtemelen ünite testleri değil, entegrasyon testleri) ekleyin. Özellikle bahsettiğiniz kırılgan modüller, içindeki herhangi bir şeyi değiştirmeden önce tam bir test odasına ihtiyaç duyacak.

  • refactor sadece testleri yerine getirmek için ihtiyacınız olan bitleri. Gerekli değişikliklerden herhangi birini en aza indirmeye çalışın. Bunun tek istisnası, testlerinizin hataları ortaya çıkarmasıdır - ardından hemen düzeltin (ve bunu güvenle yapmanız için gereken dereceye kadar yeniden ayarlayın).

  • meslektaşlarınıza "izci ilkesi" (AKA "fırsatçı yeniden düzenleme" ) öğretin ; böylece takım yeni özellikler eklemeye başladığında (veya hataları düzeltmeye başladığında), tam olarak değiştirmeleri gereken kod tabanının parçalarını iyileştirmeli ve yeniden düzenlemelidir. az değil, fazla değil.

  • ekibin Feather adlı kitabının "Eski kodla etkin bir şekilde çalışması" kitabının bir kopyasını alın.

Dolayısıyla , kırılgan modüllerini değiştirmeniz ve yeniden kırmanız gerektiğinden emin olduğunuz zamanlar geldiğinde (yeni özellik geliştirme nedeniyle veya 1. adımda eklediğiniz testler bazı hataları ortaya çıkarır), o zaman siz ve ekibiniz hazır modülleri yeniden düzenleyin ve bu uyarı yorumlarını aşağı yukarı güvenli bir şekilde yok sayın.

Bazı yorumlara cevap olarak : Adil olmak gerekirse, mevcut bir üründe bir modülün düzenli olarak sorunlara neden olduğundan şüpheleniliyorsa, özellikle de "dokunma" olarak işaretlenen bir modül olduğundan şüphelenirseniz, hepsine katılıyorum sen. Bu süreçte gözden geçirilmeli, hata ayıklanmalı ve büyük olasılıkla yeniden ele alınmalıdır (bahsettiğim testlerin desteğiyle ve mutlaka bu sıraya göre değil). Hatalar, değişim için güçlü bir gerekçedir, genellikle yeni özelliklerden daha güçlüdür. Ancak, bu bir durum karardır. "Dokunma" olarak işaretlenmiş bir modülde bir şeyleri değiştirmenin gerçekten zor olup olmadığına değinmek çok dikkatli olmalı.


70
Aşağı oy vermeye cazip geliyorum ama kaçınacağım. Bu zihniyetin çok sayıda projede daha kötü bir ürüne yol açtığını gördüm. Başarısızlıklar bir kez gerçekleştiğinde, genellikle felakete yol açarlar ve görevlerinden dolayı düzeltmeleri çok daha zordur. Gördüğüm çamuru düzenli olarak düzeltirim, ve en çok düzelttiği kadar sorun yaratır ya da en azından bilinen hiçbir sorunu bırakmadığı görülüyor; Genel olarak büyük bir artı. VE sonra kod gelecekteki gelişim için daha iyidir. Zaman içindeki bir dikiş dokuzdan tasarruf sağlar, ancak göz ardı edilen bir sorun daha da kötüleşebilir.
Aaron,

98
Bir yorum ile işaretlenmiş herhangi bir kod "Zaman modülü şeyler yapmak için biraz zaman vermek için ayarlanır. Onun böyle zamanlanmış Değilse, kıracak" iddia ediyorum zaten bir hata var. Böceğe çarpılmadığı için çekiliş şansı.
17

10
@ 17of26: mutlaka bir hata. Bazen 3. parti kütüphanelerle çalışırken, işe yaraması için her türlü "şıklık" imtiyazlarını almaya zorlanırsınız.
whatsisname,

30
@ 17/26: tehlikede olan bir modülün hatalarından şüpheleniliyorsa, herhangi bir yeniden yapılandırmadan önce test eklemek daha da önemlidir. Ve bu testler hatayı açığa çıkardığında, o zaman bu modülü değiştirmeye ihtiyaç duyuyorsunuz ve bu nedenle derhal yenilemek için bir meşruiyetiniz var. Testler herhangi bir hata ortaya çıkarmazsa, kodu olduğu gibi bırakın.
Doktor Brown

17
@Aaron: Neden test ekleyerek ya da izci ilkesini izleyerek sonuçta ürün kalitesini düşürdüğünü düşündüğünüzü anlamıyorum.
Doktor Brown

142

Evet, diğer özellikleri eklemeden önce kodu tekrar gözden geçirmelisiniz.

Bunun gibi yorumlarla ilgili sorun, kod tabanının çalıştığı ortamın özel koşullarına bağlı olmalarıdır. Belirli bir noktada programlanan zaman aşımı, programlandığı zaman gerçekten gerekli olabilir.

Ancak bu denklemi değiştirebilecek çok şey var: donanım değişiklikleri, işletim sistemi değişiklikleri, başka bir sistem bileşenindeki alakasız değişiklikler, tipik veri hacimlerindeki değişiklikler, siz adlandırın. Günümüzde hala gerekli olduğuna veya hala yeterli olduğuna dair hiçbir garanti yoktur (korunması gereken şeyin bütünlüğü uzun süredir bozulmuş olabilir - uygun regresyon testleri olmadan asla farketmeyebilirsiniz). Bu nedenle, başka bir bileşenin sonlandırılmasına izin vermek için sabit bir gecikmenin programlanması neredeyse her zaman yanlıştır ve yalnızca yanlışlıkla çalışır.

Senin durumunda, asıl koşulları bilmiyorsun ve asıl yazarlara da soramazsın. (Muhtemelen ayrıca uygun regresyon / entegrasyon testine sahip değilsinizdir, ya da devam edip testlerinizin size bir şeyleri kırıp açmadığınızı söylemesini sağlayabilirsiniz.)

Dikkatli olmayan bir şeyi değiştirmeme argümanı gibi görünebilir; ama yine de büyük değişiklikler yapılması gerektiğini söylüyorsunuz, bu yüzden bu noktada elde edilen hassas dengeyi bozma tehlikesi zaten orada. Yaptığınız tek şey yeniden yapılanma olduğunda, el arabasını üzmek şimdi çok daha iyidir ve işler kırılırsa, aynı anda ve asla ek değişiklikler yapana kadar beklemekten çok, bunun sebep olduğu yeniden yapılanma olduğundan emin olun. emin ol.


46
Burada en iyi cevap; Çok kötü bir serseri. Yukarıda kabul edilen cevap, iyi bir tavsiye değil, özellikle de "mahkum" vurgusu. Geçen yılı , şimdiye kadar gördüğüm en büyük (~ 10 ^ 6LOC sadece benim bölümüm için ), eski-est, aweful kod üzerinde çalışarak geçirdim ve bulunduğumda gördüğüm tren enkazlarını tamir etmeyi alışkanlık haline getirdim üzerinde çalıştığım bileşenin bir parçası olmasa bile zaman. Bunu yaparken, dev ekibin farkında bile olmadığına dair hatalar tespit ettim (son kullanıcılarımız muhtemelen olsa da). Aslında, bana talimat verildi. Sonuç olarak ürün geliştirildi.
Aaron,

10
Buna refactoring demiyorum, ama hata düzeltme.
Paŭlo Ebermann

7
Bir kod temeli tasarımını iyileştirmek yeniden yapılanmadır. Yeniden tasarlama, düzeltilebilecek hatalar ortaya çıkarırsa, bu hata onarımı demektir. Demek istediğim, birincisinin genellikle ikinciye yol açtığı ve ikincisinin de ilk olmadan çok zor olduğu.
Kramii

10
@Aaron bunu yaparken yönetim / geliştirici desteğine sahip olduğunuz için şanslısınız. Çoğu ortamda, zayıf tasarım ve kodun neden olduğu bilinen ve bilinmeyen hatalar, şeylerin doğal düzeni olarak kabul edilir.
Rudolf Olah

5
@nocomprende Eğer sistemi bazı testler yazmak için yeterince iyi anlamazsanız, çalışma şeklini değiştirecek bir işiniz olmadığını savunuyorum.
Patrick M,

61

Sorum şu: yazarlardan bu tür uyarılarla karşılaştığımda kodu tekrar gözden geçirmeli miyim?

Hayır ya da en azından henüz değil. Otomatik test seviyesinin çok düşük olduğunu ima ediyorsunuz. Güvenle refactor yapmadan önce testlere ihtiyacınız var.

şimdilik başka bir şey kırmadan herhangi bir özellik ekleyemiyoruz

Şu anda refactoring'e değil istikrarı artırmaya odaklanmanız gerekiyor. Stabilite artışının bir parçası olarak yeniden yapılanma işlemini gerçekleştirebilirsiniz, ancak gerçek hedefinize ulaşmak için bir araçtır - kararlı bir kod temeli.

Bunun eski bir kod temeli haline geldiği anlaşılıyor, bu yüzden ona biraz daha farklı davranmanız gerekiyor.

Karakterizasyon testleri ekleyerek başlayın. Herhangi bir özellik hakkında endişelenmeyin, yalnızca mevcut davranışı öne süren bir test ekleyin. Bu, yeni çalışmaların mevcut özellikleri bozmasını önlemeye yardımcı olacaktır.

Bir hatayı her düzeltişinizde, hatanın giderildiğini ispatlayan bir test durumu ekleyin. Bu doğrudan gerilemeleri önler.

Yeni bir özellik eklediğinizde, yeni özelliğin amaçlandığı şekilde çalıştığını en azından bazı temel testler ekleyin.

Belki de "Eski Kod ile Etkili Çalışma" nın bir kopyasını edindiniz?

Var olan kodu yeniden düzenlemek için birkaç ay verildi.

Test kapsamını artırarak başlayın. En çok kırılan alanlarla başlayın. En çok değişen alanlarla başlayın. Ardından, kötü tasarımları belirledikten sonra, onları birer birer değiştirin.

Neredeyse hiç bir zaman büyük bir refraktör yapacak biri değil, bunun yerine her hafta sürekli küçük refraktör akışı. Büyük bir refaktörün işleri kırma riski çok yüksektir ve iyi test edilmesi zordur.


10
Karakterizasyon testleri eklemek için +1. Test edilmemiş eski kodu değiştirirken, gerilemeleri en aza indirmenin tek yolu budur. Eğer bir kez değişiklik yapmaya başladığınızda testler başarısız olmaya başlarsa, teknik özellik yerine önceki davranışın gerçekten doğru olup olmadığını veya yeni değiştirilen davranışın doğru olup olmadığını kontrol edebilirsiniz.
Leo

2
Sağ. Kullanılabilir bir spesifikasyon yoksa, önceki davranışın aslında yazılımı ödeyen veya ilgilenen kişiler tarafından istenip istenmediğini kontrol edin.
bdsl

Belki de "Eski Kod ile Etkili Çalışma" nın bir kopyasını edindiniz? Bu kitabı okuması kaç hafta alacak? Ve ne zaman: İşyerinde çalışma saatleri sırasında, herkesin uyuduğu geceler?
Billal Begueradj

23

GK Chesterton'ın çitlerini hatırlayın : neden yapıldığını anlayana kadar bir yolu tıkayan bir çit çekmeyin.

Kodun yazarlarını ve söz konusu yorumları bulabilir ve anlayışı elde etmek için bunlara danışabilirsiniz. Taahhüt mesajlarına, e-posta konularına veya varsa dokümanlara bakabilirsiniz. O zaman ya işaretlenmiş parçayı yeniden düzenleyebileceksiniz ya da yorumlarda bilginizi yazacaksınız, böylece bu kodu koruyacak bir sonraki kişi daha bilinçli bir karar verebilir.

Amacınız, kodun ne yaptığını ve neden bir uyarı ile işaretlendiğini ve uyarı göz ardı edilirse ne olacağını anlamaktır.

Ondan önce "dokunma" yazan koda dokunmam.


4
OP "hayır, yazarlarla iletişim kuramıyorum" diyor.
FrustratedWithFormsDesigner

5
Yazarlarla iletişim kuramıyorum ya da herhangi bir belge yok.
kukis

21
@kukis: Yazarlarla, etki alanı uzmanlarıyla iletişim kuramıyor ve söz konusu kodla ilgili herhangi bir e-posta / wiki / docs / test vakası bulamıyor musunuz? Öyleyse, basit bir yeniden düzenleme görevi değil, yazılım arkeolojisinde kapsamlı bir araştırma projesi.
9000

12
Kodun eski olması ve yazarların bırakması alışılmadık bir durum değil. Eğer bir rakip için çalışmaya başladılarsa, tartışmak birinin NDA'sını ihlal edebilir. Bazı durumlarda yazarlar kalıcı olarak kullanılamıyor: Phil Katz'a PKzip'i soramazsınız, çünkü yıllar önce öldü.
pjc50

2
"Yazarı bulma" yla "kodun hangi sorunu çözdüğünü" anlama "ile değiştirirseniz, bu en iyi cevaptır. Bazen bu kod parçaları, haftalarca veya aylarca aylarca çalışılan ve izlenen ve uğraşılan, genellikle normal birim test türlerinin bulamadığı hatalara karşı en korkunç çözümdür. (Bazen ne yaptıklarını bilmeyen programcıların sonucu olsalar da. İlk göreviniz hangisi olduğunu anlamaktır.)
Grahamparks

6

Gösterdiğiniz gibi yorumlar içeren kod, refactor için yapılacaklar listemde en üst sırada yer alacak , ancak bunu yapmak için bir nedenim varsa . Mesele şu ki, kod çok kötü kokuyor, yorumlardan bile kokuyorsun. Herhangi bir yeni işlevi bu koda sokmaya çalışmak anlamsızdır, bu kodun değişmesi gerektiği anda ölmesi gerekir.

Ayrıca, yorumların en azından yardımcı olmadığına dikkat edin: Yalnızca uyarı veriyorlar ve sebep yok. Evet, onlar bir köpekbalığı tankının etrafındaki uyarı işaretleridir. Ancak civarda bir şey yapmak istiyorsanız, köpekbalıklarıyla yüzmeye çalışmak için küçük noktalar vardır. Imho, önce o köpekbalıklarından kurtulmalısın.

Bu, böyle bir kod üzerinde çalışmaya cesaret edemeden önce kesinlikle iyi test vakalarına ihtiyacınız olduğunu söyledi. Bu test vakalarına sahip olduktan sonra, davranışlarınızı gerçekten değiştirmediğinizden emin olmak için değiştirdiğiniz her küçük parçacığı anladığınızdan emin olun. Herhangi bir etkisi olmadıklarını ispatlayana kadar, kodun tüm davranışsal özelliklerini korumak için birinci önceliğinizi yapın. Unutma, köpekbalıklarıyla uğraşıyorsun - çok dikkatli olmalısın.

Bu nedenle, zaman aşımı durumunda: Kodun tam olarak ne beklediğini tam olarak anlayana kadar içeride bırakın ve sonra da kaldırmaya devam etmeden önce zaman aşımının neden ortaya çıktığını belirtin.

Ayrıca, patronunuzun ne tür bir çabaya başladığınızı ve neden gerekli olduğunu anladığından emin olun. Ve eğer hayır derlerse, yapma. Bu konuda kesinlikle onların desteğine ihtiyacın var.


1
Bazen kod, kirletici bir karmaşaya yol açar, çünkü gerçek davranışı dokümantasyonla uyuşmayan silikon üretim öncesi numunelerinde doğru çalışması gerekir. Geçici çözümlerin niteliğine bağlı olarak, kodun buggy yongalarında çalıştırılması gerekmeyecekse, kodu değiştirmek iyi bir fikir olabilir, ancak yeni kod için gerekli olacak mühendislik analizi düzeyi olmadan kodu değiştirmek muhtemelen iyi değildir fikir.
supercat,

@supercat Puanlarımdan biri, yeniden yapılanmanın davranışları mükemmel bir şekilde koruması gerektiğidir. Davranışı korumazsa, kitabımda yeniden yapılanmaktan daha fazlası (ve bu tür eski kodlarla uğraşırken aşırı derecede tehlikeli).
cmaster

5

Muhtemelen işler iyi çalışıyorsa, bu tür uyarılarla yeniden düzenleme yapmak iyi bir fikir değildir.

Ama yeniden ateşlenmen gerekiyorsa ...

İlk olarak, uyarıların sizi uyardığı koşulları test etmek için bazı birim testleri ve entegrasyon testleri yazın. Üretime benzer koşulları mümkün olduğunca taklit etmeye çalışın . Bu, üretim veritabanını bir test sunucusuna yansıtmak, makinede aynı servisleri çalıştırmak, vb. Sonra yeniden yönlendirme yapmaya çalışın (tabii ki izole bir dalda). Ardından, orijinal sonuçlarıyla aynı sonuçları alıp alamayacağınızı görmek için testlerinizi yeni kodunuzda çalıştırın. Yapabiliyorsanız, yeniden üretiminizi üretimde uygulamak muhtemelen sorun değil. Ancak işler ters giderse değişiklikleri geri almaya hazır olun.


5

Devam et ve değiştir diyorum. İster inanın ister inanmayın, her kodlayıcı bir dahi değildir ve bunun gibi bir uyarı iyileştirme için bir nokta olabileceği anlamına gelir. Yazarın haklı olduğunu tespit ederseniz, uyarının nedenini BELİRTEBİLİR veya BELİRTABİLİRSİNİZ.


4

Yorumlarımı bir cevaba genişletiyorum çünkü belirli bir sorunun bazı yönlerinin gözden kaçırıldığını ya da yanlış sonuçlara varmak için kullanıldığını düşünüyorum.

Bu noktada, refactor olup olmadığı sorusu erkendir (muhtemelen belirli bir 'evet' şeklinde cevaplanmış olsa bile).

Buradaki temel sorun, (bazı cevaplarda belirtildiği gibi) alıntı yaptığınız yorumların, kodun burada tartışıldığı gibi yarış koşullarına veya diğer eşzamanlılık / senkronizasyon sorunlarına sahip olduğunu göstermesidir . Bunlar birkaç nedenden ötürü özellikle zor problemlerdir. İlk olarak, gördüğünüz gibi, görünüşte ilgisiz değişiklikler sorunu tetikleyebilir (diğer böcekler de bu etkiye sahip olabilir, ancak eşzamanlılık hataları hemen hemen her zaman yapar.) İkincisi, teşhis edilmesi çok zordur: böcek genellikle kendisini bu alanda gösterir. zamanından veya koddan uzak olduğundan ve teşhis etmek için yaptığınız her şey kaybolmasına neden olabilir ( Heisenbugs).). Üçüncüsü, eşzamanlılık hatalarının testlerde bulunması çok zordur. Kısmen, bu birleşme patlaması nedeniyle gerçekleşir: sıralı kod için yeterince kötüdür, ancak eşzamanlı uygulamanın olası birleştirmelerinin eklenmesi sıralı sorunun kıyaslandığında önemsiz hale geldiği noktaya kadar yükseltir. Ek olarak, iyi bir test durumu bile sadece zaman zaman sorunu tetikleyebilir - Nancy Leveson, Therac 25'teki ölümcül böceklerden birinin olduğunu hesapladı.350 çalışmanın 1'inde gerçekleşti, ancak hatanın ne olduğunu bilmiyorsanız veya bir tanesinin olduğunu bile bilmiyorsanız, kaç tekrarın etkili bir test yaptığını bilmiyorsunuz. Ek olarak, bu ölçekte yalnızca otomatik testler yapılabilir ve test sürücüsünün hatayı gerçekten asla tetiklemeyeceği şekilde ince zamanlama kısıtlamaları getirmesi mümkündür (Heisenbugs).

POSIX pthreads kullanarak kod için Helgrind gibi bazı ortamlarda eşzamanlılık testi için bazı araçlar vardır , ancak burada özellikleri bilmiyoruz. Çevreniz için uygun araçlar varsa, testler statik analizle desteklenmelidir (veya bu tam tersi mi?).

Zorluğa ek olarak, derleyiciler (ve çalışma zamanındaki işlemciler bile) kodu bazen kendi iş güvenliği konusunda akıl almaz derecede sezgisel olarak mantıklı kılacak şekilde yeniden düzenlemek için özgürdür (belki de en iyi bilinen durum çift ​​kontrol edilir) deyim kilidini , bazı ortamlar (Java, C ++ ...) düzeltmek için değiştirilmiş olsa da.)

Bu kodun tüm belirtilere neden olan basit bir sorunu olabilir, ancak durdurma işlemine yeni özellikler eklemek için planlarınızı getirebilecek sistemik bir sorun yaşamanız daha olasıdır. Umarım sizi elinizde ciddi bir sorun olabileceğine, muhtemelen ürününüz için varoluşsal bir tehdit olabileceğine ikna etmişimdir ve yapılacak ilk şey ne olduğunu bulmaktır. Bu eşzamanlılık sorunlarını ortaya çıkarırsa, daha önce genel refactoring yapıp yapmamanız sorusunu sormadan önce ve daha fazla özellik eklemeyi denemeden önce sormanızı şiddetle tavsiye ederim.


1
Yorumlarda "ırk durumu" nu görüyorsunuz? Nerede ima ediliyor? Burada kodda görmenin faydası bile olmadan çok fazla teknik varsayımda bulunuyorsunuz.
Robert Harvey,

2
@RobertHarvey "Modül A'ya bazı şeyler yapması için zaman aşımına uğradı." - hemen hemen bir yarış koşulunun tanımı ve zaman aşımları bunlarla başa çıkmak için sağlam bir yol değildir. Bu çıkarımı çizen sadece ben değilim. Burada bir sorun yoksa, sorun değil, ancak bu yorumların yetersiz işlenen senkronizasyon için kırmızı bayraklar olduğu düşünülürse, sorgulamanın bilmesi gerekir.
sdenham

3

Oldukça büyük bir kod temeli ile uğraşıyorum ve var olan kodu yeniden düzenlemek için birkaç ay verildi. Refactor işlemi gerekli çünkü yakında ürünümüze birçok yeni özellik eklememiz gerekecek [...]

Yeniden yapılanma sırasında, zaman zaman ["buna dokunma!" Gibi yorumların olduğu sınıf, yöntem veya kod satırlarıyla karşılaşıyorum.

Evet, özellikle bu parçaları yeniden kırmalısınız . Bu uyarılar, önceki yazarlar tarafından "bu şeyleri boşuna oynama, çok karmaşık ve çok fazla beklenmedik etkileşimler var" demek için yerleştirildi. Şirketiniz yazılımı daha da geliştirmeyi ve birçok özellik eklemeyi planladığından, bu şeyleri temizlemede size özellikle görev verdi. Yani boşa uğraşmazsınız, kasıtlı olarak temizlemekten vazgeçersiniz.

Bu zor modüllerin ne yaptığını öğrenin ve daha küçük sorunlara (orijinal yazarların yapması gereken) ayırın. Bir karmaşadan korunabilir kod elde etmek için, iyi kısımların yeniden düzeltilmesi ve kötü kısımların yeniden yazılması gerekir .


2

Bu soru, ne zaman / nasıl refactor ve / veya temizleme kodunun “kodun devralınması” işareti ile tartışılmasının bir başka çeşididir. Hepimizin farklı deneyimleri var ve farklı ekip ve kültürlere sahip farklı organizasyonlarda çalışıyoruz, bu nedenle "yapmanız gerektiğini düşündüğünüz şeyi yapın ve sizi kovmayacak şekilde yapın" dır. .

Bir iş sürecinin kendi tarafına düşmesini nazikçe alacak birçok kuruluş olduğunu sanmıyorum çünkü destekleyici uygulamanın kod temizleme veya yeniden düzenleme işlemine ihtiyacı vardı.

Bu özel durumda, kod yorumları, kodun bu bölümlerinin değiştirilmemesi gerektiğinin işaretini kaldırmaktadır. Öyleyse devam ederseniz ve iş yanına düşerse, yalnızca eylemlerinizi desteklemek için gösterecek bir şeyiniz olmaz, aslında kararınıza aykırı bir eser vardır.

Her zaman olduğu gibi, dikkatlice ilerlemeli ve sadece değişmek üzere olduğunuzu her yönünü anladıktan sonra değişiklik yapmalı ve bunun nedeniyle kapasiteye, performansa ve zamanlamaya çok dikkat ederek, dikkatini test etmenin yollarını bulmalısınız. Koddaki yorumlar.

Ancak yine de, yönetiminiz ne yaptığınızdaki doğal riski anlamak zorundadır ve yaptığınız şeyin riske ağır basan bir işletme değeri olduğunu ve bu riski azaltmak için ne yapabileceğinizi kabul etmesi gerekir.

Şimdi, hepimiz kendi TODO'larımıza geri dönelim ve bildiğimiz şeyler, daha fazla zaman olsaydı, kendi kod oluşturmalarımızda geliştirilebilir.


1

Evet kesinlikle. Bunlar, bu kodu yazan kişinin koddan memnun olmadığının ve işe yarayana kadar büyük olasılıkla düştüğünün açık göstergeleridir. Gerçek meselelerin ne olduğunu anlamadılar ya da daha kötüsü, onları anladılar ve düzeltmek için çok tembellerlerdi.

Ancak, bunları düzeltmek için çok çaba sarfedilmesi gerektiği ve bu düzeltmelerin kendisiyle ilişkili riskleri olacağı konusunda bir uyarı verilir.

İdeal olarak, sorunun ne olduğunu çözebilecek ve düzgün bir şekilde düzeltebileceksiniz. Örneğin:

Modül A'ya bazı şeyler yapması için zaman aşımına uğradı. Böyle zamanlanmış değilse, kopacak.

Bu, Modül A'nın ne zaman kullanıma hazır olduğunu veya işlemeyi ne zaman bitirdiğini uygun şekilde göstermediğini göstermektedir. Belki de bunu yazan kişi, Modül A'yı tamir etmeyi rahatsız etmek istemedi veya bir sebepten ötürü yapamadı. Bu, gerçekleşmeyi bekleyen bir felakete benziyor, çünkü uygun sıralamadan ziyade şansla uğraşılan bir zamanlama bağımlılığı öneriyor. Bunu görseydim düzeltmek isterdim.

Bunu değiştirmeyin. İnan bana, işleri kıracaksın.

Bu size pek söylemez. Kodun ne yaptığına bağlı. Bu, bir nedenden ötürü, gerçekten de kodu kıracağı açık optimizasyonlar olduğu anlamına gelebilir. Örneğin, bir döngü başka bir kod parçasının dayandığı belirli bir değerde bir değişken bırakıyor olabilir. Veya bir değişken başka bir dizide test edilebilir ve değişken güncellemelerinin sırasını değiştirmek diğer kodu kırabilir.

SetTimeout'u kullanmanın iyi bir uygulama olmadığını biliyorum, ancak bu durumda kullanmak zorunda kaldım.

Bu kolay birine benziyor. Ne setTimeoutyaptığını görebilmeli ve belki de daha iyi bir yol bulmalısın.

Bununla birlikte, bu tür düzeltmeler refactorünüzün kapsamı dışındaysa, bu kodun içinde yeniden düzenlemeye çalışmanın çabalarınızın kapsamını önemli ölçüde artırabileceğinin belirtileridir.

En azından, etkilenen koda yakından bakın ve yorumu en azından sorunun ne olduğunu daha net bir şekilde açıkladığı noktaya getirip geliştiremediğinizi görün. Bu, bir sonraki kişiyi, karşılaştığınız gizemle yüzleşmekten kurtarabilir.


2
Eski sorunların artık var olmadığı noktaya kadar koşulların değişmiş olması muhtemeldir ve uyarı yorumları “İşte ejderhalar” diyen eski haritalardaki yerlere dönüşmüştür. Dalışın ve durumun ne olduğunu öğrenin ya da tarihe geçtiğini görün.

2
Gerçek dünyada, bazı cihazlar güvenilir bir hazırlık göstergesi sağlamaz, bunun yerine önceden bilinmeyen bir maksimum süre belirtir. Güvenilir ve verimli hazırlık endikasyonları iyidir, ancak bazen birileri onlarsız kullanarak sıkışıp kalıyor.
supercat,

1
@supercat Belki, belki de değil. Buradaki yorumdan anlatamayız. Bu yüzden, başka hiçbir şey yapmıyorsa, yorumun spesifikasyonlarla geliştirilmesini araştırmaya değer.
David Schwartz

1
@DavidSchwartz: Yorum kesinlikle daha yararlı olabilir, ancak bazen bir programcının bir cihazın özelliklerine uymadığı, özellikle de sorunun beklenip beklenmediği belli değilse, tüm kesin yollarını bulmaya çalışmak için ne kadar zaman harcaması gerektiği belirsizdir. geçici veya kalıcı bir şey olmak.
supercat

1

Yorumların yazarı büyük olasılıkla kodu tam olarak anlamadı . Aslında ne yaptıklarını biliyorlardı, gerçekten yararlı yorumlar yazıyorlardı (ya da ilk olarak yarış koşullarını getirmiyorlardı). " Bana güven, bir şeyleri kıracaksın " gibi bir yorum bana göre yazarın tam olarak anlamadığı beklenmeyen hatalara neden olan bir şeyi değiştirmeye çalışıyor.

Kod, muhtemelen olanları tam olarak anlamadan tahmin etme ve deneme yanılma yoluyla geliştirilir.

Bu şu anlama gelir:

  1. Kodu değiştirmek risklidir. Açıkça anlaşılması zaman alacak ve muhtemelen iyi tasarım ilkelerini izlemiyor ve belirsiz etkileri ve bağımlılıkları olabilir. Büyük olasılıkla yetersiz bir şekilde test edilmiştir ve hiç kimse kodun ne yaptığını tam olarak anlamazsa, davranışlarda hata veya değişiklik yapılmamasını sağlamak için testler yazmak zor olacaktır. Yarış koşulları (haklı yorumlar gibi) özellikle zahmetlidir - bu, ünite testlerinin sizi kurtarmayacağı bir yerdir.

  2. Riskli değil kodunu değiştirmek için. Kod, belirsiz böcek ve yarış koşullarını içerme olasılığının yüksek olması. Kodda kritik bir hata bulunursa veya yüksek öncelikli bir iş gereksinimi değişikliği bu kodu kısa sürede değiştirmenize zorlarsa, başınız büyük belada demektir. Şimdi 1'de ana hatlarıyla belirtilen tüm sorunlara sahipsiniz ancak zaman baskısı altındasınız! Ayrıca, koddaki bu "karanlık alanlar", dokunduğu kodun diğer kısımlarını yayma ve bulaşma riskine sahiptir.

Başka bir komplikasyon: Birim testleri sizi kurtarmayacak . Genellikle bu tür eski düzeltme koduna önerilen yaklaşım, önce birim veya entegrasyon testleri eklemek, sonra da yalıtmak ve yeniden yönlendirici kullanmaktır. Ancak yarış koşulları otomatik testlerle yakalanamaz. Tek çözüm, siz anlayana kadar kodun üzerinde oturup oturup düşünmek ve daha sonra yarış koşullarından kaçınmak için yeniden yazmaktır.

Bu, görevin sadece rutin yeniden düzenlemeden çok daha zorlu olduğu anlamına gelir. Gerçek bir geliştirme görevi olarak planlamanız gerekecek.

Etkilenen kodu normal yeniden düzenleme işleminin bir parçası olarak kapsama alabilirsiniz, bu nedenle en azından tehlikeli kod yalıtılmıştır.


-1

Soracağım soru, neden birinin yazdığı, her şeyden önce EDİT ETMEMEKTİR.

Bir çok kod üzerinde çalıştım ve bir kısmı çirkin ve o zaman verilen kısıtlamalar dahilinde çalışmak için çok zaman ve çaba harcadım.

Bu durumda iddiaya girdim, bu oldu ve yorumu yazan kişi birisinin değiştiğini buldu ve daha sonra tüm çalışmayı tekrar etmeli ve çalışmasını sağlamak için geri yolunu koymak zorunda kaldı. Bundan sonra, makaslama hayal kırıklığı dışında, onlar yazdı ... EDIT ETMEYİN.

Başka bir deyişle, hayatımla daha iyi şeyler yapabildiğim için bunu tekrar düzeltmek istemiyorum.

EDIT ETMEYİN diyerek, şu anda bilecek olduğumuz her şeyi bildiğimizi ve bu nedenle gelecekte hiçbir zaman yeni bir şey öğrenemeyeceğimizi söylemenin bir yolu.

En azından düzenleme yapmama nedenleri hakkında bir yorum yapılmalı. "Dokunma" veya "Girme" demek gibi. Çite neden dokunmuyorsun? Neden giriş yapmıyorsun? "Elektrikli Çit, Dokunma!" Demek daha iyi olmaz mıydı? veya "Kara Mayını! Girmeyin!". Öyleyse neden olduğu açık ve yine de hala girebiliyorsunuz, ama en azından sizden önce sonuçlarını biliyorsunuz.

Ayrıca, sistemin bu sihirli kod etrafında testler yapmamasına ve bu nedenle herhangi bir değişiklikten sonra kodun düzgün çalışacağına kimse karar veremez. Karakterizasyon testlerini problem kodunun etrafına yerleştirmek her zaman ilk adımdır. Kodu değiştirmeden önce, bağımlılıkların nasıl kırılacağı ve kodun test edileceği konusunda ipuçları için Michael Feathers tarafından "Eski Kod ile Çalışma" bölümüne bakın.

Sonunda, refactoring ve ürünün doğal ve organik bir şekilde gelişmesine izin verilmesi konusunda kısıtlamalar getirilmesi görüşün kısalıyor.


2
bu, önceki 9
cevapta
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.