Ucuz Kodun Ağır Bedeli: "Frankenstein" Kod Tabanınız Neden Sürdürülemez?

Ürününüzün kod tabanına bakıyorsunuz ve tanıyamıyorsunuz.

Hızlıca inşa edildi. Geçen yıl popüler bir platformdan yüksek puanlı üç farklı freelancer ile çalıştınız. Uygun fiyatlılardı ve hemen müsaittiler.

Başlangıçta özellikler hızlıca çıktı.

Şimdi ise geliştirme süreci durma noktasına geldi.

Kod tabanınız, yarım kalmış fikirlerin ve çakışan mimari stillerin mezarlığına dönmüş durumda. Bu, merkezi bir sinir sistemi olmayan, oradan buradan toplanmış parçalarla oluşturulmuş bir "Frankenstein" ürünü.

Bu kötü şans değil. Bu, karmaşık yazılım mühendisliğine "gig economy" (geçici iş) modelinin uygulanmasının kaçınılmaz sonucudur.

Uyumlu bir ekip yerine birbirinden kopuk bireyleri işe aldığınızda, aslında taksitli bir teknik borç satın almış olursunuz.

Birleştirici bir mühendislik liderliği olmadığında yaşanan gerçek şudur:

Freelancer modelinin gizli maliyetleri

Kötü yazılımcıları işe almadınız. Muhtemelen yanlış şeye odaklanan zeki insanları işe aldınız.

Geçici bir freelancer hıza ve bilet (ticket) kapatmaya odaklanır. Uzun vadeli sürdürülebilirliğe veya kodlarının, geçen ay kovduğunuz kişinin yazdığı modülle nasıl etkileşime gireceğine nadiren odaklanır.

Atanmış bir Mühendislik Yöneticisi veya Baş Mimar (Lead Architect) olmadan, ciddi ve katlanarak artan risklerle karşılaşırsınız:

• Hız çakılması: Her yeni özellik, mevcut iki yeri bozar. Mevcut ekibiniz zamanının %80'ini değer üretmek yerine yangın söndürmeye harcar.
• Tehlikeli bilgi siloları: "Freelancer A" ayrılırsa, ödeme modülünü kimse anlayamaz. Dokümantasyon sıfırsa, devir teslim de sıfırdır. Kötü kod tarafından rehin alınırsınız.
• Finansal kanama: Kıdemli (senior) yazılımcı ücreti ödüyorsunuz ama spagetti kodu çözmekle uğraştıkları için başlangıç seviyesi (junior) çıktı alıyorsunuz. Refactoring (kod iyileştirme) maliyetinin, işi baştan doğru yapmaktan 3 kat daha pahalıya mal olduğunu sıkça görüyoruz.
• Ölçeklenemeyen mimari: Teknoloji yığını (tech stack), o anki freelancer hangi aracı tercih ettiyse onun rastgele bir karışımıdır. Bu yapı 10 kat kullanıcı büyümesini kaldıramaz.

Çöküşteki bir kod tabanı nasıl stabilize edilir?

Bu durum tanıdık geliyorsa, bir kurtarma operasyonuna ihtiyacınız var.

Sadece "görev tamamlayanları" işe almayı bırakıp gerçek bir mühendislik fonksiyonu oluşturmaya başlamalısınız. Şu an klavye başında daha fazla ele değil, bir beyne ihtiyacınız var.

Kaotik bir kod tabanını sürdürülebilir bir ürüne dönüştürmenin oyun planı şudur:

• Acımasız bir denetim yapın: Yeni özellik geliştirmeyi hemen durdurun. Hasarı tespit etmesi için kıdemli bir mimar getirin. Güvenlik risklerini, performans darboğazlarını ve mimari çıkmazları belirleyin.
• Merkezi liderlik kurun: Bu tartışmaya kapalıdır. Bir Lead Developer veya Fractional (Yarı Zamanlı) Mühendislik Yöneticisine (EM) ihtiyacınız var. Biri "nasıl" yapılacağını sahiplenmelidir. Standartları onlar belirler ve vizyonu onlar uygular.
• İş akışını standartlaştırın: Ana branch'e doğrudan push (gönderme) yapmak yok. Zorunlu Pull Request (PR) incelemelerini uygulayın. Otomatik testleri (CI/CD) kurun. Herkesin kodunun aynı görünmesi için katı "linting" kuralları getirin.
• Borcu sistematik olarak ödeyin: Her şeyi bir anda baştan yazmaya çalışmayın. Her sprint'in %20-30'unu, yavaş yavaş yeni değer üretirken sistemin en kötü kısımlarını iyileştirmeye (refactoring) ayırın.

Gerçek dünyadan bir kurtarma hikayesi

Yakın zamanda, iki yıl boyunca beş kopuk freelancer tarafından inşa edilmiş bir lojistik platformunu devraldık.

Deployment (canlıya alma) süreci dört saat sürüyor ve sıklıkla canlı sistemi çökertiyordu. Kurucular koda dokunmaktan korkuyordu.

Beş freelancer'ı, yönetilen bir "pod" (iki kıdemli full-stack geliştirici ve bir yarı zamanlı Mühendislik Yöneticisi) ile değiştirdik.

Deployment süreçlerini standartlaştırdık ve sıkı test süreçleri getirdik.

İlk 90 günde deployment süresini 15 dakikaya indirdik. Daha da önemlisi, geliştiriciler her "commit"te sistemi bozmaktan korkmadığı için yeni özellik çıkarma hızı ikiye katlandı.

Ucuz başlangıç geliştirmesi, genellikle bir kurucunun yaptığı en pahalı hatadır.

Bir mezarlık inşa etmeyin.

Kod tabanınız bir tuzak gibi hissettiriyorsa, bir denetim (audit) için konuşalım.