Yazılımcılara tavsiye: Çalışıyorsa dokunmayın
Üzerinde çalıştığınız bir projeyi hayal edin. Siz takıma katılmadan önce diğer programcılar tarafından kodlanmış. Yazılım beklendiği gibi doğru bir şekilde çalışıyor. Düzeltilmesi gereken bazı hatalar var fakat yazılım yapması gerekeni güzel bir şekilde yapıyor. Daha fazlasını değil.
Bu kod dışından diğerlerinin gördüğü resim. Müşterilerin problemlerini çözen ve beklenildiği gibi çalışan iyi bir yazılım.
Peki ya kod? Kodun arkasındaki yazılım ekibi? Onlar üzerinde çalıştıkları yazılım hakkında ne düşünüyorlar?
Bu yazılımı geliştiren programcılardan biri olarak, sen kod tarafından baktığında tamamen farklı bir resim görüyorsun. Öncelikle, kod tabanının gereksiz bir şekilde çok büyük olduğunu düşünüyorsun. Bu yazılımın aynı fonksiyonelliği sağlayacak şekilde çok daha az kod yazarak kodlanabileceğini kesinlikle biliyorsun. Yazılan kodlar sana çok karmaşık geliyor. Bu kodlar daha basit ve yapısal bir şekilde daha iyi kodlanabileceğini düşünüyorsun. Yeni bir şey uygulamak veya yeni bir özellik geliştirmek zor ve acılı. Çünkü yeni bir özellik eklemenin eskileri de hesaba katarak gerekli adaptasyonun yapılması gerektiğini biliyorsun. Herşey birbirine geçmiş durumda. Projede yer alan modüller birbirine sıkı bir şekilde bağımlı. Bir değişiklik yapmak birçok modülü etkiler durumda. Bu nedenle küçük değişiklikleri yapmak bile uzun zaman alıyor. Peki ya hata ayıklama? Hataları bulmak ve düzeltmek çok fazla zaman alan diğer bir konu.
Kötü tasarım ve çirkin kod yapısına rağmen, yazılım düzgün çalışıyor. Müşteriler mutlu. Şimdi sen bir yol ayrımındasın. Senin için muhtemel iki yol var. Bir yol sana eski mühendislik atasözü olan “Çalışıyorsa dokunmayın” felsefesini takip etmeni söylüyor. Ve diğer yol da sana kod üzerinde çalışırken işini kolaylaştırmak ve yönetilebilir bir kod için bir takım kod iyileştirmeleri yapmanı söylüyor. Bunun için kodun bir bölümünü yeniden yapılandırıp daha okunabilir ve anlaşılabilir yapmalısın. Hangi yolu tercih ederdin? “Çalışıyorsa dokunmayın” eski mühendislik atasözünü takıp eder miydin?
İki farklı yazılımcı zihniyeti
Bana göre cevap basit. Fakat sorunun cevabını vermeden önce, bu konuyu daha iyi anlamamızı sağlayacak iki farklı yazılımcı zihniyetini tanıyalım.
İlk yazılımcı zihniyeti eski mühendislik atasözünü takıp eder: “Çalışıyorsa dokunmayın.” Onlara göre, kod stili hiçbir anlam ifade etmez. Onlar sonuç odaklı programcılardır. Önemli programlama prensiplerine aykırı olarak yazılan kod karmaşık ve kötü bir şekilde yapılandırılmış olabilir. Eğer kod çalışıp, istenen görevi yerine getiriyorsa herhangi bir sorun yoktur. Kodun nasıl yazıldığı konusunu umursamazlar. Yani bu programcılara göre, çalışan fakat kötü bir şekilde yazılmış kodu iyileştirmek tamamen zaman kaybıdır. Kod zaten çalışır durumda. Neden dokunsunlar ki? Ve bunun da ötesinde, kötü kodları düzeltirken ortaya yeni hataların çıkma ihtimali gibi büyük bir risk de var. Tüm bunlar onların eski mühendislik atasözünü takıp etmeleri gerektiğini söylüyor.
Diğer tarafta ise, bir başka programcı zihniyeti, kodu bir sanat eseri olarak gören zihniyet. Bu zihniyet yukarıda açıkladığım bütün şartlar altında kendini çok rahatsız hisseder. Bu zihniyetteki programcılar kötü bir şekilde yazılmış kodu okurken tiksinirler. Onlar projede karşılaştıkları her kod parçasını düzeltmeye çalışırlar çünkü kod stili konusunda aşırı derece de takıntılıdırlar ve yazılan her kod parçası bir sanat eseri kalitesinde olmalıdır. Başka programcılar tarafından iyi bir şekilde kodlanmış kodlar olsa bile bu kodları da kendi stillerine uydurmak için düzeltmeye çalışacaklardır. Yani temel olarak, “Çalışıyorsa dokunmayın” atasözünü takıp etmezler. Herşeyi kendi mentalitelerine göre düzeltmek isterler. Kodun çalışıp çalışmaması farketmez.
Sizin için bu durumda işe yarar en iyi çözüm ne olabilir?
Çok basit. Üzerinde sıklıkla aktif olarak çalışıtığınız kod bölümlerini bulun ve buradaki kod parçalarını daha okunabilir ve anlaşılabilir bir hale getirin. Diğer parçalara dokunmanıza gerek yok. Tabi bu parçalar herhangi bir hata içermiyorsa ve beklenildiği gibi doğru bir şekilde çalışıyorsa.
Bu ayrım neden bu kadar önemli?
Kodunuzun çekirdeğindeki yani merkezindeki kodlar üzerinde en çok çalışacağınız alanlardır. Bu alanları diğerlerine nazaran çok daha fazla okumak zorunda kalırsınız. Bu alanlarda diğer alanlara göre daha fazla değişiklikler yaparsınız. Ek bir fonksiyonellik eklemeye veya yeni bir özellik geliştirilmesine ihtiyaç duyulduğunda, bu yeni parçalar direk olarak yazılımınızın merkezindeki en önemli alanlarla birlikte çalışacaklardır. Birçok yazılım hatası çekirdekteki bu kod parçalarından meydana gelir ki bu da hataları bulup düzeltmek için en çok bu alanlar üzerinde zaman harcayacağınız anlamına gelir. 80/20 kuralını hatırlayın. “Yazılımınızdaki hataların %80’ni kodunuzun %20’lik kısmından meydana geliyor.“
Peki ya diğer parçalar?
Bu parçalar nadiren üzerinde çalışmak zorunda kalacağınız parçalardır. Onlar aylar belki de yıllar önce yazılan ve beklenildiği gibi doğru bir şekilde çalışan kod parçalarıdır. Daha basit, daha okunabilir ve anlaşılabilir bir şekilde yazılabileceklerine rağmen çirkin bir şekilde yazılmışlar. Bu onları da düzeltmeniz ve iyileştirmeniz anlamına gelmez. Allah bilir onları bir daha ne zaman okuyup değiştirmeniz gerekecek. Yani bu alanlar olduğu gibi kalabilir. Unutun onları. Düzeltmeye gerek yok. Düzeltmeye gerek yok dediğim de kod stilini kastediyorum. Eğer bu alanlarda da kritik hatalar varsa, tabi ki bu hataları da düzeltmeniz gerekecek. Bunun haricinde daha önemli işler üzerinde çalışarak zamanınızı harcayabilirsiniz.
Beklendiği gibi çalışsalar bile yazılımın çekirdeğindeki kodların iyileştirilmesi neden bu kadar önemli?
Eğer müşterilerinize uzun yıllar hizmet etmek istiyorsanız, yönetilebilir ve sürdürülebilir bir yazılıma sahip olmalısınız. Yönetilebilir bir ürün, gerekli değişikliklerin zorlu mücadeleler vermeden, kolayca ve diğer parçaları bozmadan yapılabilmesi demektir. Hata ayıklamak ve bulunan hataları düzeltmenin çok fazla zaman almaması demektir. Yeni bir özellik eklemenin kolay olmasıdır. Sonuç olarak mutlu programcılar ve mutlu müşterilere sahip olmanız demektir.
Kolay yönetilebilir ve bakımı yapılabilir bir ürüne nasıl sahip olabilirsiniz?
Programcıların bakış açısından baktığımızda, birçoğumuz zamanımızın büyük bir kısmını kod yazmaya ayırdığımızı zannederiz. Aslında, bu zamanımızın oldukça küçük bir kısmını kapsar. Programcılar zamanlarının büyük çoğunluğunu kodu okumak ve hata ayıklamak üzerine harcarlar. Bahse girerim, her programcının bulunması uzun zaman alan hatta günlerini alan bir hata ayıklama hikayesi vardır. Hatayı düzeltmek çok kolay ve çabuk bir eylemdir fakat onu bulmak tam bir kabustur.
Bu kabusları yaşamamak, en azından olasılığını azaltmak için periyodik olarak kod bakımı yapmalısınız. Yazılımcılara sadece yeni özellikler geliştirmek için ödeme yapıldığı gibi yanlış bir düşünce var. Halbu ki, daha önceden yazılmış bir kodun bakımını yapmak ve onu iyileştirmek yazılımcıların iş tanımları arasında önemli bir yere sahip. Biliyorum, genel olarak kimse yazılmış bir koda geri dönüp onu iyileştirmeyi istemez. Neden? Çünkü bu kod zaten yazılmıştır ve aktif olarak çalışıyordur. Yeni bir özellik yazılmayacak veya yazılımcıları heyecanladıracak yeni bir meydan okuma yoktur. Dolayısıyla bu durum yazılımcılara zamanlarını boş yere harcayacakları gereksiz bir yük gibi görünür.
Fakat periyodik olarak kodunuzun bakımını yapmak, yazılan çirkin kodları iyileştirmek, onları daha okunur ve anlaşılır yapmak kolay yönetilebilir bir yazılımın anahtarıdır. Bu sebeple son teslim tarihini yakalamak adına çirkin kodlar yazarak diğer bir deyişle tavizler vererek üstlendiğiniz teknik borçlara daha sonra dönüp düzeltmek yazılımının ömrünü uzatırken sizin de yazılımınızı kolay bir şekilde yönetebilmenizi sağlar.
İyi yazılan kod anlaşılması kolay olan koddur. Daha fazla anlaşılabilir kod daha fazla iş kolaylığı demektir.