- Modern yazılım geliştirme kültüründe proje ve kütüphane adları, işleve bağlı olmayan keyfi kelimelerle dolduruluyor
- Geçmişte grep, awk, sed, FORTRAN, COBOL gibi adlar işlevi ya da amacı doğrudan açıklarken, bugün anlamsız adlandırmalar ortalığı kaplamış durumda
- Bu eğilim, GitHub ve startup kültürünün yayılmasıyla hızlandı; isimle işlev arasındaki bağ neredeyse tamamen koptu
- Anlama maliyeti ve bilişsel yük artıyor; geliştiriciler her aracın rolünü kavramak için gereksiz araştırmaları tekrar tekrar yapmak zorunda kalıyor
- Yazı, açık ve işlev odaklı adlandırma kurallarının yeniden canlandırılmasını istiyor ve teknik araçlarda marka değerinden çok netlik ve profesyonelliğin önce gelmesi gerektiğini vurguluyor
Yazılım adlandırma pratiklerinin değişimi
- Richard Stallman, 2022 EmacsConf konuşmasında “hatırlaması kolay isimlerin” önemine değinerek, paket adlarının ne yaptığını göstermesi gerektiğini vurguladı
- Emacs ekosistemi geleneksel olarak dired (directory editor), eshell (Emacs shell) gibi işlev temelli adlandırma pratiklerini sürdürdü
- Ancak modern geliştiriciler araçlara rastgele isimler, mitolojik varlıklar, kurgusal karakterler gibi adlar verme eğiliminde
- Bu, başka teknik alanlarda profesyonellik eksikliği sayılabilecek bir davranış
Anlamsız isimlerin sorunu
- Örnek olarak “Viper”, “Cobra”, “Melody”, “Casbin”, “Asynq” gibi araç adlarından işlev hakkında hiçbir çıkarım yapılamıyor
- Yazar, bir arkadaşının altyapı açıklamasını anlayabilmek için arama yapmak zorunda kaldığı deneyiminden söz ediyor
- Mühendisliğin diğer alanlarında isimler yapı ya da işlevi açıklar
- Örn: Golden Gate Bridge, Hoover Dam, I-beam, butterfly valve gibi adlar biçimi veya rolü açıkça gösterir
- Kimyadaki IUPAC adlandırma sistemi gibi, adın tam olarak tek bir şeyi işaret etmesi için kurallar bulunur
- Örn: 2,2,4-trimethylpentane yalnızca tek bir molekülü ifade eder; ona rastgele “Steve” denmez
Geçmişin adlandırma kuralları ve bugünkü kopuş
- 1980'lerde grep, awk, sed, cat, diff gibi işlev temelli kısaltmalar baskındı
- FORTRAN, COBOL, BASIC, SQL, Lisp gibi programlama dili adları da amaçlarını yansıtıyordu
- 2010'lardan sonra anlamsız isimlerin yayılması başladı
- MongoDB gibi bazı örneklerin işlev veya kökenle belli bir ilişkisi vardı, ancak sonrasında GitHub ve startup kültürü içinde anlamsız adlandırmalar hızla arttı
- Bunun nedenlerinden biri olarak, Google benzeri marka odaklı başarı örneklerini taklit etme eğilimi gösteriliyor
Bilişsel maliyet ve geliştirme verimliliğinde düşüş
- libsodium gibi isimlerde işlevi tahmin etmek zor ve geliştirici sürekli bağlam değiştirmek zorunda kalıyor
- “Neden sodium?” sorusunu çözmeye çalışırken gereksiz zaman harcanıyor
- Proje bağımlılıkları arttıkça bu bilişsel vergi (cognitive tax) birikiyor
- Bu da geliştirici üretkenliğinin düşmesine yol açıyor
- Yazar, “Viper, Cobra, Melody…” gibi cümleleri işlerken anlamsız token'ları çözümlemek için zihinsel kaynakların boşa harcandığını belirtiyor
Yaygın itirazlar ve bunlara verilen yanıtlar
- “Akılda kalıcı isimler pazarlama için daha iyidir” → Geliştirici araçları tüketici ürünü değildir; işlevin açık olması daha önemlidir
- “Açıklayıcı isimler sıkıcıdır” → Sıkıcılık, netlik karşılığında kabul edilebilir; cerrahi aletler de sıkıcıdır ama kesindir
- “Eğlencesine böyle isim veriyoruz” → Bu ‘eğlencenin’ bedelini bütün kullanıcılar öder, sonuçta tüm sektörün zaman kaybına dönüşür
- “İyi isimlerin hepsi alınmış durumda” → namespace, önek ve birleşik kelimelerle bu sorun çözülebilir; en azından işleve bağlı bir isim seçilmelidir
İleriye dönük yönelim
- Sorun, kötü niyetten çok kültürel değişimin sonucu olarak açıklanıyor
- Programlama şirket merkezli yapıdan topluluk merkezli yapıya kayarken sosyal normlar zayıfladı
- Çözüm ise adlandırma kurallarının kültürel olarak yeniden kurulması
- Düzenlemeden çok, profesyonelliğin geri kazanılması, eğitim ve toplumsal baskı yoluyla iyileşme gerekiyor
- Kütüphane isimleri işlevi yansıtmalı; gerekirse birleşik kelimeler ve uzun ifadeler de kabul edilmeli
- Örn: “http-request-validator”, “zephyr”den çok daha nettir
- Maskot ile isim birbirinden ayrılmalı
- Örn: PostgreSQL, Slonik adlı fil maskotunu kullanır ama ismin kendisi işlevsel anlamını korur
- Eğer konu markalaşmanın önemli olduğu bir tüketici ürünü değilse, öncelik netlik ve profesyonellik olmalı
- “Sevdiğim anime karakterinin adını versem mi?” demeden önce, “Bir inşaat mühendisi bir köprü sistemine böyle bir ad verir miydi?” diye düşünmek gerekir
- Sonuç olarak, anlamsız isimlerin kontrolsüz çoğalmasına son verip açık profesyonel dile geri dönmek gerekiyor
- Netlik sıkıcılık değil, kullanıcının zamanına ve bilişsel kaynaklarına saygıdır
Henüz yorum yok.