Refactor ne zaman


32

Fowler's Refactoring kitabının çoğunu okudum ve geçmişimdeki küçük ve büyük birçok uygulamayı yeniden inceledim.

Öğretmek için bulduğum en zor şeylerden biri de refactor'a "zaman" dır. Bunu, geçmişte bana oldukça iyi hizmet eden bir içgüdüsel düşünceye dayanarak yapmaya meyilliyim. Ancak, şu anda bir kod parçasının tek başına mı bırakılması mı yoksa yeniden düzenlenmesi mi gerektiği hakkında insanlarla tartışmalara başladığınızda "bağırsak kontrolü" nde durmak zor.

Buna daha sert yaklaşımlar olması gerektiğini düşünüyorum, ama ne olduklarından emin değilim.

Ben "kod kokuyor", kırmızı-yeşil-refactor ve diğer düşünceleri anlıyorum, fakat çoğu zaman refactor için en iyi zaman, kodu ilk yazdığınızda değil, kodu kullanıp uyguladığınızda ikinci veya üçüncü kez olduğunu düşünüyorum. Bu aslında bir sorun ve fiili kullanımda.


2
Temel olarak, bununla aynı şeyi soruyorsunuz: programmers.stackexchange.com/questions/6268/… . Harekete geçmek için eşiğiniz hariç, maliyet ve risk düşük olduğundan, doğru mu?
S.Lott

Yanıtlar:


22

Refactor üstlenmeden maliyeti maliyetinden daha azdır değil üstlenmeden.

Ancak "maliyet" ölçün. Örneğin, kod o kadar kötü uygulandı ki, önemsiz hataların giderilmesi saatler veya günler gerektiriyor mu? Yeniden düzenleme, daha fazla müşteri kazanmanıza, kapasitenizi artırmanıza veya performansı artırmanıza ve böylece mevcut müşterilerinizi daha mutlu etmenize izin verir mi?


shortform and perfect
ZJR

8
Başka bir deyişle: "Yeniden ateşlemeye değer olduğunda yeniden ateşlenmeye değer". Duh. Aslında bu bir cevap değil, değil mi :) Measure "cost" however you can.- Tamam, nasıl? Sorunun özü bu değil mi? Bu maliyeti ölçerken hangi zaman perspektifi uygulanmalıdır?
Konrad Morawski

2
@Morawski: hayır, Bu yanlış bir paroladır. Yeniden yapılanmadan elde edilen değer yeniden yapılanmanın maliyetinden büyükse, yeniden yapılanmaya değeceğini söyledim. "Refaktöre değdiğinde refaktöre değer" demesiyle aynı şey değil. Yeniden yapılanmanın maliyetini hesaplayın. Yeniden yönlendirme yapmamanın maliyetini hesaplayın. Hangisi daha büyük?
Bryan Oakley

@BryanOakley: sorun şu ki, bu maliyetleri "hesaplayamazsınız". Onları en iyi şekilde tahmin edebilirsiniz; bu, yeniden yapılanma yapmama maliyeti söz konusu olduğunda yapılması çok zordur . Refaktörlü versiyona göre refaktörsüz versiyona hangi bakım maliyeti çarpanı uygulanır? Söz konusu kodun korunmasının veya hiç değiştirilmesinin gerekip gerekmediğini nasıl biliyorsunuz? Üreteceği böcek sayısını nasıl tahmin edersiniz? Sonunda, hepimiz bilinçsizce bu tür tahminleri, yeniden yapılanmayı düşündüğümüzde karar sürecimizin bir parçası olarak yapıyoruz, ancak ondan beklenecek bir doğruluk yok.
guillaume31

1
@ ian31: true, değerleri hesaplayamazsınız ve yapabileceğiniz en iyi tahmindir. Yine de, kısıtlı zaman ve kaynaklara sahip olduğunuz varsayılarak, refactor olup olmamasına karar vermenin tek geçerli yolu budur. Yeniden yapılandırıcının buna değip değmeyeceğine karar vermelisin. "Değeri" nasıl tanımladığın çok yanlış bir bilimdir. Mesele şu ki, bir bağırsak duygusu üzerine yeniden ateşlememelisiniz - yeniden kodlamayı "kodun daha güzel olmasını istiyorum" dışında bir sebep olmalı.
Bryan Oakley

12

  1. cyclomatic karmaşıklık 5'in altında işlevin?
  2. Bu bağlantıyı izlemeden hangi döngüsel karmaşıklığın tamamen olduğunu anladınız mı?
  3. İşlev içindeki her yol için otomatik bir testiniz veya belgelenmiş bir test durumunuz var mı?
  4. Mevcut tüm test durumları başarılı mı?
  5. Fonksiyonu ve tüm son durumlarını bana 1 dakikadan daha az bir sürede açıklayabilir misiniz?
  6. Değilse, yaklaşık 5 dakika?
  7. 10 dakika?
  8. İşlevde 100'den az kod satırı var mı (yorumlar dahil)?
  9. Bu kodun sadece görsel inceleme ile hatasız olduğunu kabul eden iki geliştirici daha bulabilir misiniz?
  10. Bu işlev yalnızca bir yerde mi kullanılıyor?
  11. İşlev performans hedeflerine uygun mu (Zaman / Bellek / CPU)?

puanlama

Yukarıdaki "hayır" yanıtlarını ekleyin:

  • 0-1 - Neden bunu yeniden düzenlemeyi düşünüyorsunuz? Muhtemelen sadece değişkenleri yeniden adlandırmak istiyorsunuz çünkü önceki geliştiricinin adlandırma kuralını beğenmediniz
  • 2-5 - Bunun biraz değişmesi gerekebilir, ancak bu aralıktaki bir şey için bir üretim bültenine izin vermem
  • 6-8 - Tamam, muhtemelen düzeltmemiz gerekiyor ... Muhtemelen bunu tekrar gözden geçirmeye devam edeceğiz ve / veya aslında ne yaptığını bilmiyoruz. Hala çitin üzerinde, ama çok şüpheli
  • 9+ - Bu, refactoring için birinci sınıf bir aday. (Not, test senaryoları yazmak bir yeniden düzenleme şeklidir)

http://mikemainguy.blogspot.com/2013/05/when-to-refactor-code.html


4
# 2 çok snob kulağa geliyor ve kodu değerlendirmek için aslında işe yaramaz . # 3 & # 4 her şirket birim testleri kullanmaz. # 8 Mümkün olan her yerde yorum yapmaktan kaçının ve 100 satır çok fazla yüklü. Portre modunda 1 büyük geniş ekran monitörüm var ve tüm işlevi aynı anda görebildim. 15 satırdan fazla gerçek kod varsa, bu şekilde tutmanızın sağlam bir nedeni olmalı. Bir kontrol listesine sahip olmak güzel, pratik bir yaklaşımdır, ancak buradaki çok fazla nokta, arkasındaki herhangi bir nedenden ötürü sadece rastgele değerleri oluşturur veya kullanır.
R. Schmitz

8

Bağırsaklarınız size bazı yeniden tazelemeler yapmanız gerektiğini söylerken, içgüdüleriniz size çok uzun zamandır önemli bir şeyi bıraktığınızı biraz geciktirdiğini söylüyor.

Ben "kod kokuyor", kırmızı-yeşil-refactor ve diğer düşünceleri anlıyorum, fakat çoğu zaman refactor için en iyi zaman, kodu ilk yazdığınızda değil, kodu kullanıp uyguladığınızda ikinci veya üçüncü kez olduğunu düşünüyorum. Bu aslında bir sorun ve fiili kullanımda.

Yeniden yapılandırmanın etkili iki düzeyi vardır. İlki, ilk kod yazdığınızda ortaya çıkan belirgin sorunlardır. Bunlar, yapılması gerekenler için size maliyeti düşük olan küçük optimizasyonlardır. Yöntemlerinizi ve sınıflarınızı küçük tutmak, DRY ve SRP'ye bağlı kalmak gibi şeyler. Ardından, tasarımınızdaki büyük kusurlarla başa çıkma konusunda ek bir aşamaya sahipsiniz; bu, kodunuz altında birkaç mil bulunana kadar hemen görülmeyebilir. Bahsettiğiniz bu ikinci seviyedir, ancak daha sonra yeniden yapılanmanın çok masraflı olmadığından emin olmak için, kodunuzu daha sonra öngördüğünüz çabanın daha kolay ve daha az masraflı hale getirileceği şekilde yazmanız gerekir. Bu, erken refactoring yapmak anlamına gelir.

Jeff'in cevabında bahsettiği gibi, "zaman paradır" , özellikle iş yükünün yüksek ve risklerin daha da yüksek olduğu şirketlerde . Kodun mümkün olan en iyi durumda olduğundan emin olmak için harcanan zaman, daha sonra yeniden yapılanmanın ne olması gerektiğine karar verdikten sonra büyük bir işlem olduğu ortaya çıktıktan sonra zamandan kazanılan zamandır.

Yazılım yazarken, kodunuzu geliştirmek için harcadığınız her an, daha sonra gerçekten ihtiyaç duyacağınız zamandan tasarruf sağlar. Refactor ne kadar erken olursa, değişiklikleriniz o kadar net olacaktır. Gelecekteki teknik borca ​​karşı yarının şişireceği dolar karşısında bugünkü dolarda aşağı ödeme yapmak gibi.

Her durumda, yeniden yapılanma, yazılım zaten eksiksiz ve kararlı olduğunda, gizemli bir geleceğe kadar koyduğunuz bir görev olmamalıdır; Yeniden düzenleme, günlük faaliyetlerinizin bir parçası olmalıdır ve bu, bahsettiğiniz Kırmızı-Yeşil-Refactor felsefesinin özüdür.


2

Sanırım sorunuz her geliştirici ve hatta programlamadan sorumlu yönetim tarafından farklı şekilde cevaplanabilir.

Kişisel tercihim, ne zaman yeni bir şey öğrendiğimde veya en iyi uygulamalarımı geliştirdiğimde, yapabileceğim kodu yeniden değerlendiriyorum - bu durum için en iyi standardın ne olduğunu öğrenir öğrenmez kodumu standartlara uydurmayı seviyorum. Yine de bunu yapmama izin verildi, çünkü aynı yazılımı uzun süre kullanan daha küçük bir şirket.

Zamanın para olduğu daha büyük bir yazılım geliştirme şirketinde, bu noktadan sonra öğrendiğiniz daha iyi uygulamalar ile tasarım yapmaya başlamak olabilir, söz konusu yazılımın 2. versiyonuna kadar yeniden yapılanma konusunda endişelenmeyin.

Refactor ne zaman gerçekten gerçekten şu an içinde bulunduğunuz şirkete bağlı olduğunu öğretiyorum.


2

"Refactor ne zaman?"

Kısa cevap: her zaman kötü kokan veya iyileştirilebilecek bir kodla karşılaştığınızda ( İzci Kuralı )

Pratik olarak, bu olur:

  • TDD'yi, TDD döngüsünün Refactor adımı sırasında sistematik olarak uygularsanız, yani testiniz yeşil olduğunda ve yeni bir test yazmaya başlamadan önce.
  • Kod incelemesi sonucunda
  • Eski kodu devralırken
  • Garip bir şekilde tasarlanmış gibi görünen kodu tüketirken
  • vb.

Bunun zor kısmı cevaplamadan sadece “yeniden ateşe geçmelisin” dediğini hissediyorum: “Bunun için daha katı yaklaşımlar olması gerektiğini düşünüyorum ama ne olduklarından emin değilim.”
Hortitude

Ne söyleyeceğimi bilemiyorum, korumak için acı verici olanı hissetmek, kod kokularını çekmek ve deneyiminizi kullanmak dışında. Size, aradığınız şey ne zaman ve ne zaman yeniden yansıtılacağını söyleyen kesin, yerleşik bir yöntem olacağından şüpheliyim.
guillaume31

1

Yenilemeyi ilk kez öğrenirken akıl hocam bana şöyle dedi: "İki kez yap, burnunu tut. Üç kez yap. Refactor." (Teşekkürler, Josh!) Açıkçası, söylediği şuydu, üçüncü kez aynı kod bloğunu yazmak üzereyken (hatta benzer bir kod kalıbında), refactor zamanı. Bunu son 10 yıldır takip ettim ve yeterince sağlam bir kural olduğunu gördüm.

Eclipse veya güçlü refactoring desteğine sahip benzer bir IDE kullanmak, yeniden düzenlemeyi yapma çabalarını azaltır. IDE desteği, ek çaba olarak görmek yerine, "üçüncü kez" vurduğunuzda (veya ihtiyacı gördüğünüzde) yeniden yönlendirici olma olasılığını artırıyor.

Ayrıca - TDD de burada büyük bir yardımdır, çünkü testlerinizi refraktörünüz olarak sürdürmeye devam edebilir ve hiçbir şeyi bozmadığınızı bilirsiniz.


1

Refactoring, tanımı gereği bir süreçtir. Bu, rafactoring görevini yapmak için boş zaman bulmaya çalışmamanız gerektiği yerine, daha iyi yazılabilecek kod koduyla her zaman yeniden düzenlemeye devam etmeniz gerektiği anlamına gelir.

Şahsen ben evrimsel prototipler yazmayı seviyorum, daha basitçe söylemek gerekirse: sadece işe yarayan kod ve daha sonra beklenen kodlama standartlarını karşılayana kadar bunları yeniden düzenlemek. Başka bir iyi örnek, ek işlevsellik eklemek ve yeniden kullanılmasını sağlamak için mevcut kodu yeniden düzenlemek.


1

20 yıllık programlamamda, işte, insanların yapışabileceği ve yöneticilerin zaman harcadığı işleri gördüğüm tek kural. (Yeniden yapılanma diyet yapmak gibidir: elbette, "kalorilerin kalorisi / kalorileri" kilo vermenin formülüdür, ancak bu insanların uyum sağlayacağı bir diyete dönüşmez.) Ve böylece:

Çalışırken sürekli refaktör. Test Driven Development uygulamasını kullanarak gün boyunca birkaç kırmızı-yeşil-refactor çevrimi elde edin. Refactor, kodun yalnızca dokunduğunuz kısımlarını yeniden gözden geçirir.

Kendinizden daha emin olduğunuzda, bu rejimden farklı olabilir.


1

Proje sahibinin ve kodun kalitesine cevap veren adamın taleplerine bağlı olduğunu düşünüyorum. Başka birinin parası söz konusu olduğunda, yalnızca tek başına karar veremezsiniz.

Teknik sebeplerden dolayı, birkaç tane var.

  • Kodda bir hata varsa, bu, bu yerin yanlış anlaşıldığı ve burada daha fazla hatanın gizlenebileceği ve muhtemelen kodun bağlı bölümlerini geliştirme girişimi ile ilgili büyük sorunların olabileceği anlamına gelir. Bu nedenle, bu yer olası yeniden düzenleme için kontrol edilmelidir.
  • Başka bir neden, bir özellik eklediğinizde veya değiştirdiğinizde, eski kodun değiştirilmesi / eklenmesi için elverişsizdir ve daha sonra değişikliklerin / eklemelerin yapılması oldukça olasıdır. Tabii ki maliyeti dengelemelisin.
  • Belki de en ciddi neden, kodu değiştirirken ve test edilemez olmasıdır.

Bir scrum ustası olarak, ekibin boyutlandırdığı her hikayenin ekibin düşündüğünden daha büyük olduğunu sürekli olarak belirten ve karşılaştığı her kod parçasını yeniden düzenlemek istediğini fark eden bir geliştiricimiz vardı. Böylece, 3 puanlık bir hikaye onun için her zaman 8 oldu. Açıkçası bu değer teslimini berbat ediyordu. Bu yüzden bir şekilde ne zaman yeniden ateşleneceğine ve kararın nasıl verilmesi gerektiğine dair bir anlayış olmalı. Sadece benim düşüncem, o (ve diğer birkaç) deneyimden.
Curtis Reed
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.