TLTR;

Yazıyı Uzun Bulanlar İçin Özet:

Projenizin kaynak kodu -sizden önceki geliştiriciler tarafından- kötü yazılmış diye yenisini yazmaya başlamayın. Öncelikle mevcut kodu iyileştirip yenisini daha iyi yazabileceğinizi kanıtlayın. Yeniden yazma kararını yaptığınız iyileştirmeler sonrasında değerlendirin.

Önsöz

Birçoğumuz, çalıştığımız projelerde kaynak kodun kötü olmasından, kendimizden öncekilerin kodu ne kadar kötü yazdığından, projeye yeni özellikler eklemenin zorluğundan, hata tespiti ve giderilmesi zorluklarından şikayet etmişizdir. Eğer bu projelerde çalışan kişilerden bir veya birkaçı yöneticilerini ikna edebilirlerse projelerin aylar, hatta yıllar süren, bitmeyen yeni sürümlerini de görmüşsünüzdür.

Çalışmış olduğum projelerin hemen hepsinde aynı problemleri yaşamış biri olarak, birçok projenin yeniden yazılması konusunda ekip arkadaşlarımı ve yöneticilerimi ikna edip, bazı projelerin de yeniden yazılması aşamasında görev almış bulunmaktayım. Ancak zaman içinde farkettim ki, projelerin yeniden yazılması, hem zaman hem de maliyet açısından şirketleri zor durumda bırakabilecek kararlardır. Özellikle de; şirketin ana mali kaynağı olan mevcut projedeki yeni talepler alınmaya devam edilirken.

Bahse konu projelerin güncel teknoloji ile yenilenmesi, iyileştirilmesi, hatta bazen yeniden yazılması fikirlerini değerlendirmek, teknolojiye uyum açısından şirket ve proje için çok faydalı olacaktır. Ancak kaynak kodunu beğenmediğimiz, uyum sağlamakta ve güncellemekte zorlandığımız projelerin hepsi için “Yeniden Yazalım” yaklaşımı birçok proje için imkansız bir talep olarak kalacaktır. Kalmalıdır da.

Peki Ne Yapmalı?

Yeniden yazmak yerine, öncelikle mevcut projeleri sağlıklı bir şekilde ayakta tutabilmek çok önemli ve gereklidir. Mevcut projeyi ayakta tutabilmek için de, “çalışıyorsa dokunma” demek yerine, dokunduğumuz her satır kodu sürekli iyileştirmek gerekiyor.

İyileştirmekten kasıt nedir?

İyileştirmek denince benim aklıma ilk olarak “Temiz Kodlama Pratiklerinin” uygulanması geliyor. Bu pratikleri daha sonraki yazılarımda ele almayı planladığım için, bu yazıda bu konuya çok girmeden düşüncelerimi aktarmaya çalışacağım.

Hata ve uyarı mesajlarının iyileştirilmesi

Birçok uygulamada, hatta bazı işletim sistemlerinde bile, kullanıcılara gösterilen hata mesajları maalesef kullanıcılara hitap etmiyor ya da doğru bilgilendirmeyi yapamıyor. İyileştirme aşamasında öncelikle kullanıcılara gösterilen mesajların (başarılı/hatalı/bilgi amaçlı) doğru olarak ve kullanıcıların anlayabileceği şekilde gösterilmesi gerekiyor. Yazılımcılar olarak maalesef bir çoğumuz buna pek dikkat etmiyoruz.

Görsel : https://www.codeproject.com/Articles/2949/Managing-Unhandled-Exceptions-in-NET


Bilinen hataların ve çözüm yollarının kullanıcılarla paylaşılması

Çalışan uygulamalarda, bilinen hatalar var ise, hatayla ilgili alınan kararlar ile yapılan işlemler kullanıcılarla (ve varsa yardım masası ile) paylaşılmalı ve geçici çözüm önerileri sunulmalıdır. Bu şekilde geliştirici ekibin kullanıcılar tarafından sürekli aynı konularla ilgili meşgul edilmesi önlenebilecektir.

Uygulamadaki hataların (hızlıca) giderilmesi

Uygulamada karşılaşılan hataların mümkün olan en kısa sürede giderilmesi, hata giderme sırasında dokunulan her satır kodun, fonksiyonun veya sınıfın temiz kodlama pratiklerine uygun olarak güncellenmesi uygulamanın iyileştirilmesi açısından çok önemlidir.

Birim testleri ve entegrasyon testlerinin yazılması

Uygulamada yapılan değişikliklerin başka sayfaları veya modülleri bozmadığından emin olabilmek için birim ve entegrasyon testlerinin doğru bir şekilde yazılması büyük önem arz etmekte. Bu konu da kendi başına kitap yazılabilecek bir konu olduğundan burada detaylarına değinmeyeceğim.

İyileştirmeleri yaptık, şimdi ne olacak?

Eğer yukarıda bahsettiğim iyileştirmeleri doğru şekilde yapabildiyseniz, uygulamanız bir süre daha mevcut hali ile çalışmaya devam edebilecektir. Hatalardan temizlenmiş olan ve biraz da temiz kodlama pratiklerine uygun olarak değiştirilen uygulamanıza güncel teknolojileri eklemeniz daha kolay olacaktır.

Bu aşamada, eğer hala “Yeniden Yazma” konusunda düşünceleriniz devam ediyorsa, mevcut uygulamada, çok kritik hata düzeltmeleri dışındaki geliştirmeleri durdurup yeni yazılacak proje için çalışmalara başlayabilirsiniz.

İyileştirmeleri yapamıyoruz, yine de yenisini yazmaya başlamalı mıyız?

Aslında bu yazıyı yazma sebebim yazının bu kısmı. Bu durumda uygulamanızı yeniden yazma kararı alırsanız çok büyük bir ihtimalle, yazının başında bahsettiğim aylar, hatta yıllar süren, bitmeyen yeni sürümünüz olacaktır.

Bu düşüncemin sebeplerine gelince;

Geliştirici ekibin 1 yıl ve daha fazla bu projede görev aldığını varsayalım. Bu süre boyunca, projede gerekli iyileştirmeleri yapmamış olan, hatta belki de -kendilerinden çok önce- kötü yazılmış olan kodu, iyileştirmek yerine, “böyle gelmiş, böyle gider” diyerek uygulamada kodlama yapmış olan ekibin yeni yazılacak projede temiz kodlama yapabilecek disiplini oluşturmaları neredeyse imkansızdır. Çünkü eski kodların kötü diye nitelendirilmesinin bir nedeni de mevcutta bu projede görevli ekiptir.

Geliştirici ekibin yaklaşık 6 aydır bu projede çalıştığını varsayarsak, büyük ihtimalle yeni projeyi yazacak bilgi birikimine henüz sahip olmaya başlamışlardır. Yukarıda bahsetmiş olduğum iyileştirmeleri önümüzdeki 6 ay boyunca yaptıklarında hem gerekli bilgi birikimine sahip olacaklardır, hem de 6 ay sonunda projenin yeniden yazılıp yazılmaması gerektiğine daha sağlıklı karar verebileceklerdir. Yeni kurulmuş bir ekiple, eski bir projenin yeniden yazılması kararı da pek sağlıklı olmayacaktır.

Sonuç

Teknolojik gelişmelerin çok hızlı ilerlemesi sebebiyle, ister istemez uygulamalarımız zaman içerisinde güncelliğini yitirecektir. Uygulamalarımızın güncelliğini yitirmemeleri için, yeni teknolojileri hızlıca uygulayabilecek esnekliğe sahip, kolay anlaşılır, kolayca test edilebilir olmaları gerekmektedir. Bunun için de yazılım ekipleri, temiz kodlama pratiklerini disiplinli bir şekilde uygulayan, kendilerini sürekli geliştiren ve yeniliklere açık olan ekipler olmalıdır.

Projenin yeniden yazılması konusunda da yazının başındaki cümlemi aynen yazıyorum:

Projenizin kaynak kodu -sizden önceki geliştiriciler tarafından- kötü yazılmış diye yenisini yazmaya başlamayın. Öncelikle mevcut kodu iyileştirip yenisini daha iyi yazabileceğinizi kanıtlayın. Yeniden yazma kararını yaptığınız iyileştirmeler sonrasında değerlendirin.

Kaynakça

Yazı Fotoğrafı: https://www.pexels.com/photo/person-with-grey-ring-using-macbook-pro-159760/

Alıntılar yapmamakla birlikte, bazı fikirleri aşağıdaki kitaplardan birinden edinmiş olabilirim.