Yeniden Düzenleme İş Akışları

Refactoring - Yeniden Düzenleme İş Akışları

https://martinfowler.com/articles/workflowsOfRefactoring/

Yeniden Düzenleme Türleri

TDD Refactoring

Refactoring genelde TDD kapsamında öğretilir.

1. Red: Geliştirilecek özellik için bir test ekle. Test geçmez. (Kırmızı) 2. Green: Geliştirilecek özelliği kabaca geliştirerek testin geçmesini sağla. (Yeşil) 3. Refactor: Yeniden düzenlemeyi kullanarak geliştirilen özelliği olabildiğince temiz ve iyi tasarlanmış hale getir.

Neden iki ayrı aşama var?

Bir testin geçmesini sağlayan kodu önce yazmak, sonra temizlemek neden önemli?

İki şapka metaforu:

Yeniden düzenleme: Yeniden düzenleme yaparken yapılan her değişiklik, davranışı değiştirmeyen küçük bir değişikliktir. Sadece testleriniz yeşilse yeniden düzenleme yaparsınız ve bir testin başarısız olması hata yaptığınızı gösterir. Böyle küçük değişikliklerden oluşan bir geliştirme süreciyle daha hızlı ilerlersiniz ve daha az riske girersiniz, çünkü debugging sürecine saplanıp kalmazsınız.

Özellik eklemek: Diğer değişiklikler özellik ekleme değişiklikleridir. Yeni testler eklersiniz ve mevcut testleri geçmez hale getirirsiniz. Davranış değiştirmeyen değişiklikler yapmak zorunda değilsiniz, (çünkü zaten yeni özellik ekliyorsunuz) ancak değişiklikleri küçük tutup hızlıca testlerin yeşil olmasına dönmek önemlidir.

Programlama yaparken sık sık bu iki şapkayı değiştirirsiniz, belki de birkaç dakikada bir, ancak -> Aynı anda sadece bir şapka takmak gerekir.

Yeniden düzenlemeyi ayırmak işe odaklanmayı kolaylaştırır. Green aşamasında yeni özelliği eklemek ve testin geçmesini sağlamaya yoğunlaşırsınız. Bu özelliğin en iyi nasıl yapılandıracağını düşünmezsiniz. Refactor aşamasında her şey çalıştığına göre küçük adımlarla ve yeşil testlerle çalışarak yeniden düzenleme moduna geçip artık iyi ve temiz tasarıma yoğunlaşabilirsiniz. Bu şekilde yapılan yeniden düzenleme "TDD refactoring" olarak adlandırılır.

Litter-Pickup Refactoring - Çöp Toplama Amaçlı Yeniden Düzenleme

Bir kod deposunda çalışırken genelde kötü kodların olduğu bölümlere denk geliriz. Belki çok yetkin olmayan bir geliştirici tarafından yazılmıştır, belki yetkin bir geliştiricinin kötü bir gününe denk gelmiştir, belki de biz 6 ay önce nasıl yapacağımızı doğru düzgün bilmeden yazmışızdır. Nedeni ne olursa olsun, çalıştığımız kodu temizleyerek, bir dahaki sefer geldiğimizde daha kolay ve hızlı çalışmayı sağlarız.

Bu yöntem genelde Boy Scout Rule - İzci Kuralı olarak adlandırılır: Her zaman kodu bulduğundan daha temiz bırak.

Comprehension Refactoring - Anlama Amaçlı Yeniden Düzenleme

İyi programcılar kolay anlaşılan ve bu nedenle kullanması ve değiştirmesi kolay koda değer verirler. Fakat temiz ve anlaşılır kod yazmak zordur. Ancak koda başka biri baktığında veya daha sonra kendi kodunuza dönüp baktığınızda onu nasıl daha anlaşılır hale getireceğinizi anlarsınız.

Ward Cunningham durumu şöyle açıklar:

"Ne zaman bir kodun ne yaptığını anlamaya çalışıyorsanız, zihninizde bir anlayış oluşturursunuz. Bu anlayışı oluşturduğunuzda, onu koda yansıtmalısınız ki, daha sonra gelen biri yeniden bu süreci yaşamak zorunda kalmasın."

Litter-Pickup Refactoring ve Comprehension Refactoring Fırsatçı Yeniden Düzenlemelerdir. İkisinde de başka bir şeyin üzerinde çalışırken bir sorun görürsünüz ve sorunu giderirsiniz.

Preparatory Refactoring - Hazırlık Amaçlı Yeniden Düzenleme

Bazen mevcut kod yapısının yeni ekleyeceğiniz özelliği kolayca eklemenize izin vermeyecek bir yapıda olduğunu görürsünüz. Bu durumda önce kodu yeni özelliği daha kolay ekleyeceğiniz hale getirebilir, daha sonra yeni özelliği kolayca ekleyebilirsiniz. Bu işlem boyama öncesinde yapılan hazırlığa benzetilebilir. Yüzeyi zımparalamak ve temizlemek boyama işinin kendisi değildir, ancak boyamanın daha hızlı yapılmasını ve daha uzun süre dayanan bir boyama işlemi yapmayı sağlar.

Planned Refactoring - Planlı Yeniden Düzenleme

Bazı takımlar yeniden düzenlemeyi planlayarak ayrı bir iş olarak ele alırlar. Takımlar adanmış bir dikkat isteyen büyük çaplı yeniden düzenlemeler için böyle bir yöntem seçer. Bu durum aslında takımın diğer yeniden düzenleme iş akışlarını kullanarak yeterince yeniden düzenleme yapmadığını gösteren bir işarettir. Eğer yeniden düzenleme işlerinizin çoğu sadece planlanmış işlerden oluşuyorsa bu kötü bir kokudur. Diğer yeniden düzenleme iş akışlarını çalışma düzeninize nasıl dahil edeceğinizi düşünmelisiniz.

Long-Term Refactoring - Uzun Vadeli Yeniden Düzenleme

Bazen belki aylar sürecek, büyük çaplı yeniden düzenlemeler yapılması ihtiyacı belirir. Örneğin büyük bir modülün başka bir modülle değiştirilmesi veya veri katmanının değiştirilmesi gibi. Bu çapta değişiklikler de yeniden düzenleme ile gerçekleştirilebilir. Takım bu işle ilgili kaba bir plan yapıp, çalışma düzenlerinde yapabildikleri kadar değişiklik yapıp istenen mimariye doğru ilerleyebilir. Bu değişiklikler özünde yeniden düzenleme olduğu için, yeni özellikler eklense de kod deposu çalışır durumda olmaya devam eder. Bu uzun vadeli yeniden düzenleme işlemleri için sık kullanılan bir teknik Branch By Abstraction 'dır. Bir soyutlama katmanı oluşturarak hem mevcut yapıyı, hem de yeni yapıyı desteklersiniz.

Sonuç

Yeniden düzenleme zaman kaybı mıdır?

Geri dönüşü sağlamak Yeniden düzenleme kodu daha kolay anlaşılır hale getirir, böylece daha sonra yapılan değişiklikler daha hızlı ve ucuz hale gelir. Hazırlık amaçlı yeniden düzenleme, yeni ekleyeceğiniz özelliği daha kolay eklemeyi sağlayarak karşılığını hemen geri öder. Yaptığınız yatırımın dönüşünü daha sonra yapılacak geliştirmeyi daha hızlı yaparak almayacaksanız yeniden düzenleme yapmayın.

Yeniden düzenleme ve yeni özellik teslimatını dengelemek Yeniden düzenleme, özellik ekleme ile birlikte yapılmalıdır. Kodu anlaşılır hale getirmek için yeniden düzenleyin, ancak her şeyi düzeltmeye çalışmayın. Önemli olan kod deposundan birkaç kez geçerek aşamalı bir iyileşme gerçekleştirmektir.

Yeniden düzenlemeyi verimli bir şekilde kullanabilmek için bu iş akışlarını birleştirmek gerekir ki yeniden düzenleme, geliştirme sürecine görünmez bir şekilde dahil olsun.