Sonu kötü biten bir hikaye : AntiPatterns — 2
Herkes ne yapılması gerektiğini söyler fakat neleri yapmamamızı gerektiğinin söylenmesi çok daha önemli ve değerlidir.
Bu yazı dizisine o amaçla başladım ve devamında ise önemli olan başka 4 antipattern hakkında kişisel yorumlarımdan oluşan bir bilgilendirme yazısı derledim. İlk yazıma yukarıdaki link aracılığla ulaşabilirsiniz.
Ambiguous Viewpoint
OOA & D (Nesneye yönelik analiz ve tasarım) modelleri, çok büyük çoğunlukla farklı bakış açılarındaki rollerin tam ayrımı yapılmadan direkt olarak tasarlanır. İyi anlaşılması adına; bir developerın hem analist, hem yazılım, hem de sistem tasarımı işini yapması ve üzerine gelen küçük talepler ile ilgili olarak arayüz tasarım kararları alması gibi bir örnek olabilir.
- The business viewpoint : kullanıcıların bilgi ve süreç modelini tanımlar. Bu bakış açısı domain olarak uzmanlaşmış rollerin çizeceği sınırlardır. Yani ekrana bir buton talebi geldiğinde butonun şeklini yerini ve text olarak ne yazacağını söyleyen arkadaşlar. Analiz bakış açısı olarak da adlandırabiliriz. Özet olarak işin ne olacağıdır.
- Specification viewpoint : Yazılım tasarımına ve arayüzlerine odaklanır. Yazılımda yer alacak sınıflar, interface yapıları, kullanılacak 3. parti kütüphaneler vb gibi tasarımsal kararlar. Özet olarak neyi nasıl yapacağımız ile ilgilenir.
- The implementation viewpoint : Bu bakış açısı, nesnelerin iç detaylarını tanımlar. Özet olarak işi yapacağınız yerdir.
Refaktoring çözümü olarak bu bakış açılarını ayrılması önerisi verilmekte. Bence bunun en iyi yolu ise rollerin belirlenmesi; architect rolü kimde, analist-kullanıcı rolü kimin, developer olarak kim çalışacak. Belki de aynı toplantıda aynı konu üzerinde aynı konuda bu bakış açılarındaki kişilerin olması ve kendi sorumluluklarına göre yorumlamaları doğru olacaktır.
Bu anti-pattern daha çok oturmuş ve devasa büyüklüğe gelmiş sistemler için büyük risk teşkil edebilir. Start-up’lar için bu roller mecburen dinamik ve bir rolü birden fazla kişi üstlenebileceği için ilk aşamalarda belki de sorun yaratmayabilir. Fakat scrum metodolojilerinin de yaygınlaşmasıyla büyük sistemlerde yapılan projelere de start-up mantığıyla bakılması bence scrum metodolojilerinin getireceği büyük dezavantajlardan biri olacak ve ilerleyen zamanlarda bu anti-pattern’ın en büyük nedenlerinden olacak gibi gözükmekte(kişisel yorumum).
Scrum gözüyle bakılırsa, bunu önlemenin yolu da bu sorumlulukların ve kararların takım içinde iyi ayrıştığı veya antipattern oluşan durumlarda da bunu haneye borç yazmak olabilir.
Golden Hammer
Bu antipattern hakkında ne söylesem tanıdığım çoğu kişi üzerine alınacaktır ki bu da özellikle ülkemizde en yaygın görüldüğünü tahmin edebilirsiniz.
Bizi üretken bir mühendis olmaktan çıkartıp sadece motorun bir dişlisi haline getiren bir antipatterndir. Çok tehlikelidir ki developerları köreltir ve tipik bir devlet memuru haline getirir.
Çok sık olarak bir developer veya bir yazılım yöneticisi, uzun zamandır üzerinde çalıştığı hantallaşmış bir ürün paketini her defasında çözüm olarak sunar. Vazgeçilmek olmak ve alternetifsiz olduğunu düşünmek ana amaçtır. İşte bu yazılım ekibi ve yönetimin tümü Golden Hammer olarak adlandırılır.
Geliştiriciler ve yöneticiler, mevcut bir yaklaşımla rahattır ve daha uygun olanı öğrenmek ve uygulamak konusunda isteksizdir.
Domain bazında yetkinlikleri o kadar fazladır ki belli bir kullanıcı veya analist kadrosuna dahi ihtiyaç olmayabilir. Tek bir teknoloji üzerinde tek bir konu üzerinde bir çember oluşturulur. Alternatif çözüm önerileri ve teknolojilere sıcak bakmazlar.
Yinelenen işleri severler ve çözülmesi için bir adım atmazlar; diyelim ki yıllık çalışan bir batch iş var ve o batch işten önce veritabanına bir dizi güncelleme işlemi yapılacak. İşte bu manuel müdahale işleri hiçbir zaman bitmez.
Aslında sizin de kafanızda canlanmıştır fakat direkt somut örnek olarak Bankacılık IT sektörü olur.(ARGE faaliyetleri yürüten veya gerçekten bu yüklerden kurtulmak isteyen bankada çalışan meslektaşlarımı tenzih ederim, selamlarım)
Çözümler, sektördeki diğer çözümlerle karşılaştırıldığında düşük performansa sahiptir ve rasyonellik & saydamlıktan uzaktır.
Refaktoring çözümü olarak da direk verilen tavsiyeyi yazıyorum;
“This solution involves a philosophical aspect as well as a change in the development process. Philosophically, an organization needs to develop a commitment to an exploration of new technologies. In addition, software developers need to be up to date on technology trends, both within the organization’s domain and in the software industry at large.”
Çok şey söylenir çok şey yazılır ama bence bu durumun çözümü yeni nesil developerların mesleklerine yaklaşımı ve teknolojik açlığına bağlı bir durum gibi geliyor.
Lütfen körü körüne bir teknolojiye bağlımlı olmayın, yapmayın etmeyin yoldaşlar. Ben javacıyım sen .netçisin yaklaşımı bu işin başlangıcı gibi geliyor. Sonrası çorap söküğü gibi geliyor.
Ek not olarak: Önceki yazımda anlattığım Lava Flow antipatterni Golden Hammer a dönüşmüş ekiplerde mutlaka görünmektedir.
Poltergeists
Hayalet — Kötü ruh sınıf anlamında kullanılıyor.
Kendine ait hiçbir sorumluluğu olmayan gereksiz ve işe yaramaz sınıflar veya controller’lar, genellikle başka bir sınıftaki yöntemleri çağırmak veya gereksiz interface yapısı kurmak için kullanılır.
Kod olarak örneklemek gerekirse(kotlin);
class TeamStack {
private var teamList : ArrayList<Team> = ArrayList()
fun push(team : Team){
this.teamList.add(team)
}
fun size() : Int {
return teamList.size
}
}
data class Team(
var teamName: String? = null,
var teamType: String? = null
)
TeamStack isimli sınıfın yaptığı şey, private olarak Team nesnesinin listesini tutmak ve üzerinde işlem yapmak. Aslında koda bakarak bile ne kadar anlamsız ve saçma bir sınıf olduğu görülüyor. Fakat bunu yapıyoruz. Herşeyi OO tasarlarım, herşeyi yapısal yaparım mantığıyla girdiğimizde kör olacağımız noktaya ulaştığımızda işte bu gerçekteşiyor.
Diğer bir adı da Çingene sınıfı.
Bunun ile ilgili olarak şiddetle aşağıdaki videoyu dinlemenizi öneririm.
Magic Numbers
Explicit is better than implicit.
Tim Peters, The Zen of Python
Buraya kadar olan antipattern lar daha çok mimari ve yazılım felsefesi kaynaklı genel niteleyebileceğimiz sorunlardı. Fakat bu antipattern bazen hepimizin yaptığı ve önlenmesi en kolay antipattern olarak listeye giriş yaptı.
Kod içinde isimlendirme yapılmış sabitler yerine direk atama yapılan numaraların veya array elemanlarının kullanılması olarak tanımlanabilir.
En büyük sorun ise bu rakamların nerden geldiği ve neyi temsil ettiğini anlamanın çoğu zaman imkansızlaştığıdır. Hal böyle olunca core bussiness sınıflarda var olan magic numberlar tam bir kabusa dönüşür. Değiştirilmesi veya anlaşılması gerekiyorsa çok fazla zaman harcatır. Diyelim ki kendisinde bir analiz veya tasarım dokümanı var olması gereken ve bu tip soruları oradan adreslemesini daha kolay yapabilecek bir analistiniz, sizden bir kredi türündeki vergi oranının kaç olduğunu sordu. Var olan yapıyı da şöyle hayal edin; aynı zamanda the god class’lar 1.madde de anlattığım golden hammer’a dönüşmüş bir yapı. Hem doğru bilgiyi vermek zorlaşır, hem developer bu işlemi yaparken zaman ve motivasyon kaybı yaşar.
Nasıl önlenir? isimlendirme yapılmış sabitleri ve ek açıklamaları kullanarak. Tabiki code review.
Eğer code review yaptığınız bir kod içinde magic number var ise gönül rahatlığıyla açana bakmadan reject edebilirsiniz.
