Yarıda kalan yazılım projesi: devralmak mı, baştan yazmak mı?

Firma ayrıldı, proje elinizde kaldı. İlk refleks "baştan yazalım" olur ve çoğu zaman en pahalı karardır. Devir envanteri, teknik inceleme ve kararı veren gerçek ölçüt.

Devralma şeması: yarıda kesilen bir yapının üzerine eklenen yeni katman ile baştan kurulan yapının karşılaştırması

Firma ayrıldı, iletişim koptu ya da sözleşme kötü bitti. Proje yarım, elinizde bir depo adresi ve çalışıp çalışmadığını bilmediğiniz bir sunucu var.

Bu noktada duyacağınız en yaygın cümle şudur: “Bunu devralmaktansa baştan yazmak daha ucuz.” Bazen doğrudur. Ama çoğu zaman bu cümle, kodu okumak istemeyen bir ekibin kestirme yoludur — ve size iki kere ödetir.

Önce erişimleri toplayın: bu teknik değil, hukuki bir iştir

Kod devrinden önce yapılması gereken şey kodla ilgili değil. Şunların sizin adınıza olduğunu doğrulayın:

  • Depo (repo) ve tüm commit geçmişi
  • Alan adı ve DNS yönetimi
  • Sunucu, bulut hesabı, veritabanı
  • Ortam değişkenleri ve gizli anahtarlar
  • Ödeme, e-posta, SMS, harita gibi üçüncü taraf hesaplar
  • En güncel veritabanı yedeği

Bu listeyi ilişki bozulmadan isteyin. Sözleşme kötü bittikten sonra erişim toplamak, teknik bir sorundan çok bir avukatlık işine döner. Bir sonraki firmayla çalışırken her şeyin ilk günden sizin adınıza açılmasını şart koşun; bu maddeyi atlamak, sonradan düzeltilmesi en pahalı hatadır.

Teknik inceleme: bir hafta, altı soru

Devralma kararı tahminle verilmez. Bir haftalık bir inceleme şunları çıkarır:

  1. Bağımlılıklar kaç yaşında? İki büyük sürüm geride kalmış bir çatı, güncelleme maliyetini projenin yarısına çıkarabilir.
  2. Test var mı? Testi olmayan kodda hiçbir değişiklik güvenli değildir; her dokunuş kumar olur.
  3. Dağıtım nasıl yapılıyor? Elle FTP ile dosya atılıyorsa geri alma diye bir şey yoktur.
  4. Veritabanı şeması tutarlı mı? Kod düzeltilebilir, bozuk veri modeli düzeltilemez — taşınır.
  5. Güvenlik açığı var mı? Bilinen açıklı bağımlılık, açıkta kalan anahtar, eksik yetki kontrolü. Ayrıntısı web sitesi güvenliği yazısında.
  6. Kod okunabiliyor mu? “Çalışıyor” ile “sürdürülebilir” aynı şey değildir. Asıl maliyet buradadır.

İncelemenin çıktısı tek bir cümle olmalı: devralmanın maliyeti şu, baştan yazmanın maliyeti bu.

Kararı veren ölçüt

Teknoloji seçimi değil, iş mantığının değeri.

Bir sistem yıllarca kullanıldıysa, içinde kimsenin hatırlamadığı yüzlerce kenar durum vardır: şu müşteri tipinde iskonto farklı işler, şu belgede vergi ayrı hesaplanır. Bunlar hiçbir yerde yazılı değildir — yalnızca kodda dururlar.

Baştan yazmak, o bilgiyi sıfırlamak demektir. Yeni sistem altı ay boyunca “eskisi bunu yapıyordu” şikâyetiyle yaşar. Eski kod çirkin olabilir ama öğrenilmiş bir şeyi taşır.

Buna karşılık şu durumlarda baştan yazmak doğrudur: çatı artık güvenlik yaması almıyorsa, veri modeli işin bugünkü hâlini taşıyamıyorsa, ya da sistem zaten kullanılmadıysa — yani korunacak bir öğrenme yoksa.

Geçiş dönemi

Devralan ekibin ilk işi özellik geliştirmek olmamalı. Sırayla: dağıtım hattını kurmak, yedeğin gerçekten geri yüklenebildiğini doğrulamak, kritik akışlara test yazmak. Bunlar bitmeden yeni özellik eklemek, yanan binaya kat çıkmaktır.

Bu üç adım genelde iki-üç hafta sürer ve görünür hiçbir şey üretmez. Bunu baştan bütçelemeyen proje, aynı aşımı ikinci kez yaşar.

Elinizdeki projeye bir hafta bakıp iki maliyeti yan yana koymamızı isterseniz görüşme planlayalım. Yeni bir ekiple sıfırdan başlayacaksanız süre beklentisini baştan doğru kurun.

İlgili yazılar

Fikirden yayına yükselen yedi basamaklı süreç şeması
Yazılım Geliştirme

Yazılım yaptırmak: fikirden yayına yedi adım

Yazılım yaptırmak isteyen bir işletme için sıra: ihtiyacı yazmak, hazır çözümü elemek, bütçe ve takvim aralığı koymak, teklif toplamak, sözleşme, geliştirme ve devir. Her adımda sizin yapmanız gerekenler.

Devamını oku

Bir fikriniz mi var, yoksa duran bir ürün mü?

Kısa bir görüşmede kapsamı netleştirelim. İlk konuşmada teknik yaklaşımı ve tahmini bütçe aralığını konuşuruz.

Bize yazın