Bu yazı, Freya Finance geliştirmeyle ilgili kısa bir seriyi kapatıyor. Makaleleri tekrar etmek yerine, en başta kendime gerçekten ne söylerdim onu, her birinin öğrenilmesinin ne kadara mal olduğuna göre sıralayarak paylaşıyorum.
Ortak nokta rahatsız edici: bu hataların neredeyse hiçbiri kendini belli etmedi. Makul görünen sayılar, geçerli görünen emirler ve doğru görünen ekranlar ürettiler. Birinin parasıyla işlem yapan bir sistemde, istisna fırlatan hata dostça olanıdır.
Önemli Noktalar
- Üçüncü taraf API'ler sessizce başarısız olur. İstediğinizden daha az veri taşıyan bir HTTP 200, 500'e karşı değil, asıl tasarım yapmanız gereken hata biçimidir.
- Simülatörün simüle ettiği hiçbir şeyi test etmeden önce simülatörün kendisini test edin. Bozuk bir simülatör, tıpkı çalışanınki gibi görünen sayılar döndürür.
- Simüle edemediğinizi raporlayın. Açıkça belirtilmiş bir boşluğu olan bir sonuç, bir koşulu sessizce eleyen temiz görünüşlü bir sonuçtan daha değerlidir.
- Hassasiyet bir yardımcı fonksiyon değil, bir alandır. Adım boyutları, tick boyutları ve minimumlar; çifte, borsaya ve piyasa türüne göre değişir.
- Kısıtları erken seçin. Kullanıcı fonlarını asla tutmama kararı, bir sorun kategorisini çözmek yerine tümüyle ortadan kaldırdı.
- Bir para arayüzünde, platformun düzenleme saydığı hareketleri denetleyin. Odaklanmış bir sayı girişinin üzerindeki fare tekerleği bunlardan biridir.
1. Her API'nin bazen yanlış şekilde başarılı olduğunu varsayın
Yaptığım en pahalı varsayım, başarısız bir isteğin başarısızlık gibi görüneceğiydi.
Yük altındaki borsalar istenenden daha az mumla HTTP 200 döndürür; hata alanı yok, uyarı yok. Derin geriye dönük testlerimizden biri yaklaşık 536.000 mum istedi ve 58.000 aldı. Aynı istek bir saat sonra tüm seti döndürdü. Yanıtta bu ikisini birbirinden ayıran hiçbir şey yoktu.
Kontrol etmiyorsanız, motor bir stratejiyi hedeflenen geçmişin küçük bir kesri üzerinde simüle eder ve kendinden emin bir sayı raporlar. Bu bir çökmeden daha kötüdür çünkü çökme dürüsttür.
Bundan iki kural çıktı: başarılı bir yanıtın yalnızca durum kodunu değil, biçimini de doğrulayın ve ne yapacağınıza karar vermeden önce geçici hataları kalıcı olanlardan ayırın. İkisi de gerçekleştiği anda birbirinin aynısı görünür ve zıt tepkileri hak eder.
2. Stratejiyi değil, simülatörü test edin
Her içgüdü sizi strateji mantığını test etmeye iter çünkü ilginç kısım orasıdır. Tuzak şu: bozuk bir simülatör, çalışanından ayırt edilemeyen bir çıktı üretir. Verinin onda birini sessizce işleyen bir çalıştırma yine de bir sayı döndürür. Çıkışları hiç değerlendirilmemiş bir çalıştırma ise şüpheli derecede düz bir sayı döndürür.
Bunu çözen değişiklik, stratejinin değiştiremeyeceği şeyler üzerinde doğrulama yapmaktı: işlenen mumların çekilen mumlarla eşleşmesi, bilinen bir dönem üzerindeki bir çalıştırmanın gerçekten o dönemi kapsaması, tetikleneceği garanti olan bir yapılandırmanın işlem üretmesi.
Bu değişmezler sağlandığında, tuhaf bir sonuç gerçek bir bulgudur. Sağlanmadığında ise sonuç, takım elbise giymiş gürültüden ibarettir.
3. Simüle edemediğinizi raporlayın
Bu bir hatadan çok bir tasarım tercihi ve bence en az takdir edileni.
Bazı koşullar yeniden oynatılamaz. Harici bir webhook sinyalinin tarihsel kaydı yoktur. Cazip olan hamle, onu atlayıp geri kalanını değerlendirmektir; bu da çıktıyı eksiksiz gösterir.
Bunun A VE B gerektiren bir stratejiye ne yaptığına bakın. B simüle edilemiyorsa, A tek başına karar verir; yani simüle edilen bot, gerçek botun dışarıda kalacağı yerde pozisyon açar. Hata rastgele değildir: VE mantığında bir koşulu elemek, ancak gerçeğe kıyasla daha fazla işlem üretebilir. Yani sapma her seferinde daha iyi görünen bir sonuca işaret eder.
Simülasyonu çalıştırmaya devam ettik, ancak sonuç, neyin atlandığını açıkça belirten bir uyarı taşıyor. Yüksek sesle başarısız olamayan bir simülatör sessizce başarısız olur ve sayı üreten bir şeyde sessiz başarısızlık, var olan en kötü hata biçimidir.
Tüm hikaye: geriye dönük testler neden yalan söyler
4. Pürüzsüz bir sermaye eğrisi bir cevap değil, bir sorudur
İlgili bir konu ve ayrı ele almaya değer çünkü koddan çok insanları kandırır.
Zarar durdurması olmayan bir DCA güvenlik emri kademesi neredeyse hiçbir zaman zarar gerçekleştirmez. Tutar ve alım ekler. Bu yüzden kapanan işlemlerin neredeyse tamamı kazançlıdır, kazanma oranı mükemmel görünür ve sermaye eğrisi düzgün bir merdivendir.
Risk hiçbir yere gitmedi. Yalnızca ertelendi ve bu ertelemenin kesin bir sınırı var: daha fazla güvenlik emri için kalan sermaye. Faydalı soru “düşüş ne kadardı” değil, “fiyat buna karşı gitmeye devam ederse, strateji hangi noktada alan tükenir” sorusudur.
Düşüşün kendisi de aynı şüpheciliği gerektirir. Zirvedeki ayrılmış sermayeye göre ölçülür; bu yüzden aynı 200 USDT'lik zarar, 500 USDT'lik bir tahsiste %40, 5.000'de ise %4 olarak görünür. Aynı şekilde işlem yapan iki bot, birbirinden çok farklı sayılar gösterebilir.
5. Hassasiyet bir yardımcı değil, bir alandır
“Miktarları geçerli adımlara yuvarla” işini tek bir yardımcı fonksiyon olarak kaydetmiştim. Oysa bu bir iş kategorisi ve hataların paraya mal olduğu bir yerde saklanıyor.
İşi kayan nokta başlatıyor: 0.29 değerini 0.01 adımıyla ölçeklemek 28.999999999999996 sonucunu verir; bu değer aşağı yuvarlandığında tam bir adım eksiğe iner, hem de sessizce ve daha küçük bir emir yönünde.
Sonra borsalar kuralların kendisi konusunda anlaşamıyor. Biri emir değerini USDT cinsinden kontrol eder, biri hiçbir değer kontrolü yapmadan kontrat sayısını kontrol eder, biri ikisini birden kontrol eder. Bu alandaki en kötü hatamız, bir borsanın sahip olmadığı bir minimumu uydurup geçerli emirleri buna göre reddetmemizden kaynaklandı. Geriye dönüp bakınca ipucu şuydu: bizim kısıt sürümümüz fiyata bağlıyken, gerçek kısıt bağlı değildi.
Borsanın çift bazında tanımladığı bir şey için tek bir sabit yazdığınız her yerde, gecikmeli fitili olan bir hata yazıyorsunuz demektir.
Tüm hikaye: kayan nokta size paraya mal olur
6. Kısıtlarınızı erken seçin
Sonuncusu bir hata değil. Sonuçlarını iyi yönde hafife aldığım bir karar.
Freya kullanıcının işlem fonlarını asla tutmaz. Anahtarlar okuma ve işlem izni taşır, asla çekim izni değil; çekim izniyle birlikte gelen bir anahtar, kabul edilip yok sayılmak yerine reddedilir. Bu ayrım kulağa geldiğinden daha önemli: “çekim yapmayacağız” bir kullanıcının doğrulayamayacağı, davranışımıza dair bir iddiadır; oysa “anahtar çekim yapamaz” borsa tarafından zorunlu kılınır ve kullanıcının kendi ayarlarından kontrol edilebilir.
Bunun bir pazarlama unsuru olmasını bekliyordum. Meğer mimari bir konuymuş ve sistemi küçülttü: emanet defteri yok, mutabakat yok, çekim kuyruğu yok, işlem sermayesi için soğuk cüzdan politikası yok. Finansal yazılımdaki en zor sorunların koca bir sınıfı ortada yok çünkü onları yaratan şeyi hiç üstlenmedik.
Onun yerini alan şey daha dar ve daha keskin: sistem gerçek zamanlı olarak doğru olmak zorunda çünkü hiçbir şeyi asla geri alamaz. Başkasının borsa hesabında gerçekleşen bir emir kesindir.
Tüm hikaye: emanetsiz işlem tasarlamak
İhtiyaç duyacağımı beklemediğim ders
Bir bonus çünkü beni en çok bu şaşırttı: bir para arayüzünde, ön yüzün de tıpkı motor kadar paranoyaya ihtiyacı var.
Odaklanmış bir <input type="number">, üzerinde tekerleği kaydırdığınızda değerini adım adım değiştirir. Bir miktar seçicide bu can sıkıcıdır. Kaldıraç, emir büyüklüğü ve fiyatta ise kullanıcının seçtiğini sessizce yeniden yazar ve form yine de doğrulamadan geçer. Bu hatayla ilgili hiçbir şey ekran görüntüsünde görünmez.
Tüm hikaye: fare tekerleği sayı girişlerinizi düzenliyor
Hepsini tek bir cümleye sıkıştırsam
Kendini belli etmeyen hatalara göre inşa edin. İstisna fırlatanlar zaten kendiliğinden sizi bulur.