Mikado Yöntemi: Eski kod kontrol altında

kapanış bildirimi

Bu makale İngilizce olarak da mevcuttur. Teknik yardımla tercüme edildi ve yayınlanmadan önce editoryal olarak gözden geçirildi.

Bir daha gösterme.

Eski sistemler belli bir çekiciliğe sahiptir çünkü kendi heyecan verici zorluklarını sunarlar. Modern yapıları yeşil alan uygulamasında bir araya getirmekten çok daha ilginç olabilirler. Ancak geliştiriciler eski sistemlerde değişiklik yapma konusunda isteksizdirler çünkü neyin bozulacağı genellikle belirsizdir.

Birçok eski sistem teknolojik olarak on yıldan fazla bir süre öncekiyle aynı seviyededir ve bu nedenle artık güncel değildir. Elde tutma ve daha fazla geliştirme için uygun çalışanları bulmak zordur. Ne yazık ki, kullanılan kütüphanelerin ve çerçevelerin düzenli olarak güncellenmesinin pek faydası yoktur. Son yıllarda pek çok elden geçen kaynak kodu gelişmiyor.

Başlıca zorluklar iç yapıya ilişkin bilgi eksikliği, projenin başında alınan kararlar ve değişikliklerin etkilerinin belirsiz olmasıdır. Ne yazık ki, çoğu geliştirici genellikle eğitimleri veya çalışmaları sırasında yalnızca yeni sistemlerin nasıl oluşturulacağını öğrenir, mevcut yazılımın nasıl korunacağını veya daha fazla geliştirileceğini öğrenmez.

Yeniden düzenleme, yapıyı ve tasarımı iyileştirmenin bir yoludur. Karmaşık ortamlarda Mikado yöntemi ek destek sunar. Yöntemi icat eden Ola Ellnestam ve Daniel Brolund'un sözleriyle: “Mikado yöntemi, analiz edilemeyecek ve dolayısıyla manipüle edilemeyecek kadar büyük bir sistemde değişiklik yapmak için karmaşık kodda önemli değişiklikler yapmanın yapılandırılmış bir yoludur. Bu, dünyadaki hemen hemen her üretim sistemi için geçerlidir” (Ola Ellnestam, Daniel Brolund: Mikado Yöntemi; Manning 2014).

Mobilya nasıl taşınır

Eski bir kod tabanını değiştirirken geliştiriciler bazen ter dökebilirler. Özellikle değişiklikler kontrolden çıktığında ve birkaç saat çalıştıktan sonra en başa döndüğünüzde. Ayrıntılı dokümantasyon veya en azından otomatik test varsa daha kolaydır. Ancak çoğu zaman gerçek yalnızca kaynak kodunda bulunur ve geliştirme ekibi boşuna test arar.

Mikado yöntemi yapılandırılmış yaklaşımı sayesinde tüm bunları desteklemektedir. Karmaşık kodun yeniden düzenlenmesi, bir apartman dairesindeki mobilyaların yeniden düzenlenmesine benzer. Yer nedeniyle eski döşemeli kanepeyi yeni satın alınan üç kişilik kanepeyle değiştirmek mümkün değilse (kapı yerinde olmayacaktır), büyük bir yenileme çalışması yapılması gerekecektir (bkz. Şekil 1).

Yemek masası yeni kanepeye yer açmalıdır. İlk önce kaldırılması gereken eski döşemeli mobilyaların yerini almalıdır. Tıpkı programlamada olduğu gibi, karıştırmanın içinde hızla kaybolabilirsiniz. Eğer sakinler yeni kanepeyi odaya taşısaydı, mobilyaları taşıyacak yer kalmayabilirdi.

Bu nedenle adımlar başlangıçta sadece teorik olarak incelenir ve engeller (örneğin yemek masasının taşınması sırasında) kaydedilir. Bir sonraki aşamada bölge sakinleri yeni keşfedilen sorunu ortadan kaldırmaya çalışacak. Ancak, bu durumda eski döşemeli mobilyalar gibi sıklıkla başka engeller de vardır. Bunun öncelikle daireden kaldırılması gerekir. Daha sonra yemek masası hareket ettirilebilir ve son olarak yeni kanepe istenilen konuma yerleştirilebilir.

Yeniden düzenleme yoluyla geliştirilmiş yazılım tasarımı

Yeniden düzenleme, yazılım tasarımını geliştirmeye yönelik bir araçtır. Yirmi yıldan fazla bir süre önce, Martin Fowler kitabında şu tanımı kaydetmişti: “Yeniden düzenleme (isim): yazılımın iç yapısında onu daha anlaşılır hale getirmek ve görünür davranışını değiştirmeden daha ekonomik olarak değiştirebilmek için yapılan bir değişiklik” (Martin Fowler; Yeniden Düzenleme: Mevcut Kodun Tasarımını İyileştirme; Addison Wesley 2019).

Kaynak kodunu yeniden yapılandırmak isteyen herkes eninde sonunda bir dizi yeniden düzenlemeyi kullanacaktır. Bunlar sözde davranışı koruyan kod dönüşümleridir: teknik mantıkta hiçbir şey değişmez. Amaç, gelecekteki değişiklikleri kolaylaştıran ve test edilebilirliği artıran daha anlaşılır bir iç yapıdır. Yeniden düzenlemenin iyi çalışması için bazı müttefiklere ihtiyacı var.

Bunlar arasında hızlı oluşturma ve oluşturma süreleri, mevcut otomatik birim veya entegrasyon testleri ve değişikliklerin herhangi bir zamanda kolayca geri alınabilmesi için sürüm yönetimi yer alır. Ayrıca araçların kullanımı güvenli ve hızlı uygulamayı destekleyebilir. Eclipse veya IntelliJ gibi birçok modern geliştirme ortamı kullanışlı bir araç seti ile birlikte gelir.

Geliştiriciler, yeniden düzenleme yoluyla yazılımlarındaki mevcut yatırımları korur, tasarımın bozulmasını önler ve okunabilirliği, düzenlenebilirliği ve test edilebilirliği artırır. Gerekirse, iyi gizlenmiş hataları bulabilir, kod hakkında aktif öğrenme yoluyla bilgi aktarabilir ve hatta kaynak kodun sıklıkla unutulan kullanıcıları olan sonraki geliştiricilere yardımcı olabilirler. Martin Golding'in sloganına göre: “Kodunuzu, onu anlaması gereken kişi, nerede yaşadığınızı bilen, elinde balta olan bir psikopatmış gibi yazın.”

Çalışma şeklimiz iki temel prensibe dayanmaktadır: Birincisi, program kodunu ihlal etmeyin ve ikincisi, aynı anda yalnızca tek bir şey üzerinde çalışın. Bunu başarmak için çok fazla öz disiplin gerekir. Geliştiriciler yalnızca küçük adımlar atmalı ve ardından kodu derlemeli ve testleri çalıştırmalıdır. Daha sonra tekrar en baştan başlıyoruz.

Kent Beck'in iki şapka metaforu da önemlidir. Aynı anda yalnızca bir şapka takabilirsiniz. Bu nedenle, yeniden düzenleme yaparken içerik kodunu değiştirmemelisiniz, yani yeni özellikler eklememeli veya hataları düzeltmemelisiniz.

Yeniden düzenleme birkaç durumda kullanılabilir: örneğin, kodun bozulmadan kalması için her gün düzenli olarak yarım saat süreyle. Veya geliştiriciler artık kaynak kodunu anlamıyorsa ve okurken aktif olarak öğrenmek istiyorsa. Yeniden düzenleme, genişletmelerden veya hata düzeltmelerinden önce olduğu gibi planlı değişiklikler için de kullanışlıdır. Veya kod incelemesi sırasında kodda tutarsızlıklar fark ettiğinizde. Robert C. Martin'in İzci Kuralı sloganına sadık kalarak: “Mekanı her zaman bulduğunuzdan daha temiz bırakın.” (Kevlin Henney: Her Programcının Bilmesi Gereken 97 Şey; O'Reilly 2010)

Bu arada, geliştiricilerin işi asla bitmiyor. Her yeniden düzenlemenin bir karşı yeniden düzenlemesi olabilir. Çünkü gerçek bir çıkmaz yoktur ve sonsuza kadar devam edebilirsiniz. Bu nedenle sınır koymak çok mantıklıdır. Geliştiriciler, analiz edilecek kod anlaşıldığında, belirlenmiş bir süre sınırına ulaşıldığında veya patron veya müşteri başka bir siparişle yaklaştığında durabilir.

Mikado yöntemi bu şekilde yardımcı olur

Yeniden düzenleme aslında oldukça basit görünüyor, ancak değil. Mümkün olan en küçük adımların atılması ve sürekli olarak testlerin derlenmesi veya çalıştırılması anlamına gelen prosedür hızla unutulur. Yönetilebilir bir bağlamda iyi çalışan şey, karmaşık yazılım sistemlerinde çok daha zordur. Mikado yöntemini kullanarak engelleyiciler hızla belirlenip analiz edilebilir. Ancak bu engeller başlangıçta tespit edilir ve ancak tüm analizin ardından adım adım ortadan kaldırılır. Ellnestam ve Brolund'un sözleriyle: “Mikado Metodu, süreçteki kod tabanını hiç bozmadan, birden fazla yineleme ve çalışma aşaması boyunca iş değeri odaklı iyileştirmeleri görselleştirmenize, planlamanıza ve uygulamanıza yardımcı olur” (Ola Ellnestam, Daniel Brolund: Mikado Metodu; Manning 2014).

Prosedür nispeten basittir (bkz. Şekil 2). İlk olarak geliştiriciler hedefi belirler (1). Bu gelecek değişimlerin başlangıç ​​noktası ve aynı zamanda sonun başarı kriteridir. Ekip daha sonra ilk çözümleri test etmeye başlar (2). Bu deneylerde, hipotezleri test etmek ve etkilerini gözlemlemek için kodu aktif olarak değiştirmenize izin verilir. Test uzmanları, Mikado grafiğinde (3) engelleri herkes için şeffaf bir şekilde görselleştirir. Daha sonra deneylerin (4) getirdiği değişiklikleri hemen tersine çevirirler; örneğin bir tane yaparak. git reset. Daha sonra 2. adıma geçin ve hiçbir engel kalmayıncaya kadar işlemi tekrarlayın.

Şekil 2 Mikado yönteminin genel akışını göstermektedir. Tekrarlanan dene-görselleştir-geri al (2) döngüsü sayesinde Mikado grafiği yavaş yavaş oluşturulur. Bu grafik sistemin yapısı hakkında birçok değerli bilgi içermektedir. Oluşturma işlemi herhangi bir zamanda durdurulabilir ve daha sonra devam ettirilebilir. Kod tabanı her zaman yürütülebilir durumdadır çünkü gerçekleştirilen tüm deneyler belgelendikten sonra tersine çevrilir. Belirlenen hedefe giden yoldaki tüm engeller analiz edildikten sonra grafik geriye doğru sarılır. Belgelenen tüm değişiklikler, orijinal hedefe ulaşılıncaya kadar (4) sırayla gerçekleştirilir (3).