Yapay Zekayla Geliştirdiğin Uygulama İlk Sürümünü Aştığında: Refactor mu, Yeniden Yazmak mı?

Bir şey yayınladın. Kullanıcılar bayıldı. Şimdi on kullanıcın var ve ihtiyaçları geliştirdiğin şekle sığmıyor. İşte mevcut uygulamayı refactor mı edeceğine, yoksa onun bir prototip olduğunu kabul edip doğru şekilde yeniden mi kuracağına nasıl karar verirsin.

Bir şey yayınladın. Kullanıcılar bayıldı. Şimdi on kullanıcın var ve orijinal şekle sığmayan özellikler istiyorlar. Bir çatal yolun başındasın: uygulamayı yeni kullanım durumuna uydurmak için yamamak mı, yoksa ilk sürümün bir prototip olduğunu kabul edip onu doğru kurmak mı. Bu, diğer her sorudan daha çok küçük projeyi öldüren sorudur, çünkü teknik bir cevabı yok — yalnızca iş açısından bir cevabı var.

Uygulamanın başarılı olduğunu fark ettiğin an

Yapay zekayla geliştirilen çoğu uygulama bir şey olarak başlar ve başka bir şey olur. Koçluk işin için bir müşteri kayıt formu geliştirdin; şimdi müşteriler geçmiş randevuları görmek ve kendi kendilerine yeniden randevu almak istiyor. Bir potansiyel müşteri puanlama aracı geliştirdin; şimdi satış ekibin özetlerin CRM’lerine aktarılmasını istiyor. Bir dosyalama sistemi geliştirdin; şimdi insanlar onun içinde işbirliği yapmak istiyor.

Her talep makul. Her biri uygulamayı, kurulduğu şeyden biraz uzaklaştırıyor. Ve belirli bir noktada — altı ay sonra ya da iki ay, bazen iki hafta — sürtünmeyi hissedersin. Eklediğin her şey temele karşı savaşıyor. Yeni özellikler “ah, önce o kısmı yeniden düzenlememiz gerek” gerektiriyor. Uygulama yavaşlıyor. Bir şeyleri değiştirmek daha uzun sürüyor.

O his, bunun hâlâ aynı uygulama mı olduğunu, yoksa onu aşıp aşmadığını düşünmen için sinyalindir.

Refactor’ın getirisi ve maliyeti

Refactor, aynı uygulamayı tutmak ama üzerine daha fazla geliştirebilesin diye onu temizlemek demektir. Yapay zeka oluşturucundan kodu yeniden düzenlemesini, aşırı karmaşık bir iş akışını bölmesini ya da özellikler için bir çöplük haline gelmiş bir ekranı yeniden tasarlamasını istersin. Birkaç saat sürer. Yeni özellik eklemez. Sadece temeli daha güçlü yapar.

Refactor işe yaradığında, sihirdir. Uygulamaya karşı savaşıyormuş gibi hissediyordun; aniden savaşmıyorsun. Bir haftada, daha önce üç hafta sürecek üç yeni özellik eklersin.

Ama refactor yalnızca sorun elindekinin şekliyse işe yarar. Bir kayıt formu geliştirdiysen ve kullanıcılar daha hızlı bir kayıt formu istiyorsa, yavaş kısmı refactor etmek bir öğleden sonradır. Hem daha hızlı hem de geçmiş saklayan bir kayıt formu istiyorlarsa, bu hâlâ tek bir uygulamadır ve refactor yardımcı olabilir. Ama randevu geçmişi, takvim entegrasyonları, SMS hatırlatmaları ve faturalama istiyorlarsa, artık daha iyi bir kayıt formu geliştirmiyorsun — bir koçluk işinin arka ofisini geliştiriyorsun. Bu farklı bir ürün.

Yeniden yazmanın getirisi ve maliyeti

Yeniden yazmak şu demek: uygulamanın gerçekte ne olması gerektiğini öğrendin ve onu o bilgiyle sıfırdan geliştireceksin. İlk sürümü çöpe atmazsın — kullanıcıların hâlâ ona bağlı. Ama eskisinin sana öğrettiğiyle bilgilenmiş yeni bir uygulamayı sıfırdan geliştirirsin ve hazır olduğunda kullanıcıları taşırsın.

Yeniden yazmak israf gibi hisseder. Bir şey geliştirdin ve şimdi onu yeniden geliştiriyorsun. Bu psikolojik maliyettir. Pratik maliyet zamandır: yeni sürüm üzerinde kullanıcıları taşımaya hazır olmadan önce iki ila dört ay harcarsın. Artık ilk sürümü bir koltuk değneği olarak kullanamayacaksın — ağsız ileri itiyorsun.

Ama yeniden yazmak sana başka hiçbir şeyin sağlayamayacağı bir şey kazandırır: özgürlük. Yeni uygulama eskisinin şekliyle kısıtlanmaz. Orijinali basit bir formsa ve yenisi tam bir arka ofis olmalıysa, bunu en baştan tasarlarsın. Performans önemliyse, onun için tasarlarsın. Güvenlik, entegrasyonlar ya da iş akışı önemliyse, bunlar sonradan eklenen yamalar değil — temeldir.

Yeniden kurulumdan sonra başarılı olan uygulamalar genellikle bunu, ekibin sorunu anlama biçiminin orijinal koddan o kadar uzaklaşmış olması sayesinde yapar ki, yamamaya çalışmak tam oturmayan kıyafetler giymek gibi gelir. Yeniden yazmak, başkaları için değil kendileri için geliştirmek demekti.

Aralarında seçim yapmak için üç soru

Soru 1: Temel şekil hâlâ doğru mu?

Temel şeklin, uygulamayı tanımlayan bir ya da iki ana iş akışıdır. Bir koçluk kayıt formu için bu “müşteri kayıt formunu doldurur, koç inceler, koç randevu verir”dir. Farklı iş akışları ekliyorsan — faturalama, takvim yönetimi, müşteri mesajlaşması — temeli genişletmiyorsun, yan özellikleri cıvatalıyorsun. Bu, farklı bir ürün geliştirdiğinin işaretidir, yani yeniden yazmak.

Aynı temelin varyasyonlarını ekliyorsan — “bireyler için kayıt, ekipler için kayıt, özel alanlarla kayıt” — bu hâlâ aynı uygulamadır. Refactor et ve genişlet.

Soru 2: Bugün refactor edersen, sürtünme tekrar gelene kadar kaç ay daha var?

Dürüst ol. Sürtünme altı ay gidiyorsa, refactor doğru hamledir. İki ay içinde tekrar acıtacaksa, çünkü sorun kod şekli değil temelin kendisiyse, yeniden yazmak seni iki kez yamamanın sahte tasarrufundan kurtarır. Yapay zeka oluşturucuna sor: “Bunu temizlersek, bunu tekrar yapmamız gerekene kadar ne kadar var?” Cevap “muhtemelen çok değil”se, yeniden kurma zamanı.

Soru 3: Kullanıcıların gerçekte neye bağlı?

v1’de üç aktif kullanıcın varsa ve yeniden kurmayı düşünüyorsan, onları bir iki günde taşıyabilirsin. Mevcut uygulamaya üretim açısından bağımlı elli kullanıcın varsa, yeniden yazmak her iki sürümü de aylarca çalışır tutmak zorunda olman demektir, ki bu kendi içinde bir acıdır.

Genellikle işe yarayan yol

Başarıyla yeniden kuran çoğu kurucu bunu paralel yapar: orijinal uygulamayı çalışır tutar ve yenisini geliştirmek için yedek kapasiteyi kullanır. Yenisi eskisiyle özellik denkliğine ulaştığında, veri ve kullanıcıları taşımak için bir hafta harcarlar ve işleri biter.

Genellikle işe yaramayan yol: refactor, refactor, refactor, ta ki üç refactor sonra mimarinin hâlâ yanlış olduğunu fark edene ve artık “eski” sürüme bunu kabul edip sıfırdan başlayamayacak kadar yatırım yapmış olana kadar.

Karar vermenin doğru zamanı

Bir dahaki sefere sürtünmeyi hissettiğinde kendine sor: “Bu uygulamanın yapması gereken şeyi daha iyi mi yaptırıyorum? Yoksa ondan hiç tasarlanmadığı bir şey olmasını mı istiyorum?” İlkiyse, refactor et. İkincisiyse, en baştan olması gereken şeyi geliştirmenin utanılacak bir yanı yok. Başarılı uygulamaların çoğu temelin 1. değil, 2. sürümündedir.