Apaçiler… İmdat
Dün akşam metrobüs ile Altunizade’den eve dönüyordum. Boğaziçi köprüsünde 3 tane genç bindi. Yaşları 16-18 civarı. Hani şu facebook ta grubu bile olan meşhur apaçilerden. Toplam 5 dakika kadar yanyana seyahat etmek zorunda kaldım. İnanın gelecekle ilgili çok ciddi endişelere gark oldum. Bu apaçilerden bazıları ülkeyi yönetecek, bazıları çocuklarımızı okutacak, ne biliyim polis asker falan olup güvenliğimizi sağlayacaklar ha!
Vah ülkem vah!
Bu üç apaçiden biri kulağında kulaklıkla, kafası ileri geri, sağa sola sürekli hareket halinde seyahat ediyor. Arada sırada kulaklığın birini çıkarıp sırtı buna dönük olan arkadaşının kulağına sokuyor. 2-3 saniye sonra geri alıyor.
Bir ara arkadaşıyla arasında şöyle bi konuşma geçti.
A1 : Apaçi 1, A2 : Apaçi 2
A1: Kanka, az sonra benim mekanın üstünden geçicez.
A2: Neresi senin mekan kanka?
A1: Reina kanka. Bi hatunlar düşüyor ki sorma. (Sanırsın Reina’nın müdavimi.)
A2: Kanka sen para yapmışın o zaman, Reina falan.
A1: Yok be kanka. Cem abi götürdü sağolsun. Bende çevre geniş kanka. Çok sağlam çevre yaptım ben son yıllarda. (Lan 16 sın, bilemedin 17.)
A2: …
A1: Geçen bi öğle yemeğine gittik Reina’ya kanka. Bi hesap geldi. 850TL aq.
A2: Oha o kadar parayı nerden buldun kanka?
A1: Cem abiyle gittik kanka. Bende nerde o para? (Bu durumla ilgili argoda sağlam bir laf vardır ama…)
A2: Eee kanka. Nasıldı?
A1: Yaa iki balık yedik kanka. O kadar. Ama bi hatun vardı. Bi asılmışım hatuna kanka. Sonra bunun sevgilisi geldi hayvan gibi. Bi koydu bana. Sonra Cem abi girdi araya ben bi bıçak yedim bacaktan. (Hele bi otur soluklan yeğenim. Nooluyor lan. Reina’da balık yerken, birden bıçaklanmış. Bir de bunu anlatıyor.)
Derken M.köy’e geldik ve aktarma için ben indim. Sonra bütün akşam ve hala düşünüyorum. Bu tipler için grup kurulacak kadar çoğalmışlar. Kafasına sert jöleyi boşaltan kendini dünyanın en yakışıklı adamı sanıp acayip fotoğraflar falan çektiriyorlar.
Gerçekten sinirlerim oynadı. En sonunda düşündürtmeye düşündürtmeye düşünmeyi bilmeyen, bildiğini unutan bir gençlik yarattılar. İşte bu gençlikte 10 yıl içinde söz sahibi olabilecek yerlere gelecekler. Doktor olup bizi tedavi edecek, avukat olup davamızı savunacaklar falan. Çok korkuyorum.
Hiding vs Overriding
Geçen gün ofiste, aramızda yaptığımız teknik bir konuşmada Method Hiding ile Method Overriding arasında ne fark olduğu gündeme geldi. Zaman geçmiş herhalde pek hatırlayan olmadı. Ama içimizden de şöyle geçiyor; “bi farkı var ki Microsoft koymuş bunları” diye.
Şöyle bir onbeş dakikalık araştırma sonucunda hatırlayıverdik. Efendim şöyle:
Bilindiği gibi polymorphism diye birşey var oop de. Yani nesnelere “… gibi davranma” özelliği verebilme. Klasik oop örnekleri ile örneklemek istersek:
İki tane sınıfımız olsun, biri diğerinden türesin;
class Animal { public virtual void Walk() { Console.WriteLine("Animal is walking."); } } class Cat : Animal { public override void Walk() { Console.WriteLine("Cat is walking."); } }
Ve şimdi bu sınıflarımızı kullanalım:
static void Main(string[] args) { Animal animal = new Cat(); animal.Walk(); }
Alacağımız çıktı şöyle olacak tahmin ettiğiniz gibi:
Cat is walking.
Şimdi override edeceğimize methodu hide edelim bakalım dünyada neler değişiyor:
class Cat : Animal { public new void Walk() { Console.WriteLine("Cat is walking."); } }
Şimdiki çıktımız ise şöyle oluyor:
Animal is walking.
Soru : Neden?
Şöyle özetleyebiliriz; methodu override ettiğimiz zaman framework Animal tipinde (Cat tipinde değil) bir nesnenin Walk methodunu çağırırken, içindeki bir tablodan (tablo olduğunu düşünelim basitçe) bu method, bu nesnenin sınıfı tarafından override edilmiş mi diye bakar. Eğer override edilmiş ise Animal sınıfının Walk methodu yerine o methodu çalıştırır.
Eğer override edilmeyip hide edilmişse, o zaman o tabloda bu kayıt bulunmaz ve Animal sınıfının Walk methodunu çağırır. Sizin nesneniz aslında Cat sınıfının bir nesnesidir ancak Walk methodu Animal sınıfının Walk methodu oluverir.
Soru : Peki niye böyle birşey yapalım? Yani niye methodu hide edelim?
Bu sorunun cevabına geçmeden statik tip ve dinamik tip ayrımını bilmek gerekiyor. Şuradan bir göz atabilirsiniz.
OOP kurallarına ters bir durum olduğu malum. Ancak diyelim ki şöyle elzem bir durum söz konusu:
Benim nesnemin statik tipi Cat olacaksa Cat sınıfına yazılan Walk methodu, yok eğer statik tipi Animal olacaksa yani Cat nesnesi Animal gibi davranacaksa Animal sınıfındaki Walk methodu çalıştırılsın.
İşte böyle bir isteğimiz olursa -ki benim şimdiye kadar olmadı- method hiding burada yardımınıza yetişir.
VS Test Method Snippet
Test driven geliştirme yapmak, eğlenceli olduğu kadar uzun süren bi işlemdir malumunuz. Bu konu ile ilgili bir yazım olacaktı.
Önce test yazacaksınız, sonra testi geçirecek kodu yazacaksınız. Başka bir test yazıp asıl işi yapacak kodu yazmaya zorlarsınız kedinizi. Sonra duplicationları gidermek için refactor edersiniz. Bunları yaparken naming convention a dikkat edersiniz.
Derken ne oldu? Hepi topu 3 ile 5 i toplayıp 8 döndüren bir method yazdınız daha. Bu methodu yazabilmek için en az 4 test yazmış olmamız lazım. Yani sadece basit bir method için 4 test yazıyoruz ki, büyükçe bir projede bu sayı nerelere çıkar varın siz düşünün.
TDD yazıyorsak en çok yazılan şey doğal olarak testtir. Farkettim ki bizim Visual Studio içinde bu durumla ilgili bir snippet yok. Ben her test için şunu kendim yazmak zorundayım:
[Test] public void TestMethodTest() { Assert.Fail("Not implemented yet!"); }
Halbuki bir code snippet olsa ve biz 1-2 tuş ile bunu şak diye yazmış sayılsak diye düşünerek bir snippet yazdım. İtiraf etmeliyim ki “prop” snippettını referans alarak yazdım.
İndirmek isterseniz buyrun.
Bu dosyayı “My Documents\Visual Studio 2008\Code Snippets\Visual C#\[İstediğiniz bir folder]\” altına atabilirisiz.
Atatürk’ün Kehanetleri
Bu kitabı okuyalı aylar oluyor. Hakkında birşeyler yazıp yazmama konusunda takıldım biraz.
Öncelikle kitabı alırken beklentim şöyleydi;
Atatürk’ün gerek 1. Dünya Savaşı gerekse Kurtuluş Savaşı sırasında verdiği kritik kararlar ve bu kararların sebep olduğu durumlar.
Lakin kitabı okudukça açık söylemek gerekirse hayal kırıklığına uğradım. Atatürk’ün verdiği kararlardan ziyade bu kararları nasıl verdiği ile ilgili bilgi aktarmaya çalışmış. Dikkat edersek “çalışmış” dedim. Zira verdiği bilgiler genelde “Yüce Allah Atatürk’e bahşettiği ileriyi görme yeteneği sayesinde savaşı kazandırmıştır” düzeyinde.
Kitabın yazarı Ali Bektan tahmin ediyorum ki iyi niyetle birşeyler anlatmak istemiş ama olmamış. Ya da bende bir problem var.
Örnek vermek gerekirse:
-"Bir gün Erkani Harbiye Reisi bana o günkü raporlarini okudu.Basit raporlardi,her zamanki gibi…Yalniz bu raporlarlar içinde bir nokta dikkatimi çekti…"
Evet görünürde hiç bir sonuç çikartilamayacak bu rapordan Mustafa Kemal inanilmaz bir sonuç çikartmis ve çok degil bir veya iki gün sonra ingilizler’in büyük taaruzu baslamistir.
Mustafa Kemal’in o rapordan çıkardığı müthiş sonucu bilmiyoruz. Kitap bundan bahsetmiyor. Bir başka örnek:
İstanbul’un isgal edildigi günlerde,İstanbul’a dönen Mustafa Kemal düsman zirhlilarini Dolmabahçe önünde gördügü zaman üzüntüyle:
"Geldikleri gibi gidecekler.."
Daha sonrasini zaten biliyoruz.Sonuç olarak geldikleri gibi gittiler.
Bunu ben de biliyorum. Ben daha değerli bilgiler almak üzere kitabını okumaya karar vermişim. Atatürk’ün, artık herkesin malumu bir cümleyi söylediğini söylemiş olması bana yetersiz geldi.
Yine benim için önemli bir konu ise yazar tam olarak olmasa da biyografik bir yazı yazıyor. Yani kurgu değil, gerçekleri anlatıyor. En azından böyle zannedip kitabı okudum. Kitapta kaynakça bökümünün olmaması bu kitap yazılırken yeteri kadar konuya özen gösterilmemiş olduğunu düşündürtüyor.
C# 4.0 Yenilikleri – 2
.Net Framework ile çalışmaya başladığımdan beri en çok eğlendiğim, en keyifle kod yazdığım konu Reflection olmuştur.
Projeye eklenmemiş, referans edilmemiş kütüphaneleri kod ile, yazdığımız uygulamaya dahil edip, kullanabilmek bana çok eğlenceli gelir.
Ama uygulaması ve kodu biraz uğraştırıcı, bugfixing sancılı geçer. Çünkü çıkan hataların hepsi Runtime da çıkar. Compile time da Reflection ile ilgili hiç hata almazsınız. Debugging zordur, vs.
Gelelim yeniliğimize : Dynamic Lookup
Dynamic lookup ile reflection wraplenip daha kollay kullanılacak hale getirilmiş. Olmayan propertyleri set edip get ederek, Olmayan methodları çağırarak kodumuzu hızlı yazmamıza olanak sağlar. Bunlar için kendimize uygun ayrı bir kütüphane yazma derdinden bu sayede kurtulmuş oluyoruz.
Bir class yazdığımızı düşünelim:
class Article
{
public int ID { get; set; }
public string Header { get; set; }
public DateTime PublishDate { get; private set; }
public void Publish(DateTime publishDate)
{
PublishDate = publishDate;
}
}
Şimdi uygulamamıza bir de şu kodları ekleyelim:
static void Main(string[] args)
{
dynamic article = Activator.CreateInstance(typeof(Article));
article.ID = 1;
article.Header = "Lorem Ipsum";
article.Publish(DateTime.Today.AddDays(2));
Console.WriteLine(string.Format("ID : {0}, Header : {1}, PublishDate : {2}", article.ID, article.Header, article.PublishDate));
}
Kodu yazarken Intellisense sizi durumdan zaten haberdar ediyor ve uyarısını da yapmış oluyor aslında.
Peki bu ne demek istiyor dersek, “Buraya yazacağın şeyler runtime da çözülmeye çalışılacak.”. Çıkarmamız gereken sonuç : “C# Case sensitive dir. Ne yazdığımıza dikkat edelim, üzülmeyelim.”
article.ID = 1;
yerine
article.Id = 1;
yazalım bakalım neler olacak?
Yani Dynamic Lookup yaparken, Case Sensitive olması sebebiyle, kullanacağımız sınıfın özelliklerinin nasıl yazıldığını mutlaka biliyor olmalıyız.
C# 4.0 Yenilikleri – 1
Eski ASP ci ve VB 6.0 cı olarak “Optional” kelimesini kullandığım çok olmuştur. Ne işimize yarardı?
Function Add(ByVal firstOperand As Integer, Optional ByVal secondOperand = 0 As Integer) As Integer Add = firstOperand + secondOperand End Function
Add fonksiyonunu, ilk parametresini gönderip, ikinci parametresini göndermeyerek kullanabiliyorduk. Fonksiyonumuzda gelen ilk parametreyi, 0 ile toplayarak geri döndürüyordu.
C# ile bu özellikten mahrum kalmıştık. Çünkü “Optional” parametre özelliği yerine, “Method Overload” özelliği gelmişti. Peki bu neydi?
private int Add(int firstOperand)
{
return Add(firstOperand,0);
}
private int Add(int firstOperand, int secondOperand)
{
return firstOperand + secondOperand;
}
Bu C# methodları da ilk yazdığımız VB kodu gibi işimizi görüyordu. Ancak bir problem vardı. Yukarıdaki birbirini overload u olan iki methodu bir webservice e koymaya kalksak, aynı isimde iki method olması sebebiyle derlesek bile service reference olarak ekleyemiyorduk. Dolayısıyla aynı isimli iki methodun birinin simini değiştirmek zorunda kalıyorduk ki bu method overload kolaylığını elimizden alıyordu.
Şimdi ne oldu da bu makale el alındı. C# 4.0 da tıpkı VB de olduğu gibi “Optional” parametreli methodlar yazabiliyor ve bu methodları WebService de sorunsuz kullanabiliyoruz.
Buyrun;
Önce WebSevice imize methodumuzu yazalım:
[WebMethod]
public int Add(int firstOperand = 0, int secondOperand = 0)
{
return firstOperand + secondOperand;
}
Şimdi bu servisi kullanacak olan programımızda şu satırları yazalım:
static void Main(string[] args)
{
Service1SoapClient client = new Service1SoapClient();
Console.WriteLine(client.Add(new AddRequest { firstOperand = 1, secondOperand = 2 }).AddResult);
Console.WriteLine(client.Add(new AddRequest { firstOperand = 2 }).AddResult);
Console.WriteLine(client.Add(new AddRequest { secondOperand = 4 }).AddResult);
}
Servisimizdeki methodumuz optional parametreye sahip olduğu için bizden “Add” methodumuza geçmek üzere AddRequest nesnesi istiyor. Biz bu nesneyi oluştururken ister bir parametreyi ,ister ikisini birden, istersek te hiçbirini geçmeyerek servis üzerindeki “Add” methodumuzu çağırabiliyoruz.
Kodumuzu çalıştırdığımızda ise aşağıdaki gibi sonuçları görüyoruz.
Basit Tasarım
Yaklaşık 9 ay kadar önce Yenibiris.com’dan 3 arkadaş TDD eğitimi almıştık. Eğitimi artık bu alanda guru sayılan J.B.Rainsberger’den (Joe) aldık. Kendisi Kanada’lı bir yazılım geliştirme danışmanı. Yani şirketlerin yazılım geliştirme ekibine “O şöyle bir sorun yaratır, şu patterni kullan”, “Daha önce falanca yerde böyle birşey olmuştu, şöyle çözdük” gibi ahkamlar kesen bir insan.
Meslek, ilk bakışta “ukalalık”, “kendini beğenmişlik”, vs gibi düşünülse de böyle olmadığı açık. Ama bu düşünce yüzünden böyle bir meslek Türkiye’de yok. Zaten sektörün hali ortada. Bu konuyu geçelim. Gelelim konu başlığımıza.
Efendim eğitimin başlamasını müteakip Joe bize ilk şu listeyi yazdı:
Simple Design
- Passes tests
- Minimize duplication
- Maximize clarity
- Reduces size
- One thing at a time
Bu 5 madde uygulanırsa sonuç : Modüler tasarım.
Maddelere gelirsek:
- Passes test : TDD de testlerin geçmesi zaten işin temeli. Tasarımın %85 ini oluşturur ve Joe’ya göre (katılmamak elde değil) zamanla otonomik bir hale dönüşüyor. Yani, nasıl yürürken hangi ayağımızı ne zaman öne atacağımızı düşünmeden hareket edip kendi haline bırakıyorsak, zamanla yazılan testlerin geçmesini sağlamak ta aynı şekilde kendi haline bırakılır.
- Minimize duplication : Daha önce yazdığım Bu kod kokuyor isimli makalede bahsi geçmişti. Aynı kod projenizde birden çok kez geçiyorsa ki bu zaman zaman olur. Bunları refactor edip minimize etmeliyiz.
- Maximize clarity : Kodumuzda anlamsız değişkenler, açıklayıcı olmayan class ya da method isimleri bulunmamalı. Asla ve asla kodumuza comment yazmamalıyız. Comment yazılmış kod, açıklayıcı değildir. Kodumuzu öyle bir yazmalıyız ki commente ihtiyaç duymadan kod kendini anlatabilmeli.
- Reduce size : Bu madde 5 i içindeki en önemsiz. Ama aklımızın bir köşesinde bulunmalı. Ne kadar çok kod yazarsak maintenance yapılacak o kadar çok satır olacak demektir. Kodumuzu mümkün olduğunca kısa tutmakta fayda. Tabi bunu yaparken dozu iyi ayarlamalı, şokunu çıkarmamalıyız.
- One thing at a time : İşte bu 5 maddenin en zoru. Aslında olay şu. Her seferinde tek bir şey yapmalıyız. İhtiyacımız oldukça kod yazmalıyız. Aksi takdirde YAGNI olacaktır.
Tecrübeli fakat TDD kullanmayan yazılımcıların bu 5 maddede en çok sonuncusunda zorlandığını öğrendik Joe’dan (Eğitimdeki örneklemelerde bizzat ben) . Sebebi de yıllarca kompleks yapılar tasarlamışlar, Presentation Layer a bi textbox koymak için; bir yandan BL yazarken, diğer yandan DAL yazarak projeler geliştirmişler. Şimdi adama diyorsun ki “dur bakalım. önce falanca classın bilmemne fonksiyonunu yaz. Database ile ilgimiz yok!!!”
E doğal olarak, eğer gelişimden hoşlanmayan bir insansa, “uğraşamam ben bununla” diyerek kestirip atabiliyor.
TDD development aşaması uzun ve keyifli, maintenance ve bugfixing aşaması ise hemen hemen hiç yok diyebileceğim kadar kısa ve zahmetsiz oluyor. Bunu ekip olarak, son yazdığımız servisleri TDD ile yazarak yaşadık.
TDD yi seviyoruz.
Bu Kod Kokuyor
Bazen kendi yazdığımız ya da başkasının yazdığı kodu incelerken “bu işte bir terslik var” dediğimiz olur. En azından benim olur. O terslik nedir, o sırada bilmem ama vardır. Bunu hissederim.
İşte buna “Code Smell” diyoruz. Yani kokan kod.
Örnek 1:
return AllItems.Where(a => a.ArticleTypeID = 1);
İşte böyle bir kod gördüğümde ben biraz işkilleniyorum. Orada kendi kendine durmakta olan “1” beni rahatsız ediyor. Acaba o “1” ne anlama gelmekte? “1” yerine “2” dersem ne olur? Oraya yazılacak sayının bir üst limiti var mıdır acaba? Ve eğer düzeltilmezse her bu kodu gördüğümde zincirleme olarak bu sorular aklıma tekrar tekrar gelecektir. Kısacası bu kod “kokmaktadır”.
Kodu kokutan maddeleri şöyle sıralayabiliriz:
- Çoğaltılmış (duplicate) kod : Eğer birebir aynı şeyi yapan kod, projenizde birden çok defa geçiyorsa, kodunuz kokmaya başlamıştır.
- Çoğaltılmış Fonksiyon : Birbirlerine çok benzeyen, hatta aynı işi yapan birden fazla fonksiyonlarınız olabilir. Overload etmeyi denemelisiniz.
- Fazla uzun fonksyion : Code Complete der ki; “Eğer bir method 35 satırdan uzun sürüyorsa, methodu parçalara ayırmayı düşünmelisiniz”. Fazla uzun fonksiyonlar kodu kokutmak için birebirdir.
- Fazla uzun class : Yine Code Complete buyurmuştur ki; “Eğer bir class, 350 satırdan uzunsa, classı parçalamayı düşünmelisiniz.”
- Başka sınıfın işini yapmaya çalışan sınıf : Eğer yazdığınız bir class, başka bir class ın methodlarını çok sık kullanmaya başladıysa, belkide iki classı birlikte düşünmelisiniz.
- Başka sınıfın işine karışan sınıf : Eğer yazılmış bir class başka bir classın işine karışmaya başlamışsa. Kendisini ilgilendirmeyen işler yapmaya kalkıyorsa, kodunuz kokuyor dikkat!!!
- Türediği sınıftan gelen mirasları reddeden sınıf : Meşhur Canlı –> Hayvan örneğinde Hayvan, Canlı’dan gelen “NefesAl” methodunu override ediyor ve en sonunda “base.NefesAl();” demiyorsa dikkat etmek gerek. Canlı’nın ne yaptığını bilmeden bunu yapmamakta fayda var.
- Tembel Sınıf : Malumunuz çok az kullanılan sınıf. Az kullanıldığı için ya hiç sorun çıkarmaz, ya da çıkardığında sorunun nereden geldiğinin anlaşılması zor olabilir.
- Gereksiz kompleks yapı : Alt tarafı bir formdaki verileri database e kayıt edecek bir yapı için bşn satır kod, onlarca sınıf, vs yazarak pireyi deve yapmışsanız kodunuz kokuyordur.
Yukarıdaki liste Wikipedia’dan alınmıştır.
Bu örnekler çoğaltılabilir. Peki tek satırlık örneğimizde (Örnek 1) burnuma gelen kokunun sebebi nedir sizce? Elbette ki “1” in ne olduğunu anlamamam. Buradaki “1” e Magic Number diyoruz. Kodlarımızın içerisinde Magic Number bulunması kokuya sebep olur. Peki bu kokudan nasıl kurtuluruz. Hemen imdadımıza sabitlerimiz yani Constant larımız yetişiyor.
Örneğimizi şöyle değiştirirsek:
Örnek 2:
const int STANDART_ARTICLE_TYPEID = 1; return AllItems.Where(a => a.ArticleTypeID = STANDART_ARTICLE_TYPEID);
Böylece, bileceğim ki benim kodumun sonucunda her zaman “Standart Makale” tipindeki makaleler döner. Her bu kodu gördüğümde de bundan böyle “1” in ne olduğunu hatırlamak zorunda kalmayacağım.
Geçmiş olsun oğlum
Takip edenler okuyup üzülmesinler diye şimdi yazıyoruz. Geçen hafta (1 Ekim 2009) Ege 3’ lü bir operasyon geçirdi. Sibel, Ege’nin altını değiştirirken, kasığının sol yanında bir şişilik olduğunu farketmiş. Bana haber verdi ve doğal olarak endişelenip doktorumuz Özlem hanımı aradık. Özlem hanım bize, kasık fatığı olabileceğini, hemen bir çocuk cerrahına göstermemiz gerektiğini söyledi. Biz de vakit kaybetmeden en yakın hastaneye götürdük Ege’yi. Tabi bu olay bayramın 3. günü, Bilge amcası ve Didem teyzesini ziyaretimiz sırasında oluyor. Bu sebeple; hastanelerde bırakın cerrahı, neredeyse doktor yok. Cerrah bulamadığımız için, çocuk doktoru muayene etti ve el muayenesi ile çıkan fıtığı yerine yerleştirip, en kısa sürede çocuk cerrahına göstermelisiniz dedi.
Ertesi gün çocuk cerrahı araştırmaya başladık. Herkese yaydık, sağolsunlar herkes bir araştırmaya koyuldu. Akşama doğru Serkan amcası, Ege için bir doktordan randevu ayarladı ve bir sonraki gün biz Çapa’daki İstanbul Tıp Fakültesi’ nin yolunu tuttuk. Çocuk Cerrahisi Anabilim Dalı başkanı Prof. Dr. Alaaddin Çelik hoca ufak bir muayene ile kasık fıtığını onayladı ve hemen ameliyat olması gerektiğini söyleyerek 1 hafta sonrası için bize gün verdi.
İşte o bir hafta geçmedi. Ağlatmamak, huzursuz etmemek için neler yaptığımızı anlatamam. Meraklı babası ben fıtık ile ilgili bulduğu tüm kaynakları okuyup nelere dikkat edilmesi gerektiğinden, ameliyat videoların kadar, fıtığın yerine yerleştirilmesinden, fıtığın boğulmasına ve sonuçlarına kadar bir sürü kaynak okudu. (Fıtık boğulması kötü birşey bu arada, hemen belirmekte fayda var. Hayati tehlike oluşturuyor.) İşte bu sebeple babası gece uyuyamıyor. Her mıkırdanmada, her alt açışımızda uyanıp, fıtığı kontrol ediyor, şişme varmı, rengi mormu, vs. falan diye diye gözüne uyku girmiyor.
Doktorumuzun muayenesi sırasında sağ tarafta da hidrosel olduğu ortaya çıkmıştı. İleride kasık fıtığına çevirme ihtimali olduğunu öğrenmiştik. Ameliyatı yapacak hocamıza durumu söyleyince onu da kontrol ederiz demişti.
Bir hafta geçiyor, Çapa’ ya gidiyoruz. Ameliyat neticede. Korkuyoruz. Ege’yi aç bırakmamızı söylüyorlar öncesinde. Ama bebek bu, nasıl anlatacaksın durumu. Ağlıyor, meme arıyor falan. Emzikle de aramız hiç iyi değil. Sevmedi, sevemedi emziği. (Bu durum hoşuma gitmedi değil.) Ama ameliyata giderken, açlıktan olacak emzik var ağzında.
Ameliyat bir yıl kadar sürüyor. En azından bize öyle geldi. Meğer 1 saat sürmüş. Döndüğünde de giderken ki gibi geliyor. Sadece daha az neşeli. Çok şükür!!! Sağ tarafındaki hidroseli de düzeltip fıtık riskini mimize etmişler. Bir de sünnet olunca 3 lü bir operasyon geçirmiş oldu Ege’miz.
İlk gün neredeyse hiç uyanmıyor. Uyanıyor, emiyor, uyuyor. Narkozun ve verilen ağrı kesici/sakinleştirici etkisi ile olduğunu öğreniyoruz.
Haa bu arada, hazır narkoz almışken, sünnet te aradan çıkıversin diye düşünerek sünnetini de hallettiriyoruz.
İlk haftamız banyo yapamamamı sebebiyle zaman zaman huzursuz geçti. Onun dışında ne bir damla ağrı, ne bir başka problem. Pansuman falan da yok. Sadece 2 saatte bir falan altını değiştirdik ve her değişiklikte hastaneden verilen antispetik ten pipisine sıktık bir kaç damla. Tümü bu.
Ameliyat üzerinden 10 gün kadar geçti. Şükür hepsi geride kaldı. En kötüsü bu olsun diyoruz.
Bu badireyi de atlattıktan sonra yazılarımızı sıklaştırabileceğiz artık.
Ameliyat ile ilgili 1-2 fotoğraf: Ege’nin büyüdüğünde tepkisini çekmemek için bazı yerleri(!) mozaikledim. Kırmızı içindeki yerler, kasık fıtığı ameliyat izleri.
