Yarım kalan bir yazılım projesini devralmadan önce neye bakıyoruz

Önce proje gerçekten sizin elinizde mi, ona bakıyoruz

Kodun iyi ya da kötü olması ikinci soru. İlk soru, projeyi yürütmek için gereken her şeyin size ait olup olmadığı. Eski firma işi bıraktığında elinizde kodun son hali bir zip dosyası olarak kalmış olabilir. Sunucu, alan adı ya da uygulama mağazası hesabı ise hâlâ onların adına kayıtlı olabilir. Bu durumda yazılım kâğıt üzerinde sizindir ama onu güncelleyemezsiniz.

Bu adımda dört şeye bakıyoruz:

• Kaynak kod ve geçmişi. Kodun son halinin yanında, kimin neyi ne zaman değiştirdiğini gösteren geçmişini de istiyoruz. Bu çoğu projede bir Git deposu. Geçmiş, bir kararın neden alındığını ve koda en son nereden dokunulduğunu gösterir.
• Sunucu, veritabanı ve alan adı. Yazılımın nerede çalıştığına, bu hizmetlerin kimin adına kayıtlı olduğuna ve erişimin kimde olduğuna bakıyoruz.
• Dış hizmet hesapları. Ödeme altyapısı, SMS ve e-posta servisleri, harita gibi dış hizmetler ve mobil uygulama varsa App Store ile Google Play geliştirici hesapları. Uygulama eski firmanın hesabında yayındaysa mağaza kaydının sizin hesabınıza taşınması gerekir. Taşıma işlemini eski hesabın sahibi başlatır; bu yüzden ilişki bitmeden konuşulmalı.
• Mali haklar. Kod elinizde olsa bile hakları size devredilmemiş olabilir. Fikir ve Sanat Eserleri Kanunu'nun 52. maddesi, mali hakların devrinin yazılı yapılmasını ve devredilen hakların tek tek sayılmasını şart koşar. Sözleşmenizde bu maddeler var mı, ona bakıyoruz. Emin olamadığımız yerde hukukçunuza danışmanızı öneriyoruz; bu konuda son sözü biz söylemiyoruz.

Kendi projelerimizde kodun tamamı teslimde müşteriye geçiyor. Devraldığımız bir işte de aynı netliği arıyoruz, çünkü sahipliği belirsiz bir yazılımın üzerine kurulan her yeni iş sizi ileride zor durumda bırakabilir.

Kodu eski ekip olmadan çalıştırabiliyor muyuz?

Sonraki adımda kodu kendi bilgisayarlarımızda, eski ekipten hiç yardım almadan çalıştırmayı deniyoruz. Elimizde yalnızca depodaki dosyalar ve varsa kurulum notları oluyor. Bu deneme, belgelerin anlatmadığı eksikleri ortaya çıkarır. Bir ayar yalnızca eski geliştiricinin bilgisayarında kalmış, kullanılan paketlerin sürümleri kaydedilmemiş ya da kurulum adımları hiç yazılmamış olabilir.

Aynı soruyu yayına alma için de soruyoruz. Yeni bir sürüm sunucuya nasıl çıkıyor: bunu otomatik bir akış mı yapıyor, yoksa biri her seferinde elle mi yüklüyor? Ayrı bir test ortamı var mı? Otomatik testler yazılmış mı, yazıldıysa hâlâ geçiyor mu? Kodu çalıştıramadığımız ya da yayına alamadığımız her nokta rapora bulgu olarak giriyor. Yanına da düzeltmenin ne kadar süreceğini yazıyoruz.

Ekranda görünen her özellik bitmiş sayılmaz

Yarım kalan bir projede ekranlar bitmiş görünebilir. Bir ekranın açılması, arkasındaki işin bittiğini göstermez. Listedeki veriler sunucudan değil, koda elle yazılmış örneklerden geliyor olabilir. Bir filtre ekranda durur ama sonucu değiştirmez; bir düğmeye basınca hiçbir şey olmaz.

Bu yüzden sözleşmedeki ya da iş listesindeki her maddeyi uygulamada açıp tek tek deniyor ve üç durumdan birine koyuyoruz: çalışıyor, yarım, yok. Eski ekip Jira gibi bir iş takip aracı kullandıysa, orada “bitti” diye kapanmış işleri de bu denemeyle karşılaştırıyoruz. Ortaya çıkan tablo, sözleşmedeki işin ne kadarının gerçekten teslim edildiğini gösteriyor. Kalan işin süresini de bu tabloya bakarak hesaplıyoruz.

Riskleri ayrı bir listede veriyoruz

Bazı bulgular, projenin geleceğine karar verilmesini beklemeden kapatılmalı. Bunları raporun içinde kaybolmasın diye ayrı bir listede, aciliyet sırasıyla veriyoruz. Baktığımız başlıca konular şunlar:

• Şifreler ve erişim anahtarları kodun içine yazılmış mı, depoya girmiş mi?
• Kullanılan paketlerde bilinen bir güvenlik açığı var mı, paketler hâlâ güncelleme alıyor mu?
• Ad, telefon, adres ve TC kimlik numarası gibi kişisel veriler nerede ve nasıl saklanıyor? KVKK açısından risk taşıyan bir durum var mı?
• Yedek alınıyor mu? Alınıyorsa o yedekten geri yükleme hiç denenmiş mi? Denenmemiş bir yedeğin işe yarayıp yaramayacağı bilinmez.
• Ödeme alınıyorsa, para çekildiği hâlde siparişin oluşmadığı bir durum var mı?

Kişisel veri ve ödemeyle ilgili bulgular, yazılım yayında kaldığı her gün risk taşıdığı için listenin başına geçiyor.

Devam mı, baştan mı: iki yolun maliyetini yan yana koyuyoruz

Yeni gelen bir ekip için en kolay öneri “baştan yazalım” olur. Başkasının yazdığı kodu okumak, yenisini yazmaktan zordur. Stack Overflow'un kurucularından Joel Spolsky, 2000 yılında yazdığı bir yazıda bunu programlamanın temel kurallarından biri sayar. Aynı yazıda Netscape'in tarayıcısını baştan yazma kararını, bir yazılım şirketinin yapabileceği en kötü stratejik hata olarak anlatır. Yazı yayımlandığında Netscape yaklaşık üç yıldır yeni bir ana sürüm çıkaramamıştı.

Biz iki yolun süresini ve maliyetini yan yana koyuyor, hangisi sizin için daha ucuz ve daha az riskliyse onu öneriyoruz. Genelde şu durumlara bakıyoruz:

Cevap ikisinin arasında da çıkabilir: sağlam kısımlar kalır, sorunlu bir bölüm yeniden yazılır. Proje bizim iyi bilmediğimiz bir teknolojiyle yazılmışsa bunu da raporda açıkça yazıyoruz. Yapamayacağımız işe girmiyoruz; gerekirse sizi bu işi yapabilecek bir ekibe yönlendiriyoruz.

İncelemenin sonunda elinize ne geçiyor

İnceleme birkaç gün sürüyor ve ön değerlendirmemizin bir parçası olduğu için ücretsiz. Sonunda size yazılı bir rapor veriyoruz. Raporda dört bölüm var:

• Durum: Neyin çalıştığı, neyin yarım kaldığı ve neyin hiç yapılmadığı.
• Riskler ve güvenlik bulguları: Ayrı bir listede, aciliyet sırasıyla.
• Önerimiz: Mevcut kodla devam mı, baştan mı, yoksa ikisinin karışımı mı; gerekçesiyle.
• Kalan iş, süre ve fiyat: Önerdiğimiz yolun iş listesi ve teklifimiz.

Rapor sizde kalıyor; projeye bizimle devam etmek zorunda değilsiniz. Devam ederseniz raporda yazan süre ve fiyatla çalışıyoruz. Ödemeyi iş bittiğinde ve siz “oldu” dediğinizde alıyoruz. Yazdığımız kodun tamamı da sizin oluyor. Çalışma biçimimizin ayrıntısı Nasıl çalışırız sayfasında.

Eski ekiple yollarınız ayrılmadan bunları isteyin

Kiminle devam ederseniz edin, aşağıdakileri eski ekipten ilişki bitmeden istemeniz devralmayı kısaltır. İlişki bittikten sonra bunların bir kısmını almak zorlaşır, bazılarını almak hiç mümkün olmayabilir.

• Kaynak kodun tamamı, değişiklik geçmişiyle birlikte (Git deposu)
• Sunucu, veritabanı ve alan adı erişimleri; hangisinin kimin adına kayıtlı olduğu
• Ödeme, SMS, e-posta ve harita gibi dış hizmetlerin hesapları
• Mobil uygulama varsa App Store ve Google Play hesapları ya da uygulamanın sizin hesabınıza taşınması
• Ortam ayarları ve şifreler; e-postayla değil, şifre yöneticisi gibi güvenli bir yoldan
• Tasarım dosyaları (ör. Figma) ve iş takip kayıtları (ör. Jira)
• Bilinen hataların ve yarım kalan işlerin listesi
• Mali hakların size devredildiğini gösteren yazılı belge
• Mümkünse eski ekiple bir saatlik bir devir görüşmesi