19 Haziran 2025'te St. Petersburg'daki PiterJS #79'a gittim. Akşamın konusu gösterişli değildi ve tam da bu yüzden faydalıydı: sıradaki özelliği nasıl çıkaracağımız değil, zaten inşa edilmiş olanı nasıl sürdüreceğimiz — monitoring, deployment ve refactoring.
Program bu temayla yakından örtüşüyordu. Pavel Shlykov eski bir monoliti iyileştirmeyi, Alexander Panfilov FrontOps'u, Igor Antonov ise web uygulaması performans metriklerini anlattı. Üç konudan da uygulamaya dönük notlarla ayrıldım.
Beklenmedik kısım Q&A oldu. Oturumlarda en iyi soruları sorduğum için iki ödül kazandım. Küçük bir ayrıntıydı ama akşamın bende en çok kalan parçası oldu; çünkü yüz yüze teknik meetup'ları neden hâlâ değerli bulduğumu tekrar gösterdi. Hazırlanmış bir konuşmayı tüketmekten fazlasını yapabiliyorsunuz. Konuyu anlatan kişiler hâlâ odadayken kendi anlayışınızı sınayabiliyorsunuz.
Faydalı tema yenilik değil, bakım işiydi
Frontend etkinlikleri kolayca yeni framework'lerin, API'lerin ve soyutlamaların geçidine dönüşebiliyor. PiterJS #79 daha ayakları yere basan bir etkinlikti. Duyurulan tema, zaten var olan yazılımı desteklemekti.
Bu önemli; çünkü mühendislik işinin büyük bölümü ilk başarılı sürümden sonra başlıyor. Legacy bir monolit otomatik olarak kötü bir sistem değildir, “modernizasyon” da otomatik olarak her şeyi baştan yazmak anlamına gelmez. Pratik soru genellikle daha dardır: şu anda sistemi gerçekten zorlayan kısıt ne ve hangi değişiklik, ortadan kaldırdığından daha fazla risk yaratmadan bu sorunu azaltır?
Üç konuşmanın birbirine iyi oturmasının nedeni de buydu. Refactoring kodu değiştirir. FrontOps, frontend'in nasıl build edildiğini, paketlendiğini, dağıtıldığını ve işletildiğini değiştirir. Performans çalışması ise sonucu nasıl ölçtüğümüzü değiştirir. Bunlar aynı sorunun farklı katmanlarıdır: büyümüş gerçek bir sistemi anlaşılır ve kontrol edilebilir tutmak.
FrontOps bir Dockerfile'dan daha geniştir
Meetup'tan aldığım notlardan biri Docker ile FrontOps uygulamakla ilgiliydi. Buradaki önemli ayrım şu: Docker bir araçtır; FrontOps'un tanımı değildir.
Frontend sorumluluğu npm run build başarıyla tamamlandığında bitmek zorunda değildir. Production'da hâlâ reproducible build'ler, artifact'ların nasıl paketlendiği, yapılandırmanın uygulamaya nasıl ulaştığı, release rollback'leri, cache davranışı ve hataların nasıl gözlemlendiği düşünülmelidir. Container'lar bu işlerin bir bölümünü daha öngörülebilir hâle getirebilir, ancak operasyonel kararların yerini tutmaz.
Bu, yaygın bir zihinsel modeli düzeltmek için faydalı: başarılı bir build, build'in tamamlandığını kanıtlar. Uygulamanın doğru deploy edileceğini, production'da doğru davranacağını ya da bir şey bozulduğunda kolayca geri kazanılacağını kanıtlamaz.
Performans, “yavaş”ın ne olduğunu belirlemekle başlar
Performans konuşmasının özellikle pratik tarafı, ölçümü nasıl çerçevelediğiydi. Duyurulan kapsam; yükleme hızını etkileyen faktörleri, farklı frontend performans metriklerini, “yavaş”ı sayısallaştırma yollarını ve hatta optimizasyonun neden her zaman gerekli olmadığını içeriyordu.
Son nokta kolayca gözden kaçabiliyor. “Daha hızlı yap” nesnel bir hedef gibi görünür, ancak bir metrik ve kullanıcı tarafından hissedilen bir problem olmadan pahalı bir tahmine dönüşebilir. Faydalı bir performans süreci; gerçekten neyin yavaş olduğunu tanımlamak, ölçmek, darboğazı bulmak, ilgili tek bir şeyi değiştirmek ve yeniden ölçmekle başlar.
Bir metrik tek başına kullanıcı deneyimi değildir, fakat tartışmaya ortak bir ölçü birimi kazandırır. Ölçüm olmadan performans çalışması, gerçekten önemli olan problemin iyileştiğine dair net kanıt sunmayan teknik açıdan etkileyici değişiklikler koleksiyonuna dönüşebilir.
Q&A meetup'ın değerini benim için değiştirdi
Kayıtları daha sonra izleyip bağlantıları toplayabilirdim. Aynı kolaylıkla yeniden üretilemeyecek şey, konuşmaların etrafındaki etkileşimdi. İyi bir soru sormak, belirsizliğinizi başka bir mühendisin cevaplayabileceği kadar somut bir şeye sıkıştırmaya zorluyor.
İki ödül kazanmak eğlenceliydi, ama daha yararlı ders daha basitti: katılmaya hazır gelmek, yüz yüze bir meetup'ı canlı bir YouTube playlist'i gibi izlemekten çok daha değerli hâle getiriyor.
Güçlü bir teknik soruda genellikle bağlam ve bir kısıt vardır. “En iyi mimari hangisi?” yerine, bir ekip legacy sistemi baştan yazamıyorsa, deployment backward-compatible kalmak zorundaysa ya da bir performans metriği iyileşmesine rağmen kullanıcı tarafında karşılığı yoksa hangi trade-off'un değiştiğini sormak daha yararlı olabilir.
Her sorunun zekice olması gerekmez. Asıl amaç varsayımları, sınırları veya failure mode'ları görünür hâle getirmektir.
Bir sonraki teknik meetup'a ne götürürdüm
- Bir konuşmanın benim için neden önemli olduğunu bilmek. Başlamadan önce gerçek bir problem veya belirsizlik yazmak.
- Konuşmacının deneyimiyle kendi sistemimi ayırmak. Faydalı bir case study kanıttır; evrensel reçete değildir.
- Trade-off'ları sormak. “Bunu ne zaman kullanmazdın?” çoğu zaman “En iyi araç hangisi?” sorusundan daha fazla şey açığa çıkarır.
- Tek bir takip aksiyonu yazmak. Bir not, meetup'tan sonra doğrulanacak, test edilecek veya okunacak bir şeye bağlandığında daha değerlidir.
- İkna edici bir konuşmayı production kanıtıyla karıştırmamak. Mimari, deployment ve performans kararları yine de kendi ortamınızda doğrulanmalıdır.
Bende kalan ne oldu
Tek bir meetup'ın ne kadar şeyi değiştirebileceğini abartmak istemiyorum. PiterJS'ten evrensel bir mimari reçetesiyle çıkmadım; iyi bir konuşma dokümantasyonun, profiling'in, testlerin veya production verisinin yerini tutmaz.
Gerçekte yanımda götürdüğüm şey daha somuttu: legacy bir monoliti modernize etme, Docker ile FrontOps ve web performansını ölçme üzerine faydalı notlar; Q&A'den iki ödül; ve yerel geliştirici topluluklarına fiziksel olarak katılmanın değerini hatırlatan bir deneyim daha.
Kayıtlar sunumu koruyabilir. Arşivlenmesi en zor olan şey, sunumun etrafındaki konuşmadır.