Kodlardaki Kötü Kokuları Tespit Etme Yöntemleri ve Algoritma Analizi Aylin Güzel 1, Özlem Aktaş 2 1,2 Dokuz Eylül Üniversitesi, Bilgisayar Mühendisliği Bölümü, İzmir aylin.guzel@ogr.deu.edu.tr, aktas.ozlem@deu.edu.tr Özet: Yazılım geliştirme sürecinde analiz, karar verme ya da uygulamada yapılan yanlışlar kodlarda kötü kokunun ortaya çıkmasına sebep olur. Tasarım problemleri de kodlarda kötü koku şeklinde görülmektedir. Kodlardaki kötü kokular yazılımın kalitesini azaltmaktadır. Daha kaliteli, performansı yüksek, maliyeti düşük, başka bir yerde kullanılması, değiştirilmesi ve geliştirilmesi kolay yazılımlar için kodlardaki kötü kokuların yeniden düzenleme ile yok edilmesi gerekmektedir. Yeniden düzenleme basittir ancak yazılım kalitesine etkisi büyüktür. Bu çalışmada, kodlardaki kötü kokunun ne olduğu, hangi durumlarda ortaya çıkabileceği ve bunun üstesinden nasıl gelinebileceği konuları detaylı olarak anlatılmış, algoritma analizi yöntemi ile kodlardaki kötü kokunun tespit edilmesi yaklaşımı incelenmiştir. Anahtar Sözcükler: Yeniden Düzenleme, Yazılım Mühendisliği, Kötü Koku, Algoritma Analizi, Kod İnceleme, İyi Kod, Optimizasyon. Methods for Determining Bad Smells in Code and Algorithm Analysis Abstract: In software development process, analysis, decision making or mistakes made in the application causes appearing bad smells in code. Also, design problems in the code are seen as a bad smell. Bad smells in the code reduces the quality of the software. Bad smells in the code must be destroyed for better quality, high-performance, low-cost, re-use, modification and easy development of software. Refactoring is simple but has a huge impact on software quality. In this study, the topics of what the bad smell in the code is, in which situations it can occur and how the bad smell can be overcomed are studied in the literature, and detecting bad smells in code was examined by algorithm analysis approach. Keywords: Refactoring, Software Engineering, Bad Smells, Algorithm Analysis, Code Review, Good Code, Optimization. 1. Giriş Bilgisayar bilimi, kısaca bir bilgisayarın nasıl çalıştığını ve nasıl düşündüğünü öğrenmek olarak tanımlanabilir. Bilgisayarın işleyişini anlamak da yazılımcının nasıl düşünmesi ve bilgisayara nasıl yaklaşması gerektiğini anlamasını sağlar. Bu sayede bilgisayara istenilen her türlü işlem yaptırılabilinir. Yazılımcı ya da yazılım geliştirme ekibindeki diğer uzmanlar gerçekleştirimini yapmak istedikleri sistemi yanlış analiz ettiklerinde, sistem hakkında yanlış kararlar verdiklerinde, düşündükleri doğru şeyleri sistem için yanlış uyguladıklarında, yazılım geliştirme prensiplerini göz ardı ederek çalışmalarına devam ettiklerinde, sadece anı kurtarmak adına karmaşık, okunabilirliği ve anlaşılabilirliği zayıf olan kod yazdıklarında, kodda kötü koku meydana gelir. Koddaki kötü kokular, sistemdeki potansiyel problemlerin bir göstergesidir. Bu noktada doğru karar vererek yazılıma müdahale edip, yazılımın performansını, okunabilirliğini, esnekliğini, anlaşılabilirliğini arttırmak amaçlanmalıdır.
Bu amaçlar doğrultusunda yapılması gereken işlem Yeniden Düzenleme (ing. Refactoring) olarak adlandırılır. Yeniden Düzenleme, yazılımı daha basit, daha anlaşılır, değiştirmesi daha kolay ve yazılımın okunabilirliğini yüksek bir seviyeye getirerek yazılımın performansını iyileştirmeyi amaçlamaktadır. Aynı zamanda kodlarda yeni hiyerarşiler kurarak kodların daha kolay geliştirilebilir, değiştirilebilir, tanınabilir, başka projelerde kullanılabilir hale gelmesine yardımcı olur. Belirtilen hedefleri temel alarak kodun iç yapısını değiştiren ancak dış yapısında herhangi bir değişikliğe neden olmayacak şekilde yapılan düzenlemeler bütününe Yeniden Düzenleme denmektedir. Kodun hali hazırda yaptığı işin, koda Yeniden Düzenleme uygulanması öncesi ve sonrasında aynı kalması durumu, kodun dış yapısında değişim meydana gelmemesi olarak ifade edilir. Kodun iç yapısını değiştirmek için kullanılabilecek Yeniden Düzenleme yöntemlerinden bazıları aşağıdaki gibidir[2][3][5]: Tekrar eden kodları ayrı fonksiyonlara ayırmak, İlgili rutinleri bir sınıf altında toplamak, Değişken isimlerini işlevine uygun şekilde değiştirmek, Algoritmaları daha hızlı çalışır hale getirmek, Gerekli durumlarda metotların isimlerini; yaptıkları işi metotların isimlerinden anlaşılacak şekilde değiştirmek, Aynı kod yapısının birden fazla alanda olduğu durumlarda bu kodu programda tek olacak şekilde düzenlemek, Uzun metotları okunması ve bakımının daha kolay olması için kısa hale getirmek, Çok uzun döngülerde döngünün iç kısmındaki kod bloğunu kısa tutmak ve bu amaçla değişkenleri mümkün olduğunca döngünün dışında tanımlamak, Okunabilirliği ve debug modda kodun takibini azalttığı için iç içe çok fazla döngü kullanmamak, Aşırı parametre alan metotların yaptıkları işleri azaltmak için bölmek yani parametre sayılarını azaltmak, Basit veri tiplerinin aşırı yüklenmesini önlemek için değişkene uygun olmayan, programı yoracak ve gereğinden fazla bellek ayrılmasına neden olacak veri tipini kullanmamak, Mevcut kodda işe yaramayan ya da içerisinde çok az işi barındıran sınıfları gerekli ve uygun koşullar sağlandığı taktirde silmek, İleride lazım olur düşüncesiyle daha önce yazdığımız ancak mevcut durumda kullanılmayan kodları yorum olarak programda tutmamak, Kodu yeterince açık ve temiz yazmak yerine; programı yapılan işin anlaşılması için gereksiz yorumlarla boğmamak, Sınıf isimlerini amacına uygun olarak belirlemek, Ucu açık sınıf tanımlamamak; oluşturulan sınıf kendisinden beklenenden daha fazla işi yapıyorsa ilgisiz görevleri başka bir sınıf oluşturarak bu sınıfta toplamak ya
da program içerisinde ilgili olabilecek bir sınıfa taşımak, Ait olduğu sınıftan ziyada başka bir sınıftan özellik kullanan metotları ilgili sınıfa taşıyarak mevcut sınıf içerisinden çağırmak, Birbirine benzer işler yapan iki metodu kodu tekrarlamamak için tek metotta birleştirerek parametreye göre ilgili kısmın çalışmasını sağlamak, Aldığı parametreye göre birbirinden farklı iki iş yapan metodu ikiye bölmek, Bir nesnenin alanlarını metotta tek tek işlemek yerine, tüm nesneyi parametre olarak geçmek, Metod içerisinde bir objenin sadece bir ya da iki alanının kullanılacağı durumlarda objeyi metoda geçmek yerine ihtiyaç duyulan alanları kullanmak, Karmaşık mantıksal koşullardan kaçınmak, Hatırlanılması gereken her şeyi kodun kendisinin içerisine koymak. Yeniden Düzenleme daima temiz kodu hedefler, kodu temizlemek için etkili ve kontrollü bir teknik sağlar. Çoğu zaman yazılımda anı kurtarmak adına yeterince etkin olmayan çözümler üretilebilir. Bilgisayara ne yapılması gerekiyorsa bunu söylemek ve yapılması gereken görevlerin mevcut programda gerçekleştiğini görmek çoğu yazılımcı için yeterlidir. Ancak böyle bir durumun ileride sebep olabileceği durumlar yazılımcı tarafından tahmin edilmelidir. Yazılımcı yazılım geliştirme sürecine, yapılması istenen sistemin tüm gereksinimlerine, doğru düşünüp doğru çözüm üretmeye ve okunabilirliği, işlevi tam olan doğru ve düzenli programlar yazmaya hakim olmalıdır. Daima daha ileriyi düşünerek hareket etmelidir. Yazılımcı, süreç içerisinde, nasıl daha iyi kod yazılabilir, yazılımdan nasıl daha iyi bir performans elde edilebilir, yazılan kod başka bir sisteme kolayca entegre edilebilecek kadar doğru ve temiz midir, bir sonraki yazılımcı kodu adete gazete okur gibi okuyabilecek mi ya da sisteme müdahale edip kod üzerinde kolay bir şekilde değişiklik yapabilecek midir ve en önemlisi de gerçekten bu yazılan en iyi çözüm müdür gibi kaygılar taşımalıdır. Aksi taktirde, yazılmış olan kodu belli bir süre sonra değiştirmek isteyen yazılımcı, kodu doğru anlayıp, doğru müdahale edemeyebilir ve yapmak istediği değişikler çok uzun zaman alabilir. Bu da hem kişisel hem kurumsal motivasyon bozukluğuna, hem de maliyetin artmasına neden olabilir. Bazı durumlarda yazılımın performansını ihmal edilebilecek kadar etkileyen küçük kötü kokular göz ardı edilebilir. Ancak esnekliği, tanınırlığı, okunurluğu ve anlaşılabilirliği kötü olan kodlar mevcut yazılımcıyı kurtarsa bile sonraki yazılımcı için kabus olacaktır. Bu yüzden daima ya sonrası? düşüncesi yazılımcının aklında olmalıdır. Yazılımı yeniden düzenlemek için kötü kokunun ortaya çıkması beklenmemelidir. Her aşamada kod tekrar gözlenerek eksiklikler giderilmelidir, çünkü küçük detaylar dahi olsa, kod üzerinde Yeniden Düzenleme yapmamak, kodun daha temiz olma durumunu engeller. Çünkü küçük detaylar üzerinde Yeniden Düzenleme yapmak, tasarımda daha önce göremediğimiz eksiklikleri ya da yanlışlıkları fark etmemize yardımcı olur. Bu durum aynı zamanda iyi bir tasarım yapmayı kolaylaştırır. Ayrıca, tasarım desenlerinin yazılımda daha etkin bir şekilde kullanılmasına imkan sağlar.
2. Literatüre Genel Bakış Mens ve Tourwe [12], çalışmalarında Yeniden Düzenleme ve Yeniden Yapılandırma (ing. Restructuring) kavramlarına açıklık getirmiştir. Çalışan bir kod yapısı için gerekli olan Yeniden Düzenleme yöntemlerini uygulamış ve tasarımı daha anlaşılır, kolay müdahale edilebilir, nesneye dayalı tasarım ilkelerine uygun hale getirmiştir. Çalışmada yanlış tasarlanmış Doküman sınıf hiyerarşisi uygun Yeniden Düzenleme metodları kullanılarak ve bu metodların ne zaman, nerede, hangi durumlarda kullanılacağı örnek üzerinden açıklanarak tasarım optimum hale getirilmiştir. Çalışmada kullanılan yanlış tasarım örneği Şekil 1 de gösterilmiştir. Şekil 1. Doküman Sınıf Hiyerarşisi ve Yardımcı Sınıflar Şekil 1 de gösterilen hiyerarşide, Doküman sınıfının farklı işlevlerinin alt sınıflara dağıtılmasından dolayı ve Doküman sınıfına yeni bir özellik eklenmek istenildiğinde (metin arama, yazım denetimi vb.) Doküman sınıfının bütün alt sınıflarının değiştirilmesi gerektiği için tasarımın optimum olmadığı ve belirtilen sorunları çözmek için tasarımda Yeniden Düzenleme yapılması gerektiği belirtilmiştir. Tasarıma Visitor sınıfı eklenerek bütün alt sınıfları içinde barındırması sağlanmış, gerekli metod ve değişken isim değişiklikleri, uygun yerlere gerekli metotların taşınması, yeni sınıf ekleme gibi temel Yeniden Düzenleme yöntemleri kullanılarak tasarım optimum duruma getirilmiştir. Yeniden Düzenleme yöntemiyle uygun hale getirilen tasarım Şekil 2 de gösterilmiştir. Şekil 2. Yeni Doküman Sınıf Hiyerarşisi Liu ve arkadaşları [9], çalışmalarında yazılımların niçin ve hangi durumlarda yeniden yapılandırılması gerektiğini vurgulamıştır. Koddaki kötü kokuların araç desteği ile otomatik veya yarı otomatik bir şekilde tespit edilebileceğini ve çözümlenebileceğini belirtmişlerdir. Ancak bu noktada araç tarafından otomatik olarak tespit edilen kötü kokuların manuel olarak tekrar kontrol edilmesi gerektiği çünkü araç yardımıyla tespit edilen kötü kokuların doğruluğunun % 100 garanti altında olmadığı belirtilmiştir. Ayrıca, Yeniden Düzenleme kuralları doğrultusunda yazılım mühendislerinin koddaki kötü kokuları belirleyerek yeniden yapılandırabilecekleri de vurgulanmıştır. Yeniden Düzenleme kurallarının hepsinin araçlar tarafından desteklenmediği ve Yeniden Düzenleme kurallarının, araçlar tarafından desteklenen kurallara göre çok hızlı arttığı, koddaki kötü kokuları tespit etmenin araç desteği olsa bile zaman harcayıcı olduğu belirtilmiştir. Bazı kötü kokuların çözümlenmesinin, koddaki diğer kötü kokuların tespit edilmesini ve çözümlenmesini etkileyebileceği vurgulanmıştır. Örneğin, kötü kokulara sahip bir programda tekrar eden kod bloklarının uzun metotlara sebep olabileceği belirtilmiş ve eğer tekrar eden kod bloğu ortadan kaldırılırsa uzun metodun da kendiliğinden temiz kod standartlarına dönüşebileceği belirtilmiştir. Koddaki kötü
kokuların tespiti ve çözümlenmesinin akışı Şekil 3 de gösterilmiştir. Şekil 3. Kötü kokuları tespit etme ve çözümleme Chatzigeorgiou ve Manakos [1], çalışmalarında tasarımın ve analizin etkili olmamasının kodda kötü kokulara sebep olacağını, yazılımdaki tasarım problemlerinin yani koddaki kokuların çözümünün Yeniden Yapılandırma yapmak olduğunu belirtmişlerdir. Çalışmalarında geçerli bir Java kodu üzerinde JDeodarant Tool kullanılarak dört kötü koku tespit etmişlerdir. Uzun metodlar, boyutu büyük, karmaşıklığı yüksek, uyumu düşük; anlaşılırlığı, hata ayıklanması, test edilmesi ve bakımının yapılması çok zaman ve çaba isteyen kötü kokular olarak tanımlanmıştır. Bu problem, metodu daha küçük parçalara ayırarak ya da araç yardımıyla otomatik olarak tespit edilerek çözümlenmiştir. Geniş ve karmaşık sınıfları tespit etmek için ( God Class) JDeodarant Tool Kümeleme Algoritması yaklaşımı kullanılmıştır. Durum Kontrolü (ing. State Checking) olarak ifade edilen Şart ya da Eğer (ing. Switch or if/else) ifadeleri programın farklı yerlerinde görüldüklerinde, kodda Durum/Strateji (ing. State/Strategy) Tasarım Deseni eksikliği olduğu tespit edilmiştir. Bu kötü kokuyu JDeodarant Tool yardımıyla tespit etmek de mümkündür. Khomh ve arkadaşları [8], bugüne kadar gerek araştırmacıların gerekse uygulayıcıların koddaki ve tasarımdaki kötü kokuları tespit etmek için çeşitli yaklaşımlar geliştirdiklerini ancak bu yaklaşımların hiç birisinin kötü kokuyu tespit etme sürecindeki belirsizliği çözümleyemediğini belirtmiştir. Koddaki kötü kokuların tespiti için Bayes Yaklaşımı (BBNs) kullanılmıştır. Yaklaşım Blob AntiPattern üzerinde gösterilmiştir. BBN iki test program üzerinde değerlendirilmiş ve başarılı olduğu gözlenmiştir. Moha [13], çalışmasında zayıf tasarım kararlarından kaynaklanan tasarım kusurlarının nesneye dayalı tasarımların kalitesini azaltıcı bir etkiye sahip olduğunu, tasarım kusurlarının kesin bir şekilde tespit edilmesi ve düzeltilmesi için çok az sayıda yazılım aracı bulunduğunu, çalışmanın hedefinin tasarım kusurlarını kesin bir şekilde belirleyen ve tasarım kusurlarının ayrıntılarından otomatik tespit ve düzeltme yapan sistematik bir yaklaşım oluşturmak olduğunu belirtmiştir. Metodun ismi DECOR (Defect detection for CORrection) olarak belirlenmiş olup, oluşturulan metodun tasarım kusurlarını kesin olarak tespit ettiği ve uygun şekilde tasarım kusurlarını düzelttiği görülmüştür. DECOR, sırasıyla tasarım kusurunu açıklama, tespit etme, düzeltme ve doğrulama işlemlerini temel alır. Malhotra ve Pritam [10] nesneye dayalı bir sistemdeki mevcut kötü kokuların bir sınıf için tespit edilme eğilimini deneysel olarak onaylamak amacıyla bu çalışmayı gerçekleştirdiler. Quartz olarak adlandırılan açık kaynak zamanlayıcıdan 79 sınıf alarak veri seti olarak kullandılar. Eğilimi düşük ve yüksek olarak sınıflandırdılar. Quartz ın her iki versiyonu için ortak olan 79 sınıf için yapılan çalışmada, yüksek değişim eğilimindeki sınıfların gerçek sayısı 65 iken, çalışmadaki tahmin edilme durumu 53 tür. Benzer şekilde düşük değişim eğilimindeki sınıfların gerçek sayısı 14 iken çalışmada 26 olarak tahmin edilmiştir. Ayrıca Java sınıflarındaki 13 farklı kötü kokuyu tespit
etmek için eşik değerleri kullanılarak bir araç geliştirilmiştir. Schumacher ve arkadaşları [15], çalışmalarında kodda kötü kokuya neden olan geniş çaplı sınıfların ( God Class) profesyonel yazılım geliştiriciler tarafından nasıl tanındığını ve bu sınıflara nasıl çözüm getirdiklerini araştırmıştır. Devasa sınıflar çoklu sınıflara bölünerek ya da alt sınıflar bu devasa sınıftan çıkartılarak koddaki kötü kokuya çözüm getirilebilineceği belirtilmiştir. CodeVizard yazılım aracı ile metrik tabanlı yaklaşım devasa sınıfların tanınmasında kullanılmıştır. Bu bileşen C# programlarını ayrıştırmak ve kod metriklerini hesaplamak için kullanılmaktadır. Çalışmada çok büyük sınıfları, hem insanların hem de araçların tespit edebileceği ve başarı oranlarının yüksek olduğu kanıtlanmıştır. Kessentini ve arkadaşları [7], çalışmalarında Darvin in evrim teorisinden esinlenilerek ortaya çıkmış olan Genetik Algoritma yı koddaki kötü kokuları iyileştirmek için kullanmışlardır. Referans kodu ile kötü kokuları düzeltmek için kullanılan genel yaklaşım Şekil 4 te gösterilmiştir. Şekil 4. Yaklaşımın genel mimarisi Genetik Algoritmada sonuçlar vektör olarak gösterilmektedir. Çaprazlama ve mutasyon kullanılarak arama uzayı oluşturulmuştur. Koddaki kusuru düzeltmek için uygulanan Genetik Algoritma yaklaşımının sözde kodu aşağıdaki gibidir: 2: Pop:= set_of(i) 3: initial_population(pop, Max_size) 4: repeat 5: for all I Pop do 6: new_code := execute_refactorings(i, D) 7: fitness(i) := compare(rc, new_code) 8: end for 9: best_solution := best_fitness(i); 10: Pop := generate_new_population(pop) 11: it:=it+1; 12: until it=max_it or best_fitness fitness_threshold 13: return best_solution Kod kusurlarının düzeltilmesi için kullanılan yaklaşım açık kaynaklı sistemlerde test edilmiş ve başarılı olduğu gözlemlenmiştir. Rech ve Schäfer [14], yazılım sistemlerinin kalitesini iyileştirmek amacıyla CodeSonar aracını geliştirmişlerdir. CodeSonar, yazılım geliştirme ve bakım süreçleri boyunca tasarım kusurlarını göstermek için tasarlanmıştır. Nesneye dayalı sistemlerde koddaki kusurları otomatik olarak tanımayı ve göstermeyi hedeflemiştir. Eclipse yazılım geliştirme ortamı için geliştirilen sistem sınıfları, bu sınıfların metodları arasındaki ilişkileri ve başka sınıfları görselleştirir ve yazılım sistemindeki potansiyel kusurlar için geliştiriciyi uyarır. Bu çalışmada, koddaki kusurların keşfi ve yazılım görselleştirme için yazılım kontrolü, yazılım testi, yazılım ürün metrikleri, yazılım görselleştirme ve Yeniden Düzenleme teknikleri kullanılmıştır. Çalışmada CodeSonar aracının kullanımı detaylı olarak açıklanmış, basit ve anlaşılır bir araç olduğu belirtilmiştir. Input: Set of reference code RC Input: Set of refactorings RO Input: Code containing bad-smells D Output: Refactorings sequence RS 1: I:= combination(ro)
3. Koddaki Kötü Kokular ve Algoritma Analizi Algoritma bir problemi çözmek için uygulanan ardışık adımlar dizisidir ve bilgisayar biliminin temelini oluşturur. Bir algoritmadan beklenen hızlı çalışması ve bellekte az yer kaplamasıdır [4]. İyi bir algoritma daima en iyi performansı hedefler. Algoritma analizi algoritmaların performansını ölçmek için, farklı algoritmalarla karşılaştırmak için, daha iyisi mümkün mü, mevcut çözüm en iyi olan mi sorularına yanıt bulmak için kullanılır. Bir algoritmanın performansı iç (çalıştırmak için gereken zaman ve çalıştırmak için gereken yer) ve dış faktörlere (girdi verisinin büyüklüğü, bilgisayarın hızı, derleyicinin kalitesi) bağlıdır [6]. Koddaki kötü kokular yazılımda performans kaybına neden olur [2]. Performans kaybı ise yazılımın maliyetin yükselmesine, motivasyon bozukluğuna; taşınabilirliği, değiştirilebilirliği ve okunabilirliği zor olan kodların ortaya çıkmasına neden olur. Yazılımın performansını iyileştirmek için Yeniden Düzenleme kullanılmalıdır. Algoritmanın iç detaylarına bakılarak algoritmanın performansını tanımlamak için matematiksek bir yaklaşım olan Büyük O notasyonu kullanılır. Büyük-O notasyonu bir algoritmanın büyüme hızını gösterir ve büyüme hızı da bir algoritmanın performansını yansıtan en iyi göstergedir [6]. Koddaki kötü kokular Yeniden Düzenleme metodlarına göre yazılım mühendisi bakış açısıyla ya da araç yardımıyla tespit edilip, elle ya da yazılım aracı yardımıyla çözümlenebilir. Birçok çalışmada koddaki kötü kokunun tespitinde yanılmalar gözlenmiştir. Bu eksikliğin giderilebilmesi amacıyla, birçok Yeniden Düzenleme kuralı için, yazılım mühendisinin ya da yazılım aracının koddaki kötü kokuları doğru olarak tespit edip etmediğinin Algoritma Analizi yaklaşımı kullanılarak doğrulanabileceği öngörülmektedir. Bu doğrultuda, çok uzun döngülerin, iç içe çok fazla kullanılan döngü yapılarının, aşırı parametre alan metotların ve devasa sınıfların programı yorduğunun kanıtlanmasında Algoritma Analizi yaklaşımı kullanılabilecektir. 4. Sonuç ve Öneriler Bu çalışma, yazılım geliştirme süreci temel alınarak, yazılım mühendisliği disiplini çerçevesinde hazırlanmış olup, kodda kötü koku olarak bilinen tasarım yanlışlarının aslında sistemi analiz etme, sistem için karar verme ya da uygulamadaki eksiklik ve ihmallerden kaynaklandığı vurgulanmıştır. Kodlardaki kusurlar, Yeniden Düzenleme kuralları çerçevesinde bir yazılım aracı kullanılarak ya da yazılım mühendisinin tecrübesi sayesinde kodda kötü kokuların olduğuna karar vermesiyle tespit edilebilir. Ancak bu noktada bazı sorunlar göze çarpmaktadır. Birincisi, yazılım mühendisinin yanlış kararlar verme ihtimalidir. İkincisi, yazılım mühendisinin bakış açısı ve tecrübesi kullanılarak koddaki kötü kokuyu tespit etme ve çözümleme işlemlerinin çok uzun zaman almasının, maliyet ve işgücü kaybına neden olmasıdır. Daha önce yapılan çalışmalarda, koddaki kötü kokuyu tespit etmek için kullanılan yazılım araçlarının mevcut Yeniden Düzenleme yöntemlerinin tamamını içermediği, sadece belli bir kısmını tespit edebildiği ve çözüm üretebildiği görülmüştür. Yazılım araçlarının gelişme hızıyla yeni kod kusurlarının ortaya çıkmasının aynı ya da yakın hızlarda olmaması bu durumun en önemli sebebidir. Bu çalışmada literatür incelemesi detaylı olarak yapılmış, eksikler vurgulanarak gelecekte yapılacak çalışmalar için yol göstermesi hedeflenmiştir. Gelecek çalışmalarda, koddaki kötü kokular araç ya da yazılım mühendisi bakış açısıyla tespit edilecek ve Algoritma Analizi yöntemiyle kodda bulunan birçok kötü kokunun yazılımın performansını olumsuz olarak ne derece etkilediği kanıtlanmaya çalışılacaktır.
5. Kaynaklar [1] Chatzigeorgiou, A., Manakos, A., "Investigating the evolution of code smells in object-oriented systems", Innovations System Software Engineering, 10, 3-18, (2014). [2] Fowler, M., Beck, K., Brant, J., Opdyke, W., Roberts, D., Refactoring: Improving the Design of Existing Code, Addison-Wesley Professional(2002). [3]http://analystdeveloper.com/blogs/gurkan/ archive/2006/03/19/3060.aspx, [Date Accessed: 7 Oct 2014 ]. [4]http://bilgisayarkavramlari.sadievrenseker. com/2010/09/24/algoritma-analizi-analysisof-algorithms/, [Date Accessed: 3 Oct 2014 ]. [5] https://www.kemalkefeli.com/refactoringnedir.html, [Date Accessed: 7 Oct 2014 ]. [6]http://www.erdalguvenoglu.com/veriyapila ri/algoritma_analizi.pdf/, [Date Accessed:3 Oct 2014]. [10] Malhotra, R., Pritam, N.," Assessment of Code Smells for Predicting Class Change Proneness", Software Quality Professional, 15(1), 33-40 (2012). [11] Mehlhorn, K. & Sanders, P., "Algorithms and Data Structures", Springer,(2008) [12] Mens, T. & Tourwe, T., " A Survey of Software Refactoring", IEEE Transactions on Software Engineering, 30(2), 126-139 (2004). [13] Moha, M., "Detection and Correction of Design Defects in Object-Oriented Designs", OOPSLA 07, Canada, 949-950 (2007). [14] Rech, J. & Schäfer, W., "Visual Support of Software Engineers during Development and Maintenance", ACM SIGSOFT Software Engineering Notes, 32(2), (2007). [15] Schumacher, J., Zazworka, N., Shull, F., Seaman, C., Shaw, M., "Building Empirical Support for Automated Code Smell Detection", ESEM 10, Italy, (2010). [7] Kessentini, M., Mahaouachi, R., Ghedira, K., "What you like in design use to correct bad-smells", Software Qual J, 21:551-571 (2013). [8] Khomh, F., Vaucher, S., Gueheneuc, Y., Sahraoui, H., " A Bayesian Approach for the Detection of Code and Design Smells", Ninth International Conference on Quality Software, 305-314,(2009). [9] Liu, H., Zhiyi, M., Shao, W., Niu, Z., "Schedule of Bad Smell Detection and Resolution: A New Way to Save Effort ", IEEE Transactions on Software Engineering, 38(1), 220-235 (2012).