Ö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.

Eski Hataların Yeni Sürümleri: Kodda Geçmişi Taşımanın Laneti

Geriye dönük uyumluluk, yazılım dünyasının en kibar görünümlü hayaletlerinden biridir. Dışarıdan bakınca olgunluk, güvenilirlik ve kullanıcıya saygı gibi görünür. İçeriden bakınca ise bazen kırık bir sandalyeyi müzede sergilemek değil, hâlâ toplantı odasında kullanmak zorunda kalmaktır. Bir zamanlar aceleyle yazılmış, kimsenin tam anlamadığı, fakat milyonlarca sistemin üzerine bina edildiği bir karar; yıllar sonra mimarinin kutsal taşı haline gelir. Çünkü onu kaldırırsanız sadece bir fonksiyonu değil, bir ekosistemi düşürürsünüz.

Programlamada geriye dönük uyumluluk şu basit vaadi verir: Dün çalışan şey bugün de çalışacak. Bu vaat, kullanıcı için huzurdur; geliştirici içinse omuzlara asılmış görünmez bir çuval. İçinde eski API kararları, yanlış isimlendirilmiş parametreler, tuhaf varsayılan değerler, mantıksız veri formatları ve birinin 2009’da cuma akşamı saat 17.43’te yaptığı küçük bir kestirme vardır. O kestirme artık ürünün anayasasına dönüşmüştür.

Hatanın Kültüre Dönüşmesi

Bir bug tek başına teknik bir olaydır; ama yıllarca korunursa kültür olur. Yazılım tarihindeki pek çok gariplik bu yüzden yaşamaya devam eder. Bir alanın adı yanlış yazılmıştır ama düzeltilemez, çünkü müşterinin entegrasyonu ona bağlıdır. Bir fonksiyon mantıksız sonuç döndürür ama değiştirilemez, çünkü bazı sistemler o mantıksızlığa göre davranmayı öğrenmiştir. Hata artık hata değildir; protokoldür. Tıpkı eski bir şehirde yanlış açılmış bir yolun zamanla ana caddeye dönüşmesi gibi.

Burada problem yalnızca teknik borç değildir. Teknik borç, ödenebilir bir borçtur; faizini hesaplar, taksit planı yaparsınız. Geriye dönük uyumluluk ise bazen miras hukukuna benzer: Borcu siz yapmadınız ama tapu sizin üzerinize geçti. Üstelik alacaklılar da haklıdır. Kullanıcı çalışır sistemi sever. Şirket kırılmayan sözleşmeleri sever. Ekosistem istikrar ister. Geliştirici ise temiz, zarif, akılcı bir tasarım hayal eder. İşte çatışma burada başlar: Estetik ile sadakat, doğruluk ile süreklilik, gelecek ile geçmiş aynı kod tabanında kavga eder.

Kırmadan Yenilemenin Sanatı

İyi mühendislik, her şeyi yıkıp yeniden yapmak değildir. Bu, bazen genç geliştiricinin romantik yanılgısıdır. Eski kodu görünce kılıcı çeker: Bunu komple atalım. Fakat gerçek sistemler laboratuvar faresi değildir; canlı organizmadır. İçlerinde müşteriler, veri akışları, alışkanlıklar, sözleşmeler, raporlar, otomasyonlar ve kimsenin dokunmaya cesaret edemediği cron işleri yaşar. Bir şeyi değiştirmek istiyorsanız önce onu kimin neden kullandığını anlamalısınız.

Bu yüzden geriye dönük uyumluluk, disiplin ister. Versiyonlama, açık kullanım dışı bırakma politikaları, geçiş rehberleri, uyarı mekanizmaları, adaptör katmanları ve ölçümleme şarttır. Bir API değiştirilecekse önce eski davranış gözlemlenir. Kim kullanıyor, nasıl kullanıyor, ne kadar kritik kullanıyor? Sonra yeni yol sunulur. Eski yol hemen yakılmaz; üzerine tabela asılır: Bu köprü yaşlandı, lütfen yeni köprüyü kullanın. En sonunda, yeterince zaman ve iletişimden sonra kapatılır. Medeni yazılım budur.

Fakat her şeyi sonsuza dek uyumlu tutmak da erdem değildir. Bazen geriye dönük uyumluluk adı altında sistemin geleceğini rehin alırız. Kimse kırılmasın diye her garip davranışı koruruz; sonra yeni özellik eklemek mayın tarlasında bale yapmaya döner. Kod, geçmiş kullanıcıların anıt mezarlığına dönüşür. Her satırın başında şu yazılıdır: Buraya dokunma, biri bir yerde ağlayabilir.

Cesaret ve Nezaket Dengesi

Sağlıklı yaklaşım iki uçtan da kaçınır. Ne geçmişi kutsallaştırmak gerekir ne de geçmişe savaş açmak. Geriye dönük uyumluluk bir ahlaki sorumluluktur; ama sonsuz itaat yemini değildir. Kullanıcının güvenini korumak önemlidir, fakat sistemin evrim hakkı da vardır. Eski hatayı taşımak bazen merhamettir, bazen korkaklık. Aradaki farkı ölçen şey niyet değil, plandır.

Bir yazılım ekibi kendine şu soruları sormalıdır: Bu uyumluluk kime hizmet ediyor? Eski davranışı korumanın maliyeti nedir? Yeni tasarım gerçekten daha mı iyi, yoksa sadece daha mı yeni? Kullanıcıya geçiş için yeterli araç verdik mi? Kırılma kaçınılmazsa bunu dürüstçe duyurduk mu? Bu sorular cevaplanmadan yapılan her devrim, prod ortamında patlayan bir havai fişektir.

Sonuçta geriye dönük uyumluluk, kodun hafızasıdır. Hafıza olmadan kimlik olmaz; ama travmayı sonsuza dek tekrar etmek de iyileşme değildir. Usta geliştirici, geçmişin hatasını inkâr etmez; onu belgeler, sınırlar, izole eder ve mümkünse onurlu bir emekliliğe gönderir. Çünkü iyi yazılım yalnızca çalışmakla kalmaz; zaman içinde yaşlanmayı da bilir. Asıl mesele, geçmişin kamburunu geleceğin omurgası sanmamaktır.

Tekerleği Yeniden İcat Etmeyenlerin Gizli Süper Gücü

Bir programcı bazen kendini yalnız bir dağcı sanır: Önünde buzlu bir problem yamacı, elinde klavye kazması, arkada kahveyle çalışan küçük bir kamp ateşi. Oysa çoğu zaman çıktığı dağ, binlerce kişinin daha önce tırmandığı, rotaları çizilmiş, riskli geçitleri işaretlenmiş bir dağdır. Kod kütüphaneleri tam da bu yüzden büyüleyicidir: Yalnız olmadığımızı, hatta yalnız başlamamız gerekmediğini hatırlatırlar.

Kütüphane dediğimiz şey, sadece bir dosya yığını ya da indirilebilir paket değildir. Bir kod kütüphanesi, önceki nesillerin uğraştığı hataların, denediği çözümlerin, yaptığı yanlışların ve sonunda bulduğu daha iyi yolların damıtılmış hâlidir. Matematikte teorem neyse, yazılımda iyi tasarlanmış bir kütüphane de odur: Tekrar tekrar kanıtlanması gerekmeyen, üzerine yeni düşünceler inşa edebileceğimiz güvenilir bir basamak.

Yeniden Keşfetmemenin Hafifliği

Bir tarih işleme kütüphanesi kullanmak, takvimlerin insanlık tarihinde ne kadar tuhaf olduğuyla yeniden boğuşmamak demektir. Artık yıllar, zaman dilimleri, yaz saati uygulamaları, milisaniyeler ve ülkelere göre değişen kurallar… Bunları sıfırdan yazmaya kalkışan her geliştirici, kısa süre sonra bilgisayar biliminin aslında biraz da bürokrasiyle güreşmek olduğunu fark eder. Benzer şekilde bir şifreleme algoritmasını kendi başına yazmak çoğu zaman cesaret değil, tehlikeli bir özgüvendir. Çünkü bazı sorunlar yalnızca zor değildir; yanlış çözüldüğünde felaket üretir.

Burada önemli ayrım şudur: Kütüphane kullanmak tembellik değildir; doğru tembelliktir. Programlamada iyi tembellik, gereksiz tekrarları ortadan kaldırır ve zihinsel enerjiyi asıl probleme ayırır. Eğer bir web uygulaması geliştiriyorsanız, her defasında HTTP protokolünü elle işlemek, form verilerini sıfırdan ayrıştırmak, güvenlik başlıklarını ezbere kurmak sizi kahraman yapmaz. Sizi yorgun, hataya açık ve muhtemelen teslim tarihini kaçırmış biri yapar. Kütüphane, enerjinizi altyapı çukuruna değil, ürünün değer yaratan kısmına yönlendirir.

Fakat bu hafifliğin bir gölgesi de vardır. Kütüphaneler kültürel miras olduğu kadar kültürel bağımlılıktır. Ne kullandığını bilmeyen geliştirici, hazır çözümlerden oluşan parlak bir labirentte kaybolabilir. Bir paketi projeye eklemek kolaydır; onun hangi varsayımlarla çalıştığını, hangi güvenlik açıklarına sahip olabileceğini, bakımının sürüp sürmediğini anlamak ise zanaatkârlık ister. Modern yazılım dünyasında bir satır kod yazmadan yüzlerce bağımlılığı içeri almak mümkündür. Bu, uygarlığın konforu kadar kırılganlığını da gösterir: Bir tuğla yerinden oynarsa, bazen bütün bina öksürür.

Bu yüzden olgun yaklaşım ne her şeyi sıfırdan yazmak ne de her problemi ilk gördüğümüz paketle örtmektir. Sistemli düşünmek gerekir. Önce problemi tanımla: Gerçekten genel bir çözüm mü gerekiyor, yoksa küçük ve yerel bir iş mi? Sonra maliyeti hesapla: Kütüphane öğrenme yükü, performans etkisi, lisans şartları, bakım durumu ve topluluk desteği nedir? Ardından sınırları belirle: Bu kütüphane sistemin hangi katmanına girecek, ne kadar vazgeçilmez hâle gelecek, yarın değiştirmek gerekirse ne kadar acı verecek?

Kod kütüphaneleri, yazılımın kültürel mirasıdır çünkü bilgiyi yalnızca saklamaz, çalıştırır. Bir müzedeki eser gibi cam fanusta durmaz; derlenir, çağrılır, test edilir, çatallar, güncellenir, bazen de sessizce terk edilir. Her fonksiyon, küçük bir toplumsal anlaşmadır: Biri bu sorunu düşündü, çözdü, paylaştı; sen de bunu kullanarak daha ileri git. Böyle bakınca açık kaynak ekosistemi, dijital çağın İskenderiye Kütüphanesi gibidir; tek farkı, raflara dokunduğunuzda rafların da size dokunmasıdır.

Sonuçta iyi geliştirici, tekerleği yeniden icat etmeyen ama tekerleğin nasıl döndüğünü merak eden kişidir. Kütüphaneler bize dayanılmaz bir hafiflik sunar: Geçmişin yükünü sırtımızda taşımadan onun üzerine basabilmek. Fakat bu hafiflik bilinç ister. Çünkü miras, yalnızca tüketilecek bir konfor değil; anlaşılacak, korunacak ve gerektiğinde daha iyisine dönüştürülecek bir sorumluluktur.

Sınıf Babadan Kalır mı? OOP Mirası, Genetik ve Kuşak Çatışmasının Kod Hali

Bir yazılımcı için inheritance, yani miras, kulağa neredeyse aile toplantısı gibi gelir: Bir üst sınıf vardır, çocuk sınıflar vardır, herkes bir şeyler devralır, bazıları memnundur, bazıları ise içinden sessizce refactor etmek ister. Genetikte de tablo çok farklı değildir. Göz renginden metabolizmaya, yatkınlıklardan davranış örüntülerine kadar biyolojik kodlar kuşaktan kuşağa aktarılır. Fakat mesele yalnızca aktarım değildir; asıl hikâye, devralınan şeyle ne yapıldığıdır.

OOP’de bir sınıf başka bir sınıftan türediğinde, üst sınıfın özelliklerini ve davranışlarını alır. Diyelim ki bir Canli sınıfımız var: solunum yapar, beslenir, çoğalır. Bundan Memeli sınıfı türetiriz; sonra Insan. Kodda bu pratik görünür. Aynı mantık biyolojide de vardır: Önce ortak özellikler, sonra özelleşmeler. Fakat işin dramatik kısmı burada başlar. Çünkü her çocuk sınıf, üst sınıfın her davranışını aynen taşımak zorunda değildir. Override eder. Yani der ki: Bunu senden aldım ama böyle kullanmayacağım.

Kuşak çatışması bir override problemidir

Anne babanın çocuğuna devrettiği şey yalnızca genetik değildir; alışkanlıklar, korkular, ekonomik refleksler, sevme biçimleri, susma teknikleri ve öfke protokolleri de aktarılır. OOP diliyle söylersek, aile bir base class gibi çalışır. Çocuk ise ondan türeyen ama kendi runtime koşullarında çalışan yeni bir sınıftır. Sorun, üst sınıfın kendi metodlarının evrensel olduğunu sanmasıyla çıkar. Baba sınıfı şöyle der: calis() metodu böyle yazılır. Anne sınıfı ekler: guvendeKal() metodu asla değiştirilmez. Çocuk sınıf ise çağın API’larına bakar ve cevap verir: Bu sistem artık başka bağımlılıklarla çalışıyor.

Programlamada kötü miras tasarımı, bağımlılık cehennemi üretir. Bir alt sınıf, üst sınıfın gereksiz tüm yükünü taşımaya mecbur kalırsa esneklik kaybolur. Buna kırılgan temel sınıf problemi denir. Biyolojik ve kültürel düzeyde de benzeri yaşanır. İnsan, atalarından gelen kodları taşır; ama bütün kodlar bugünün dünyasında anlamlı değildir. Bir zamanlar hayatta kalmayı sağlayan aşırı tetikte olma hali, modern ofiste anksiyeteye dönüşebilir. Bir zamanlar kabileyi koruyan içe kapalılık, bugün iletişim krizine neden olabilir.

Burada önemli ayrım şudur: Miras kötüdür demek sığ bir sonuç olur. OOP’de inheritance doğru yerde kullanıldığında güçlüdür. Ortak davranışı tekrar yazmayı önler, sistemi anlaşılır kılar, soyutlamayı kuvvetlendirir. Genetik miras da böyledir. Bedenimiz milyonlarca yıllık başarılı denemelerin arşividir. Reflekslerimiz, bağışıklığımız, öğrenme kapasitemiz bu büyük kod tabanından gelir. Fakat hiçbir ciddi yazılımcı, eski kod çalışıyor diye ona dokunmama dogmasına tapmaz. Çalışan kod da incelenir, test edilir, gerekirse yeniden tasarlanır.

Kompozisyon mu, miras mı?

Modern yazılım tasarımında sıkça duyulan ilke şudur: Miras yerine kompozisyonu tercih et. Yani bir nesnenin ne olduğundan çok, hangi yetenekleri bir araya getirdiğine bak. Bu fikir kuşak çatışmasına da şaşırtıcı biçimde uyar. İnsan yalnızca ailesinin alt sınıfı değildir. Sadece soyadından, genlerinden, çocukluk klasöründen ibaret değildir. Okudukları, dostları, şehirleri, başarısızlıkları, terapileri, aşkları ve kayıplarıyla kendini besteler. Yani insan, inheritance ile başlar ama composition ile olgunlaşır.

Kuşaklar arasındaki çatışma çoğu zaman şu yanlış beklentiden doğar: Üst sınıf, alt sınıfın kendisini genişletmesini ister ama değiştirmesini istemez. Oysa polymorphism tam da değişik biçimlerde davranabilme gücüdür. Aynı aileden gelen iki çocuk, aynı yasam() metodunu bambaşka biçimde çalıştırabilir. Biri geleneksel rotayı seçer, diğeri radikal bir kariyer değişimi yapar. Biri şehirde kök salar, diğeri dünyayı gezer. Bu hata değil; sistemin çok biçimliliğidir.

Elbette her override özgürlük değildir. Bazen çocuk, ailesine karşı çıkıyorum sanırken yine aile kodunun tersinden çalışan bir versiyonudur. Babası gibi olmamak için aldığı her karar, hâlâ babayı merkez alan bir algoritmadır. Gerçek özgürlük, mirası inkâr etmek değil, onu okumaktır. Hangi metod bana ait, hangisi devralınmış? Hangi değişken hâlâ çocuklukta set edilmiş? Hangi exception her ilişkide tekrar fırlatılıyor? Kendini tanımak, kaynak kodu açıp korkmadan bakmaktır.

Sonuçta OOP ile genetik arasındaki benzetme bize şunu öğretir: Hiçbir sınıf boşluktan doğmaz, hiçbir insan da sıfırdan yazılmaz. Hepimiz bir kod tabanının devamıyız. Ama iyi haber şu: Devraldığımız her şey kader değildir. Bazı metodları override edebilir, bazı bağımlılıkları silebilir, bazılarını adapter ile dönüştürebiliriz. Kuşak çatışması da belki bir savaş değil, büyük bir refactoring sürecidir. Eski kodu aşağılamadan, yeni sistemi boğmadan, daha temiz, daha esnek ve daha insani bir mimari kurma çabası.

Reddi Miras

İnsanların kendi hayatları boyunca özel mülkiyet edinme hakları oluşuna katılıyorum; çünkü oyunu teşvik edici bir etkisi var. Ancak miras kavramına evvelden beri sıcak bakmıyorum ve yeni dünyada miras uygulamasının tıpkı evlilik kurumu gibi şu ana kadar bilindiği formatının değişime uğramasını istiyorum.
Sipiritüel çevrelerde rastladığım kadarıyla herkes karmik bağlardan kurtulmaya çok sıcak bakıyor, bunun birebir uzantısı olan mirastan kurtulma konusunu düşünen var mı diye merak ediyorum.
Bu konudaki fikirleriniz ve önerileriniz nelerdir frekanslarım?
Gerçekten reddi miras istiyor muyuz?
Bu konuda getirilebilecek reformlar nasıl olabilir?

  • YENİ’den DOĞAnlar Kulubü Miras 7 yaratılmışız 🙂 genetiğimiz bile miras..

    YENİ’den DOĞAnlar Kulubü

    Miras olan genetiğimizi kullandık yüzlerce yıldır!Şimdi ÖZgün olma zamanı.Ben,reddi mirası düşündüm.Daha doğrusu köklerimden ayrılma zamanı gelip çatınca,özellikle de bana bırakılacak olan 2 daire ile hayatımı kontrol etmeye,istediklerini yaptırmaya yoksa mirastan hak alamayacağımı söyleyen anne babama bunu belirttim de.İstemiyorum..bağışlayın bir hayır kurumuna dedim.Beni bAĞlayan hiç birşey istemiyorum:)Bu aralar arkadaşlarıma sık sık ‘homeless’ olmaya karar verdim diyorum.bir budist rahibin bir Velinin hafifliğini ve özgürlüğünü yaşamak istiyorum:)Katman katman soyulmak isteğim öyle baskın ve yoğun ki 🙂

    YENİ’den DOĞAnlar Kulubü Acaip Özgür ve Özgünüm:) Hiç kimse hiçbir şey bırakmadı bana. Abime bıraktılar. Babacığımın giderayak “ben bir hata yaptım kızım” demesiyle nasıl boynuna sarılıp onu susturduğumu ve teşekkür edip öptüğümü unutmam mümkün değil. Sevgiden başka miras yok;)

    YENİ’den DOĞAnlar Kulubü Sizce karmadan kurtulundu diye duyuru yapıp sevinenler, işin bu kısmını da düşünüyorlar mıdır?
  • YENİ’den DOĞAnlar Kulubü Benim Yeni dünyadaki miras düzenlemeleriyle ilgili fikrim şimdilik şöyle. Mirasın yasallığı ortadan kaldırılır. Ölen kişinin varlığı bu konuda oluşturulan bir fona aktarılır. Fon, doğrudan cumhurbaşkanına bağlı olur, ve en yüksek yargı organınca daimi olarak denetlenir. Söz konusu fonda biriken değerler fakir çocukların eğitim düzenlemeleri için kullanılır. Aslında bu işlemi toplumdaki ekonomik ve kültürel eşitsizliğin giderilmesi olarak görebiliriz. Burada çözülmesi gereken sonuç ise sermaye birikimi olmadığında serbest girişimin nasıl olacağı hakkında olmalıdır. Mirasın reddi, sermayenin de zaman içinde kuvvet kaybetmesini getirir. Bu konuda pek çok çare ileri sürülebilir, istendikten sonra her şey mümkün.
  • AsIlan A iyi bir öneri bence. sermaye birikmese de olur, çalışan ve patron yerine müşterek girişimler, ortalıklar olmalı

    Devraldığımız en büyük miras zaman bilinci, zaman algısı. O mirası tümüyle bırakıp şimdide varolmayı öğrenmedikçe diğer bütün yükleri de taşımaya devam ederiz.

    YENİ’den DOĞAnlar Kulubü yani kendi şu anda oluşturduğun karmalar olacak tabi fakat atalardan miras kalanlardan kurtulundu artık deniyordu pek çok yerde. Yeni enerjinin, zamanın bi hediyesi gibi sunuluyor. Neyse işin bu kısmını benden başka duyan olmamış buralarda, bunu geçelim 🙂 Miras meselesine bakalım.
    Ersin K Karma’dan kurtulmuş muyuz, bilmiyordum. Bence karma anlık oluşuyor, her şey anda olup bitiyor artık.
  • YENİ’den DOĞAnlar Kulubü yani kendi şu anda oluşturduğun karmalar olacak tabi fakat atalardan miras kalanlardan kurtulundu artık deniyordu pek çok yerde. Yeni enerjinin, zamanın bi hediyesi gibi sunuluyor. Neyse işin bu kısmını benden başka duyan olmamış buralarda, bunu geçelim 🙂 Miras meselesine bakalım.