Trader’ın önündeki ekranı sıfırdan yazmak

Haziran 2017’de Chicago merkezli bir yüksek frekanslı işlem (high-frequency trading) firması Türkiye’de ofis açıyordu. Ankara tarafının açılışında çalıştım; unvanım Türkiye ekip lideri ve yazılım mühendisiydi. On ay sürdü.

İşin iki tarafı vardı, iki ayrı dilde. Trader’ların önünde duracak arayüz Python’la yazılacaktı. O arayüzün göstereceği her şeyi üreten strateji tarafı ise C ile yazılmıştı ve çalışan bir sistemdi. Benim işim önce birincisini sıfırdan kurmak, sonra ikincisini birincisini besleyecek hâle getirmekti.

Ankara’da bir ekip kurmak

Şirket Chicago merkezliydi, açılan ofis Ankara’daydı. Bir ofisin açılışında yazılım tek iş değil: on ayın bir bölümü işe alıma gitti. Junior ve senior yazılım mühendisi pozisyonları için 10’dan fazla adayla görüştüm. Kod yazmakla mülakat yapmak aynı takvimi paylaşıyordu ve ikisi de ertelenebilir değildi.

Aynı anda iki seviyeye birden bakmak iki ayrı iştir. Sıfırdan kurulan bir ofisin senior tarafında aradığınız kişi, kimsenin oturup anlatamayacağı bir kod tabanına tek başına girip zarar vermeden çıkabilen kişidir. Junior tarafında aradığınız kişi ise bir yıl sonra o kod tabanının sahibi olacak kişidir. İlan aynı şirket için açılıyor, ama iki ayrı soru soruyorsunuz.

Yazdığım arayüzü gösteremem

Bu sayfanın eksiği baştan söylenmeli. ICY Capital için yazdığım arayüzlerin ekran görüntüsü yayımlanamaz; hepsi gizli. Aşağıdaki kare de benim işim değil — üçüncü tarafa ait hazır bir işlem platformu ve tarihi bu işten öncesine düşüyor. Buraya yalnızca bu tür ekranların hangi yoğunlukta çalıştığı hakkında fikir vermesi için koyuyorum.

Gizli yazılım üzerinde çalışmanın bir bedeli var ve teknik değil. Yazdığınız hiçbir şeyi dışarıya gösteremiyorsunuz: ne bir ekran görüntüsü, ne bir kod parçası, ne de bir ölçüm. Geriye yalnızca anlatabildiğiniz kadarı kalıyor. Bu sayfa da o kadarı.

Arayüzün iki ölçüsü

Bir işlem arayüzü iki şeyle ölçülür: aynı anda ne kadar bilgi gösterebildiği ve saniyede ne kadar veri işleyebildiği. Yazdığım arayüz her iki ölçüde de elimizdeki eskisinden çok daha yetenekliydi.

İki ölçü birbirini çeker. Ekranda canlı güncellenen alan sayısı arttıkça her güncellemenin maliyeti artar; gelen veri hızlandıkça arayüzün geride kalma ihtimali artar. Bir arayüzü hızlandırmanın en kolay yolu daha az şey göstermektir, zenginleştirmenin en kolay yolu da daha seyrek güncellemektir. İkisini aynı anda istiyorsanız kolay yolların ikisi de kapalıdır.

Veriye yetişemeyen bir arayüz yavaşlamaz, geç kalır. Ekranda duran sayı yanlış değildir, eskidir; bakan kişi de ikisini birbirinden ayıramaz. Bu yüzden böyle bir programda asıl soru akıcı görünüp görünmediği değil, geride kaldığında bunu fark edip edemeyeceğinizdir.

Bu yüzden var olanı genişletmek yerine sıfırdan yazdım. Bu her zaman doğru karar değil; çoğu durumda çalışan bir programı yeniden yazmak, çözülmüş problemleri ikinci kez çözmek demektir. Burada doğru olmasının sebebi, aşılmak istenen sınırın bir özellik eksikliği değil, programın kurulduğu yapının kendisi olmasıydı. Ekranda ne göstereceğinizi sonradan değiştirebilirsiniz; veriyi nasıl aldığınızı sonradan değiştiremezsiniz.

Ekranın arkasındaki C tarafı

Arayüzün gösterdiği hiçbir şeyi arayüz üretmiyordu. Veriyi üreten taraf C ile yazılmıştı; yeni arayüzün ihtiyaç duyduğu bilgiyi saklama, işleme, kayıt altına alma ve aktarma tarafını elden geçirdim. Aynı sırada eski hataları düzelttim ve çeşitli performans iyileştirmeleri yaptım.

Bu iki taraf aynı işin iki yarısı değil. Python tarafında boş bir sayfa açıyordum; C tarafında çalışan ve güvenilen bir sistemin içine giriyordum. Her yeni alan, her yeni kayıt satırı, hâlihazırda doğru çalışan bir şeyin yanına ekleniyordu.

Bu dört işin en az konuşulanı kayıt tutmak. Piyasa geri sarılamaz; bir anı sonradan yeniden üretemezsiniz. O anın kaydı elinizde yoksa an hiç olmamış gibidir — ne bir hatayı gösterebilirsiniz, ne bir kararı savunabilirsiniz. Kayıt, sistemin sonradan üzerine düşünülebilir olmasının tek yolu.

Bu, işin görünmeyen yarısıydı ve asıl öğrendiğim şey burada. Bir arayüzün tavanını arayüz belirlemez. Ne kadar bilgiyi aynı anda gösterebileceğinizi, o bilgiyi üreten tarafın onu nasıl tuttuğu ve ne sıklıkta verdiği belirler. Yalnızca gösterim katmanını yeniden yazsaydım darboğazı kaldırmış olmazdım, sadece bir alt kata taşımış olurdum. Görünen iş Python’daydı; işin yarısı C tarafındaydı.

Ani hareketleri önceden görmek

Son bölümde piyasa verisini analiz eden araçlar yazmaya başladım. Amaç ani piyasa hareketlerinin ne zaman olduğunu anlamak, mümkünse öncesinde görmekti. Bu, ötekilerden farklı türde bir problem: arayüzde ve veri yolunda doğru cevabın neye benzediğini biliyorsunuz, burada bilmiyorsunuz.

Zorluk verinin azlığı değil, aradığınız şeyin seyrekliği. Elinizde saniyesi saniyesine kayıtlı, saatlerce süren bir akış var; içinde açıklamak istediğiniz an ise bir avuç. Geri kalanı gürültü, üstelik aradığınıza benzeyen yüzlerce yanlış aday üreten bir gürültü.

Bu tarafta gösterebileceğim bir sonuç yok. Mart 2018’de ayrıldım ve araçlar başladıkları yerde kaldı. Yarıda bıraktığım bir işi bitmiş gibi anlatmanın anlamı olmaz; bu vakanın en dürüst cümlesi bu.

Geriye kalan

Bir sonraki ay Coinium’u kurdum; o başka bir sayfanın konusu.

On aydan tek bir şey seçmem gerekse, kullanıcının nerede oturduğunun ne kadar önemli olduğunu söylerdim. Yazdığım arayüzü kullananlar kendi şirketimin trader’larıydı. Kullanıcınız sizinle aynı şirkette çalışıyorsa yanlış bir tasarım kararının bedeli aylar sonra bir ölçüm ekranında değil, aynı gün karşınızda belirir.

Bu, tüketiciye ürün yapmaktan çok daha rahat bir konum. Rahatlığın bedeli de var: kullanıcıyı ikna etmek yerine ona sormak mümkün olduğunda, bir tasarımın neden doğru olduğunu düşünmeyi bırakabilirsiniz. Kendi kurduğum şirketlerde böyle bir kullanıcının hiç olmadığını, oradan çıkınca daha net gördüm.