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
| Soru | Kısa cevap |
|---|---|
| Görev nedir? | Sınırlı bir eski kod iyileştirmesini planlayın ve doğrulayın. |
| Kaç puan aldınız? | Risk analizi ve mevcut davranışın korunduğuna dair kanıtlar. |
| Kapsamlı bir yeniden yazma projesi iyi bir eğitim projesi midir? | Genellikle hayır. Uygulanan beceriyi gizler ve korunmuş davranışın gösterilmesini zorlaştırır. |
| Kod yeniden düzenleme kalıpları üzerine bir test yeterli mi? | Hayır. Ön koşulları doğrular, ancak bir mühendisin bir değişikliği planlayıp doğrulayabileceğini teyit etmez. |
| İçeriği kim doğruluyor? | Kod tabanını bilen bir mühendislik yöneticisi ve kıdemli bir mühendis. |
| Eğitim neleri düzeltemez? | Eksik test ekipmanı, serbest bırakma basıncı, belirsiz sahiplik ve bakım çalışmaları için zaman olmaması. |
| İşe yaradığını nereden biliyorsun? | Daha önce görülmemiş, eski kodlara ait bir vaka, üzerinde mutabık kalınan kriterlere göre değerlendirilecek ve gerçek iş ortamında takip edilecektir. |
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, mevcut bir kod tabanının tasarımını iyileştirmek için kullanılan , küçük, davranışı koruyan dönüşümlerden oluşan kontrollü bir teknik olarak tanımlar. "Davranışı koruyan" ifadesi, yeniden düzenlemeyi yeniden yazmaktan ayıran şeydir ve eğitimde görünür kılınması gereken de budur. Teknik borç metaforu Ward Cunningham tarafından ortaya atılmıştır ve Fowler'ın tartışması, borcun kasıtlı ve ihtiyatlı bir şekilde üstlenilebileceğini, dolayısıyla her dağınık modülün düzeltilmesi gereken bir hata olmadığını hatırlatan faydalı bir örnektir.
Michael Feathers'ın eski kodlar üzerine yazdığı kitap da aynı uygulama yaklaşımını benimsiyor. Yayıncının açıklamasına göre kitap, geliştiricilere uygulamayı istemeden değiştirmediklerinden emin olmak için testler yazmayı ve mevcut yazılımı tamamen yeniden yazmadan kontrol altına almayı öğretiyor.
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:
- 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.
- 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.
- 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ığı. Kendi hızınızda çalışma bu aşamaya uygundur. Hatırlama testi yalnızca ön koşulları doğrular.
Pratik yapın. 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ında, kodu değiştirmeden önce testler yazılması önerilir ve alıştırma, küçük adımlar atma, testleri sık sık çalıştırma ve tasarımı adım adım iyileştirme pratiği olarak çerçevelenir. Her proje için mantıklı bir sıra şöyledir: hedefi ve sınırı 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 edin.
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şzamansız değerlendirme mi? Canlı destek, örneğin durup eksik bir testi eklemek mi yoksa devam etmek mi gerektiği gibi belirsiz durumlarda en büyük değeri katar. Öğrencilerin planlarını ve testlerini, uzmanlar tarafından açıklama eklenmiş bir versiyonla karşılaştırdıkları durumlarda ise eşzamansız değerlendirme yeterlidir. Birçok ekip her ikisini de kullanır: önce kendi hızlarında hazırlık, ardından zor vakalar için 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.
Olay şu: Eski bir fonksiyon, indirim, vergi ve kargo kuralı da dahil olmak üzere sipariş toplamını hesaplıyor. Hiç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çıklar, toplayacağı kanıtları belirtir ve ihtiyaç duyduğu ek bilgi veya desteği söyler.
İ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 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ğerlendirici, fonksiyonun bugün boş bir sepet, toplamı negatif yapan bir indirim ve yuvarlama durumu için ne yaptığını sorar. Yeniden deneme, öğrenciden kapsamı tek bir davranışa daraltmasını ve bunun değişmediğini nasıl kanıtlayacağını söylemesini ister.
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 yakalardım. Ardından indirim hesaplamasını kendi fonksiyonuna 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 sorardım.” Dikkat edin, bu cevap 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ğunu açıklayın. 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 korunmuş 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:
| Kriter | Gözlemlenebilir kanıtlar |
|---|---|
| Görev yürütme | Sınırlı bir eski kod iyileştirmesini planlar ve doğrular, yapılan işlemi ve bunun ardındaki kanıtları kaydeder. |
| muhakeme | Kısıtlamaları, alternatifleri ve belirsizliği açıklar, riskleri ve davranışın korunduğuna dair kanıtları inceler. |
| Sınırları | Onaylanmış prosedürleri kullanır ve bilgi veya yetki yetersiz olduğunda yardım ister. |
Ç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 bunlardan birini gizleyemez. Bu değerlendirme ölçütü bir öneridir, onaylanmış bir hazırlık standardı değildir: bir mühendislik yöneticisiyle uyarlayın ve pilot uygulamasını yapın. Yararlı geri bildirim içeren etkileşimli uygulama tasarlama kılavuzumuz , kararlarla bağlantılı geri bildirimin nasıl yazılacağını göstermektedir.
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, uyarlanabilir, etkileşimli ve canlı öğrenmenin ne zaman kullanılacağına ilişkin makalemize bakın.
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.
