Bir kod incelemesinde, ekranın karşısında oturup “tamam, bu şimdi ne yapıyor?” dediğiniz oldu mu? Benim oldu. Hatta birkaç kez. 2019 yazında, İstanbul’da bir fintech projesinde çalışırken, ekipteki en parlak arkadaşlardan biri bir işi o kadar “şık” hale getirmişti ki kod çalışıyordu ama insan aklına pek hitap etmiyordu — her satır sanki biliyor musun, beni okuma zahmetine girme diyor gibiydi. İşin garibi şu: böyle anlarda sorun genelde araçta olmuyor. Sorun, aracın her yere sürülmesinde.
İngilizce kaynakta geçen o meşhur lafı ben biraz yumuşatıp söyleyeyim: array_map bir tasarım deseni değil (şaşırtıcı ama gerçek). Evet, çok kullanışlı bir fonksiyon. Hızlıdır, kısa yazar, bazı yerlerde gerçekten hayat kurtarır. Ama onu her problemi çözen sihirli değnek gibi görmek — işte orada iş karışıyor.
Şimdi gelelim işin can alıcı noktasına.
Nerede Koptu Bu İş?
Editör masasında bu konuyu ilk gördüğümde aklıma hemen 2022’de Ankara’da yaptığım bir kod denetimi geldi. Küçük bir SaaS ekibi vardı. Ürün iyi gidiyordu ama backend tarafında herkes kendi zevkine göre küçük kısayollar üretmişti; bir noktada veri dönüştürme zinciri o kadar uzamıştı ki tek satırlık bir hatayı bulmak için beş dosya açmanız gerekiyordu. Her dosyayı açtığınızda “acaba bu muydu” sorusuyla kendinizi yeni bir tünelin içinde buluyordunuz. Hani insanın içinden “durun bir dakika” demesi geliyor ya… aynen öyle.
Asıl mesele şu: bazı geliştiriciler bir aracı buluyor ve sonra onu her yerde kullanmaya başlıyor. Kötü niyet değil bu. Çoğu zaman tam tersine iyi niyet — “bak ne kadar temiz oldu” hissi geliyor insana. Fakat temiz görünen şeyin altında bazen bayağı dağınık bir düşünce yatıyor.
Durun, bir saniye.
Ben buna biraz “fazla zeki olma sendromu” diyorum. Kod review sırasında dikkat çekici görünmek kolay (inanın bana). Zor olan ise altı ay sonra o kodu başka birinin korkmadan değiştirebilmesi. Evet, asıl sınav orada başlıyor.
Kodun ikinci hayatı vardır: okunmak, anlaşılmak ve gerektiğinde değiştirilebilmek zorundadır. Çalışması yetmez.
Clever Görünmek mi, Net Olmak mı?
Şimdi gelelim işin can alıcı kısmına. Clever code ile clear code arasında ince ama çok önemli bir çizgi var — ilk bakışta şık duran yapıların bazıları pratikte yavaşlatıyor, hem performans anlamında değil sadece, zihinsel yük olarak da yoruyor insanı. Bir şeyi çözmek için üç katman soyuyorsanız, orada küçük bir alarm çalmalı. Çalmalı ama çalmıyor çoğu zaman.
Geçen sene İzmir’de bir startup ekibine dışarıdan destek verirken bunu net gördüm (bizzat test ettim). Veri dönüşümleri için üst üste bindirilmiş map’ler kullanmışlardı; dışarıdan bakınca minimalist duruyordu. Debug ederken herkes aynı soruyu soruyordu: “Bu ara adımda ne oluyor?” İşin komiği, çözüm daha uzun yazılınca daha okunur hale geldi.
Bakın, Yani mesele şu değil: array_map kötü mü? Hayır. Mesele şu: nerede, ne kadar, hangi niyetle kullanıyorsun? Eğer amaç veriyi tek hamlede dönüştürmekse tamamdır. Ama zincirleme sihir gösterisine dönüyorsa… açık konuşayım, orada kod kokusu başlıyor.
| Kullanım Şekli | Okunabilirlik | Bakım Kolaylığı | Bence Ne Durumda Kullanılır? |
|---|---|---|---|
| Tek array_map | İyi | İyi | Basit dönüşümlerde gayet yerinde |
| Nesting üstüne nesting | Zayıf | Zayıf | Sadece çok özel durumlarda, dikkatle |
| Düz foreach + açık adımlar | Çok iyi | Çok iyi | Ekip içi bakım gerektiren çoğu işte tercih edilir |
Kod Çalışıyor Ama Kim Anlayacak?
Küçük takım vs kurumsal ekip: Küçük startup’ta bazen hızlı olmak gerekir, kabul ediyorum. İki kişiyle ürün çıkarıyorsanız her satırın roman gibi olması gerekmiyor. Gel gelelim ekip büyüdükçe tablo değişiyor — beş kişi okuduğunda anlaşılmayan şey, on beş kişilik ekipte tam anlamıyla boru hattına dönüşüyor, boru hattı tıkanınca da herkes birbirine bakıyor (inanın bana). Tanıdık geldi mi?
Kısa vadeli hız vs uzun vadeli sürdürülebilirlik: Birkaç dakikada yazılan zarif görünen yapı bazen haftalarca bakım maliyeti çıkarıyor. Ben bunu özellikle güvenlik tarafında çok gördüm; hızlı yazılmış filtreleme mantıkları ilk gün iş görüyor. Edge-case gelince pat diye dağılıyorlar. Sonra geriye dönüp bakıyorsun — zaten baştan belliymiş (yanlış duymadınız)
Neden bu kadar cazip geliyor?
Çünkü insan zekâsını seviyor tabi. Hele bir de teknik ekiplerde “bak bunu böyle çözdüm” duygusu hoş gelir insana — ve ben de eskiden tam böyleydim, dürüst olayım (yanlış duymadınız). 2021’de Bursa’da hazırladığım küçük bir raporlama modülünde gereksiz yere functional yaklaşımı abartmıştım, sonra aynı modülü iki hafta sonra açınca kendime kızdım. Fazla süslüydü. Neden yaptım? Bilmiyorum. Herhalde o an dikkat çekici hissettirmişti.
Peki ne zaman mantıklı?
Eğer veri gerçekten transform odaklıysa ve işlem zinciri kısa kalıyorsa array_map gayet işe yarar. Mesela düz string temizleme, basit alan eşleme ya da tek tip listeyi normalize etme gibi işlerde fena değildir, hatta bayağı pratiktir. Bu kadar.
Nerede frene basmalı?
Şunu fark ettim: Dur bir saniye — önce şunu söyleyeyim: karmaşıklığı saklamak ile karmaşıklığı çözmek aynı şey değil. Eğer map içine map sokuyor, içinde koşul üstüne koşul ekliyor ve sonunda geri dönen veri tipini bile açıklamak zorlaşıyorsa artık durma vakti gelmiştir. X, otomatik çeviriyle duvarları biraz daha inceltti yazımızda bu konuya da değinmiştik.
$result = [];
foreach ($items as $item) {
$normalized = transform($item);
if ($normalized === null) {
continue;
}
$result[] = $normalized;
}Daha Temiz Alternatifler Var mı?
Var. Hem de çoğu zaman düşündüğünüzden daha sade olanlar bunlar oluyor. Örneğin açık isimlendirilmiş yardımcı fonksiyonlar kullanabilirsiniz; veriyi önce hazırlayıp sonra dönüştürebilirsiniz; ya da tek satır yerine iki net adım atarsınız. Bazen bu yaklaşım ilk bakışta “eski usul” gibi görünür, bunu biliyorum. Ama sahada test ettiğinizde fark ortaya çıkıyor: log okumak kolaylaşıyor, hata ayıklamak rahatıyor, ekip içi iletişim bile düzeliyor — kulağa fazla iddialı gelebilir ama öyle.
Bazı projelerde küçük yardımcı sınıflar ya da saf fonksiyonlar bence çok daha dengeli sonuç veriyor. Bir bakıma, hele bir de kurumsal yapılarda herkesin rahat okuyabileceği isimler seçmek büyük fark yaratıyor — çünkü kod sadece makinenin değil, insanların da tükettiği bir şey haline geliyor zamanla.
Neyse uzatmayayım: sade çözüm her zaman basit çözüm demek değildir. Bazen tam tersine daha olgun çözümdür.
Tasarım Deseni Sandığımız Şeyler Neden Şişiyor?
Birkaç yıl önce Berlin’den çalışan bir ekip arkadaşımla konuşurken ilginç bir cümle kurmuştu: “Bir araç başarı kazanırsa insanlar onu mimari sanmaya başlıyor.” Çok doğru buldum bunu.
array_map bunun klasik örneklerinden biri olabilir (ki bu çoğu kişinin gözünden kaçıyor) Bitcoin Neden Yazılımdan Kopuyor? Savaş ve Yapay Zeka Etkisi yazımızda bu konuya da değinmiştik.
Araçların popülerleşmesi güzel şeydir — bu kısmı tartışmıyorum. Ama popülerlik tasarım disiplini üretmiyor. Bir kütüphane fonksiyonunu desen diye pazarlamaya başladığınız anda sistemin zihni bulanıyor; sonra yeni gelen geliştirici de doğal olarak aynı yolu izliyor, zincir uzuyor, ve kimse nedenini hatırlamıyor. Hmm, tanıdık bir hikâye.
Bunu biraz açayım.
- Araç: Belirli işi yapan küçük yapı
- Dekorasyon: Gereksiz süslemelerle karmaşa artırma riski (bence en önemlisi)
- Tasarım deseni: Tekrarlanan probleme düzenli yaklaşım (bence en önemlisi)
- Kötü alışkanlık: Araçla deseni karıştırmak
Peki Ben Olsam Ne Yapardım?
Açık konuşayım: ben çoğu durumda önce okunabilirliği seçerim. Performans kritik değilse ya da ölçülmemişse, önce düz anlatırım. İlk hedefim şudur: bir ay sonra başka biri baktığında yüzünü ekşitmesin. Bu kadar basit aslında. AI Ajanlar Neden Yalan Söyler: Asıl Ders Ne? yazımızda bu konuya da değinmiştik.
Ha bu arada, bazı takımlarda bunun tam tersi baskın olur — “daha kısa olsun”, “daha modern görünsün”, “functional olsun” (ciddiyim). Tamam güzel. Ama eğer sonuç anlaşılmazsa kısa olmasının pek kıymeti kalmıyor. Kısa ve anlaşılmaz mı, yoksa biraz uzun ama net mi? İkincisini alırım (ilk duyduğumda inanamadım) Poco X8 Pro Max Türkiye’de: Dev Batarya, Büyük Soru İşareti yazımızda da bu konuya değinmiştik. Apple’ın Yeni M5 MacBook Air’i İndirime Girdi: Fiyatlar Düştü yazımızda da bu konuya değinmiştik.
Benim pratik kuralım şu: önce netlik, sonra gerekirse sıkıştırma. Tersini yapınca borç büyüyor.
- Dönüşümü önce açık şekilde yazın.
- Aynı mantık tekrar ediyorsa soyutlayın.
- Zincir uzuyorsa ara değişken ekleyin.
- Kodu başkasına okutun; yüz ifadesi çok şey söyler! — bunu es geçmeyin
Sıkça Sorulan Sorular
`array_map` ne zaman kullanılmalı?
`array_map`, basit ve tek tip dönüşümlerde oldukça işe yarar. Liste üzerindeki değerleri doğrudan başka forma çevirmek istiyorsanız iyi seçimdir.
`array_map` neden bazen kötü görünüyor?
Zincirleme kullanıldığında okuması zorlaşır ve hata ayıklaması sıkıntılı olur. Mesela iç içe `array_map` yapıları kodu olduğundan karmaşık gösterir (inanın bana)
`foreach` mi `array_map` mi daha iyi?
Sabit cevap yok; amaca bağlıdır. Okunabilirlik öncelikliyse `foreach` çoğu zaman daha nettir. Kısa ve saf dönüşümlerde ise `array_map` gayet mantıklıdır.
Kodda fazla soyutlama nasıl anlaşılır?
Eğer akışı takip etmek için sürekli başka dosyalara atlamak zorunda kalıyorsanız fazla soyutlama vardır.
Kod sizi yönlendirmeli; siz kodu avlamamalısınız.
Kaynaklar ve İleri Okuma
Şunu söyleyeyim, PHP Resmî Dokümantasyonu — array_map()
PHP Resmî Dokümantasyonu — foreach Yapısı
Martin Fowler — Code Smell Yazıları
Sıkça Sorulan Sorular (Ek)
`array_map` performans açısından avantajlı mı?
Bazen evet, ama performans kazancı her senaryoda belirleyici olmaz.
Önce ölçmek gerekir; tahminle karar vermek çoğu zaman yanıltır (ciddiyim)
Nest edilmiş `array_map` neden önerilmiyor?
Cevap basit:
okuması zor,
debug etmesi yorucu,
bakımı pahalı.
Bir süre sonra kimse hangi adımın ne yaptığını net hatırlamaz.
Tasarımsal olarak en sağlıklı yaklaşım nedir?
Kodun niyetini açık etmek en sağlıklı yaklaşımdır.
Fonksiyon adı, ara değişkenler ve akış düzeni bunu destekliyorsa sorun azalır.
Az önce söylediklerimi toparlarsam:
araçları sevelim ama onlara dizayn rolü vermeyelim.
Araç araçtır.
Desen desen…
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
