Transkript
Merhaba arkadaşlar. Bu hafta Android Discovery ekibinden Can Seray ve Pelin ile birlikte biraz böyle Android ekibini daha yakından tanımaya çalışacağız.
Ama öncesinde biraz böyle kendinizden bahsedebilir misiniz Pelin ve Can Seray?
Ne işle uğraşıyorsunuz, neler yapıyorsunuz?
Şu ana kadar geçmişinizden böyle kısaca bir bahsedebilirseniz süper olur.
Ben başlayayım isterseniz.
Ben Cansu Ay. Trendyol'da Discovery ekibinde çalışıyorum.
Yaklaşık 5 aydır. Bundan öncesinde yaklaşık 2,5 senedeki bir iş tecrübem var.
15 ayında dediğim gibi burada geçiriyorum.
Pelin abim. Selamlar.
Pelin ben de. Yaklaşık 2 yıldır Trendyol'da Discovery takımında Android developer olarak çalışıyorum.
Bundan önce de yine bir mobil yazılım ajansında Android developer olarak çalışmıştım.
Ben de bu şekilde. Discovery ekibinde çalıştığınızdan bahsettiniz Android tarafında ama Discovery ne yapar?
Android ekibinde bu hangi kısma tekabül eder?
Şöyle, Android ekibinin aslında ana hatlarıyla iki bölümü ayırıyoruz Discovery ve Checkout diye.
Discovery ekibi olarak mobil uygulamadaki ana sayfa, search, favori, koleksiyon, fitreleme, server store gibi ekranların geliştirmelerini Discovery ekibi olarak biz yapıyoruz.
Discovery ekibi hangi domenilerle ya da ekiplerle biraz daha yakın çalışıyor?
Discovery ekibi deyince aslında öncelikle Android takımı olarak kendi içinizde de böyle küçük ekiplere ayrılmış bulunmaktayız.
Bu projenin base kısmıyla alakalı bir durum olduğu zaman kendi takımımız içerisinde interaksiyon halindeyiz.
Onun dışında da genelde mobil beklet ile sürekli iletişim halindeyiz.
Bunlar Discovery özelinde düşününce Zeus takımı en çok gittiğimiz ekiplerden biri.
Onun dışında bazen bazı apilerde farklı takımlardan da destek almak durumunda kalıyoruz.
Mesela en son social işleri yapıldı.
Social işlerinde marketing center yönetiyor.
Yani oradaki herhangi bir isteğe ulaşmamız gerektiğinde video BFF'e gidiyoruz.
Ya da favori ve koleksiyonlarla alakalı bir durum olduğunda reko'ya ulaşıyoruz.
Onun dışında bazen işte eventlerle alakalı işler geliyor.
Marketing takımıyla da böyle görüşmeler halinde kalıyoruz.
Tabii ki bir de katılmaz olarak IS Disco takımıyla da sürekli kontak halindeyiz.
Çünkü benzer feature'ları geliştiriyoruz.
Bazen paralel geliştiriyoruz, bazen birimiz bir hafta önce alıyor, diğerine feedback veriyor.
Veya işte yamaları ortak bir şekilde hazırlıyoruz.
Genel olarak bu takımlarla iletişim halindeyiz diyebiliriz.
Ekibinizin peki dağılımı nasıl title'lar olarak?
Kaç tane product owner var, kaç tane developer var, kaç tane testçi arkadaş var?
Bizim takımımızda genel olarak Android takımı düşündüğümüzde 30-35 arası Android Developer var.
Bu sayı böyle çok dinamik bir şekilde değişiyor.
Belki podcast yayınlandığında gerçekten sayımız farklı da olabilir.
Onun dışında yaklaşık 8 takıma bölünmüş durumdayız.
Her takımda ortalama 4-5 Android Developer ve o takıma ait işte oradaki işleri yöneten 1-2 ile değilsen QA arkadaş ve bizde biz neşesini getiren de productlarımız oluyor ve her takımda bir takım lideri
mevcut. Pandemi döneminde aslında hepimiz bu sorunu çok yaşadık ama aslında artık çözdüğümüz bir sorun da oldu bu.
Yeni başlayan bir kişiyi onboard etmek her ekipte böyle ortak maddelere sahip oldu ama siz nasıl onboard ediyorsunuz?
Hani böyle yeni başlayan biri nasıl onboard oluyor?
Yeni yazdığı kodunu ne zaman canlıda görüyor?
Kısa bir süre önce bu süreci geçirmiş bir olarak ben bahsedeyim bundan.
Kendi sürecimden bahsedeyim.
Ben işe girmeden birkaç gün önce body'im ve ekibimden iki kişiyle bir grup oluşturuldu.
Ve aslında biz orada tanıştık.
Bu çok güzel bir şeydi bu arada. İlk baştaki heyecanımı çok almıştı benden.
İşe başladıktan sonra tanışma toplantıları, ekiple kaynaşma toplantıları oluyor öncelikle.
Buna biraz öncelik veriliyor. Bu çok güzel bir şey bu arada.
Çünkü çok kalabalık bir ekip. Her zaman herkese iş yapma fırsatı bulamayabilirsiniz kısa bir süre içinde.
Ve ilk baştan onlarla tanışıyor olmak insan motivasyonu çok yükseltiyor.
Projede kodunuzun olması ve canlıya çıkması konusunda şu kadar süre önce olmamalı gibi bir durum yok.
Ben girdikten çok kısa bir süre sonra canlıya çıkmıştı kodum.
Ama burada şöyle bir problem de yaşamıyorsunuz.
Codebase'de çok yenisiniz.
Alacağınız iş, hakim olmadığınız bir projeyle ilgili.
Bu sürece ilk başlarda daha çok payer geçiriyorsunuz arkadaşlarınızla.
yazdığımız kod da iyi bir review'dan geçiriyor vesaire olduğu için şu sistem çok iyi yani.
Yeni bir insan burada bir süre geliştirme yapamaz gibi bir durum yok.
Ama yaptığı geliştirmede kesinlikle yayınlanabilir.
İyi işler oluyor zaten. Biraz böyle ecaili intimantasyonunuzdan bahsedebilir misin?
Yani bir iş size nasıl geliyor ve o işin yanlığa çıkana kadarki süreci nasıl ilerliyor?
Kısaca biraz bahsedebilirsiniz.
Şöyle oluyor. Aslında agile boardumuzdan böyle stümlerimizden bahsedip böyle gözümüzde böyle canlandırarak anlatırsam herhalde daha tatlı olur.
Bize bir iş geldiğinde ready for dev diye bir stümde o işler bizi bekliyor.
Bu işi alıyorum ve artık bu iş in dev'de.
Ben bu işe başladım. Bu iş sürecinde dediğim gibi payer bir şekilde tek başımıza fark etmek için yani tam bir ekip işiyle dediğimiz şekilde bu işi ilerletiyoruz.
Bu iş tamamlandıktan sonra PR'ımı açıyorum ve burada code review süreci başlıyor.
Bizde Tüm ekip Code Review yapabiliyor.
Burada çeşitli yorumlar oluyor.
Yorumlara göre düzenlememiz gereken yerler varsa düzenliyoruz.
Ve 4 approve alırsa bu işimiz Ready for QA'ya geçiyor.
QA'ya geçtiğinde bu geliştirme esnasında yazdığımız unit testlerimiz ve otomasyon...
sayesinde trigger ediliyor. QA arkadaşlarımız bununla eş zamanlı olarak manuel testleri yapıyorlar.
Eğer bu süreçte işimizle ilgili bir bug ya da bir problem çıkarsa o bug ve problemin nezdinde bu proses başa sarıyor.
Bunu da çözdükten sonra tekrar bir defa QA'ya geliyoruz.
Aynı kod review sürecini geçirip buradan da okeylenirse artık QAT süreci başlıyor.
Produk arkadaşlarımız inceliyor işi.
Oradan da okeylenirse ban diyoruz ve işimiz okeylenmiş oluyor.
İlk sormak istiyorum burada. Yani platformun böyle doğası gereği biraz çok fazla ecaat sanki olamayacakmış gibi geliyor.
Çünkü işte bir onaya yollanıyor paket.
Daha sonra onun diptoy çıkması, yeni paketin oluşturması vesaire falan böyle bir süreç var.
Siz burada nasıl ilerliyorsunuz?
Bu sizin için bir engel teşkil ediyor mu?
Gerçi iOS tarafında biraz daha sıkıntılı bu durum sanırım ama Android'de biraz daha kolay mı paket oluşturulabiliyor?
Biraz oralardan da bahsedebilir misiniz?
Burada dikdorma sürecimizde biz aslında bir paket çıkacaksak bunu önce belli bir yüzdeye açıyoruz.
Daha sonra o paket üzerinden takip yapıyoruz.
Biz mesela bir sorunla karşılaştığımız zaman yeni paket göndermemize gerek kalmıyor.
Var olan süreç üzerinden yeni bir RC oluşturuyoruz ve eğer acil müdahale etmemiz gereken bir durum olursa o RC'yi canlıya alıyoruz ve o canlıya aldığımız paketin yüzdesini arttırıyoruz ki daha
sağlıklı pakete daha fazla kullanıcı ulaşabilsin diye.
Şimdi Trendyol uzun zamandır da kullanılan bir uygulama olduğu için deployment süresinde belki de diğer Android'un...
uygulamalara kadar uzun bir bekleme süresi yaşamıyoruz.
Mesela gün içerisinde biz göndermek istediğimiz paketi canlıya alabiliyoruz.
İşlerin ilerleyişinden aslında bahsettik ama tabii hepsinin bir background'u var.
Ve bence bu benim kişisel fikrim.
Ama ekipteki bütün işlerle bir kişinin %100 eşleşiyor olması bana çok ütopik geliyor.
Bu konuda sizin de fikrinizi aslında almak istiyorum.
Yani sizin board'unuza gelen işte background'unuzda olan her iş ekibinizdeki herkesle %100 eşleşiyor mu?
Ve yapmak istemediğiniz bir iş olursa?
Mesela özellikle. O gibi durumlarda nasıl aksiyonlar alıyorsunuz?
Gizem sana bu konuda gerçekten katılıyorum.
İdeal dünyada eğer bir feature geliyorsa o ekipteki herkesin aynı performans sonunu müdahale edebilmesini biz zaten istiyoruz.
Ama büyük bir domeninde bu her zaman çok sağlıklı bir şekilde ilerlemiyor.
Şöyle oluyor, bizim işin başlığına göre değişiyor.
Eğer daha küçük bir feature ise, yapılması çok zor bir iş değilse, bir hafta, iki haftalık bir zamanı alacaksa planlama sonrası sıralanan işlerden en üstte.
Uygun olan developer kimse en üstte kişi kendine esayn ediyor.
Burada bir iş seçme sürecine girmiyoruz.
Ama genel olarak eğer büyük bir feature daha fazla planlamayı ihtiyacı duyan bir özellik uygulamayı ekleyeceğimiz zaman burada bir iş bölümüne gitmeye çalışıyoruz.
Disko'yu da şöyle temel domenlere ayırabiliriz.
Mesela search ve filtre apayrı bir yer.
Ana sayfa, widgetler bambaşka.
Favori koleksiyon apayrı bir dünya.
Bir kişinin tek seferde...
Aynı hakimiyeti tüm domainlerde sağlaması mümkün değil.
Biz de ekip içerisinde böyle ufak ufak bölünüyoruz.
Ama bu keskin bir ayrım değil.
Yeri geliyor. Can Seray da koleksiyona bakabilir, Surge'e bakabilir.
Ama başta diyoruz ki eğer Widget ise X kişisi bu domaini bir süre hakim olsun diyoruz.
Orayla ilgili büyük bir feature geldiğinde o dedike bir şekilde ilerlesin istiyoruz.
Bu adaptasyonu sağladığında, orayla ilgili bir feature geliştireceğinde, bir pay-in durumu yaşandığında diğer takım arkadaşına gerekli aktarımı yapabildiğine inandığımız...
süre içerisinde bu aramızdaki iş dağılımını dağıtıyoruz.
Tamam bu sefer artık diğer kişi.
Favoriye geçsin, öbürü sörde geçsin ki sürekli bir şekilde bir domen uzun süre vakit harcayalım.
Günün sonunda dediğim gibi işlerle eşleşmeye çalışalım gibi bir hedefimiz var.
Yani hiç iş seçmiyoruz diyemem ama iş seçmemeyi herkesin o işe adapte olabilmesini hedefleyecek şekilde ilerlemeye çalışıyoruz.
Aslında böyle herkesi de geliştirecek bir yaklaşım gerçekten de.
Mobil tarafta böyle Android tarafında benim bildiğim gibi ya Java ile yazılıyor ya Kotlin ile yazılıyor.
Mobil ile alakalı çok kısıtlı bilgimle yorum yapmaya çalışıyorum.
Çok yapamıyorum. O yüzden size soracağım.
Kullandığınız teknolojiler ve neden bunları seçtiğiniz kısmında biraz bizi bilgilendirebilir misiniz?
Biz Android tarafında Kotlin'e yazıyoruz şu an projeyi.
Bunun öncesinde Java ile başlanmış sonra Kotlin'e geçirilmiş proje.
Kullandığımız teknolojilerle ilgili şöyle bir şey diyebilirim.
Android'in sunduğu güncel tüm teknolojileri takip etmeye çalışıyoruz.
Ve güncel bir şey çıktığında bunu direkt alıp entegre edelim proje demeden önce bunu prosesden geçiriyoruz.
Hep beraber konuşuyoruz, tartışıyoruz.
Ve bizim işimize yarayabilecek olanları kullanmaya çalışıyoruz.
Ekip de zaten... bu yeni teknolojilerle ilgili gelişmeleri herkes çok sıkı takip ediyor.
Bununla ilgili channel'larımız var.
Birbirimize paylaşıyoruz, üstüne konuşuyoruz.
Bazen bunları deneyen arkadaşlarımız bize de deneyimlerini paylaşıyor.
Böyle bir teknolojiyi denedim ve şu işe yarıyor vesaire gibi.
Bu şekilde ilerliyoruz.
Android böyle sürekli sürüm güncelliyor.
Bunlar sizi nasıl etkiliyor? Yani yeni bir sürümde çok farklı şeyler olabiliyor mu?
Hem yeni sürümde farklı şeyler olabiliyor Android'de hem de cihazın markasına göre bir de aslında birçok şey değişebiliyor.
Ben mesela bu işe ilk başladığımda sadece aldığımız bir kamera izninde bile farklı cihazlar, farklı versiyonlarda çok fazla problemler yaşabiliyorduk.
Bunu şu an telde bazında anlatmıyorum.
Ama hepsini bir şekilde handle ediyoruz.
Zaten belli metrikleri de takip ettiğimiz için herhangi bir cihazda ya da versiyonda herhangi bir feature'ımız hata verebilir, crash edebilir.
Bunları da zaten takip ediyor olduğumuz için bunları kolay bir şekilde handle edebiliyoruz.
Peki Android'de ki bu fazla sürüm güncellemelerine bahsettik ama Trendyol'un Android uygulaması hangi versiyon ve üstünü destekliyor ve aslında hangi versiyon üstü olacağına nasıl karar
veriyorsunuz? Yanlış hatırlamıyorsam 23 SDK ve yukarısını artık destekliyorduk biz.
Bu da genelde çıktığımız feature'lar ve kullanan kullanıcıların cihazlarıyla alakalı bir şekilde.
Artık hani bazı şeyler hissediyorsun ki tarihinden kalma oluyor veya o versiyonu kullanan kullanıcı sesinin gitgide azaldığını fark ediyorsun.
Veya artık bu durum projeyi hantallaştırıyor.
Birazcık da bir sektör de takip ederek bu kararları alıyoruz.
Benim şahsi yaklaşımım şöyle oluyor.
Eğer güncel bir sürüm varsa onu...
birazcık daha stabil hale gelmesini bekliyoruz genelde.
Daha stabil hale geldikten sonra bununla ilgili daha fazla blog yazıları araştırma olduktan sonra onu projeye idare etmeye çalışıyoruz genelde.
Renatiyon'un mobil uygulaması az önce dediğim gibi büyük bir kitleye ulaşıyor aslında ve haliyle de burada kalite biraz daha ön plana çıkıyor gibi düşünüyorum.
Çünkü hem Android tarafında çok fazla cihaz var desteklenmesi gereken hem de işte farklı farklı Android versiyonları var.
Kaliteyi korumak için neler yapıyorsunuz?
Mesela şimdi ne tür testler yazıyorsunuz?
Şöyle bir giriş yapabilirim.
Öncelikle unit test'e çok önem veriyoruz.
UI testlerimizi yazıyoruz.
Manuel testlerde zaten birçok versiyonda ve cihaz tipinde uygulamanın yerine çıkacak versiyonu test edilebilir oluyor.
Şu anlık benim aklıma gelenler bunlar.
Pelin seni beklemek istediğin bir şey varsa.
Ben de bunları ekleyecektim.
Hani öncesinde yazdığımız logikleri kontrol ettiğimiz unit test, UI test ile bu daha minimum hatayla kullanıcıya ulaşmaya çalışıyoruz ve kullanıcı metriklerini takip ediyoruz.
Ekip içerisinde uyguladığınız bazı işte pratikler var mı?
Az önce biraz bahsettiniz, girdiniz gerçi ama işte kod review yapıtıyor demiştiniz.
Mesela işte kod review, pair programming bu tür pratikleri uyguluyor musunuz ekip içerisinde?
Ekip içerisinde genelde pay programming'i dediğim gibi önem veriyoruz.
Burada en başta dikkat ettiğimiz şey bir kişinin onboarding sürecinde alması gereken desteği yeteri kadar verip vermediğimiz.
Onun dışında yine dediğim gibi UI testi, unit testler ve kod kalitesini artırmaya çalışıyoruz.
Şimdi biz mesela bir kod üyesi sürecinden geçiyoruz.
Detaylı bir test aşaması, ondan sonra yiğitler, regresyon süreci ve detaylı bir araştırma, incelemeden geçiyoruz.
Ama aslında büyük bir projede burada atlanan bir durum.
olduğu zaman canlıda herhangi bir problemi yakalamamız, fixlememiz bizim için zaten stresli bir durum oluyor.
Bunu minimuma indirmek için de unit testler veya işte böyle UI testlerle atıyorum bir kullanıcı soruşta arama yapıyor, etek yazıyor ve arama soruşlarının girdiği keywordla alakalı olması gerekiyor.
Bunu sadece unit testte kontrol etmiyoruz.
UI testlerini yazıyoruz. Sanki kullanıcı deneyimi varmış gibi bir otomasyon üzerinden takip ediyoruz.
Ve bir projeye çıkmadan önce bu testlere koşarak yaptığımız featureler eski yerleri bozuyor mu?
Bunun takibini de bu yönde ilerletiyoruz.
Production'daki buglardan bahsettik.
Bu arada hemen şeyi sormak aklıma geldi.
Aslında release süreciniz nasıl ilerliyor?
Belli bir release günleriniz var mı?
Veya ayda en az ve en fazla şu kadar release çıkacağız kesinlikle dediğiniz oluyor mu?
Biz son zamanlarda bu süreci çok düzgün bir sisteme oturttuk.
Önceden çok daha karışık.
Mesela işte diyorduk ki ayın üçünde bir paket çıkacağız mutlaka.
Sonra sekiz farklı ekip, her ekip aynı zamanda dana geçmiyordu.
O ayın üçünde dediğimiz paket beşine altısına falan saykabiliyordu.
Ve artık çok düzensiz bir sürece gidiyordu.
Bunu şöyle oturtmaya çalıştık biz.
Her iki haftaya bir paket çıkıyoruz.
Bu aslında kısıtlı bir zaman.
Başlarda da çok yorucu oluyordu.
Sanki sürekli regresyon koşuyor gibi hissettiriyordu.
Ama şöyle bir artısı oldu bize.
Artık bizim için paket çıkmak büyük bir olay olmaktan çıktı.
Hani biz zaten normal feature'ımızı yapıyoruz.
O iki hafta içerisinde neler merge oluyorsa onlar dahil oluyor.
Yani normal sürecimizde biz arka planda hiçbir şey yapmıyoruz.
Bir şekilde paket çıkıyor. Bu dönem ilerliyor gibi oldu.
Şu sistemde oturduk.
Mesela çarşamba günü genelde direkli işleriniz falan varsa bir kanala yazılıyor.
Cuma akşamına kadar tüm işleriniz dan olacak deniyor.
Cuma akşamına kadar dan olmayan işler pakete dahil edilmiyor.
Burada eğer çok uç, çok ekstrem bir case yoksa gerçekten paketinin gecikmesini önleyecek bir şey yapmıyoruz.
Artık prodaklarla da bu konuda iyi anlaştığımızı düşünüyorum.
Yetişmiyorsa o zaman diğer pakete kalacak.
Zaten diğer paket iki hafta sonra olduğu için bir feature'in o anda canlıya çıkmaması çok da kritik bir süreç de yaratmıyor oluyor.
Cuma akşamı dana geçiyor.
Pazartesi günü biz regresyona başlıyoruz.
RC süreci başlıyor.
Üç günlük bir regresyon süreci geçiyor.
Bu pakete özel veya işte o canlıdaki...
oluşabilecek bug'ları tespit ediyoruz.
Onları çarşamba gününe kadar fiks ediyoruz ve temel hedefimiz çarşamba gün sonuna kadar o paket canlıya çıkmak.
Şu ana kadar bir sıkıntı yaşamadık.
Ekstrem bir durum olursa, regresyon sürecinde o canlıdaki paket etkileyecek kritik bir bug varsa tabii ki o şekilde çıkmıyoruz.
Ama bir günden fazla ötelenme bir durumu şu ana kadar yaşamadık.
Yani güzel bir sisteme oturttuk bu deployment sürecine.
Süper. Peki bildiğiniz gibi aslında yazılım gerçekten kendimizi geliştirmemiz gereken bir alan.
Peki sizin böyle ekipte kendinizi geliştirmeniz adına vakit yaratabildiğiniz durumlar olabiliyor mu?
Bence kesinlikle oluyor.
Zaten ekip bunu çok destekliyor.
Kendimizi geliştirmemiz ve bunları ekibimizle de paylaşmamız, çalışma arkadaşımızla.
geliştirmeniz çok önemli. Böyle olunca da sizin de zaten kendinizi geliştirmeye dair motivasyonunuz artıyor bence.
Yani ben öğrendiğim şeyin değer gördüğünü hem bana hem de takım arkadaşıma bir şeyler kattığını gördüğümde daha çok kesinlikle araştırmaya ve öğrenmeye meylediyorum.
Bu sadece teknik konularda da geçerli değil bu arada.
Yani herhangi bir konuda bir sunum yapabilirsiniz mesela ekibinizle.
Biz bundan birkaç ay önce galiba şekerin zararlarıyla ilgili mesela bir sunuma katıldık.
Bunun gibi şeyleri yapabiliyoruz.
Bu bizi çok yükselten bir durum.
Genelde backend tarafında biraz alışığız.
Genelde şu ana kadar gelen konuk ekipler hep backend ekipleri oldu.
O yüzden bir monitoring, alert kısımları nasıl işlediğini biraz az çok biliyoruz ama mobil tarafta çok aşina değiliz.
Biraz o taraftan da bahsedebilir misiniz?
Yani uygulamayı nasıl monitör ediyorsunuz?
Ya da hangi durumlarda alert oluşturuyorsunuz?
Bir insanda oluştuğu zaman nasıl müdahale ediyorsunuz?
Bu kısımları biraz açabilir misiniz?
Tabii bizim alert sistemimizde her canlının kendi ayrı bir kanalı var.
Orada gittikleri apilere...
ayrı loglar oluşturuyoruz.
Bunları da response time ve error rate'ler olarak ayırıyoruz.
Yani benim gittiğim API'de kullanıcıların yaşamış olduğu threshold'ları takip ediyorum ben.
Örneğin bir API'ye giderken son bir haftalık o kullanıcıların ortalama response time'lerine bakıyoruz.
Bu stabil bir durumdur diyoruz.
Bunun üzerine işte bir ya da iki katı kadar üzerine çıkarsa burada birazcık içgüdüsel bir threshold değeri veriyoruz.
Diyoruz ki demek ki burada kritik bir durum var.
Bu kritik durumlarda da O logo oluşturduğumuz channel'lara alarmlar fırlatıyoruz ve orada bir alarm geliyorsa her channel'da TASAN Developer ekip ilgili bekende oraya tagliyor ve burayla
ilgili almanız gereken bir aksiyon var mı?
Bunları bu şekilde takip ediyoruz.
Güzel süreçlerden bahsettik.
Biraz da böyle kaotik süreçlerden bahsedelim.
Takım olarak bu zamana kadar yaşadığınız en büyük challenge'ınız neydi?
Bence en büyük challenge'mız çok büyük bir proje, çok büyük bir kod ve büyük time'larımız.
Yani proje büyük, büyük time'lar uzun sürüyor.
Buna çok hak veriyorum. Ama bizim bunun için çalışan bir platform ekibimiz var.
Yani sadece bunun için çalışmıyor kesinlikle.
Ama büyük time'larımızı...
kısaltmaya yönelik de işler yapıyor ve bunu takibini çok iyi ilerletiyor.
Bu konuda günden güne çok iyi sonuçlar alıyoruz.
Buradan mükemmel platform hekimimize sevgilerimi gönderiyorum.
O yüzden aslında benim şu ana kadar yaşadığım en büyük challenge bu diyebilirim.
Ama bu bizim için kesinlikle başa çıkamadığımız bir challenge'den ziyade günden güne daha da ufak bir sorunu dönüşecek olan handle edebildiğimiz bir sorun.
İlla ki bir sorun olmuştur.
İlla bu retroya gelmiştir.
Bize lütfen böyle retroda konuştuğunuz güzel bir madde ele gelin.
Son retro'daydı. Bir öncesinde kanlı bir retro olmuştu.
Ben iki yıldır burada çalışıyorum.
İki yıldır oturtamadığımız bir sistem var.
Code review süreci. Şimdi 30-35 developer diye bahsettim.
Yoğun bir çalışma temposu.
Herkes deli gibi PR açıyor.
Ve o PR'lerden en az 4 yapı almadan o iş test aşamasına geçemiyor.
Çok fazla PR var.
Takip etmesi artık developer olarak da zorlaşmaya başladı.
QA'lar da bundan doğal olarak rahatsız olmaya başladı.
Pakete gelecek işin 3 gün review'da kalması aslında 3 günlük bir kayıp.
gibi. Çünkü yeterli sayıda hızlı bir approve, hızlı bir review alırsa zaten hemencecik QA aşamasına geçebilecekken gereksiz yere orada bir zaman kaybı oluyor diye işte böyle.
Bir konuşmaya başladık.
Bu dört approve olayını yaklaşık bir, bir buçuk saat boyunca tartıştık.
En sonunda şey oldu böyle.
Değişik fantezik böyle çözüme üretilmeye başladı.
Şey yapalım, raporlara bakalım.
Hani aylık ortalama bir kişinin vermesi gereken approve sayısı kaç?
Kimler onun altında kalıyor?
İhşalayalım mı? Ya da işte böyle bir PR açıldığı zaman random birilerine atayalım onlar approve versin gibi böyle değişik öneriler geldi.
En sonunda dedik ki bu bu kadar efora değmez.
Gerçekten herkes sorumluluğunu almalı falan gibi bir aksiyon aldık.
Otomasyon süreçlerinden takip etmeye başladık.
Eğer bir PR açılıyorsa bize, bizim Beylek diye adlandırdığımız otomasyon sürecimiz var.
O bize haber veriyor.
İşte bana günün belli saatlerinde bak burada bu PR'ler var, bunun iki aprubu eksik.
Sen bunu rivvetlemişsin, hadi bak diye böyle tarziz mekanizması dediğimiz alarmlar oluyor.
Bir de şey oldu hani biz bir anda bootcamp düzenlemiştik.
Birden fazla developer, yaklaşık 10-15 tane bootcamp öğrencisi bir anda ekibe katıldı ve onların ilk bir ayında açılan bir PR'a tamam bu developer mörsenebilir, hadi veriyorum e-proof'u gibi böyle cesaretli bir yaklaşımı
olamadı. Ama onlar da PR açmaya başladı.
Bir anda PR sayısı iki katına çıktı ama e-proof sayılarında değişiklik yoktu.
Bu süreç yavaşladı falan. Baya bir birbirimizi yediğimiz retromuz olmuştu ama sonra neyse ki düzenine oturttuk.
Gerçekten zor bir süreç ama en azından kolay bir şekilde atlatmışsınız.
Ben de şeyi sormak istiyorum.
Şu ana kadar böyle hep konuştuk, güzel güzel süreçlerden bahsettik.
Ama ekip olarak sizce gelişim alanı nedir Android Discord ekibinin?
Şöyle cevap verebilirim.
Bunu direkt kendi ekibim nezdinde değil, genel benim ideal dünyamdaki bir ekibim neye geliştirmesi gerektiğini kendi çabımda yorumlayayım.
Bence kesinlikle en geliştirmesi gereken şey feedback vermek ve almak konusundaki pozitif düşüncemiz.
Ekip içerisinde çalışırken feedback çekme çok önemli.
Çünkü bazen herhangi bir problem olabilir.
Bunlar illa çok büyük problemler olmak zorunda değil.
Bunları kendimiz fark etmeyebiliriz.
Karşımızdaki arkadaşımız fark etmeyebilir.
Bu düzenli feedbackleşmeyi yapmalıyız.
Çünkü bu hepimizin kesinlikle yararına ve...
iletişimi çok arttıran bir durum olduğunu düşünüyorum.
Pelin sen eklemek istediğin bir şey var mı?
Ya ben de kesinlikle katılıyorum.
Özellikle bugün bu sürecinde önceden olsa birbirimize sürekli iletişim halindeydik.
Artık iyice uzaklaşıyoruz.
Kiminle yönde iletişim kurmamız gerektiği yavaşlamaya başlıyor.
Mutlaka buna çok dikkat etmeliyiz.
Ben tamamen katılıyorum sana.
Peki. Genelde yani insanlar bence yani yazılım dünyasında böyledir.
Genelde sadece yöneticiler işte yönettiği ekiptekilerle birebir yaparlar vesaire.
Sizin kendi ekip içinde birbirinizle developer, bir developer bir developerla, bir productla işte bir QA bir developerla gelip birebir yaptığınız zamanlar oluyor mu?
Oluyor ama bunu hadi bire bir yapalım sana invite göndereyim şeklinde değil.
Şu şekilde yapıyoruz. Biz zaten payır halinde çalışıyoruz ama payırken iş konuşuyoruz.
Bir şeyi çözmeye çalışıyoruz.
Ve şöyle örnek vereyim. Mesela ben Pelin'le üç payır yaptım.
Dördüncü de Pelin'le 15 dakika sohbet edelim diyorum.
15 dakika açıyoruz, giriyoruz o zaman sohbet ediyoruz.
Orada zaten herhangi canımızı sıkan bir şey varsa konuşuyoruz.
Birimiz diğerimiz zaten gördüğümüzde ne konuşacağını anladığımız için artık bu iyi.
arkadaşlık sayesinde böyle birebirlerimiz oluyor.
Peki böyle birbirinize düzenli feedback veriyor musunuz?
Yani böyle ben sana şu an birebir atıyorum, senin böyle bir hareket yaptığını gördüm, bu beni çok kötü etkiledi, bunu çözmek için nerede yapabiliriz gibi böyle formal feedbackleşmeleriniz oluyor mu?
Ben henüz böyle çok negatif bir örneği yaşamadım açıkçası ama kesinlikle mesela badimle alandaki ilk girdiğim süreçteki zamanı anlatayım.
Çok kısa süreçte birbirimize feedback veriyorduk.
Çünkü bunun yapılan bir hatanın ya da hataya benzer ufak bir şeyin o anlık söylenmeyip iki gün daha devam etmesi belki daha kötü bir şeye sebep olabilir.
Bunu gayet yumuşak tatlı bir şekilde yani çok sert bir şekilde söylemeden birbirimize hemen uyarıyoruz.
Peki ekipte birbirinizle...
İşte anladığım kadarıyla sıcak bir ilişkiniz var ve aslında birbirinizi önemsiyorsunuz.
Bu bağlamda aslında bir arkadaşınızın motivasyonunu düşük gördüğünüzde bir işte toplantı içinde olabilir, payer çalışırken olabilir, bir gruptaki yazdıklarından öyle algılamış olabilirsiniz.
Bu gibi durumlarla karşılaştığınızda ekip arkadaşınızın motivasyonunu yükseltmek adına bir şeyler yapıyor musunuz?
Bunu dert edinip yaptığınız şeylerden herhangi bir örnek verebilir misiniz bize?
Ya böyle sürekli iletişim halinde kalınca ve artık birbirimizle karakterini daha fazla tanımaya başlayınca bazen ses tonundan veya bazen işte planlamada uzayan bir sohbetten artık o kişinin etkilenip etkilenmeyeceğini falan bilmiyorum.
Ben hani hissedebiliyorum ve böyle bir durum yaşanmasın diye genelde ne yaptın, ne ettin böyle goy goyla giriyorum.
Böyle konuşmaya çalışıyorum.
Eğer anlatmak istediği bir şey varsa dinlemeye çalışıyorum.
Ekip ile ilgili alakalı bir aksiyon alabilecek durumdaysak bunu aksiyonu mutlaka çevirmeye çalışıyorum.
Çünkü bence günde en az 8 saat biriyle çalışmak gerçekten ciddi bir zaman.
Ve bu zamanı mutsuz bir insanla geçirmek istemezsin.
Dolayısıyla işte arkadaş gibi dert dinleme veya işte böyle ciddi anlamda aksiyon alınacaksa buna dikkat edelim gibi böyle channel atma, konuşma, toplanalım gibi ilerletmeye çalışıyorum sürece açıkçası.
Pelin'le kesinlikle katılıyorum.
Bir yerden sonra beraber çalışıp birbirimizi tanıdığımızda Pelin de dediği gibi Pelin ben canım şuna sıktımdan ziyade Pelin yazdığım bir şeyden sabahki sesinden bir şekilde bunu anlayıp kendi zaten konuya girip bir
şekilde kesinlikle motivasyonunu yükseltmiş oluyor.
Son olarak bir sorum daha var.
Canlı sistemde en son yaşadığınız bir problemden bahsedebilir misin?
O problem neydi ve nasıl çözdünüz?
Size nasıl bir learning oldu bu?
Ya canlıda Çok şükür ki uzun zamandır böyle çok kritik durumla karşılaşmıyoruz.
En son bir şey vardı, ana sayfada görseller yüklenmiyordu.
Şöyle garip bir durum olmuştu.
Biz yakın bir tarihte paket çıkmamıştık.
Hani yeni bir paket çıksak geliştirilen bir iş bozmuştur diye yorum yapacağız.
Öyle bir şey yok. Nivrelik loklarına bakıyoruz.
Her şey normal görünüyor.
Son kapı inşallah Ayas'ta da bozuktur gibi bir umutla gidiyoruz ki suçu bekende atalım.
Ayas'ta canavar gibi çalışıyor falan.
Hiçbir şey eklemeden nasıl bu görseller gelmeye olabilir diye böyle bir şeye giriştik.
Daha sonra işte bir bakla falan çözdük durumu.
Şöyle bir durumla karşılaşmıştık.
Codebase'de bir tane uyguladığımız bir kod satırı var.
First, get first diye.
Onu first or null'a çevirmek.
Burada çok teknik konuşalım ama hani şunu önlem olarak almaya çalışmıştık.
Burada bu null check yapılmıyorsa proje gerekirse build olmasın, gerekirse testar fail olsun gibi bir önlem mi alsak dedik.
Bu birazcık bizim için uç bir case'di.
Onun dışında da hatırlamıyorum, hatırlamak da istemiyorum.
Yani böyle cevap bile vermek istemiyorum açıkçası.
Evet ya gerçekten insan unutmak istiyor ama en güzel öğrenimler de oradan geliyor.
Çok teşekkürler arkadaşlar katıldığınız için.
Android dünyasıyla alakalı bilmediğim yeni şeyler öğrendim sayenizde.
Nasıl Trendyol'un Android uygulaması geliştiriyor onunla alakalı yeni şeyler öğrendim.
Peki hangi şarkıyı söyleyeceksiniz bize?
Çünkü artık hazırlıklı gelmesi gerektiğini insanlar biliyor olmalı.
Can Saray'a atıyorum topu.
Söylemeyeceğiz de yan çizeceğiz sanıyorsunuz belki ama özenle seçilmiş bir şarkımız var.
Bütün sözlerinde ayrı bir anlam taşıyor.
Bu şarkıyı tüm ekip arkadaşlarımı armağan ediyorum.
Pelin bana eşlik edecek misin? Ben alkışla ve arada mırıldanmayla eşlik etsem bence okey değil mi?
Başlıyorum o zaman şarkımıza.
Tamam geliyorum arkadan. Ama biraz duygusal bir şarkı o yüzden baştan söyleyeyim.
Eğer modunuzu çok düşürecekse söylemeyebilirim şarkıyı.
Yok kesinlikle modumuz düşmez.
Çok hevesle bekliyoruz.
Peki. Tospik, Tospik, canım arkadaşım.
Hiç yalnız bırakmadım, hep yanındayım.
Tospik, Tospik, sen çok sevindin.
Senin çok sevdiğimi bilmelisin.
Bu da alkış bekliyorum.
Sanat desen var.
Gerçekten. Bu şarkıyı...
bütün arkadaşlarıma armağan ediyorum.
Android ekibi müzik konusunda çok başarılı diyebilir miyiz?
Bence diyebiliriz. Kesinlikle diyebiliriz.
Her podcast'ın sonunda şarkı söylemek için davet bekliyoruz.
Tabii her forumun sonunda aslında çağırabiliriz.
Bundan sonra evlerim tombik tombik söyleyeceğim.
Bu zamana kadar sonunda şarkı söylemeyen tüm ekipler için haydi bakalım.
Ben bu podcast'ın en çok bu anını bekledim.
Çok çalıştık biz. Çok çalıştık.
Domainleri falan bıraktık.
Çok hızlı geçti bence podcast.
Ben kesinlikle bir davet daha bekliyorum Pelin'le beraber.
Ne dersin Pelin? Tabii ki neden olmasın.
Pelin biraz gönülsüz tabii ki dedi ama 3 podcast'e bir gelsek keşke.
Ben konuşmayı seviyorum.
Biraz heyecanlandım ama sorulara her zaman cevap vermeye açığım yer.
Ne zaman isterseniz. Teşekkürler.
Çok teşekkür ederiz. Görüşmek üzere.
Biz teşekkür ederiz.
Teşekkürler.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.