Akin Yazılım Mühendisliği Brooks, En iyi kod, No Silver Bullet, süreç, süreç analizi, süreç tabanlı çalışma, yazılım, yazılım geliştirmek, Yazılım Mühendisliği
Bir kurum düşünün ki, bir şirket örneğin, çalışanlarının bir araca, binek otosuna, ihtiyacı olduğunda paaat, hemen araba yapmaya koyuluyor. Ya da diyelim ki kurum çalışanları çok sık uçakla seyahat ediyorlar, kurumun tepesindeki yönetici bakmış olmuyor “devamlı uçak bileti al uç, nereye kadar?” diye düşünüp, biz de kendi uçağımızı yapalım diye karar veriyor ve başlıyorlar işe…
okumaya devam …
Toplam görüntülenme sayısı: 1369
Akin Hikayeler, Java, Performans Java, JVM tuning, performans
Bugünkü hikayemizde yine bir performans problemi var. Problem, Java EE ile geliştirilmiş ve Weblogic AS üzerinde çalışan, transactional, web üzerinden tamamen internete açık ve sorgulama arayüzlerinin yoğun olarak kullanıldığı bir bilgi sistemiydi. Sistem çoğunlukla mesai saatleri içinde kullanılıyordu, sonrasında erişilebilir olsa bile kullanımı çok azdı. Problem ise, tamamen gelişigüzel ya da random olarak seyreden yavaşlıktı. Sistem yöneticileri yaptıkları gözlemlerde zaman zaman, ön taraftaki use caselerle ilişkilendiremedikleri yavaşlamaların sebebinin aşırı bellek tüketimi olduğunu belirlemiş durumdaydılar. Sistem clustered bir ortamda çalıştığından herhangi bir kesinti yaşanmıyordu ama bu problemin de çözülmesi gerekliydi.
Sistem yöneticilerinin verdikleri bilgilerden sonra lider developerlarla görüştüğümde, bazı usual suspect araştırmalarımı yaptım. Örneğin veri tabanı sorgulamaları, sorgulardan dönen verinin mahiyeti, bu verinin uygulama tarafından nesnelerle nasıl yönetildiği, web tarafındaki oturum (session) yönetimi vs. konulardaki yaklaşımlarını öğrenmeye çalıştım. Developerlardan bir şey çıkmadı, dahası her şeyi düşünerek ve iyi bir şekilde yaptıklarını, bundan dolayı da bu bellek problemine anlam veremediklerini söylediler. Biraz da “bizim problemimiz” değil havasındaydılar izlenimi elde ettim.
Sonrasında, sistemin kullanımda olmadığı, gece yarısı gibi bir zamanda, canlı ortamdaki uygulama sunucularının bize daha fazla bilgi verecek şekilde çalıştırılmalarını sağladım. Ben de test amaçlı kullanılan, pre-production sistem üzerinde çalışmaya başladım. Ortama girmek, genel de olsa mimariyi öğrenmek, sistemin ayağa kalkarken kullandığı parametrelerini bulmak vs. nihayetinde böyle ortamlarda sıklıkla yaptıklarımdandır. Sistemler büyüdükçe, onlara dokunmak ve bilgi almak daha da karmaşıklaşır. Erişebilmek bile bir problem haline gelir.
Neyse, test sistemi üzerinde bunları elde ettikten sonra, olabildiğince çok kişinin, sistemi kullanması sağlandı ve ben de JVM içindeki olup biteni gözlemlemeye başladım. Fakat bu çalışma çok da işe yaramadı, çünkü problemli durumu üretmedi. Sebebi, kullanıcı sayısını azlığı yanında, hep bildiğimiz, developerların tester olarak kullanılmasının getirdiği yapaylıktı. Fakat sebebini bilmediğimiz bir problemi ararken, şansımızı olabildiğince arttırmak için yapılabilecek her şeyi yapma eğiliminde oluruz. Hatta bu çalışmalar sırasında, performansla pek de alakası olmayan konularda gözlemler yaptım ve bunları paylaştım. Mesela isimlendirme ile ilgili konulardan tutun da çok karmaşık metot ve sınıflara kadar, cohesion ve coupling problemleri, gerekli gereksiz kullanılmış wrapper sınıflar, çok threadli ortam olmasına rağmen bu göz önüne alınmadan yazılmış kodlar vs. Tonla teknik borç çıkar o sıradaki çalışmalardan ama bunları kim duyar da kulak verir, onu sormayın.
Performans problemlerinin sebebini bulmak çoğu zaman onları düzeltmekten daha zor olabilir. Çok basit bir kod hatası, deadlock ya da sonsuz döngü problemi, hemen hiç bir şekilde koda bakarak anlaşılacak tipten bir problem değildir örneğin. Dolayısıyla o hatayı tekrardan üretemezseniz, probleme yol açan durumu tekrar, kontrollü bir şekilde gözlemleyemezseniz, problemi bulmak için çok da şansınız yoktur. Zamanınız ve imkanınız varsa, sistem üzerinde otomatik test araçlarıyla çalışıp yük üretebilirsiniz ama hala problemi oluşturacak durumu yaratamayabilirsiniz. Örneğin, yüzlerce arayüzün belki de çok basit bir noktasından tetiklenen bir problemdir peşinde koştuğunuz ama siz boş yere farklı use caselere yüklenerek arka tarafta, JVM’in içinde bir bellek problemi, çok uzun süren metot çağrıları, veri tabanından dönmeyen sorgular vs. arar durusunuz. Nitekim burada da öyle oldu.
Ertesi gün çalışmaya devam ederken, canlı ortamdaki uygulama sunucularından birinde benzer bir yavaşlık gözlemlendi ve sonrasında uygulama sunucusunun JVM’inin dumpını alıp üzerinde çalıştığımda, hiç bir filtreden geçmeden dolayısıyla “where” ifadesine sahip olmadan veri tabanına gönderilen bir sorgunun, yüzbinlerce satırı belleğe yüklediğini, JVM’in de heap belleğinin tamamını bu sorgudan dönen satırlardaki nesneleri oluşturmak için kullandığını gözlemledim. Hatta dumptan yola çıkarak o anda sistemde hangi kullanıcıların oturumlarının olduğunu, hangi kullanıcının, web arayüzünde nerede, bu sorguyu çalıştıracak use casei işlettiği vb. verilerin hepsine ulaştım. Bu arada parantezlik ufak bir bilgi: Eğer kritik bilgileri, örneğin şifreleri vs. hashlemezseniz, benim gibi çalışanlar, o anda sistemi kullananların tüm mahrem bilgilerini kolayca görebilirler!
Sonrası iplik söküğü gibi geldi zaten. Ön tarafta, arayüzde ne yapıldığı, arkada hangi metot çağrılarından sonra veri tabanına hangi sql cümlesinin gönderildiği, dönen cevaptaki satır sayısı, her satırdaki bilgi vs. hepsini ortaya koydum. Developerların gözünden kaçan bir durum, kötü bir sql sorgusu oluşturuyor ve joinlerden sonra oluşan yüzbinlerce satır, sorgunun cevabı olarak JVM’e dönülüyordu. Web arayüzünde zaten böyle bir cevap beklemeyen developerlar, herhangi bir paging de uygulamadıklarından, JVM’e, veri tabanından dönen satırlar için tonla nesne yaratmak dışında bir seçenek de bırakmıyorlardı.
Developerlara bu durumu ilettiğimizde, hızlıca gidip web arayüzüne bir kaç kontrol, zorunlu alan vs. filtreleri koydular ve problem ortadan kalktı. Problemi bulmak 2 küsür gün tuttu, çözmek en çok bir saatti! Ah şu developerlar olmasa ne kadar rahat olacak yazılım geliştirmek!
Developerlar eğer yaptıkları işi daha geniş bir perspektiften göremiyor ve “benim makinamda çalışıyor” ya da “ben test ettim, hiç bir problem yok” şeklinde konuşuyorlarsa, lütfen buna güvenmeyin. Bu tavra önem verin, bu tür sözlerin arkasını doldurmaya zorlayın onları ama sadece bu sözlerle ilerlemeyin. Ya da bir başka deyişle, her developerın bunu söyleme hakkı olmadığını bilin. Tam da bu yüzden architect/mimar vb. rollerle, sisteme çok farklı açılardan, yukarıdan, bakabilen, tecrübeli ve sistem anlayışına sahip kişilere ihtiyacımız var.
Kıssadan hisse: Yazılım geliştirme, developerlara bırakılamayacak kadar karmaşık bir iştir!
Toplam görüntülenme sayısı: 682
Akin Eğitim ve Seminer, Java, Yazılım Mühendisliği
Eğitim hayatımda bana sıkça sorulan birisi de bir programlama dilini öğrenmekten proje geliştirmeye nasıl geçileceği konusudur. Çok sık duyarsınız “Java’yı biliyorum ama bir proje nasıl yapılır, neresinden başlanır, nasıl ilerlenir bilmiyorum” şeklindeki konuşmaları. Doğrudur, bu durum herkesin kariyerinin başında yaşadığı cinsten sıkıntılardandır. Bu yazıda bu sıkıntının nasıl aşılabileceğini ele almak istiyorum.
Programlama, bir programlama dili yoluyla bilgisayara bir iş yaptırmaktır. Programlama dili ise bir araçtır, bilgisayara iş yaptırmanın en temel yoludur. Programlama dilleri dışında da bilgisayara iş yaptırmanın yolları vardır ama bir uygulama kadar geniş ve detaylı iş yaptırmaktan bahsediyorsak, hele işin içinde kullanıcılarla iletişim varsa, programlama dilleri dışında pek alternatifimiz yok gibi. Fakat bir programlama dili öğrenmek, temelde onun anahtar kelimelerini, kullanışlarını ve söz dizimini öğrenmek demektir. Her ne kadar programlama dilini öğrenmek ile onu kullanarak problem çözmek içe içe geçmiş süreçler olarak görünüyorsa da işin başında daha çok programlama dilinin kendisi ile uğraşılırken ilerleyen zamanlarda, özellikle dilin temellerinde belli bir noktaya gelince, problem çözme tarafı daha ağır basmaya başlar. Örneğin üniversitede, algoritmalar, veri yapıları, ağlar, derleyiciler (compilers) vb. ders ya da konularla bir programlama dilinin bir problemi çözmek için nasıl kullanılacağını öğreniriz. Örneğin pi sayısını hesaplamanın farklı yöntemleriyle if-while-for vb. pek çok kontrol yapısını, bir sayıya kadar olan tüm asal sayıları bulmada kullanılan Sieve of Eratosthenes algoritması ile dizileri kullanırız ve nihayetinde hem dile olan hakimiyetimizi geliştiririz hem de dil ile problem çözme yöntemlerini öğreniriz. Sonrasında ise compilers, ağlar ya da bilgisayar grafiği gibi derslerde muhtemelen daha büyük programlama hatta proje ödevleri yaparız. Tüm bu pratikler bizim hem programlama gücümüze katkıda bulunur hem de ağlar, veri tabanı, bilgisayar grafiği vb. temel bilgisayar ve yazılım yapılarıyla ilgili bilgi ve tecrübeye sahip olmamızı sağlar.
Peki tüm bu konularda son derece iyi olmak bir proje geliştirmek yeterli midir? Tabi ki değildir. Çünkü yazılım, programlamadan daha fazla şeyi ifade eder ve ancak proje ile yazılım geliştirilir. Genelde yazılım projelerini, programlamadan ibaret olarak görme eğilimdeyiz, hatta yazılım sistemlerini “program” olarak adlandırıldığına da sıklıkla şahit oluyorum. Yazılımın, programın daha büyüğü olarak görecek şekilde bir basitleştirme mümkün olsa bile, gerçekte böyle bir algıya sahip olmak bizi yazılımla ilgili çok ciddi yanlışlara götürür. Aynen gerçek bir uçağın geliştirilmesini, model uçak yapımının sadece daha büyük hali olarak görmekteki gibi. Zaten bu yazının başında bahsettiğim sıkıntı tam da budur: Programlamayı bilmemize rağmen proje yapmakta zorlanmamız. Sistemlerin büyümesinin getirdiği karmaşıklık çoğu zaman doğrusal değil de doğrusal olmayan şekilde artar ve bu durum zaten başlı başına bir sorundur.
Proje yazılıma özel bir kavram değildir elbet ve yazılım projelerinin de diğer disiplinlerdeki projeler gibi belirlenmesi gereken bazı tarafları vardır. Peki öğrenme sürecinde dile ciddi bir hakimiyet sağlama safhasını geçtik ve geldik kendi kendimize bazı projeler yapmaya. Neler yapmamız gerekli? (Bu yazıda daha çok kişilerin öğrenme sürecinde, kendi kendilerine yaptıkları projeleri göz önüne alacağımdan, bu gereklilikleri çok ciddi ve formal bir çerçevede düşünmeyeceğim.)
Öncelikle bir yazılım projesinin, iyi ya da kötü ihtiyaçları belirlenmiş ve sınırları çizilmiş olmalıdır. Dolayısıyla programlamadan yazılım geliştirmeye geçerken ele alacağınız projeninizin belli bir detayda çerçevesi olmalıdır. İhtiyaçları belirlenmeden girişilecek bir projenin bitmesi pek de mümkün olmayacaktır, bundan dolayı da yapılan geliştirme “proje” olmaktan çıkacaktır. Eğer ihtiyaçları belirlemede, projenizin çerçevesini çizmede zorlanıyorsanız, en basit ve gerekli olanlara odaklanın ve detayını çıkarmakta zorlandığınız kısımları ileriki sürümlere atın ve bir an önce ilk sürümünüzü çıkarmanızı sağlayacak kısımlara öncelik verin derim.
Öte taraftan bir yazılım projesinin, ihtiyaçları çerçevesinde belirlenmiş bir mimarisinin de olması gereklidir. Nasıl ihtiyaçlar belirlenmediğinde projede pek çok yaz-boz oluyorsa benzer durum mimari belirlenmediğinde de söz konusudur. Mimari yapılar ise belli bir teorik alt yapıya sahip olarak kurgulanmakla birlikte genelde tecrübe tabanlıdır ve mimari algı, okumaktan daha çok deneme-yanılma ile gelişir. Gerçi mimari bilgi birikimimiz de gittikçe daha formal hale geliyor ve çeşitleniyor; bu yüzden gittikçe daha fazla okumak ve uygulamak önemli hale geliyor. Özellikle kullanılan dil vb. teknolojilerin temel kalıplarının (pattern) ve mimari best practicelerinin bilinmesi bu anlamda çok önemlidir. Örneğin katmanlı yapılar kullanacaksınız, AOP ile aspectleri ayıracaksınız ve olabildiğince durumsuz (stateless) yapılar kullanacaksınız şeklidne üst prensiplerden yola çıkarak detaylara inebilirsiniz. Dolayısıyla projenizin mimari konularına da çala kalem dalmayın, biraz düşünün, okuyun, araştırma yapın ve ihtiyaçlarınızın sizi ne tür bir mimariye doğru ittirdiğini anlamaya çalışın, aksi taktirde projenin büyüklüğüne bağlı olmak üzere sıkıntılı sonuçlarla karşılaşabilirsiniz. Bu tür durumlar aslen öğrenmenizin bir parçasıdır ve doğrudan vakit kaybı olarak da görülmemelidir ama atış yaparken de olabildiğince destekli atmak gereklidir. Aşırı yaz-boz hem kaliteyi düşürür hem de motivasyonu.
Projelerinizde fonksiyonel tasarıma da önem verin. Sınıflar, arayüzler, “is-a” ve “has-a” ilişkileri, hem statik hem de dinamik görüntülerin neler olduklarına, sorumluluk tabanlı yaklaşımla karar verin. Bu gibi çalışmalar için UML kullanabilirseniz çok şık olur ama kullanamıyorsanız çok da takılmayın, bulgularınızı kendinize has bir şekilde, beyaz bir kağıda da olsa ifade edin. Bu sırada yani kavramsal olarak düşünürken nesneler arasındaki ilişkileri tasarım kalıplarıyla nasıl daha rahat hale getirebileceğinizi, nesnelerin nasıl daha sağlıklı olabileceğini de düşünün. Bu tür düşünmeler yazılım üzerine soyut düşünme kapasitenizi arttırarak size çok şey kazandıracaktır.
Sonrasında girişeceğiniz kodlamada birim testlerini yazmak, temiz (clean) bir şekilde kod yazmaya çalışmak ve API dokümantasyonuna önem vermek muhtemelen kodunuzu çok daha kaliteli ve anlaşılır kılacaktır. Ayrıca projenizde üçüncü el bileşen ve frameworkleri kullanmak, projenizi çok daha sağlıklı hale getirebileceğini de unutmayın. Bu anlamda tekerleği yeniden keşfetmeyip, enerjinizi koddaki orijinal taraflara saklayın.
Nihayetinde çok ilgi çekici olmasa da bir miktar test malzemesi oluşturmak, temel süreçleri test edebilmek için bir miktar çalışma yapmak ve örnek veri oluşturmak, projenizin sağlıklı bir şekilde nihayete ermesi açısından önemlidir.
Görüldüğü gibi yukarıdaki proje geliştirme sürecinde, programlama kadar analiz, tasarım ve dokümantasyon gibi çalışmalar da vardır. Dahası programlamanın dışındaki bu çalışmaların sağlıklı yapılması, ciddi bir eğitim ve yazılım mühendisliği nosyonu gerektirmektedir. Aksi taktirde usandırıcı bir git-gel girdabına girmek işten bile değildir. Fakat öte taraftan tam programlamada ilerleyelim derken ap-ayrı bir yazılım mühendisliği duvarına toslamak gibi bir durum söz konusu. Bu noktada öğrenme sürecinde programlamadan proje geliştirmeye geçişin ancak bir yol gösterici sayesinde yapılabileceğini söyleyebiliriz. Yani ciddi teknoloji ve metodoloji bilgi ve tecrübesine sahip bir öncünün yol göstermesi, gerekirse kısıtlaması ve yönlendirmesiyle, kontrollü bir şekilde bu süreci işletmek, sanırım geçişi kansız ve çok daha verimli hale getirecektir.
Ben bu amaçla eğitim faaliyetlerimde müşterilerime, eğitimde verilen malzemenin, yukarıda kısaca açıkladığım gibi, ayrıca bir workshop ile proje geliştirme çalışması olarak da uygulanmasını salık veriyorum. Ancak bu şekilde eğitimde verilenin gerçekten öğrenilmesi mümkün olabilir. Workshopu yapmak için temel bilgiye sahip olmak gereklidir. Ama verilen bilginin sağlıklı bir yazılım geliştirme bağlamında anlam bulması için de ders içi ufak örneklerden öteye geçen workshopa ihtiyaç vardır. Benzerlik kurarsak, workshopsız bir eğitim ile doğrudan gerçek projeye girmenin, tahta üzerinde taktiği alıp maça çıkmaya benzediğini söyleyebiliriz. Bu yüzden workshoplarla bir miktar pişmeyen developerların, gerçek projeyi haklı olarak öğrenme amaçlı olarak kullanmaları çok sık görülen bir durumdur. Her projede öğrenme söz konusudur ama sahip olduğu teorik bilgiyi hiç kullanma imkanı bulamamış kişilerin doğrudan projeye atılmaları, projeyi çoğunlukla çöplüğe çevirmektedir. Halbuki aslolan, gerekirse workshopı çöplüğe çevirmek ama bu sayede anlamayı pekiştirmek ve gerçek uygulama ortamına hazırlanmaktır.
Bu noktada yazılımcı olarak çalışan arkadaşlara tavsiyem, eğitim alırken muhakkak workshop da talep edin. Bence kaç günlük ya da saatlik eğitim alıyorsanız aynı miktar workshopa ihtiyaç vardır.
Bu noktada benzer yaklaşımı, JavaTürk bünyesinde açmış olduğum eğitimlerde de kullanacağım ve gördüğünüz, aldığınız eğitimlerin workshoplarını da sanal ortamda açacağım. Bu şekilde isteyen eğitimden sonra workshopa devam edebilecek, eğitim ihtiyacı olmadığını ama uygulama ihtiyacı olduğunu düşünen de doğrudan workshopa dahil olabilecektir. Workshoplarla ilgili olarak eğitim sayfasını takip etmenizi öneririm.
Toplam görüntülenme sayısı: 1160
Akin Yazılım Kalitesi ve Test, Yazılım Mühendisliği
Danışmanlık yaptığım yerlerin birinde var olan kod üzerinde çalışırken 979 tane metodu olan bir sınıf gördüm. Evet yanlış okumadınız, 979 metodu olan bir sınıf 🙂 Bu durumu yanımda oturan ve o projede çalışan bir yazılımcıya söylediğimde bana “Akın bey, o sınıf ilk yazılırken o kadar büyük değildi, sonradan eklene eklene bu hale geldi” dedi. Söylediği şey açıkçası bizim yazılım geliştirmeyle ilgili en temel yanlışlarımızdan birini ifade ediyordu. Biz yazılım geliştirmeyi sadece “eklemek”ten ibaret biliyoruz. Dolayısıyla işin başında belki 100 civarında metottan oluşan bu sınıf 2 senenin sonunda 979 metoda sahip hale gelmişti. Tabi ki bir sınıfın 100 metoda sahip olması da sorgulanacak bir durumdur ama benim bu yazıda vurgulamak istediğim şey, yazılımı geliştirmenin devamlı olarak ekleme yapmaktan ibaret olduğunu düşünmemizdir. Aslında yazılım satır sayısı olarak büyürken yazılımdaki soyutlamaların küçülmesini gereklidir.
Bence önce şunu belirtmemiz gerekli. Biz dilimizde yazılımı geliştirmekten ya da kod, program yazmaktan bahsederiz. “No Silver Bullet” isimli makalesinde F. Brooks, hayatı boyunca yazılımla alakalı olarak önceleri “writing” yani “yazma” kelimesini kullanırken 1958 yılında (!) bir arkadaşından duyarak “building” yani “bina etme, geliştirme” terimini kullanmaya başladığını, sonrasında ise, tecrübesine dayanarak bu durumu en iyi ifade eden kelimenin “growing” yani “büyüme” olduğuna karar verdiğini yazar. Dolayısıyla yazılım tabiatı icabı, aynen organizmalarda ya da mühendislik yapılarında olduğu gibi büyür ve büyütülür.
Yazılım, proje boyunca büyür. Sonrasında proje biter ama yazılım hala büyümeye devam eder. Muhtemelen yazılımlar, çöpe atılacağı tarihe kadar büyümeye devam ederler. Öte yandan, biliyoruz ki yazılım temelde soyutlamalardan oluşan bir yapıdır. Yazılımların büyümesi, o yazılımlardaki soyutlamaların da büyümesi anlamına gelir mi? Yoksa yazılımların büyümesi daha çok içindeki soyutlamaların sayıca artması ve çeşitlenmesi anlamına mı gelmelidir? Daha açık bir ifadeyle, projenin başında 20 metoda sahip olan bir sınıf, 2 sene sonra projenin sonunda kaç metoda sahip olması beklenmelidir? Hala 20 mi? 15 mi? yoksa 100 mü?
Benim gördüğüm, bir refactoring kültürünün olmadığı yazılım geliştirme ortamlarında ve takımlarında, yazılımın büyümesinin en temel şekli eklemektir. Yeni soyutlamalar eklenir ama var olan soyutlamalardan herhangi bir şey çıkarılmaz. Örneğin bir pakete yeni sınıflar ekleriz ya da bir sınıfa yeni metotlar ekleriz ya da var olan bir metoda yeni “if” blokları ekleriz. Tüm bu eklemeleri boşuna yapmıyoruz, sonuçta bir ihtiyacı gideriyoruz. Ama her ihtiyacın, var olan yazılıma sadece yeni kod eklemeyle giderilmesi, kod eklenirken herhangi bir düzenleme yapılmaması anlamına geliyor. Bu durumda da yerine getirilecek ihtiyacı gerçekleştirecek kod parçasının, var olan kod yapısına nasıl monte edileceği, yeni kodun neresinin var olan yazılımda nereye oturacağı, tüm bunlar için var olan soyutlamalarda herhangi bir düzenlemeye gidilip gidilmeyeceğini genelde es geçiyoruz. Bundan dolayı sadece ekliyoruz. Hatta çoğu zaman eklerken, var olan kodlardan bazı parçaları “copy” ile alıp “paste” ile yeni eklenen yere monte ediyoruz. Bu da kod tekrarlarına sebep oluyor. Aslında yapılması gereken sadece eklemek değildir, çünkü eklemek refactoringde çoğunlukla tek yapılan şey değildir, hatta ilk yapılan bile değildir. Aslolan yazılımı, önce çıkarıp sonra ekleyerek, yani organizasyonel değişikliklerle büyütmektir.
Önce çıkarmak sonra eklemek nasıl olur? Ekleme yapacağınız yer bir metodun içinde ise, en basitinden ekleme yapılacak parçayı ayrı bir metot olarak soyutlayabilirsiniz. Hatta bu şekilde metottan kod parçası çıkarıp ayrı bir metot olarak soyutlamak, benzer şekilde bazı metotları var oldukları sınıf ya da arayüzden, yeni yaratılan sınıf ya da arayüzlere taşımak gibi refactoring çalışmalarına da gidebilecektir.
Bir yazılıma yapılacak değişikliklerin doğrudan eklenmek yerine, refactoring yani yazılımın mimarisi ve kodunda iyileştirici düzenlemeler yaparak gerçekleştirilmesi için göz önünde bulundurulması gereken iki yaklaşım vardır: İlki tasarım kalıplarının kullanılması, ikincisi de bu konuda çok iyi bir eser olan Martin Fowler‘ın Refactoring isimli kitabının iyice okunması ve sindirilmesidir.
Tasarım şablonlarının ciddi bir kısmı, örneğin Strateji, State, Command ve Proxy, genelde bir metot içinde toplanan pek çok karar yapısını soyutlayıp, bir arayüzü yerine getiren sınıflara bölmek fikri üzerinedir. Bu sayede gittikçe sayıları artan karar mekanizmalarına sahip kocaman metotlar yerine, her bir kararın kendisine ait metotta ifade edildiği, odaklı, daha basit ve anlaşılır yapılar oluşur.
Martin Fowler ise Refactoring isimli kitabında, farklı durumların nasıl iyileştirileceğini pek çok örnekle sistematik olarak anlatır.
Bu şekilde çıkarıp eklemelerle, yeni organizasyonlarla ilerlemek, copy-paste yerine cut-paste kullanarak var olan kod parçalarını tekrar tekrar düzenleyerek, her yeniliğin sisteme nasıl girmesi gerektiğini düşünerek yazılımı büyütmek, yazılımdaki satır sayısını, sınıf, metot vb. soyutlamaların sayısını arttırırken, bu soyutlamaların daima makul büyüklükte kalmalarını da temin edecektir. Bu da yazılımın büyüse bile karmaşıklığının olabildiğince kontrol edilebilir düzeyde kalmasını sağlar.
Bu şekilde, yazılımlardaki soyutlamaların, proje süresince ve sonrasındaki bakım sürecinde, eklenerek büyümesi yerine, mitoz ve mayoz bölünmelerle küçülmesi, en azından çok büyümemesi sağlanır. İşte böyle bir refactoring algısına sahip olunmayan bir yerde proje ilerledikçe, bir sınıftaki metot sayısı 979lara kadar gelir. Çünkü bu sınıfın sorumluluklarıyla igili olarak hem yanlış bir algı dolayısıyla da soyutlama vardır çünkü 979 sayısına gelinmiştir, hem de o ortamda refactoring kültürü yoktur, çünkü bu sayıya zaman içinde, metot ekleyerek gelinmiştir. Nitekim ben 979 sayısını bulduktan yaklaşık 2 ay kadar sonra aynı sınıfa baktığımda metot sayısı 1000’i geçmişti 🙂
Eskiden bu yana çok sevdiğim bir sözü buraya almak istiyorum. Hem yazar, hem şair hem de bir pilot olan Fransız aristokrat Antoine de Saint-Exupery şöyle demiş:
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Yani
Mükemmellik, eklenecek bir şey olmadığında değil, çıkarılacak bir şey olmadığında başarılır.
Mühendisler mükemmeli değil, uygun olanı ararlar. Dolayısıyla daha yumuşak bir şekilde, yazılım soyutlamalarımızı uygun karmaşıklık düzeyinde tutmak için onlara eklemeler yapmak yerine onlardan çıkarma yapmayı düşünmeliyiz.
Bu konudaki pratik örnekleri bir sonraki yazıya bırakalım.
Toplam görüntülenme sayısı: 1560