Makineler Dünyayı Raflara Dizince: Ontolojik Mühendisliğin Görünmez Zekâsı

Bir makineye “kedi” dediğinizde ne anlar? Sevimli bir ev hayvanı mı, memeli bir canlı mı, dört ayaklı bir nesne mi, yoksa internetteki sonsuz komik videoların başrol oyuncusu mu? İnsan için bu sorunun cevabı bağlama göre kayar; zihin, anlamı bir lastik gibi uzatır. Makine içinse mesele daha serttir: Kedi nedir, neyin alt türüdür, hangi özellikleri taşır, neyle karıştırılmamalıdır? İşte ontolojik mühendislik tam burada sahneye çıkar: Dünyayı makinelerin anlayabileceği şekilde kavramlara, ilişkilere ve hiyerarşilere ayırma sanatı ve disiplini.

Ontoloji, felsefede “varlık nedir?” sorusuyla başlar. Bilişimde ise bu soru biraz daha pratikleşir: “Bir sistemin hakkında konuştuğu şeyler nelerdir ve bunlar birbirine nasıl bağlıdır?” Bir hastane yazılımı için “hasta”, “doktor”, “teşhis”, “ilaç” ve “alerji” sadece kelimeler değildir; birbirine bağlı varlık sınıflarıdır. Bir hasta ilaç kullanabilir, bir ilaç yan etki üretebilir, bir alerji tedaviyi değiştirebilir. Makinenin akıllı davranması için bu ağın açık, tutarlı ve sorgulanabilir olması gerekir.

Veri Yığını Değil, Anlam Haritası

Modern sistemler veriyle dolu; fakat veri, tek başına zeki değildir. Bir depoda milyonlarca kutu olabilir, ama hangi kutunun kırılgan, hangisinin gıda, hangisinin yanıcı madde olduğunu bilmiyorsanız depo sadece düzenli bir kaostur. Ontolojik mühendislik, veriye etiket yapıştırmaktan fazlasını yapar: “Bu şey şunun türüdür”, “bu özellik şuradan miras alınır”, “bu ilişki şu koşullarda geçerlidir” der. Böylece makine yalnızca kayıt tutmaz, çıkarım yapmaya başlar.

Örneğin “serçe bir kuştur” ve “kuşlar genellikle uçar” bilgileri sisteme verilmişse, makine serçenin uçabileceğini varsayabilir. Ama “penguen bir kuştur” ve “penguenler uçamaz” bilgisi de varsa, sistem istisnayı yönetebilmelidir. Hiyerarşi, burada basit bir aile ağacı değildir; kurallar, miraslar, istisnalar ve bağlamsal gerçekliklerle örülmüş dinamik bir iskelettir. İyi tasarlanmış bir ontoloji, makineye ezber değil, kontrollü akıl yürütme kazandırır.

Kavramların Politikası

Ancak dikkat: Dünyayı sınıflandırmak masum değildir. “Çalışan”, “müşteri”, “riskli kullanıcı”, “başarılı öğrenci” gibi kavramlar teknik görünür ama değer yüklüdür. Bir ontoloji kurduğunuzda, sisteme yalnızca varlıkları değil, dünyaya bakış biçiminizi de kodlarsınız. Hangi ayrımlar önemli? Hangi özellikler görünmez? Hangi ilişki normal kabul edilir? Bu sorular, ontolojik mühendisliği sadece teknik değil, etik bir uğraş hâline getirir.

Yapay zekâ sistemlerinde bu daha da kritikleşir. Büyük dil modelleri kelimeler arasında istatistiksel bağlar kurabilir; fakat bir hukuk, tıp veya kamu sistemi için yalnızca olasılık yetmez. “Belirti”, “hastalık” ve “tanı” arasındaki farkı bilmeyen bir sistem, kulağa akıllı gelen ama tehlikeli öneriler üretebilir. Ontolojiler burada bir tür omurga sağlar: Modelin serbest çağrışımlarını disipline eder, kavramların sınırlarını belirler, çıkarımların denetlenebilir olmasını sağlar.

Makineler Anlar mı, Yoksa Düzenler mi?

En kışkırtıcı soru şu: Ontolojik mühendislik makinelerin gerçekten anlamasını sağlar mı? Belki “anlama” kelimesini insan bilinciyle aynı kefeye koyarsak cevap hayırdır. Makine, kediyi okşamaz, kaybettiği kedinin ardından üzülmez. Ama operasyonel anlamda, yani doğru ilişkiyi kurma, uygun sınıfa yerleştirme, çelişkiyi yakalama ve yeni sonuç çıkarma düzeyinde anlamlı davranabilir. Bu da küçümsenecek bir şey değildir; uygarlığın büyük bölümü zaten doğru sınıflandırmalar üzerine kuruludur.

Ontolojik mühendisliğin geleceği, yalnızca daha akıllı arama motorları ya da daha düzenli veritabanları değildir. Dijital ikizlerden robotlara, bilimsel keşiften akıllı şehirlere kadar her yerde makinelerin “neyin ne olduğunu” bilmesi gerekecek. Bir robot için bardak sadece silindir biçimli bir nesne değil; tutulabilir, kırılabilir, sıvı içerebilir, insana uzatılabilir bir varlıktır. Bu katmanlı bilgi olmadan robot, dünyaya çarpan pahalı bir süpürgeden fazlası olamaz.

Sonuçta ontolojik mühendislik, makineler için bir tür kozmoloji inşa etmektir. Evreni onların gözünde sınıflara, özelliklere ve ilişkilere ayırırız. Fakat her harita gibi bu harita da seçicidir. Bu yüzden en iyi ontoloji, sadece doğru çalışan değil, sorgulanabilir olandır. Makinelere dünyayı öğretirken aslında kendimize de şunu sorarız: Biz dünyayı gerçekten nasıl bölüyoruz, neyi var sayıyor, neyi yok sayıyoruz? Belki de makinelerin nesneler ve kavramlar arasındaki hiyerarşiyi anlamlandırması, insanın kendi anlam mimarisini ilk kez bu kadar çıplak görmesidir.

Ekranda Aynı, İçeride Devrim: Kod Refaktörünün Gizli Estetiği

Kod refaktörü, yazılım dünyasının en tuhaf sanatlarından biridir: Seyirci salona girer, perde açılır, sahne aynı görünür. Düğmeler aynı yerde, ekran aynı renkte, kullanıcı yine aynı işlemi yapar. Fakat kulisin arkasında dekor sökülmüş, kablolar etiketlenmiş, oyuncuların giriş çıkışları yeniden düzenlenmiş, yangın çıkışları açılmıştır. Dışarıdan hiçbir şey değişmemiştir; içeride ise küçük bir uygarlık kurulmuştur.

Bu yüzden refaktör, sadece teknik bir işlem değil, bir ahlak biçimidir. Çünkü hızlıca çalışan ama içten içe çürüyen kod ile karşılaşan geliştirici, iki yoldan birini seçer: Ya halının altına bir hata daha süpürür ya da diz çöküp zemindeki çatlağı onarır. Refaktör yapan kişi, gelecekteki bilinmeyen bir meslektaşına, hatta çoğu zaman kendisinin üç ay sonraki hâline not bırakır: Burada seni bekleyen bir mayın yok, rahat yürü.

Davranış aynı kalır, anlam değişir

Refaktörün temel ilkesi basittir: Dış davranışı değiştirmeden iç yapıyı iyileştirmek. Bu cümle kuru görünür ama yazılım mühendisliğinin Zen bahçesidir. Bir fonksiyon hâlâ aynı sonucu döndürür; fakat artık adının ne yaptığı anlaşılır. Bir sınıf hâlâ aynı sorumluluğu taşır; fakat sırtındaki beş gereksiz çuval indirilmiştir. Bir koşul hâlâ aynı kararı verir; fakat artık ormanda kaybolmuş bir if-else labirenti değildir.

Burada güzellik, kullanıcı arayüzünde değil, niyette ve düzendedir. İyi refaktör edilmiş kod, sessizce nefes alır. Değişiklik talebi geldiğinde panikle camdan atlamaz; sandalyeyi çeker, çayını koyar ve şöyle der: Buyur, nereye evrileceğiz? Kötü kod ise aynı isteği duyunca mağara ayısı gibi hırlar. Çünkü bağımlılıklar birbirine düğümlenmiş, isimler sisli, testler yok, mantık her yere sızmıştır.

Temizlik takıntısı değil, risk yönetimi

Refaktör bazen yanlış anlaşılır. Sanki geliştiricinin estetik kaprisiymiş gibi görülür: Aa, arkadaşımız kodun simetrisini beğenmemiş, biraz süsleyecek. Hayır. Refaktör, süsleme değildir; karmaşıklık borcunun faizini düşürmektir. Teknik borç, kredi kartı gibidir: Bugün hızlı geçersin, yarın faiz seni toplantı odasında yakalar. Bir noktadan sonra yeni özellik eklemek, bataklıkta piyano taşımaya benzer.

Bu nedenle iyi refaktör, ölçülü ve amaçlıdır. Her şeyi yeniden yazma sarhoşluğu refaktör değil, mimari yangındır. Gerçek refaktör küçük adımlarla ilerler: Bir metodu böl, bir adı netleştir, tekrarı kaldır, yan etkiyi izole et, testi ekle, bağımlılığı tersine çevir. Her adımda sistem çalışmaya devam eder. Cerrahın hastayı güzelleştirmek için değil, yaşatmak için kesmesi gibi.

İsim vermek, dünyayı kurmaktır

Programlamada isimlendirme, küçümsenen bir felsefe problemidir. Bir değişkene temp demek, onu sisin içine atmaktır. calculate demek de çoğu zaman yetmez; neyi hesaplıyor, kimin için, hangi bağlamda? İyi isim, zihinsel yükü azaltır. Kod okuyan kişi artık dedektiflik yapmaz; metni izler. Refaktör bu anlamda dilin arkeolojisidir: Koddaki bulanık kavramları kazar, ortaya gerçek niyeti çıkarır.

Bir başka estetik nokta da sınır çizmektir. Her şeyi bilen nesneler, yazılımın küçük diktatörleridir. Her yere erişen yardımcı sınıflar, imparatorluğun casus ağıdır. Refaktör, bu güç yoğunlaşmasını dağıtır. Sorumluluklar ayrılır, modüller kendi mahremiyetini kazanır, veri akışı izlenebilir hâle gelir. İyi mimari, her parçanın hem yalnız kalabildiği hem de doğru anda konuşabildiği bir şehir planıdır.

Testler: İç düzenin aynası

Refaktörün cesareti testlerden gelir. Test yoksa geliştirici karanlıkta mobilya taşıyordur; her an vazoya çarpabilir. Test varsa ışık yanar. Dış davranışın değişmediğini doğrulamak, refaktörün güvenlik kemeridir. Bu yüzden testler sadece hata yakalama aracı değil, tasarımın nabız ölçeridir. Test edilmesi zor kod genellikle fazla bağlı, fazla gizli anlaşmalar yapan, fazla dramatik koddur.

Sonunda refaktörün estetiği şurada belirir: Kimse alkışlamaz. Kullanıcı fark etmez. Ürün yöneticisi bazen ne yaptığını bile anlamaz. Fakat bir gün kritik bir değişiklik gelir ve ekip şaşırtıcı bir sakinlikle ilerler. İşte o an, geçmişte yapılan görünmez temizlik konuşur. Refaktör, geleceğin paniklerini bugünden susturma sanatıdır. Dışarıda aynı bina durur; içeride taşıyıcı kolonlar hizalanmış, merdivenler aydınlatılmış, kapılar artık duvara açılmamaktadır. Yazılımda gerçek güzellik bazen tam da budur: Hiçbir şey olmamış gibi görünür, çünkü içeride her şey olması gerektiği gibidir.

Evrenin Dinlediği Şifre: Kuantum Anahtar Dağıtımı Gerçekten Kırılamaz mı?

Bir şifre düşünün: Gücünü daha büyük asal sayılardan, daha hızlı işlemcilerden ya da saldırganın yeterince sabırsız olmasından değil, doğanın en temel huylarından alıyor. Kapıyı çelikle değil, evrenin davranış kurallarıyla kilitliyorsunuz. Kuantum Anahtar Dağıtımı, yani QKD, tam olarak bu fikrin etrafında döner. Eğer biri anahtarı çalmaya kalkarsa, kuantum dünyasının nazlı parçacıkları bunu sessizce geçiştirmez; iz bırakır, düzeni bozar, alarmı çaldırır.

Klasik kriptografide çoğu güvenlik, bazı matematiksel problemlerin pratikte çözülemeyecek kadar zor olmasına dayanır. Bugün kullandığımız birçok şifreleme sistemi, saldırganın devasa sayıları çarpanlarına ayırmasının ya da ayrık logaritma gibi problemlerde boğulmasının çok uzun süreceğini varsayar. Bu kötü bir varsayım değildir; modern dünyanın omurgasını taşır. Fakat kuantum bilgisayarlar sahneye çıktığında bu omurganın bazı kemikleri çatırdayabilir. Shor algoritması gibi yöntemler, bugün güvenli sandığımız bazı sistemleri gelecekte savunmasız bırakabilir.

QKD burada başka bir kapı açar. Şifreyi doğrudan kuantumla yazmaz; asıl yaptığı şey, iki taraf arasında gizli bir anahtarın güvenli biçimde paylaşılmasını sağlamaktır. Alice ve Bob adlı klasik kahramanlarımızı düşünelim. Alice, Bob’a tek tek fotonlar gönderir. Bu fotonların polarizasyon gibi ölçülebilir kuantum özellikleri vardır. Araya Eve adlı meraklı bir dinleyici girip fotonları ölçmeye kalkarsa, kuantum mekaniğinin ölçüm ilkesi devreye girer: Ölçmek, sistemi değiştirir. Eve yalnızca bakmış olmakla bile iz bırakır.

Gizliliğin fiziği

QKD’nin en meşhur protokollerinden biri BB84’tür. Bu protokolde Alice, fotonları farklı bazlarda kodlar; Bob da rastgele bazlarda ölçer. Daha sonra açık bir kanaldan hangi bazları kullandıklarını karşılaştırırlar, fakat ölçüm sonuçlarının kendisini açıklamazlar. Bazların uyuştuğu durumlar, ham anahtarın parçası olur. Eğer bir dinleyici varsa, ölçüm hataları artar. Yani sistem, yalnızca mesaj iletmez; aynı zamanda kendisine dokunulup dokunulmadığını da sınar. Bu, kriptografide neredeyse şiirsel bir fikirdir: Bir sırrı çalmak isteyen kişi, sırrın dokusunu bozmak zorundadır.

Elbette burada dikkatli olmak gerekir. QKD, tek başına her şeyi sihirli biçimde çözen bir güvenlik muskası değildir. Mutlak güvenlik iddiası, ideal fiziksel varsayımlar altında ve doğru kullanımla anlam kazanır. Paylaşılan anahtar, örneğin tek kullanımlık şerit yöntemiyle kullanılırsa bilgi kuramsal güvenlik elde edilebilir. Fakat gerçek cihazlar kusurludur. Dedektörler kandırılabilir, ışık kaynakları sızdırabilir, yazılım hataları yapılabilir, kullanıcılar aceleci davranabilir. Evrenin kanunları sağlam olabilir; ama laboratuvardaki kablo gevşekse saldırgan kapıyı oradan aralar.

Bu yüzden QKD’yi anlamanın en sağlıklı yolu onu bir mucize değil, güvenlik mimarisinde çok güçlü bir katman olarak görmektir. Fiber optik hatlar üzerinden çalışan sistemler, şehirler arası kuantum ağları, uydularla yapılan deneyler ve kuantum internet vizyonu bu alanı giderek somutlaştırıyor. Çin’in Micius uydusu gibi örnekler, kuantum anahtar dağıtımının yalnızca teorik bir oyuncak olmadığını gösterdi. Bankalar, devlet kurumları ve kritik altyapılar için uzun vadeli gizlilik ihtiyacı arttıkça, QKD daha cazip hale geliyor.

Yine de soru şudur: Kırılamaz şifre gerçekten mümkün mü? Cevap, hem evet hem hayır. Evet, çünkü kuantum mekaniği bize anahtar dağıtımında klasik yöntemlerin veremediği türden bir güvenlik garantisi sunar. Hayır, çünkü güvenlik hiçbir zaman tek bir teknolojiye indirgenemez. En güçlü kuantum hattının ucunda zayıf bir parola, kötü yapılandırılmış bir sunucu ya da dikkatsiz bir insan varsa, doğa kanunları bile sosyal mühendislik karşısında utanarak susar.

QKD’nin asıl büyüsü, insanlığın güvenliği hesaplama gücünün ötesine taşıma cesaretidir. Artık sır saklamak için yalnızca matematiğe değil, fotonların kırılgan dansına da güveniyoruz. Bu dans bize şunu fısıldar: Bazı kapılar daha kalın kilitlerle değil, bakıldığı anda değişen gerçekliklerle korunur. Ve belki de geleceğin en iyi şifresi, evrenin kendisine sorulmuş doğru bir sorudan başka bir şey değildir.

Singleton Patron, Observer Komşu: Yazılım Desenleriyle Toplumun Gizli Tiyatrosu

Yazılım tasarım desenleri ilk bakışta soğuk bir mühendislik sözlüğü gibi görünür: Singleton, Observer, Factory, Adapter… Oysa biraz yaklaşınca bu desenlerin sadece kodu değil, toplumu da tarif ettiğini fark ederiz. Çünkü insan kalabalıkları da tıpkı büyük yazılım sistemleri gibi karmaşıktır; tekrar eden problemler üretir, bu problemlere pratik çözümler bulur ve sonra bu çözümleri gelenek, rol, unvan ya da karakter diye paketler. Mahalledeki her şeyi bilen teyze ile bir olay olduğunda anında haberdar olan Observer deseni arasında sandığımızdan az mesafe vardır.

Design pattern dediğimiz şey, aynı türden problemlere defalarca verilmiş sınanmış cevaptır. Kod dünyasında bu, geliştiricinin her seferinde sıfırdan kahramanlık yapmasını engeller. Toplumda da roller benzer bir iş görür. Öğretmen, arabulucu, asi genç, bilge ihtiyar, düzen koruyucu, girişimci, günah keçisi… Bunların her biri sosyal sistemin tekrar eden gerilimlerine verilmiş kalıplaşmış çözümlerdir. Klişe olmaları onları değersiz yapmaz; tam tersine, klişe dediğimiz şey çoğu zaman kültürel hafızanın önbelleğidir.

Singleton: Tek Adam, Tek Kapı, Tek Hakikat

Singleton deseni, bir sınıftan yalnızca bir örnek üretilmesini garanti eder. Yazılımda bazen gereklidir: merkezi yapılandırma, log sistemi, kaynak yönetimi. Toplumdaki karşılığı ise daha tehlikelidir: her şeyi bilen tek lider, tek uzman, tek ağabey, tek kanaat önderi. Bir ailede herkesin son sözüne baktığı kişi, bir ofiste bütün kararların önünde düğümlendiği yönetici, bir toplulukta gerçeğin tek distribütörü olan figür… Singleton sosyal hayatta pratiklik sağlar ama bağımlılık üretir. Sistem hızlı karar alır; fakat o tek nesne bozulursa, bütün mimari titrer.

Observer deseninde bir nesnenin durumu değiştiğinde ona bağlı gözlemciler haberdar edilir. Sosyal medyayı düşünün: biri ilişki durumunu değiştirir, yüzlerce Observer tetiklenir. Mahalle kültürü de eski usul bir event-driven mimaridir. Perdeler aralanır, balkonlar subscribe olur, haber yayılır. Observer sağlıklıdır; çünkü sistemin çevresel farkındalığını artırır. Ama aşırı kullanıldığında paranoyak bir toplum üretir: herkes herkesin olay dinleyicisidir, kimse kendi iç sürecinde yalnız kalamaz. Bildirim çağında insan, kendi ruhunun bile push notification alıcısına dönüşür.

Factory deseni, nesne üretimini merkezileştirir ve soyutlar. Toplumda bunun karşılığı kurumlar ve ritüellerdir. Okullar öğrenci üretmez sadece; vatandaş, uzman, itaatkâr, muhalif, başarılı çocuk gibi sosyal nesneler üretir. Aileler, şirketler, tarikatlar, üniversiteler ve algoritmalar birer Factory gibi çalışır. Hangi girdiden hangi rolün çıkacağını belirleyen görünmez kalıpları vardır. Burada soru şudur: Bizi kim instantiate ediyor? Kendi kurucumuz biz miyiz, yoksa başkalarının sınıf şemasından türetilmiş birer nesne miyiz?

Adapter deseni iki uyumsuz arayüzü konuşturur. Toplumun Adapter karakterleri tercümanlardır: kuşaklar arasında köprü olan çocuk, mühendisle müşteri arasında sıkışan ürün yöneticisi, aileyle modern hayat arasında arabuluculuk yapan genç kadın, akademiyle halk arasında dil kuran popüler bilimci. Adapter görünmez emek harcar. Herkes anlaşmayı doğal sanır, oysa arada biri protokol çevirisi yapıyordur. Bu rol yorucudur; çünkü Adapter hem kaynak sistemin hem hedef sistemin hatasını üstlenir. Yine de medeniyet dediğimiz şey, büyük ölçüde iyi yazılmış adaptörlerden oluşur.

Decorator deseni bir nesneye davranış ekler; onu kökten değiştirmez, katmanlandırır. Sosyal hayatta unvanlar, kıyafetler, diplomalar, biyografiler ve marka kimlikleri birer Decorator’dır. İnsan aynı insandır, ama üzerine profesörlük, CEO’luk, sanatçılık, aktivistlik, influencer’lık sarılır. Sorun, dekorasyonun özü yutmasıdır. Kodda aşırı Decorator okunabilirliği bozar; hayatta aşırı imaj da karakteri belirsizleştirir. Bir noktadan sonra karşımızdaki kişinin kim olduğunu değil, hangi katmanları taşıdığını görürüz.

Strategy deseni, davranışı koşullara göre değiştirilebilir hale getirir. Bu, sağlıklı yetişkinliğin yazılımsal metaforudur. Her durumda aynı tepkiyi veren insan kırılgandır; bağırmak, susmak, kaçmak ya da memnun etmek tek stratejiyse sistem kolay tahmin edilir ve kolay sömürülür. Bilge kişi içinde çoklu Strategy barındırır: gerektiğinde savaşır, gerektiğinde geri çekilir, gerektiğinde pazarlık eder, gerektiğinde bekler. Jungiyen dille söylersek, olgun benlik tek bir persona’ya hapsolmaz; gölgesiyle, kahramanıyla, bilgesiyle ve soytarısıyla temas kurar.

Bu benzetmelerin büyüsü şurada: Tasarım desenleri bize klişelerden utanmamayı, ama onlara teslim olmamayı öğretir. Kötü yazılımcı deseni ezbere uygular; iyi yazılımcı bağlamı okur. Kötü toplum da insanları hazır rollere hapseder; iyi toplum rollerin geçici, geçirgen ve dönüştürülebilir olduğunu bilir. Belki de en büyük mesele şudur: Kendi hayatımızın kod tabanında hangi desenleri miras aldık, hangilerini bilinçle kullandık, hangileri artık teknik borca dönüştü? İnsan, bazen refactor edilmesi gereken bir mimaridir.

Ölü Kod Mezarlığı: Sistemi Yavaşlatan Hayalet İnançlar

Her yazılım sisteminin bodrum katında bir mezarlık vardır. Orada artık çalışmayan fonksiyonlar, yıllar önce terk edilmiş koşullar, kimsenin çağırmadığı sınıflar ve üstüne not düşülmüş kadim büyüler uyur: sakın silme, bir gün lazım olabilir. Ölü kod tam olarak budur; programın yaşayan akışına katkısı olmayan ama depoda yer kaplayan, zihni meşgul eden, bakım maliyetini artıran eski parçalar. İlginç olan şu: Ölü kod teknik bir mesele gibi görünür, ama çoğu zaman psikolojik bir arızanın izidir. Kod çalışmaz; korku çalışır.

Bir ekip düşünün. Beş yıl önce yazılmış bir ödeme modülünün içinde devasa bir if bloğu duruyor. Artık hiçbir müşteri o yolu kullanmıyor, dokümantasyon onu anmıyor, testler ona uğramıyor. Ama biri silmeyi önerdiğinde odada sessizlik oluşuyor. Çünkü kodun kendisinden çok, onun etrafındaki efsane yaşıyor: Eski CTO bunu yazmıştı. Büyük bir müşteride sorun çıkarmıştı. Bir ara kampanya döneminde hayat kurtarmıştı. İşte yazılımda ölü kod, çoğu zaman eski bir savaşın madalyasıdır; paslanmıştır ama kimse duvardan indirmeye cesaret edemez.

Ölü kod neden tehlikelidir?

Çünkü yazılım yalnızca işlemciye verilen talimatlardan oluşmaz; aynı zamanda geliştiricinin zihninde kurduğu modeldir. Sistemde gereksiz kod ne kadar artarsa, bu model o kadar bulanıklaşır. Yeni gelen geliştirici şunu sorar: Bu fonksiyon hâlâ kullanılıyor mu? Bu parametre niye var? Bu hata yakalama bloğu hangi senaryo için? Cevap yoksa, kod artık bilgi değil gürültüdür. Gürültü de karar vermeyi yavaşlatır. Yavaş karar veren ekip, hızlı bozulan sistem üretir.

Ölü kodun maliyeti yalnızca satır sayısı değildir. Derleme süresini uzatabilir, statik analizleri kirletebilir, güvenlik taramalarında yanlış alarm üretebilir, test kapsamını sahte şekilde yükseltebilir. Daha kötüsü, yeni bir özellik geliştirirken yanlış referans noktası sunar. Geliştirici, yaşayan mimariyi değil, fosilleşmiş bir çözümü taklit eder. Böylece ölü kod çoğalır; mezarlık, şehir planına dönüşür.

Burada en kritik ayrım şudur: Eski kod ölü kod demek değildir. Legacy kod, hâlâ değer üretiyorsa yaşlı ama canlıdır. Ölü kod ise artık sistem davranışının parçası olmayan koddur. Onu kutsal yapan yaşlılığı değil, belirsizliğidir. Belirsizlik arttıkça insanlar silmek yerine dokunmamayı seçer. Dokunmamak güvenli görünür, ama uzun vadede en pahalı stratejilerden biridir.

Silmek bir vandalizm değil, bakım disiplinidir

Ölü kodla mücadele romantik cesaretle değil, yöntemle yapılır. Önce kullanım izleri aranır: çağrı grafikleri, loglar, feature flag kayıtları, telemetri, testler, sürüm geçmişi. Kod gerçekten çalışmıyorsa, onu yorum satırına almak çözüm değildir; bu sadece cesedi salona taşımaktır. Versiyon kontrol sistemi zaten hafızadır. Git varsa, mezar taşı olarak yorum satırı bırakmaya gerek yoktur.

İyi bir temizlik süreci küçük ve geri döndürülebilir adımlarla ilerler. Önce şüpheli alan işaretlenir, ardından gözlem süresi tanımlanır. Kullanım yoksa testler güncellenir, bağımlılıklar kaldırılır, kod silinir. Pull request açıklamasında neden silindiği net yazılır. Böylece silme eylemi kişisel bir saldırı değil, izlenebilir bir mühendislik kararı olur. Ölü kodu silmek, geçmişteki geliştiriciyi küçümsemek değildir; onun bir zamanlar çözdüğü problemin artık var olmadığını kabul etmektir.

Bu konu yazılımın dışına da sızar. Kurumların süreçlerinde, ekiplerin alışkanlıklarında, bireylerin düşüncelerinde de ölü kod vardır. Bir zamanlar işe yarayan ama artık sadece refleks olarak sürdürülen kurallar. Kimsenin okumadığı raporlar. Her toplantıda tekrarlanan ama karar üretmeyen cümleler. Eski bir başarının gölgesinde yaşayan inançlar. Yazılım bize acımasız bir ayna tutar: Çalışmayan şeyi sistemde tutarsan, sistem sonunda ona benzemeye başlar.

En sağlıklı kod tabanları, en çok kod yazılanlar değil, gereksiz kodun düzenli olarak eksiltildiği yerlerdir. Çünkü iyi mühendislik eklemek kadar çıkarmayı da bilmektir. Bir satırı silmek bazen yüz satır yazmaktan daha yüksek zekâ ister. Ölü kodun fısıltısı hep aynıdır: Ya lazım olursam? Usta geliştiricinin cevabı ise sakindir: Lazım olursan geçmişten geri çağırırım; bugün yaşamıyorsan, üretimde yerin yok.