Anti-Patterns
•Transferir como PPTX, PDF•
3 gostaram•1,513 visualizações
Y.T.Ü. Kalite ve Verimlilik Kulübü tarafından 2013 yılında düzenlenen Finans ve Yazılım Günlerine ait Anti-Patterns konulu sunumdur.
Recomendados
Mais conteúdo relacionado
Mais de Burak Selim Şenyurt
Mais de Burak Selim Şenyurt (14)
Último
Último (20)
Anti-Patterns
- 1. Anti-Patterns BURAK SELIM ŞENYURT ING BANK - KıDEMLI YAZıLıM DANıŞMANı WWW.BURAKSENYURT.COM
- 2. Bir Süre Önce, Projenin Bir Yerinde… Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 3. Anti-Patterns • İlk bakıldığında ideal gibi görünen ama zaman içerisinde geliştirilmekte olan ürüne olumsuz etkilerde bulunan, farklı kategorilerden disiplin ve yaklaşımların oluşturduğu çözümler bütünüdür. GKM (Günü Kurtarma Modeli) Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 4. Örnekler
- 5. Golden Hammer - Methodological Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 6. Reinventing the Square Wheel Methodological Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 7. Copy-Paste Programming Methodological Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 8. Lava Flow - Programming
- 9. Boat Anchor - Programming Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 10. Cargo Cult Programming Programming Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 11. Spaghetti Code - Programming Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 12. Error Hiding - Programming Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 13. Analysis Paralysis - Organizational Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 14. Vendor Lock-In - Organizational Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 15. Dead End – Software Development Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 16. God Object – Object Oriented Design Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 17. Magic PushButton – Software Design Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 18. OverEngineering – Project Management Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com
- 19. Gerçek Tablo
- 20. Software Engineering Software Design Abstraction inversion Ambigous viewpoint Big ball of mud Database-as-IPC Gold planting Inner-platform effect Input kludge Interface bloat Magic pushbutton Race Hazard Stovepipe System Object-Oriented Design Anemic domain model BaseBean Call super Circle-ellipse problem Circular Dependency Constant interface God Object Object cesspool Object orgy Polergeists Sequential coupling Yo-yo problem Programming Methodogical Configuration Management Accidential complexity Action at a distance Blind Faith Copy and past Programming Golden Hammer Boat anchor Imporability factor Not invented here Invented here Premature Optimization Programming by Permutation Busy waiting Caching failure Cargo cult programming Coding by exception Error hiding Hard code Reinventing the square wheel Silver bullet Tester driven development Lava flow Loop-switch sequence Magic numbers Magic strings Repeating yourself Shotgun surgery Soft code Spaghetti code Lasagna Code Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com Dependency hell DLL hell Extension conflict JAR Hell
- 21. Social and Business Operations Project Management Organizational Analysis Paralysis Avalanche Cash cow Death march Design by commitment Groupthink Escalation of commitment Overengineering Management by perkele Smoke and mirrors Management by objectives Analysis Software bloat Moral hazard Mushroom management Stovepipe or Silos Vendor lock-in Anti-Patterns | burak selim şenyurt | www.buraksenyurt.com Bystander apathy
- 22. Neden Önemli? Bir ürünü geliştirirken, gelecekte eklenecek yeni özellikler ve kabiliyetler için de yatırım yaptığımızı unutmamalıyız.
- 23. Kaynaklar AntiPatterns: Refactoring Software, Architectures, a nd Projects in Crisis William J. Brown, Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray Anti-Patterns | burak selim şenyurt | about.me/buraksenyurt
- 24. Teşekkürler Burak Selim Şenyurt ING Bank – Kıdemli Yazılım Danışmanı www.buraksenyurt.com
Notas do Editor
- Bundan birkaç yıl önce finansal önemi olan kritik bir projede single-developer(Lone Wolf) olarak değerlendirilmiştim. Uygulama ile ilgilenen bir ekip yoktu. Ürün 3 sene öncesinde geliştirilmeye başlanmış üzerinden farklı dönemlerde ama eş zamanlı çalışmayan developer’ lar geçmişti. Herkes sıkışık takvime uymaya çalışmış başlangıçta iyi tasarlanmış gibi görünen(ki bu da tartışılır) uygulama kodları oldukça kalabalıklaşmıştı. Derken yeni talepler geldi ve bunları entegre etmek üzere işe koyuldu. Birkaç ay sonra yıl sonu geldi ve yeni yıl ile birlikte iş birimlerinden anomalik durum bildirimleri yapılmaya başlandı. Bazı verilerde düzensizlikler vardı. Veri bozukluğu 1 sene öncesine kadar gidiyordu.Birkaç gün boyunca exception vermeyen iş kuralı seviyesinde meydana gelen sorunu tespit etmeye çalıştım. Derken orada duran bir kütüphaneye denk geldim. İlgili kütüphane başka bir outsource firma tarafından geliştirilmişti ve kaynak kodları elimde değildi. Birkaç masa ötede oturan ekipten kodları aldım ve incelemeye başladım. Tesadüf o ki bu projede görev almış bazı arkadaşlar orada da çalışmıştı. Sonunda bir fonksiyona ulaştım. Metodun ilginç olan yanı önemli bir ada sahip olmasına rağmen geriye bir şey döndürmeyişi ve içerisinde kod barındırmayışıydı. Tam anlamıyla oraya yazılmış pek çok fonksiyonu yorum satırı haline getirilmiş ne amaçla kullanıldığı belli olmayan bir sınıf içerisinde sessizce duruyordu. Artık lava flow haline gelmiş ürün de yer alan minik bir Boat Anchor durumu idi.Sonuçta tam bir felaketti. Pek çok finansal işlem o günlerde yanlış değerlendirilmiş ve düzgün bir şekilde yorumlanamamıştı. İşte o gün daha önceden kulak dolgunluğu taşıdığım anti-patterns konusuna biraz daha ciddi anlamda eğilmem gerektiğine karar verdim.Buna benzer pek çok senaryo ile pek çok projede karşılaşıyoruz aslında.
- Daha önceden başarılı bir şekilde uygulanmış bir çözümün, sonraki problemlerde kullanılmaya çalışılması olarak düşünülebilir. Oysaki bazı problemler aynı yöntemler ve yaklaşımlar ile çözümlenemeyebilir. Bu biraz da çözümü arayan kişilerin daha önce başarılı bir şekilde uyguladıkları yaklaşımları sahiplenmesinden kaynaklanır. Örneğin tüm yazılımların SOA mimari bütünü içerisinde ele alınması gerektiğini düşünmek bu duruma örnek olarak verilebilir. (Ayrıca bir çekicimiz olduğunda tüm sorunların çivi olarak görme ihtimalimiz yüksektir)Diğer taraftan en sık görülen Anti-Pattern’ ler arasında yer alır.Söz konusu pattern’ in oluşmasının nedenlerinden birisi teknolojik gelişmelerden ekiplerin haberdar olmamasıdır. Bazı firmalar gerekli eğitimlerin getirdiği ek maliyetlerden kaçınır ve ekibi donatmaz.İstisnai Durum :Kullanımını geçerli kılan istisnai durumlar da vardır. Söz gelimi uzun soluklu ürünlerde Oracle veri tabanının kullanılması ve diğer çözümler için de ele alınması kabul edilebilir bir yaklaşımdır. Bankalarda bu tip veri tabanı seçimleri genellikle bir kez yapılır ve kolay kolay değiştirilmez.
- Bazı yazılım problemlerinin çözümünde kullanılacak olan yollar zaten standart ve bellidir. Üstelik bu çözümler için standart hale gelmiş mimari yaklaşımlar, ürünler ve alt yapılar mevcuttur. (Hatta tasarım kalıpları) Problemin bu tip yardımcılar ile çözülemeyeceğini düşünüp sıfırdan bir çözüm üretilmeye başlandığı hal tekerleğin yeniden keşfi olarak düşünülür ve bu anti-pattern’ in oluşmasına neden olur. Nitekim ekip söz konusu problemin çok özel olduğuna ve var olan pratikler ile ele alınamayacağına inanır.Genel sebepleri;Yazılım geliştirme projeleri arasında teknoloji transferi ve yeterli iletişimin(özellikle bilgi akışının) olmaması.Sürecin gerektirdiği sistemin baştan inşa edilmesi gerektiğine inanılması.İstisnai Durum :Bazı istisnai hallerde kabul edilebilir. Özellikle araştırma(Resource) nitelikli projelerde, öğrenme süreçlerinde ve bazı bilimsel çalışmalarda göz ardı edilebilir.
- Kaynaklarda Cut-Paste programming olarak da geçer. Çoğunlukla bir çözüm için yazılımın her hangi bir yerinde uygulanan bir kod parçasının, ihtiyaç olunan başka bir yerde aynen kopyalanarak kullanılmaya devam etmesidir. Bunun doğal sonucu olarak bir değişiklik olması halinde kodun yapıştırıldığı yerlere gidilmesi gerekecektir. Güncellemeler için fazla maliyetli eforlar sarf edilebilir. Hatalar gözden kaçabilir ve uygulamanın yanlış çalışma riski giderek artabilir. Söz konusu parçaları soyutlayıp nesne yönelimli dil temellerine uygun olacak şekilde ayrıştırmak önemlidir. Günümüzün gelişmiş yazılım mimari yaklaşımlarında bu tip bir durumun oluşması son derece azdır ama yine de günü kurtarma stratjisi burada da etkisini gösterebilir.Başka adları da vardır. ClipboardCoding, Software Cloning, Software Propogation gibi. İstisnai Durum :
- Bazen araştırma/resource amaçlı olarak başlayan yazılımlar ürüne dönüşürler. Ürüne dönüşme noktasında geriye doğru bakıldığında ne amaçla yazıldıkları belli olmayan(hatta yazan kişinin de şirketten ayrılmış olması sebebiyle kimsenin bilemediği) kod parçalarından oluşan bir tarihi antika oluşabilir. Öyleki bazı developer’ lara sorulduğunda ilgili kod parçasının hangi amaçla geliştirildiğini hatırlamayabilir bile(İstisnai bir durum ise gri veya ak saçlı geliştiricilerin bunu hatırlayabilmesidir)Bu durumun oluşmasının pek çok nedeni vardır. Örneğin projede görevlendirilip tek başına kodlama yapan bir geliştirici sebepler arasında sayılabilir(Single-Developer veya Lone Wolf written code)Sonuç olarak ürünün içeriğine bakıldığında müdahale edilmesi zor, modası geçmiş ve kullanılmayan kod parçaları içeren, üstüne sürekli yeni özellikler eklenirken hata ayıklaması da oldukça zorlaşan bir ürün ortaya çıkar.İçinde başka Anti-Pattern’ leri de barındırır diyebiliriz. Söz gelimi Boat Anchor, Spaghetti Code, Error Hiding vb…Kaynak kodun takibi de zorlaşır. Çözüm yollarından birisi Configuration Management’ tır.İstisnai Durum :Tabi oluşmasına müsaade edilebilecek durumlar da vardır ki bu durum çalışmanın bir araştırma çalışması olmasını gerektirir.
- «Daha sonra bu fonksiyona/kütüphaneye ihtiyacımız olabilir» denilerek yazılan fakat yazıldığı yerde unutulan kod parçalarının ortaya çıkarttığı durumdur. Unutulan kod parçaları yıllar sonra bırakıldıkları halleri ile kafalarda tam bir soru işareti oluşturabilirler. Neden yazıldıkları, ne amaçla kullanıldıkları bilinmeyebilir. Yazılımsal görünümü haricinde donanımsal tarafta da karşımıza çıkar. Örneğin artık demode olmuş, teknolojisi oldukça eskimiş bir bilgisayarın hasarlı bile olsa bir köşede durmaya devam etmesi/unutulması olarak da düşünülebilir.Aslında bir mini anti pattern’ dir.İstisnai Durum :
- Bu aslında bir inanışı sorgusuz sualsiz kabul etmekten dolayı isimlendirilmiş bir desendir. Çoğu zaman geliştirici bir çözüm için kullandığı bileşenleri, prensip ile desenleri, kod parçalarının nasıl çalıştığını/niye kullanıldığını bilmeden uygular. Bu sıkı sıkıya bağlılık aynı felsefeleri başka çözümlerde de kullanmaya çalışmasına yol açar. Bir nevi Copy-Paste Programming Anti-Pattern yaklaşımının bir sonucu olarak ortaya çıkabilir. Geliştirici çözüm için bir kod parçasını gerekli olup olmadığını ve nasıl çalıştığını anlamadan bir yerden bir yere taşıyarak uygulamaya çalışır.İstisnai Durum :
- Genellikle mantıksal bir tasarım bütünü içerisinde düşünülmeden hareket edildiğinde ortaya çıkar. Nesne yönelimli dil yetenekleri göz ardı edilir ve neredeyse her iş süreci için ayrı birer fonksiyonun yazılması söz konusudur. Bunun doğal sonucu olarak okunabilirlikten uzak, takibi oldukça zor bir kod bütünü ortaya çıkar. Yaşam döngüleri içerisinde sürekli olarak güncellenen programlar ve deneyimsiz geliştiriciler bu tip kodların oluşmasına sebebiyet verebilir.Nesne yönelimli olmayan dillerde daha sık rastlanır.Metotlar daha çok süreç odaklı yazılır hatta süreç adları olarak isimlendirilir.Nesneler arasında neredeyse hiç ilişki yoktur.Çoğu metot parametre almaz ve global seviyedeki sınıf değişkenlerini oluşturmakta kullanılır.Kodun yeniden kullanılabilirliği zordur.OOP temel özellikleri(kalıtım, çok biçimlilik, soyutlama) kullanılmaz.Bu tip kodları genellikle kodun sahibinden başkası anlamaz/anlamakta güçlük çeker ve hatta «bunu tekrar yazsam daha iyi olur» der.İstisnai Durum :Bazı ara yüz parçalarında implementasyonun iç içe olduğu hallerde göz ardı edilebilir. Özellikle bileşenin yaşam ömrünün kısa olduğu ve sistemin geri kalanından tamamen ayrıldığı/izole edildiği durumlarda göz yumulabilir. Örneğin bir web ara yüzünde yoğun javascript kullanıldığı hallerde sayfa kodunun bu şekilde karmaşıklaşması gibi.
- Bazen geliştiriciler, asıl hata mesajını son kullanıcıdan saklama veya anlamlı bir gerekçe göstermeme yolunu tercih ederler. Çoğunlukla nesne yönelimli dillerin kullanıldığı senaryolarda Exception Handling noktasında kendisini gösterir. Kullanıcının oluşan hata ile ilişkili olarak anlamlı bir mesajla uyarılmayışı çok doğal olarak sorunun anlaşılamaması demektir. Bu anti-pattern oluştuğunda geliştirici genellikle exception handling’ i ezer ve uç noktalara anlamlı mesajlar vermeyi ihmal eder.Örnek bir senaryo;A fonksiyonunun B bileşenindeki bir servise ihtiyacı olduğunu düşünelim. B bileşeni de A’dan gelen isteği yerine getirmek için C bileşenine ihtiyaç duysun. C kendi içinde bir exception alırsa bunu B bileşenine iletebilir. B bileşeni de C’den gelen hatayı rethrow ederek A’ ya iletebilir. A bu noktada gelen hatayı handle edecek yeterli bilgiye sahip olamayabilir. Bu durumda A şu 3 alternatiften birisini seçer; ya hatayı rethrow eder, ya hatayı yakalar onu loglar ve yine rethrow eder ya da hatayı yakalar ama anlamlı olabilecek hiçbir şey yapmaz. Deneyimsiz programcılar genellikle 3ncü hali seçer ve hatayı gizleyerek anlamlı bir çıktı üretmezler. Burada en büyük problem şudur. Belki de uygulama için kritik olan ve işletilen sürecin doğru yürümesine engel olan bir durum oluşmuştur ama son kullanıcı/uç noktadaki program error-hiding nedeniyle bunun farkında bile değildir.İstisnai Durum :
- Analiz FelciBazı projelerin analiz safhası hem uzun sürer hem de kullanılan kaynakların(eleman gibi) maliyeti yüksek ve fazla olur. Çoğunlukla waterfall adı verilen yazılım geliştirme metodolojisinde karşımıza çıkar. Analizin uzamasının belli nedenleri vardır. Bunlardan birisi gereksiz detaylara çok fazla girilmesidir. Mükemmel bir analiz olmadan tasarım yapılamayacağı ve ilerlenemeyeceği varsayılır. Bu Anti-Pattern ayrıca günümüzün popüler çevik süreçlerinin doğmasında da rol almış olabilir. Nitekim çevik süreçler iterafit yaklaşımı tercih ederlerken iterasyonlar sonucunda işe yarar bir ürünün veya paketin müşteriye sunulmasına odaklanırlar.İstisnai Durum : Kitaba göre bu deseni haklı çıkartacak hiçbir istisnai durum yoktur.
- Müşteri olarak bir üreticinin ürünü veya hizmetine sıkı sıkıya bağlı olunan hallerde ortaya çıkar. Öyleki farklı bir üreticinin ürününe geçiş yapmak için ekstra maliyet altına girmek gerekebilir. Sıklıkla verilen örneklerden birisi SIM kartla satılan ve başka SIM kartla çalışmayan telefonlardır. Bir başka örnek müzik sistemi içeriye gömülü olan otomobillerdir. Bunlarda müzik sistemi değiştirmek epeyce külfetli iştir. Ya da bir servis sağlayıcısı tarafından sunulan hizmet veya satın alınan bir yazılım bileşeninin herhangi bir ara katman geliştirilmeksizin doğrudan kullanılması bu halin oluşması anlamına gelir.Bu duruma düşülmesinin belli başlı sebepleri vardır. Örneğin sadece Pazar ve satış bilgilerine bakılıp ürünün teknik detayı atlandığında kolayca ortaya çıkabilir. Diğer yandan uygulamanın sıkı sıkıya bağlı olduğu yazılımdan kopartılmasına uygun teknik bir çözüm veya maliyet modeli olmadığında da oluşabilir.Durumun oluşmasını engellemek için uygulama bazında katmanları iyi bir şekilde izole etmek ve vendor ürünü yerine yeri geldiğinde bir başkasını koyabilme kabiliyetini oluşturabilmek gerekir. Bu da ürün ile onu kullanan asıl uygulama arasında izole edilmiş bir katmanın olması ile sağlanabilir.İstisnai Durum :Bir uygulamanın gerektirdiği harici çözümleri büyük oranda karşılayan tek bir Vendor ile çalışılıyorsa göz yumulabilir.
- Bir Mini-Anti Pattern olarak tanımlanmıştır.Genellikle çözümlerde kullanılan 3ncü parti bileşenlerde değişiklikler yapıldığında ortaya çıkar. Bileşenin destekçisinin yapacağı bir güncelleme sonrasında, hali hazırda yapılmış olan değişiklikler ortadan kalkar. Kalkması istenmiyorsa bu durumda entegre edilmesi için epeyce efor sarf edilmesi gerekebilir. Bu tip bileşenlerde değişiklik yapmaktan kaçınmak daha doğrudur. Pek tabi bileşen sahibi bir süre sonra ürüne olan desteğini de bırakabilir.Bu durumun önüne geçmek için aynen VendorLock-In de olduğu gibi bileşenleri izole edilmiş bir katman ile asıl uygulamadan ayrıştırma yolu tercih edilebilir.İstisnai Durum :
- Bir sınıf içerisine çok sayıda fonksiyonelliğin gömüldüğü(60dan fazla metot) ve sınıf ile ilişkili verilerin ayrı veri sınıflarında tutularak bu sınıfla ilişkilendirildiği hal olarak düşünülebilir. Process odaklı procedural yaklaşım da diyebiliriz. Bu durumda tüm iş yükünü üstlenen sınıfların bakımı, genişletilmesi, iş mantıklarının kolayca okunur olarak içerisinde yer alması oldukça zorlaşır. Karmaşıklığın yanında belleğe yüklenmesi de zaman alan nesneler ortaya çıkar. Sınıf daha da kalabalıklaştığında yeni istekler için güncellemelerin yapılması zorlaşacaktır. Üstelik iş mantıklarının da yeteri kadar soyutlanamaması nedeniyle tekrarlı kodların önüne geçilmesi mümkün olmayacak ortak iş mantıkları farklı kanallara sunulamayacaktır.BLOB Anti Pattern olarak da anılır.Anti-Patterns kitabının konuya ilişkin örnekte PowerBuilder ile tasarlanan bir GUI ele alınmıştır.İstisnai Durum :Bazı istisnai durumlarda oluşmasına müsaade edilebilir. Örneğin miras olarak alınan çok eski sistemlerin sarmalanarak daha kolay erişilebilmesi ve yeni nesil ortamlara basit bir katman üzerinden sunulması hallerinde göz önüne alınabilir. Örneğin bir donamımın (Fax makinesi gibi) driver yazılımını .Net veya Java tabanlı bir uygulamada rahat kullanabilmek için onu sarmallayan kütüphaneler God Object olsalar dahi izolasyonu sağladıklarından tercih edilebilirler.
- Bu desen GUI tipindeki uygulamalarda ortaya çıkar. Arayüz tarafı ile iş mantıkları genellikle buton gibi bir kontrol arkasına gömülür. Ara yüz kontrollerine ait doğrulama işlemleri gibi operasyonlar butona basılmadan önce, çalıştırılması gereken iş mantıkları ise butona basıldıktan sonra devreye giren olay metodlarında ele alınır. Doğal olarak iş mantıkları soyutlanmamış olacağından arayüz ile sıkı sıkıya bağlı hale gelir ve ilgili iş birimleri farklı yerlerde kullanılmak istendiğinde işler zorlaşır. Kodun okunabilirliği de ortadan kalkar. İstisnai Durum :
- Bir uygulamanın gereğinden ve ihtiyaç duyulandan fazla kompleks geliştirilmesidir. İstenen şeyler çok basit seviyede olabilecekken karmaşıklaştırılır. Bu bir nevi sedan tipindeki aile arabasının 340 KM süratle gidebilmesini sağlayacak teknolojiyi kullanarak üretim yapmaya benzer. Sonuçta üretim maliyeti yükselir. Kısacası bir problemi olduğundan daha karmaşıkmış gibi algılayıp çözmeye çalışmak olarak düşünülebilir.İstisnai Durum :