Bir sprintten daha uzun süren refactoring ile nasıl başa çıkabilirim?


49

500 K kod satırı aşan bir kod tabanı ile çalışıyorum. Yeniden düzenlemeye ciddi ihtiyaç var. Normal iki haftalık sprint süresinden daha uzun süreceği tespit edilen yeniden düzenleme çalışmaları yapıldı. Bu sitedeki diğer cevaplarda önerildiği gibi bunlar daha küçük görevlere bölünemez. Ürün, yinelemenin sonunda çalışmalıdır ve kısmi yeniden yapılandırma, öğeler arasındaki bağımlılık korkunç olduğu için sistemi kullanılamaz bir durumda bırakacaktır. Peki bu engele yaklaşmanın en iyi yolu ne olabilir? Yine bahsetmiştim, daha küçük parçalara ayırmak, zaten yapılmış bir seçenek değil.

Güncelleme: İnsanların neden 2 haftalık bir sprint ile uyuşamayacağına dair bir açıklama yapması gerekiyor. Bir sprintde sadece kod yazmaktan daha fazlası var. Test olmadan kodsuz bir politikamız var. Bu politika her zaman mevcut değildi ve kod tabanının büyük bir bölümünde bunlara sahip değil. Ayrıca entegrasyon testlerimizden bazıları hala manuel testlerdir. Mesele, yeniden yapılanmanın kendisinin çok büyük olması değil. Küçük değişikliklerin sistemin birçok parçası üzerinde etkisi olduğu gerçeğinden dolayı, bu parçaların doğru bir şekilde çalışmasını sağlamak zorundayız.

Bir sprint'i uzatamaz veya uzatamayız çünkü aylık düzeltmelerimiz vardır. Bu nedenle, bir sprintin ötesine uzanan bu değişiklik, düzeltmeye eklenen diğer işleri durduramaz.

Yeniden düzenleme vs Yeniden tasarlama: Geliştirme sürecimizin bu yeniden düzenleme işlemini iki haftalık bir döngüde gerçekleştirecek kadar verimli olmaması, yeniden tasarım olarak yeniden adlandırılmasını garanti etmez. Gelecekte, sürecimiz geliştikçe iki haftalık bir süreç içerisinde aynı görevi yerine getirebileceğimize inanmak istiyorum. Burada söz konusu olan kodun çok uzun zamandır değişmesi gerekmedi ve oldukça kararlı. Şimdi, şirketin yönü değişime daha uygun hale geldikçe, kod tabanının bu bölümünün geri kalan kısımlar gibi uyarlanabilir olmasını istiyoruz. Bu yeniden tadilat gerektirir. Buradaki cevaplara dayanarak, bu yeniden düzenleme işleminin normal sprintlerin zaman diliminde çalışması için gereken eksik iskelenin olduğu anlaşılıyor.

Cevap:

Corbin March'ın ilk kez önerdiği dal ve birleştirme yaklaşımını yapacağım, böylece bu sorun alanları ve eksik testlerin nasıl tespit edileceği hakkında daha fazla bilgi edinebiliriz. Bence ilerlemeye devam ediyorum, Buhb'un testlerin eksik olduğu alanları tespit etmek için önerdiği yaklaşımı benimsemeli, önce bunları uygulamalı, sonra yeniden düzenlemeyi yapmalı. Normal iki haftalık sprint çevrimimize devam etmemize izin verecek, tıpkı birçok kişinin söylediği gibi refactoring için her zaman böyle olması gerektiğini söyledi.


23
Bir yan not olarak, bu tanım gereği yeniden yapılanma değil , büyük ölçekli yeniden tasarımdır . Umarım bunu nitpicking olarak kabul etmiyorsunuz - IMHO iletişim sorunlarından kaçınmak için net terminoloji kullanmak önemlidir :-)
Péter Török

9
@Charles, "Yeniden düzenleme genellikle küçük adımlarla yapılır. Her küçük adımdan sonra, işlevsel olarak değişmeyen bir çalışma sistemiyle kalırsınız. " Yukarıda bağladığım sayfadan alıntı.
Péter Török

2
@Charles: Sistemin çalışmasını sağlarken yeniden yapılandırma her zaman aşamalı olarak yapılabilir. Yeniden yapılandırılmakta olan sınıfın / paketin / modülün tepesine büyük bir "Yeniden düzenleme devam ediyor" yorumu koyup parçaları teker teker yapın. Nesne modeli geçiş halindeyken geçici bir sürümü keserseniz, Tamam.
Sean McMillan

7
Düzenli olarak bir çalışma koduna sahip olamayacağınız büyük adımlar atıyorsanız, yeniden yapılanmanın ne zaman yeniden tasarlanacağının tanımı budur. Lütfen, kelimeyi kötüye kullandığınız için sizi aradıkları için kızmayın. Yeniden tasarım hakkında sormakta yanlış bir şey yok. Yorum yapanlar yalnızca istediğiniz yanıtları alamayacağınızı belirtmeye çalışıyorlar çünkü sözcüğü yanlış kullanıyorsunuz, bu zaten olan şey.
jprete

5
Biliyorum biraz konu dışı, ama küçük adımlarla yeniden düzenlemeyi imkansız hale getiren koşulların ne olduğunu merak etmemi sağladın. Lütfen bununla ilgili biraz daha arka plan paylaşın.
Buhb

Yanıtlar:


14

Yeniden yapılanmayı geciktirme lüksüne sahipseniz, kodlama tabanını rahatça yeniden aktarabileceğiniz noktaya ve ardından yeniden tek bir sprintte yeniden aktive edeceğiniz noktaya gelecek yinelemelere odaklanmanızı öneririm.


68

Benim önerim:

  1. Şube oluştur
  2. Günlük bagajdan şubenize kadar birleştirme yapın ve çatışmaları çözün.
  3. Tamamlanana kadar çalış. Şubeniz birkaç sprint için çekirdek gelişim dışında olabilir.
  4. Bagaja geri dön.

Muhtemelen çirkinleşeceği gerçeğini aşmak yok. Seni kıskanıyorum Tecrübelerime göre, bir projeyi büyük ölçüde değiştirdiğinizde, devam eden gelişmeyi yeni paradigmaya birleştirmekten daha kolay - her nasılsa her şey bittikten sonra yeni paradigmayı şimdi değişen bir gövdeye birleştirmek daha kolaydır. Yine de acıtacak.


1
Bu yaklaşımı kullanarak tartıştık ve ele almadan önce başka bir fikir çıkmazsa, yapmayı planladığımız şey budur.
Charles Lambert,

3
Korkarım ki, böylesine kapsamlı bir refactoring yapmak istiyorsanız, gövde ve dal arasında ileri geri bir araya gelecek olursunuz.
Giorgio

Çoğu durumda (umarım) birleştirilmiş değişiklikler, burada söz konusu kodu etkilemez. Güvenilir bir sonuç elde ederse, bu değişiklik için zaman çizelgesini genişletmeyi umursamıyorum.
Charles Lambert

1
Sunumunuzun değişkenliğini göz önüne alarak, bu spekülatif dallanmayı ve birleşmeyi kolaylaştırdığı için Git'i düşünmelisiniz .
John Tobler

1
@ Giorgio: öyleyse, ben günlük birleşme biraz paranoyak görünüyor, ama sonra gerçekten takımın büyüklüğüne bağlı. Ne kadar çok insan, ne kadar çok değişiklik olursa o kadar sık ​​birleşmelisiniz. Çalışmak için zamanınız varsa, günlük olsa da, alt sınır gibi görünüyor.
Matthieu M.

40

Her görev (yapay) 2 haftalık bir sprint içinde yapılamaz, bu yüzden sağduyu çağrılır. Daha fazla parçalanamazsa ve yapılması gerekiyorsa, devam et ve yap. Süreç nihai sonuçtan daha önemli değildir ve asla kırılmayacak bir yasadan ziyade bir kılavuz olarak görülmelidir.


3
Cevabınız konuyla ilgili çok iyi bilgi. Söylediğin gibi "devam et ve yap" için buradayım. Bazı bilgileri alma ümidiyle soruyu sordum, böylelikle var olan durumumla paralel çalışan bir süreç bulabilirim ya da mevcut durumumu çözmek için mevcut süreci bir şekilde değiştirebilirim. Geliştiricilere söyleyecek bir şeye ihtiyacım var ki çalışacakları en az 2 kez daha olacak şekilde çalışma yönergeleri olsun.
Charles Lambert

+1 "Süreç, sonuçtan daha önemli değil ve asla kırılmayacak bir yasadan ziyade bir kılavuz olarak görülmeli." - İnsanlar bunu gerçekten unutmuş görünüyor.
Bjarke Freund-Hansen

32

Sadece 3, 4 veya 5 haftalık bir sprint yapın. Kimin umrunda? Belli ki, daha kısa sürede hiçbir şey yapılamayacağına ikna oldun, bu yüzden onunla savaşmayı kes.

Sadece arkadaşlarınıza Kraliyet Kör Çevik Bağımlılık Derneği'ndeki söylemeyin.


Örgütsel nedenlerden dolayı (aylık düzeltmeler), 2 haftalık sprintlerin değiştirilmesi oldukça zor görünüyor.
Steve Bennett

10

Michael Feathers'ın Legacy Code ile Etkili Çalışması kitabından başlamanızı öneririm . Yeniden düzenlenme tarzı değişikliklerin kapsamını azaltmak için çeşitli teknikleri kapsar.


Kesin olarak iyi bir kitap, ancak birden fazla sprint üzerine yeniden düzenlemeyi bölmeyi kapsadığını sanmıyorum.
Adam Lear

4
Bunu + 1 olarak vereceğim çünkü muhtemelen öğrenmeye başladığınızda başlayabileceğiniz en iyi kitaptır, ünvanın dediği gibi, eski kodla etkin bir şekilde çalışabilirsiniz. Bu soruyu sorabilecek ve işleri daha küçük adımlara bölmenin ne anlama geldiğini anlayamayan biriyle ilgilidir.
Charles Lambert,

@Anna - o zaman küçük değişiklikleri önleyen bağlantı çeşitlerini kırma teknikleri hakkında konuşan bölüm 25'i (yeniden) okumak isteyebilirsiniz.
kdgregory

@kdgregory Fuarı yeterince. :) Cevabınıza daha müthiş yapmak için bunu ekleyerek Zihin?
Adam Lear

7

Mağazamızda, bir sürüm penceresinde tamamlanamayan büyük yeniden yapılandırma veya yeniden yazma görevlerimiz olduğunda, işlevsellik sistemde olduğu gibi bırakılır. Ancak, zaman zaman elverdiği gibi yeni, yeniden düzenlenmiş lego-blok fonksiyonlarına başlıyoruz. Sonunda, yeterli sayıda lego bloğumuzun yapıldığı bir duruma geliriz, bir sprintin lego bloklarını uygulamaya sokmak ve kullanıcılar için açmak için yeterli zamanı sağlar.

Daha net bir şekilde, yeni isimler kullanarak büyük işlevleri parçalara ayırır veya elden geçiririz. Sonunda, kötü, eski kod yerine yeniden adlandırılmış, yeniden yapılanmış çalışmalarımızı kullanıyoruz.


Bu iyi bir fikir, ancak yürürlüğe girmesi için yüksek düzeyde bir iletişim gerektirir. Örneğin, kodlarken, herhangi bir yerde kullanılmayan ve halka açık olmayan bir yöntem belirlersem, kaldıracağım.
Charles Lambert,

5

Yeniden yapılandırmanın ortasında kodun nasıl düzgün bir şekilde çalıştığını bulmak için bir sprint ayırın. Bu, kullanımdan kaldırılmış yöntemler ve sınıflar, sarmalayıcılar, adaptörler ve benzerleri şeklinde olabilir. Yeniden düzenlemeniz, uzun süre daha temiz olması için kodu kısa bir süre daha kirletebilir; bu iyi. Şu anda bunun yapılamayacağını söylüyorsun. Bunun doğru olduğunu sanmıyorum - senin süreci eğer nasıl olacağını düşünmek olabilir bunu yapmak için uygulayabileceğiniz adımları düşünmek, yapılması. Sonra dal.


Bunların hepsini zaten yaptık. Bu, kırılmayacağını açıkça ifade etmemin nedeni buydu.
Charles Lambert,

Gerçekten mi? Tüm bir sprint harcayarak sisteminizi bozmadan nasıl refactor yapmayı planladınız ve hiçbir şey bulamadınız mı? Özel bir planlama sprintinin hiçbir şeyle ortaya çıkmadığına inanmak zor; belki bir danışman getirmeniz gerekir (ve hayır, ben bir değilim, bir konser almaya çalışmıyorum).
Carl Manaster

1
Hiçbir şey demedim. Söylediklerinize benzer bir süreçten geçtiğimizi ve diğer ucunda tek bir sprint içinde yeniden düzenlenemeyen bazı kodlarla çıktığımızı söylüyordum.
Charles Lambert

Dedim ki: "Kodun uygun şekilde orta refaktörde nasıl çalışacağına karar vermeye bir sprint adanın." "Bunların hepsini zaten yaptık." Dedin. Şimdi başka türlü mi söylüyorsun? Bu kulağa tartışmalı geliyorsa özür dilerim ama anlamıyorum.
Carl Manaster

5

Corbin March'ın cevabında + 1, düşündüğüm tam olarak buydu. Kod tabanınız biraz çirkin gibi görünüyor ve temizlenmesi tek bir sprint döngüsünden daha fazlasını gerektiriyor.
Yani Corbin'in dediği gibi

  1. "yeniden projelendirme projesi" içine dallama
  2. şube değişikliğini test et
  3. KG testi için test ortamınıza tanıtın
  4. yeniden yapılanma tamamlanana kadar artımlı olarak tekrar bagaja doğru birleştirin.

Eminim bunu dev yöneticinize satmakta hiçbir sorun yaşamayacaksınızdır, eğer Başbakanlarınız bunu görmekte zorlanıyorlarsa, Roma'nın bir günde inşa edilmediğini ve Roma'ya atılan tüm çöpleri temizlediklerini açıklayın. Sokaklar da bir günde yapılmayacak. Yenileme biraz zaman alacaktır, ancak daha kolay bakım, daha hızlı geliştirme sürümleri, daha az üretim bileti ve daha iyi bir şekilde gerçekleştirilen SLA açısından iyi olacaktır.


1
Herkese konuşmam için gereken tüm cephaneye sahibim. Sunarken sadece uygulamak için resmi bir plana ihtiyacım var. Buradaki cevaplardan tekrarlanabilir bir çözüm bulacağımdan şüphem yok.
Charles Lambert

4

Gerçekten yapmak istediğiniz yeniden tasarım büyük bir iş olsa da, bireysel bağımlılıkları kırmak / ayrıştırmak için daha küçük parçaları yeniden düzenlemek mümkün olabilir mi? Bilirsiniz - şüphe duyduğunuzda, dolaysızlık ekleyin. Bu dekuplajların her biri, tamamlayamadığınız mamuttan daha küçük bir görev olmalıdır.

Bağımlılıklar ortadan kalktıktan sonra, sprints içinde elde edilebilecek geri kalan yeniden yapılandırma görevlerini kırabilmelisiniz.


3

Şu an için çalışmakta olduğum projede 4 haftalık sprint kullanıyoruz. Ve bazen bir kullanıcı hikayesini bitiremiyoruz ve sadece aşağıdaki sprint boyunca yeniden başlatıyoruz.

Bununla birlikte, IMHO bir yeniden düzenlemeyi 4 haftalık bir sprint için daha küçük hikayelere bölmek mümkün olmalıdır. Kodu 4 hafta içinde tutarlı bir duruma getiremezseniz, başvurunuzu yeniden düzenlemek yerine yeniden yazdığınızı hissediyorum.


4 haftalık bir sprint onu kapsamalıdır. Bununla birlikte, şu anki 2 haftalık sprintleri diğer hata düzeltmeleri vb. Nedeniyle durduramayız. Bu nedenle, bunun birden fazla sprint üzerinden ilerlemesi gerekir. Böylece benim sorunumun parçası.
Charles Lambert

Dediğim gibi, 4 haftalık sprint kullanıyoruz ve bir hikaye 4 hafta içinde bitmediyse, bir sonraki sprint için planlıyoruz. En azından 2 haftalık bir sprint sonunda sistemi tutarlı bir durumda tutabilir misiniz (ve ardından aşağıdaki sprint boyunca devam edebilir)?
Giorgio

Değil doğrulanabilir tutarlı durumu.
Charles Lambert,

Dalgamı, başkalarının “yeniden yapılanma” yerine kullanmak için başka bir kelime bulacağınızı ummak için harcadıkları çabaya eklemeliyim. Yeniden yapılanma iyi tanımlanmıştır ve kapsamı, yapmanız gereken muazzam ve zaman alan yeniden tasarım ve yeniden programlamaya göre çok daha hızlı ve kısa vadelidir.
John Tobler

2

Belirli görevlerin 2 haftalık sprint döngüsünden daha uzun sürdüğü durumlarda, görevin başka bir zaman için sıralanmasını öneririm. Ekibiniz yeniden yapılanmaya ihtiyaç duyulduğunu belirledi ve bu önemli. Bazen, başka bir seçenek yoktur ... ve, evet, bu berbat.

Yeniden düzenlemeye başlama zamanı geldiğinde, normal sprintleri askıya alacaksınız. Başka seçeneğin yok. Akıllı sürüm kontrolü kullanın - dal, refactor, test, birleştirme. Bazı büyük projelerin yeniden yapılandırılmasının özelliklerden öncelikli olduğu her zaman bir nokta vardır. Mümkünse, daha iyi esneklik için endişeleri ayırmaya çalışırdım.


Sonsuza dek erteleyemeyiz ve cevabınız yeniden yapılanmanın nasıl yapıldığını ele almıyor.
Charles Lambert

@Charles: 'başka bir zaman için sıralı ' ;) Projeyi iptal etmedim demedim.
IA

2

Son zamanlarda kod tabanımızın bir parçasıyla aynı sorunu çözdükten sonra (biraz daha büyük), umarım sizinle birkaç görüş paylaşabilirim. Benim durumumda, kod temeli başka bir ekip tarafından geliştirildi, bu nedenle orijinal geliştiricilerin hiçbiri bu yeniden yapılandırmaya dahil olmadı. Kod temeli ile ilgili deneyimim yaklaşık 1 yıl ve başka bir geliştirici de 2 yıl görev yaptı.

Buradaki diğer cevaplarla ilgili iki küçük not vermeme izin ver:

  • Dallanma, kendiniz için bir oyun alanı kurmanıza yardımcı olacaktır, ancak değişikliklerinizi büyük bir değişiklik setinde asla bagajda birleştirmeyin. Takımın geri kalanıyla ciddi bir belaya gireceksin.
  • Artımlı olarak yapmanız gerekir ve yapılabilir. Bahane yok. Ele almak için Eski Kod kapağı ile Verimli Çalışmayı okuyun . Tekrar oku.
  • Bunu yapabileceğini düşünmek büyük bir adım yanlış. Her ne kadar daha iş gibi görünse de, adım adım yapmak yönetimi çok daha kolaydır.

İki hafta veya daha uzun süre görünüşte "rezervasyon dışı" görünmek farkedilmez gitmeyecek. Proje yönetimi ve hatta daha da önemlisi ekibi tarafından desteklendiğinizden emin olmalısınız. Takım bu yeniden düzenlemeye bağlı değilse (ve bu, uzak bir gelecekte değil, şimdi yap demektir) başınız belaya girer.

Yalnız yapmayın, çift programlama kullanın. Bu kesinlikle her zaman aynı klavyenin önünde oturmanız gerektiği anlamına gelmez, ancak küçük ve dar görevleri (örneğin, bu sınıfın davranışını yakalayan testler yazma) tek tek ele almanız gerektiği anlamına gelmez.

Bir Scratch Refactoring yapın ve bu şekilde kullanın. (Bir çeşit "fırlatma" prototipinin yeniden yapılandırılması, "fırlatma" bitinin önemi önemlidir!) Açıkçası, yeniden düzenlemenin tüm etkilerini biliyor olmanız pek mümkün değildir. Çiziksiz bir yeniden düzenleme, bazı konularda size yardımcı olacaktır:

  • Var olduklarını asla bilmediğiniz sistemin parçalarını keşfedeceksiniz.
  • Modüllerin nasıl birbirine bağlandığını daha iyi görebileceksiniz
  • Sisteminizi modüller halinde gruplandırmanın yeni bir yolunu keşfedeceksiniz, muhtemelen mevcut anlayışınızdan çok farklı. Eşinizle görüşlerini tartışın. Yeni görüşünüzü damıtmaya çalışın. Halihazırda nerede olduklarını ve mantıksal olarak nereye ait olmaları gerektiğini söyleyen kısa bir mimari teknik yazı (veya bir şema çizin) yazın.

Sıfırdan yeniden düzenlemenizi yaptığınızda, umarım gidip her şeyi değiştiremeyeceğinizi keşfedersiniz. Kendini kötü hissedeceksin, bu sadece büyük bir karmaşa ve sadece bir düğmeyi çevirip çalışmasını sağlayamazsın. Bana olan bu, durumunuzda farklı olabilir.

Ancak eşim ve ben sistemimizi daha iyi anladık. Artık bireysel, daha küçük (yine de büyük olsa da) yeniden yapılanmaları / yeniden tasarımları tanımlayabildik. Sistem vizyonumuzu bir şemada yakaladık ve bu vizyonu uygulamak için hazırladığımız backlog öğeleriyle birlikte ekibimizle paylaştık. Ortak mutabakatla güçlendirilerek, bir sonraki yinelemede hangi maddeleri uygulayacağımıza karar verdik.

Bize yardımcı olan son şey büyük bir beyaz tahta kullanmaktı. Kafanda tutmak için çok fazla şey var. Not tutman çok önemli. Günün sonunda, bugün yaptığınızı ve yarın ne yapmak istediğinizi kendinize ait bir brifing notu yazın. Büyük zamanları rahatlatmaya yardımcı oluyor ve göreve ayak uydurmak istiyorsanız rahat bir zamana ihtiyacınız var. İyi şanslar!


1

Daha fazla geliştirme yapılmayan bir bakım penceresi başlatın. Yeniden tasarlamayı gerçekleştirin, ardından geliştirme sprint'lerine devam edin.


0

Elimizde iki tür çalışma var:

  1. Adam-saat çalışmaları
  2. Genius çalışır

Yöntemler bir çok benzeri geliştiricilere zaten bilinmektedir beri Refactoring genellikle çalışmalarının ilk tip oluşur DRY , SRP , OCP , DI proje refactored iki ay sürer Dolayısıyla, vb basitçe iki ay sürer , orada Kaçış yok. Bu yüzden benim önerim, orijinal projeye zarar vermemek ve mevcut durumu üzerinde çalışmasına izin vermekti. Paydaşlardan ve ürün sahibinden yeni istek ve gereksinimler almayı bırakın . Ardından ekibin projede çalışmasına izin verin ve yenilenmeye hazır olun.


0

Yardımcı olabilecek bir öneri: Eğer kodunuzu iki hafta içinde yeniden test etmek ve yeniden test etmek için yeterli zamanınız olmayacak şekilde test etmediyseniz, ilk önce kod üzerinde değişiklik yapmak için başka bir ilgisiz küçük değişiklik yapmayı düşünün. ilk sprint için iki veya yazılı testler. Belki yeniden düzenlemek istediğiniz kodun denenmemiş birkaç istemcisini tanımlayabilirsiniz; Bir müşteri seçin ve sizi bu müşteri için testler yazmaya zorlayacak olan iş için bazı değişiklikler yapın. Kurallara daha aşina olduğunuzda, onunla çalışmaktan ve daha fazla test yaptırdıktan sonra, birkaç küçük katkı sağlayan yeniden düzenleme gerçekleştirmiş olabilirsiniz, yeniden düzenleme işlemini gerçekleştirmek için çok daha iyi bir konumda olacaksınız (ve şimdi daha kolay ) her ikisini de bir yinelemede test etme.

Başka bir yaklaşım, suçlu kodun bir kopyasını çıkarmak, yeniden düzenlemek ve ardından istemcileri birer birer yeni koda taşımaktır. Bu çalışma yinelemeler arasında parçalanabilir.

Ve vazgeçme: Sadece büyük bir yeniden düzenlemenin daha küçük adımlara bölünemeyeceğini kabul etmeyin. En kolay / en hızlı / en iyi yaklaşım, yinelemeden daha uzun sürebilir. Ancak bu, yineleme büyüklüğünde parçalar yapmanın bir yolu olmadığı anlamına gelmez.

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.