sinan's personal blog about software, games and entrepreneurship

Hi, I'm Sinan Ermiş. Nice to meet you!

I am a game development specialist residing in Ankara, Turkey. Following several years of experience in the gaming industry, I am currently working on an unannounced project under the banner of my company, Holy Crab Games. Additionally, I am pursuing a bachelor's degree in computer science at Hacettepe University.

I would love to engage in conversations about any topic imaginable. Always feel free to reach me at:

Some of my blog posts


Bir Junior Developer’ın Gözünden Clean Code — Nedir, Nasıl Başa Çıkılır?

“Yazılım öğren yeenim, gelecek bilgisayarda. Bak bil geytse adam garajda başlayıp milyarder oldu” diyen mahalle berberini dinledik diyelim. Kendimize hedef olarak belki bir dil, belki bir alan, belki de bir platform belirledik, belirlediğimiz hedefte çalışmaya başladık. Aşamalar herkes için üç aşağı beş yukarı aynı. Ekrana “Hello World” yazdırdık, hızımızı alamayıp ekrana asal sayıları yazdıran program bile yazdık. Peki sonra?

Sonrasında basit projeler yapmak geliyor. Mobil uygulama geliştiriyorsan todo app, oyun geliştiriyorsan pong, front-end’ci isen kişisel web site vs. vs. Bunlar da bir şekilde halloluyor. Projeler bir tık daha büyüdüğünde kod git gide yönetmesi zor bir hal alıyor. “Bununla başa çıkmanın bir yolu olmalı” diye düşünürken internette bir kavram görüyor insan. “CLEAN CODE”. Kocaman harflerle hem de. Sonra merak ediyor nasıl bir şeymiş diye, azıcık araştırınca önüne ‘SOLID prensipleri’, ‘programlama kalıpları‘, ‘proje mimarisi’ gibi şeyler çıkıyor. “Deniz derya konular bunlar, neresinden girsem ki?” diye düşünürken sıkışıp kalmış hissediyor. En azından bende böyle oldu.


Kendimi tanıtayım. Merhaba, ben Sinan. İki sene önce -kazara- İTÜ’de el*ktronik mühendisliği öğrencisi oldum, olur olmaz Darth Vader’ın babası olduğunu taze öğrenmiş Luke gibi “NOOOOOOOOOOOO!” diye çığlık attım. Çünkü ben senelerdir yazılımcı olmak, oyun yapmak istiyordum. Ama yapacak bir şey yoktu, olan olmuştu, mecburen alaylı neferlerden biri olmak zorunday(d)ım. O zamandan beri (2 senedir) Unity ve C# ile oyun geliştiriyorum. Bu yazıda geçtiğimiz bu iki senede deneyimlediklerimle ve çıkarımlarımla alakalı bir şeyler anlatacağım. Bahsedeceklerim oldukça kişisel düşünceler olacak. Aksini düşündüğünüz kısımlar için yorum kısmına bekliyorum.

Luke Skywalker'ın NO diye bağırdığı bir GIF

Kanımca temiz kod yazmanın yolu ezberlenmiş SOLID kurallarını uygulamaktan veya programlama kalıplarını kullanmaktan geçmiyor, aksine temiz kod istemsizce buraya çıkıyor. Hangi işinin ehli yazılımcıyla konuşsam bu kuralları en son ne zaman kasten uyguladığını hatırlamadığını belirtti. Bu kurallar daha çok belli bir yerden sonra refleks haline geliyor, insan uyguladığını fark etmiyor. Bu düşünceye nasıl vardığıma gelelim.

İlk -diğerlerine nispetle- büyük oyunumu yapmak istediğimde bu kadar şeyi bir araya nasıl koyabilirim, bu kadar şey nasıl olur da birbirine girmez diye düşünmekten bir süre hiç yol alamadım. Araştırdığımda önüme ezberlenmesi gereken bir şeymiş gibi SOLID çıktı, “constant değişkenleri BOYLE_ISIMLENDIR, private olanların başına _ koy” gibisinden yine ezber bir isimlendirme listesi çıktı, “kardeşim o kodu yanlış yazıyorsun” diyen youtuber tayfası çıktı. Fobi gibi bir şey oldu sonunda: “ya kötü kod yazarsam” fobisi.

Bir şekilde o proje bitti, üzerine pek çok farklı proje bitti. Zaman içinde kötü kod yazarım fobim de geçti. Bu fobimi “game programming patterns” kitabını ezberlediğim için yenmedim. Evet kitabı okudum ama o kadar, her patterni öğreneyim diye bir çabam olmadı. Bana yardımcı olan şey kod yazarken düşünme biçimimi eğitmek oldu. Yazının kalanında koda nasıl yaklaştığıma değineceğim.


Planlamak vakit kaybı değildir.

Sapıklık seviyesine varmadığı sürece planlamak vakit kaybı değildir. Kodun hangi bölümüyle hangi bölümü beraber çalışacak, hangi bölümler birbirine doğrudan bağımlı olacak başta düşünmek daha sonraki pek çok angarya işi ortadan kaldırabilir. Tabi seviyesini iyi ayarlamak, plan yapacağım diye aylaklık yapılan saatlere girince çıkmasını bilmek lazım.

İşlevsel kod temiz koddan daha önemlidir.

Evet. Hobi amaçlı kod yazmıyorsan, yazdığın kodun para kazanması IDE önünde “sanat” icra etmekten daha önemlidir. Tamam teknik borç dengesi çok önemli ama temiz kod yazma da zamanla gelişen bir kas, newbie olarak tertemiz yazacağım diye kasmaya gerek yok. İşine bak kafi. Özellikle hyper casual oyun sektöründe bu çok daha net. 2 haftalık deadline’lara yetişmek temiz kod yazmaktan ÇOK daha önemli, çünkü muhtemelen birkaç gün sonra nasıl temiz kod yazdığının bir önemi kalmıyor ツ

Abstraction ve encapsulation çoğunlukla kafi.

Bu kavramlar için araba örneği çok hoşuma gidiyor. Kontağı çevirince arkada dönen yüzlerce kimyasal, fiziksel ve elektronik olaydan haberimiz olmuyor. Bize sadece çalışan arabayı kullanmak kalıyor. İleride araba arızalandığında ilgili parçayı değiştirmek yetiyor, böylece servis masrafı düşüyor. Bu abstraction(soyutlama).

Aynı arabanın kaputunu açmadan içinde neler olduğunu göremiyoruz, mühendisler bizden gizlemiş. Kaputu açınca motor kapağını açmadan motorun içini göremiyoruz, bir güvenlik katmanı daha. Bu da encapsulation(kapsüllemenin berbat bir çeviri olduğunu düşünüyorum).

Aynı şeyi kodda uygulamaya çalışmak -sadece buna dikkat edince bile- kodun devam ettirilebilirliğini epey arttırıyor. Player’ın bir yere ateş etmesi mi lazım? Bırak kendi içinde halletsin. İleride ateş mantığını mı değiştireceksin, ilgili parçayı(fonksiyonu) değiştirsen yeterli. Yalnızca abstraction kullanımını prensip olarak edinince bile kod kalitesi önemli ölçüde artıyor.

Peki herhangi bir yerden player’ın boyuna erişip üstüne değiştirebilirsek ne olur? Kısa cevap curcuna, uzun cevap muhtemelen bozulmaya müsait bir oyun.

OOP konseptleri felsefesinden kullanımına deniz derya konular, ufak bir video bırakıp devam ediyorum.

Unutma, birileri senden sonra kodunu okuyacak.

Maalesef durum bundan ibaret -_- Dünyada tek bir yazılımcı yok, senden sonra birileri aynı projede çalışacak. Birileri derken çok uzağı kastetmiyorum, yazdığın koda 2 hafta sonra dönünce bile neler döndüğünü anlaması zor olabiliyor. Bu nedenle daha en başta kodlarken buna göre düşünmek gerekiyor. İsimlendirmelerin açık olmasına dikkat etmek, “magic number” kullanımından kaçmak gerekiyor. Comment koymaktan fazlasını kastediyorum. Bir nevi kod kendi kendinin yorum satırı olmalı (self-documenting), ekstra yorum satırı gerekmeden okunabilen kod kaliteli kabul edilebilir.

Herhangi bir aptal, bir bilgisayarın anlayabileceği kodları yazabilir. İyi programcılar, insanların anlayabileceği kodları yazarlar. — Martin Fowler

Biraz oyun geliştirme özelinde olacak ama şu videodaki yaklaşım okunabilir kod yazmaya güzel bir örnek.

Standardizasyon önemli.

Hobi proje bile olsa kodda belli standartları belirlemenin önemli olduğunu düşünüyorum. Çok kompleks işlere girmeye de gerek yok. Basit isimlendirme kurallarına, kod stiline işe girişmeden karar vermek ve sadık kalmak düşünüldüğünden daha mühim. Sıfırdan karar vermeye de gerek yok, “ coding conventions” diye arayınca çıkan standartlardan hoşunuza gideni seçebilirsiniz.

Çok okuyan çok gezenden fazla biliyor.

Bu doğrudan temiz kod yazmakla alakalı değil belki ama kod okumanın önemli olduğunu düşünüyorum. Arada keyfine açıp open source projeleri okumak hem kod organizasyonu açısından ufuk açıcı oluyor hem de yeni şeyler görmeyi sağlıyor. Bu konuda GitHub’ın hafif yazılım sosyal medyası benzeri varlığını oldukça seviyorum. Kim kimi takip etmiş, kim hangi projeyi yıldızlamış, kim hangi projeye release çıkmış görmek oldukça eğlenceli geliyor :)


Toparlamak gerekirse, temiz kod bir çeşit kas. Ve bu kas design pattern ezberlemekle değil, üzerine kafa yordukça gelişiyor. Başta da belirttiğim üzere fazlasıyla öznel görüşlere dayalı bir yazı, farklı görüşleri yorum kısmına bekliyorum.