Yeniden yapılandırma eğitim projeleri: Teknik borç azaltmayı öğreten eski kod çalışmalarını nasıl yapılandırabilirsiniz?

Bir ekip, kimsenin tam olarak anlamadığı bir faturalama modülünü devralıyor. Mevcut davranışı koruyacak hiçbir test içermiyor. "Temizlemek" için bir sprint öneriliyor ve plan, çekirdeği yeni bir yapıda yeniden yazmak. Yeni sürümün müşterilerden hala doğru şekilde ücret alıp almadığını nasıl anlayacaklarını kimse söyleyemiyor.

Bu, belgelenmiş bir olay değil, açıklayıcı bir senaryodur. Bir kod yeniden düzenleme eğitim projesinin kapatması gereken boşluğu tanımlar: kodun dağınık olduğunu görebilen ancak henüz sınırlı bir iyileştirme planlayamayan ve davranışın korunduğunu gösteremeyen mühendisler.

Bu kılavuz, mühendislik yeteneklendirme liderleri ve mühendislik yöneticileri içindir. Performans sorununu nasıl tanımlayacağınızı, eksiklikleri nasıl teşhis edeceğinizi, tasarım hazırlığını ve uygulamasını, bir vaka üzerinde çalışmayı ve becerinin gerçek işe aktarılıp aktarılmadığını değerlendirmeyi kapsar. Eğitim tasarımına odaklanmaktadır. Programınızdaki kod, testler ve kurallar, kendi sisteminizde kıdemli mühendisler tarafından doğrulanmalıdır.

Yeniden yapılandırma (refactoring) eğitim projesi nedir?

Kod yeniden yapılandırma eğitim projesi, hem yetenek geliştirmeyi hem de kodu iyileştirmeyi amaçlayan, eski kod üzerinde yapılandırılmış bir çalışmadır. Öğrenciler küçük, sınırlı bir değişiklik planlar, mevcut davranışı testlerle korur, tasarımı küçük adımlarla iyileştirir ve hiçbir şeyin bozulmadığına dair kanıt sunar. Kod daha iyi hale gelir ve daha da önemlisi, mühendisler gerçek teknik borç konusunda ihtiyaç duyacakları değerlendirme becerilerini geliştirirler.

Hızlı gerçekler

1. Performans sorununu açıklayın.

Görevle başlayın: sınırlı bir eski kod iyileştirmesini planlayın ve doğrulayın. "Sınırlı" kelimesi burada önemli. Öğrenci, tamamlayabileceği kadar küçük bir değişiklik seçer ve kapsamın içinde nelerin olduğunu ve nelerin dışında olduğunu belirleyebilir.

Terimler konusunda net olmak faydalıdır. Martin Fowler, yeniden düzenlemeyi şu şekilde tanımlar: Mevcut bir kod tabanının tasarımını iyileştirmek için kullanılan kontrollü bir teknik.Küçük, davranışı koruyan dönüşümlerden oluşur. "Davranışı koruyan" ifadesi, yeniden düzenlemeyi yeniden yazmaktan ayıran şeydir ve eğitimin görünür kılması gereken de budur. Teknik borç metaforunun kendisi Ward Cunningham tarafından ortaya atılmıştır.Fowler'ın tartışması, borcun bilinçli ve ihtiyatlı bir şekilde üstlenilebileceğini, dolayısıyla her karmaşık modülün düzeltilmesi gereken bir hata olmadığını hatırlatmak açısından faydalı.

Michael Feathers'ın eski kodlar üzerine yazdığı kitap da uygulama konusunda aynı çizgiyi izliyor. Yayıncının açıklamasına göre kitap, geliştiricilere testler yazmayı öğretiyor ve bu testlerin amacının doğruluğunu sağlamayı garanti ediyor. Uygulamayı kasıtsız olarak değiştirmiyorlar.ve mevcut yazılımları tamamen yeniden yazmaya gerek kalmadan kontrol altına almak.

Performans değerlendirmesini tek bir cümleyle yazın ve bir mühendislik yöneticisine kontrol ettirin: “Verilen eski bir modül ve tanımlanmış bir hedef doğrultusunda, mühendis sınırlı bir değişiklik önerir, mevcut davranışı belirleyen testler ekler, değişikliği küçük adımlarla gerçekleştirir ve davranışın korunduğunu gösterir.”

2. Öğrenme ve bağlam eksikliklerini teşhis edin.

Herhangi bir şey inşa etmeden önce, gerekli görevi mevcut faaliyetlerinizle karşılaştırın ve değerlendirin. Genellikle üç soru, bir eğitim açığını başka bir şeyden ayırır:

1. Mevcut uygulamada gerçek görev kullanılıyor mu? Eğer eğitimde slaytlar aracılığıyla kod yeniden düzenleme kalıpları anlatılıyorsa ama hiç kimse test edilmemiş kodu değiştirmiyorsa, kimse koruma davranışını uygulamamış demektir. Eğer değerlendirme, kod kokuları üzerine çoktan seçmeli bir test ise, hatırlama yeteneğini ölçer.
2. Bilişsel talep nedir? Bloom'un revize edilmiş taksonomisinde, bir değişikliğin güvenli olup olmadığına karar vermek analiz ve değerlendirme seviyelerinde yer alırken, planı ve testleri tasarlamak oluşturma seviyesine ulaşır. Faaliyetlerin bu seviyelerle eşleştirilmesi, kılavuzumuzda ele alınmıştır. Öğrenme etkinliklerini Bloom Taksonomisi ile eşleştirmek.
3. Beceriden başka bir şey mi engel oluyor? Personel, araçlar ve prosedürleri kontrol edin. Eğer derleme bir saat sürüyorsa, kimse sık sık test yapmayacaktır. Bakım çalışmaları asla planlanmıyorsa, mühendisler yalnızca gizlice yeniden düzenleme yapacaklardır. Eğitim dışı nedenleri, bunları düzeltebilecek kişilere bildirin.

3. Amaca yönelik hazırlık ve uygulama tasarlayın.

Eğitimin hangi eksiklikleri giderebileceğini öğrendikten sonra, her aşamaya ayrı bir görev atayın.

Hazırlık. Kısa bir teşhis testiyle ön koşulları kontrol edin: test çerçevenizin nasıl çalıştığı, karakterizasyon testinin ne olduğu ve ekibinizin nasıl inceleme ve birleştirme yaptığı. Bu aşama için kendi hızınızda çalışma uygundur. Hatırlama testi yalnızca ön koşulları doğrular.

Uygulama. Net bir şekle sahip sistematik yeniden düzenleme projeleri kullanın. Küçük, güvenli bir örnekle başlayın, ardından kendi kod tabanınızın gerçek ama sınırlı bir bölümüne geçin. Gilded Rose kata, ilk adım için iyi bilinen bir başlangıç ​​noktasıdır. Emily Bache tarafından sürdürülen README dosyası, Kodda değişiklik yapmadan önce test yazmayı önerir. Bu yaklaşım, küçük adımlar atmayı, testleri sık sık çalıştırmayı ve tasarımı adım adım geliştirmeyi içeren bir alıştırma olarak çerçevelendiriliyor. Her proje için mantıklı bir sıra şöyledir: hedefi ve sınırları tanımlayın, kodun bugün ne yaptığını yakalayan testler yazın, her seferinde bir şeyi değiştirin, her adımdan sonra testleri çalıştırın ve öğrendiklerinizi not alın.

Geri bildirim. Geri bildirimi toplam puana değil, kararlara bağlayın. "İndirim mantığını çıkardınız, ancak testleriniz yalnızca olumlu senaryoyu kapsadı, bu nedenle yuvarlama değişikliğini fark etmemiş olabilirsiniz" ifadesi, "5 üzerinden 3" ifadesinden daha faydalıdır.

Canlı eğitmen desteği mi yoksa eş zamanlı olmayan tekrar mı? Canlı geri bildirim, örneğin durup eksik bir testi eklemek mi yoksa devam etmek mi gerektiği gibi belirsiz durumlarda en büyük değeri katar. Öğrenciler planlarını ve testlerini açıklama eklenmiş bir uzman versiyonuyla karşılaştırdığında ise eş zamanlı olmayan değerlendirme yeterlidir. Birçok ekip her ikisini de kullanır: önce kendi hızlarında hazırlık, ardından zor durumlar üzerinde kolaylaştırılmış bir oturum.

4. Gerçekçi bir örnek üzerinde çalışın.

Örnek niteliğindedir. Kullanmadan önce bir mühendislik yöneticisinin durumu ve cevap kriterlerini doğrulaması gerekir.

Dosya. Eski bir fonksiyon, indirim, vergi ve kargo kuralı da dahil olmak üzere sipariş toplamını hesaplıyor. Herhangi bir test içermiyor. Bir ekip, tüm faturalama modülünü daha "temiz" hale getirmek için yeniden yapılandırmayı öneriyor.

Görev. Öğrenci ne yapacağını açıklıyor, toplayacağı kanıtları sıralıyor ve ihtiyaç duyduğu ek bilgi veya desteği belirtiyor.

İlk deneme. “Modülü üç ayrı servise bölerdim ve mantığı oraya taşırdım, sonra da test ortamında sayıları kontrol ederdim.” Öğrenci büyük bir değişiklik ve geç, manuel bir kontrol yöntemi seçmiş. Eski ve yeni sürümlerin uç durumlarda aynı fikirde olup olmadığını anlamanın bir yolu yok.

Geri bildirim ve yeniden deneme. Değerlendirmeyi yapan kişi, fonksiyonun bugün boş bir sepet, toplamı negatif yapan bir indirim ve yuvarlama durumu için ne yaptığını soruyor. Tekrar deneme aşamasında ise öğrenciye kapsamı tek bir davranışa daraltması ve bu davranışın değişmediğini nasıl kanıtlayacağını söylemesi isteniyor.

Daha güçlü bir girişim. “Şimdilik modül yapısını olduğu gibi bırakırdım. Sipariş toplamı fonksiyonunun bugün bir dizi girdi için, uç durumlar da dahil olmak üzere, döndürdüğü değerleri test olarak kaydederdim. Ardından indirim hesaplamasını ayrı bir fonksiyona ayırır, bu tek adımdan sonra testleri çalıştırır ve dururdum. Gönderim kuralının anlamadığım bir davranışı olduğunu not eder ve ona dokunmadan önce bir meslektaşıma danışırdım.” Dikkat edin, bu yanıt değişikliği sınırlandırıyor, önce davranışı koruyor ve bilinmeyeni adlandırıyor.

Her bir yanıtın neden savunulabilir veya eksik olduğu. Her birini, değerlendiricinin tercihine göre değil, onaylanmış kriterlere göre değerlendirin. İlk girişim uzun vadeli mantıklı bir yön olabilir, ancak korunan davranışa dair hiçbir kanıt içermediği için bir plan olarak eksiktir. Daha güçlü girişim ise küçük, kontrol edilebilir ve belirsizlik konusunda dürüsttür.

5. Kapasiteyi değerlendirin ve devri planlayın

Yeterlilik kanıtı, öğrencinin daha önce görmediği yeni bir eski kod örneği üzerindeki performanstır. Risk analizini ve davranışın korunduğuna dair kanıtları puanlayın. Basit bir değerlendirme ölçeği, her kriter için 0 ile 2 arasında bir puan kullanır:

Çapa noktaları: 0 eksik veya desteksiz, 1 ilgili eksikliklerle kısmi ve 2 ise kabul edilen kriterlere göre eksiksiz ve gerekçelendirilmiş anlamına gelir. Kritik hataları ayrı olarak tanımlayın; örneğin, fark edilebilecek bir test olmadan davranış değişikliği gibi, böylece genel puan bir hatayı gizleyemez. Bu değerlendirme bir öneridir, onaylanmış bir hazırlık standardı değildir: bir mühendislik yöneticisiyle uyarlayın ve pilot uygulamasını yapın. Kılavuzumuz Faydalı geri bildirim içeren etkileşimli uygulama tasarımı Kararlara bağlanan geri bildirimlerin nasıl yazılacağını gösterir.

Aktarımı bilinçli bir şekilde planlayın. Tatbikatın ardından, her mühendise bir gözden geçirenle birlikte ele alması için küçük, gerçek bir borç verin veya bir şeyi bozan yakın tarihli bir değişiklik hakkında kısa bir retrospektif yapın. Aktarımı, atölye çalışmasının hemen ardından değil, gerçek iş ortamına yeterli maruz kalma sonrasında kontrol edin.

Etkileşimli sunumun yardımcı olduğu yerler

Etkileşimli formatlar, herkesin grup sunumunu görmeden önce katkıda bulunması gereken durumlarda yardımcı olur. Canlı bir oturumda, kolaylaştırıcı kısa bir eski kod parçası gösterebilir, her mühendisten yapacakları ilk değişikliği ve bunun nasıl güvenli olduğunu kanıtlayacaklarını sunmalarını isteyebilir ve ardından tartışmadan önce kodun dağılımını gösterebilir. Aynı istem, hazırlık için kendi hızınızda da çalıştırılabilir. AhaSlides, etkileşimli öğrenmeyi ve canlı ile kendi hızınızda sunum arasında geçişi destekler. Bu bir sunum ve öğrenme aracıdır, kod çalıştırmak veya analiz etmek için bir yer değildir, bu nedenle yeniden düzenlemeyi kendi ortamınızda çalıştırın. Kullanmayı planladığınız herhangi bir özel yazma, geri bildirim veya raporlama işlevini kendi iş akışınıza göre kontrol edin. Format seçimi konusunda rehberlik için makalemize bakın. Uyarlanabilir, etkileşimli ve canlı öğrenmeyi ne zaman kullanmalı?.

Değişenleri ölçün

Mühendislerin görevi yapabileceğini gösterecek unsurları önceden belirleyin. Risk analizinin kalitesini ve daha önce görülmemiş bir vakada korunan davranış kanıtlarını bir temel çizgiyle karşılaştırın. Kimlerin dahil edileceğini, paydayı ve zamanlamayı tanımlayın. Sonuçlar iyileşirse, eğitime kredi vermeden önce aynı dönemde başka nelerin değiştiğini (örneğin yeni test araçları, daha hızlı bir derleme veya sahiplik değişikliği) kontrol edin.

Kalabilecek kısıtlamalar

• Bakım çalışmaları için zaman geldi. Borçla ilgili işler hiçbir zaman planlanmazsa, eğitimli mühendisler becerilerini kullanabilecekleri bir yer bulamazlar.
• Test araçları. Kullanılabilir bir test düzeneği veya hızlı bir kurulum olmadan, küçük adımlar ve sık kontrolleri sürdürmek zordur.
• Dava kapsamı. Geçmişten bir örnek olay, birkaç risk türünü göstermektedir. Bir puan, genel olarak bir mühendisin yargısını tanımlamaz.
• Yeniden düzenleme yapmamaya ne zaman karar vermek. Bazı kodlar olduğu gibi bırakılmalı, değiştirilmeli veya tamamen kullanımdan kaldırılmalıdır ve bu karar yalnızca beceriden daha fazlasını gerektirir.
• Aktarım. Bir kata'daki performans, teslimat baskısı altındaki bir üretim modülündeki performansla aynı değildir.

Bunları sponsorlara erkenden bildirin ve ayrı ayrı düzeltmeler planlayın. Eğitim, bir mühendisin planlayabileceği ve kanıtlayabileceği şeyleri geliştirir. Ancak zamanı veya araçları yaratmaz.

Sık Sorulan Sorular

Yeniden yapılandırma (refactoring) eğitim projesi nedir?

Bu, mühendislerin küçük bir değişiklik planladığı, mevcut davranışı testlerle koruduğu, tasarımı küçük adımlarla değiştirdiği ve hiçbir şeyin bozulmadığını gösterdiği, eski kodlar üzerinde yapılandırılmış bir uygulamadır.

Teknik borç hakkında bilgi edinmenin iyi bir yolu, yazılımı tamamen yeniden yazmak mıdır?

Genellikle hayır. Yeniden yazma işlemi büyük, doğrulanması zor ve geliştirmek istediğiniz beceriyi gizler. Mevcut davranışı yakalayan testlerle sınırlı bir değişiklik, mantığı görünür kılar.

Mühendislerin kod yeniden düzenleme işlemlerini güvenli bir şekilde yapıp yapamayacaklarını nasıl değerlendirirsiniz?

Eski koddan alınmış yeni bir örnek verin ve risk analizini ve davranışın korunduğuna dair kanıtları, üzerinde anlaşılmış kriterlere göre puanlayın. Yeniden düzenleme kalıpları üzerine bir sınav yalnızca ön koşulları doğrular.

Eğitim için örnek bir kod tabanına ihtiyacınız var mı?

Güvenli bir şekilde pratik yapabileceğiniz bir yere ihtiyacınız var. Birçok ekip, herkese açık bir kata ile başlar ve ardından kendi kodlarının sınırlı bir bölümüne geçer. Mühendislik yöneticiniz kodun uygun olduğunu onaylamalıdır.

Nerede başlar

Kod tabanınızdaki küçük, tekrarlayan bir tür eski değişikliği seçin. Performans raporunu yazın, bir mühendislik yöneticisine durumu ve korunan davranışı gösterecek testleri doğrulatın ve 0 ile 2 arasında bir ölçek ve kritik hataların listesini içeren üç kriterli bir değerlendirme tablosu hazırlayın. Uygulamaya geçirmeden önce küçük bir grupla pilot olarak test edin.

Bir yeniden yapılandırma karar alma egzersizinin kendi ekibinizle nasıl canlı olarak yürütülebileceğini ve sonrasında kendi hızınızda nasıl yeniden kullanılabileceğini görmek için AhaSlides'ı inceleyin.