Kafayı yiyecektim. Patron "Haftaya kadar bu veriler taşınacak" dediğinde, "Tamam abi, hızlıca bir script yazar hallederiz" demiştim. İki yıl sonra, o "hızlıca" yazdığım bot, şirketin tüm finansal raporlamasını besleyen can damarına dönüştü. Ve şu an onu anlayabilen tek kişi benim, o da zorla.
"Geçici"nin Kalıcılığı</B]
O zamanlar acelen vardır ya, Python ile pandas ve requests kütüphanelerini kullanarak, iki API'yi birbirine bağlayan basit bir script fırlatmıştım ortaya. İçinde "TODO: Refactor later" yazan yorum satırları, hata yakalama bloklarından çok daha fazlaydı. Mantık basitti: A'dan çek, biraz şekillendir, B'ye at. İş bitti, script de kapanacaktı. Meğerse iş hiç bitmeyecekmiş.
Kabus Başlıyor: "Bu Nasıl Çalışıyor Ki?"</B]
Geçen hafta, kaynak sistemdeki bir alan adı değişti. Bot patladı tabii. Ekibin yeni mühendisi bana geldi, "Abi loglara baktım da, bu `transform_data` fonksiyonu neden 3 kere farklı formatta JSON döndürüyor?" diye sordu. Ben de donup kaldım. O fonksiyonu yazarkenki mental durumumu hatırlamaya çalıştım. StackOverflow'da bile bulamazsın bu karmaşayı. Meğerse sorun, iki yıl önceki bir API değişikliğine uyum sağlamak için scriptin ortasına eklediğim, ama asıl mantığı hiç silmediğim geçici bir koşuldaymış. Şaka gibi ama, o koşul artık her zaman `True` dönüyordu.
Dokunmaya Korkulan Kod</B]
Şimdi elimde, içinde kimsenin dokunmaya cesaret edemediği, 1500 satırlık bir "geçici çözüm" var. Yeni gelen herkes bu koda baktığında "Bu çalışıyorsa sakın dokunma" kuralını öğreniyor. Dokümantasyon mu? Ona da "Kodun kendisi dokümantasyondur" diyerek gülüp geçmişim. Yazık bana. Artık bu canavarı refactor etmek, orijinali çalışır halde tutup yanına yenisini yazmaktan daha riskli hale geldi.
İşin komik (ya da trajik) tarafı, o bot olmadan şirket durma noktasına geliyor. "Geçici" diye başlayan her proje, sistemin en kritik parçası olmaya mahkum mudur sizce de? Bu kodu temizlemek için bir plan yapmam lazım ama nereden başlayacağımı bile bilmiyorum. Siz de böyle "geçici" bir şey yazıp, sonra onunla yaşamaya mahkum olduğunuz oldu mu? Bu tür bir "teknik borç" canavarını nasıl ve ne zaman ele almalı?
"Geçici"nin Kalıcılığı</B]O zamanlar acelen vardır ya, Python ile pandas ve requests kütüphanelerini kullanarak, iki API'yi birbirine bağlayan basit bir script fırlatmıştım ortaya. İçinde "TODO: Refactor later" yazan yorum satırları, hata yakalama bloklarından çok daha fazlaydı. Mantık basitti: A'dan çek, biraz şekillendir, B'ye at. İş bitti, script de kapanacaktı. Meğerse iş hiç bitmeyecekmiş.
Python:
# TODO: Bu kısım çok kırılgan, düzeltilecek! (2022)
data = merge(df_old, df_new, how='left') # Kim 'left' join'i ne için kullandıysa...Geçen hafta, kaynak sistemdeki bir alan adı değişti. Bot patladı tabii. Ekibin yeni mühendisi bana geldi, "Abi loglara baktım da, bu `transform_data` fonksiyonu neden 3 kere farklı formatta JSON döndürüyor?" diye sordu. Ben de donup kaldım. O fonksiyonu yazarkenki mental durumumu hatırlamaya çalıştım. StackOverflow'da bile bulamazsın bu karmaşayı. Meğerse sorun, iki yıl önceki bir API değişikliğine uyum sağlamak için scriptin ortasına eklediğim, ama asıl mantığı hiç silmediğim geçici bir koşuldaymış. Şaka gibi ama, o koşul artık her zaman `True` dönüyordu.
Dokunmaya Korkulan Kod</B]Şimdi elimde, içinde kimsenin dokunmaya cesaret edemediği, 1500 satırlık bir "geçici çözüm" var. Yeni gelen herkes bu koda baktığında "Bu çalışıyorsa sakın dokunma" kuralını öğreniyor. Dokümantasyon mu? Ona da "Kodun kendisi dokümantasyondur" diyerek gülüp geçmişim. Yazık bana. Artık bu canavarı refactor etmek, orijinali çalışır halde tutup yanına yenisini yazmaktan daha riskli hale geldi.
İşin komik (ya da trajik) tarafı, o bot olmadan şirket durma noktasına geliyor. "Geçici" diye başlayan her proje, sistemin en kritik parçası olmaya mahkum mudur sizce de? Bu kodu temizlemek için bir plan yapmam lazım ama nereden başlayacağımı bile bilmiyorum. Siz de böyle "geçici" bir şey yazıp, sonra onunla yaşamaya mahkum olduğunuz oldu mu? Bu tür bir "teknik borç" canavarını nasıl ve ne zaman ele almalı?