Türkiye'nin en büyük inovasyon ve girişimcilik bültenine katılın
Kanallar İlham Uygulamalar SSS Sözlük Giriş Üye Ol

Yazılım Geliştirme

/yazilim · 8.YIL

Fikirden çalışan ürüne yazılımın her hali: web, backend, veritabanı, mimari kararlar, kod kalitesi ve araçlar. Dil ve framework fark etmez; yazan herkesin ortak kanalı.

25 içerik Katıl
#yazılım geliştirme akışına dön
@nikea · 17 gün önce

legacy koda dokunmak: üç yıllık bir projeyi devraldım, nereden başladım

Şirkete girdiğimde ortada belgesi olmayan, testi olmayan ve yazanların hiçbiri kalmamış bir sistem vardı. Panik yapmadan ilerlemenin bir yolu var, izlediğim sırayı yazayım.

İlk hafta: hiçbir şeye dokunmadım. Sadece okudum ve çalıştırdım. Sistemi ayağa kaldırmak üç gün sürdü ve bu süreç zaten çok şey öğretti.

Bu aşamada yaptığım tek yazma işi, kurulum adımlarını bir dosyaya not etmek oldu. Sonraki kişi için ilk hediye bu.

İkinci hafta: haritayı çıkardım. Hangi modül ne yapıyor, hangi dış sisteme bağlanıyor, veri nereden geliyor. Bir sayfalık kaba bir şema çizdim ve duvara astım.

Üçüncü hafta: emniyet ağı kurdum. Koda dokunmadan önce, mevcut davranışı doğrulayan testler yazdım. Birim testi değil, uçtan uca birkaç senaryo. Amaç doğru çalıştığını kanıtlamak değil, değiştirdiğimde bozulduğunu fark etmek.

Bu aşama en sıkıcı ama en kritik olanı. Testsiz legacy koda dokunmak, karanlıkta yürümek.

Dördüncü hafta ve sonrası: küçük ve izole değişiklikler. Her seferinde tek bir şey. Büyük yeniden yazma cazip geliyor ama neredeyse her zaman kötü bitiyor.

Öğrendiğim şeyler:

Anlamadığınız kodu silmeyin. Tuhaf görünen bir kontrol, muhtemelen bir olay sonucu eklenmiş.

Versiyon geçmişine bakın. Bir satırın neden eklendiğini commit mesajından öğrenebiliyorsunuz.

Eski çalışanları bulun. Bir saatlik sohbet, iki haftalık okumaya bedel.

Dokunduğunuz her yeri belgeleyin. Yeniden yazmaya kalkmadan önce anlaşılır hale getirin.
0 3 yorum
Yorumlar (3)
@erayuzun · 14 gün önce 1
Anlamadığınız kodu silmeyin uyarısı çok doğru, buna Chesterton çiti deniyor ve gerçekten işe yarıyor.

Bizde biri tuhaf görünen bir kontrolü temizlik yaparken silmişti. İki ay sonra belirli bir müşteride hata çıktı, sebep o kontroldü.

O satır, yıllar önce bir müşteri kaynaklı veri bozukluğu için eklenmişmiş.

Çözüm olarak şu alışkanlığı edindik: tuhaf bir kod görünce silmek yerine yanına neden var olduğunu araştırıp yorum yazıyoruz. Silmek ancak sebebini bulduktan sonra.
@dandanakan · 11 gün önce 0
Uçtan uca testle emniyet ağı kurma yaklaşımı doğru ama bir zorluğu var, onu ekleyeyim.

Legacy sistemlerde test ortamı kurmak genelde en zor kısım. Veritabanı bağımlılıkları, dış servis çağrıları, sabit yapılandırmalar.

Bizde işe yarayan ara çözüm, karakterizasyon testi yazmaktı. Sistemi mevcut haliyle çalıştırıp çıktıyı kaydediyorsunuz, sonra değişiklikten sonra aynı girdiyle çıktıyı karşılaştırıyorsunuz.

Doğru olup olmadığına bakmıyorsunuz, aynı olup olmadığına bakıyorsunuz. Legacy için yeterli ve kurması kolay.
@titus · 9 gün önce 4
Büyük yeniden yazmanın neredeyse her zaman kötü bittiği konusunda tam olarak aynı fikirdeyim.

İki kez yaşadım. İkisinde de yeni sistem eskisinin özelliklerini yakalayamadan bütçe bitti.

Sebebi şu: eski sistem yıllar içinde yüzlerce küçük iş kuralı biriktirmiş ve bunların hiçbiri yazılı değil. Yeniden yazarken onları kaçırıyorsunuz ve her biri bir müşteri şikâyeti olarak geri geliyor.

Kademeli değiştirme daha yavaş görünüyor ama bitiyor. Yeniden yazma hızlı görünüyor ve bitmiyor.