Yarım kalan yazılım projesini devralmak

Yarım kalan yazılım projesi devralınabilir mi?

Evet, yarım kalan yazılım projesi çoğu zaman devralınabilir ve her zaman baştan yazmak gerekmez. Geliştirici ayrılmış olabilir, ajans kapanmış olabilir ya da iş bir noktada tıkanmış olabilir. Sebep ne olursa olsun, elinizde çalışan bir parça varsa onu kurtarmak genellikle mümkündür.

Ama önce ne olduğunu bilmek gerekir. Bu yazıda bir projeyi devralırken izlediğimiz sırayı anlatıyoruz. Aynı listeyi, işi başka biriyle devam ettirecek olsanız da kullanabilirsiniz.

İlk hafta ne yapılmalı?

İlk hafta kod yazılmaz, erişimler toplanır. Projenin çalıştığı her yerin anahtarı sizin elinizde olmalıdır. Aksi hâlde yeni ekip işe başlasa bile bir hesabın şifresi yüzünden aylarca beklenebilir.

Aşağıdaki listeyi tek tek işaretleyin. Her kalemde iki soru sorun: Bu hesap kimin adına? Şifreyi ve yetkiyi kim değiştirebilir?

Alan adı ve sunucunun neden sizin adınıza olması gerektiğini alan adı ve hosting kimin adına olmalı yazısında ayrıntılı anlattık. Alan adı başka bir kayıt firmasına taşınacaksa genellikle bir transfer kodu gerekir. Genel alan adlarında bu kuralları ICANN belirler. .tr uzantılı alan adlarında süreç farklı işler. Kayıt firmanıza danışın.

Kod incelemesinde neye bakılır?

Kod incelemesi, projenin şu anki gerçek durumunu gösterir: ne çalışıyor, ne çalışmıyor, ne riskli. Söylenen değil, çalışan esas alınır. Biz inceleme sırasında şunlara bakarız:

• Çalışıyor mu: Proje yeni bir bilgisayarda sıfırdan kurulup ayağa kalkıyor mu?
• Güncel mi: Kullanılan dil, çatı ve kütüphane sürümleri hâlâ destekleniyor mu?
• Güvenli mi: Şifreler ve anahtarlar kodun içine yazılmış mı? Bilinen açıklar var mı?
• Test var mı: Otomatik testler var mı, varsa geçiyor mu?
• Veri sağlam mı: Veritabanı yapısı mantıklı mı, veri tutarlı mı?
• Anlaşılır mı: Başka bir geliştirici kodu okuyup devam edebilir mi?

Bu maddelerde zamanla biriken ve ileride daha pahalıya düzeltilecek sorunların toplamına teknik borç denir. İncelemenin sonunda yazılı bir durum raporu çıkar. Raporda neyin sağlam olduğu, neyin düzeltilmesi gerektiği ve neyin baştan yazılması gerektiği sade bir dille yer alır. Teknik bilginiz olmasa da okuyup karar verebilmelisiniz.

Devam mı, baştan mı?

Karar, mevcut kodu düzeltmenin yeniden yazmaktan daha az iş olup olmadığına göre verilir. Çoğu projede cevap ikisinin arasındadır. Sağlam kısımlar korunur, sorunlu kısımlar yeniden yazılır.

Tamamen baştan yazmak şu durumlarda gündeme gelir: kullanılan teknoloji artık desteklenmiyorsa, veri yapısı işin kendisiyle çelişiyorsa ya da güvenlik sorunları kodun her yerine yayılmışsa. Bu durumda bile veri ve tasarım çoğu zaman kurtarılır.

Yeni ekibin ilk tepkisi hep "baştan yazalım" oluyorsa dikkatli olun. Bu bazen doğrudur, bazen de kodu okumamanın kolay yoludur. Gerekçeyi raporda yazılı olarak isteyin.

Devir sırasında canlı sistem nasıl korunur?

Canlı sistem, üzerinde değişiklik yapılmadan önce yedeklenerek ve ayrı bir test ortamı kurularak korunur. Proje yayındaysa ve müşterileriniz onu kullanıyorsa ilk hedef hiçbir şeyi bozmamaktır. Önce veritabanının ve dosyaların tam yedeği alınır. Sonra projenin bir kopyası test ortamında ayağa kaldırılır. Test ortamı, canlı sistemin bir kopyası üzerinde güvenle deneme yapılan yerdir.

Düzeltmeler önce orada denenir, sonra canlıya alınır. Canlıya her geçişin geri alınabilir olması gerekir. Böylece bir şey ters giderse sistem birkaç dakika içinde eski hâline döner.

Eski geliştiriciyle nasıl konuşulmalı?

Eski geliştiriciyle sakin ve yazılı iletişim kurmak en hızlı sonucu verir. Suçlamak yerine neye ihtiyacınız olduğunu liste hâlinde iletin: erişimler, belgeler, açık işler. Kısa bir devir görüşmesi, haftalarca kod okumaktan daha çok şey anlatabilir.

Ulaşılamıyorsa da iş durmaz. Erişimler sizin adınızaysa yeni ekip kodu okuyarak ilerler. Erişimler başkasının adınaysa önce onları geri almak gerekir. Bu yüzden erişim listesi ilk adımdır.

Aynı durumu bir daha yaşamamak için ne yapmalı?

Her şeyi ilk günden kendi adınıza tutun ve işin ne zaman bittiğini yazılı olarak tanımlayın. Kod deposu, sunucu, alan adı ve tüm hesaplar sizin olursa hiçbir ekip vazgeçilmez olmaz. Kod deposu, kodun tüm geçmişiyle birlikte tutulduğu yerdir.

Devraldığımız işlere de yeni bir bitiş tanımı yazarız. Neyin, hangi tarihte, nasıl kontrol edilerek bitmiş sayılacağı ilk gün imzalanır. Yarım kalmış bir projede yüzde 90 sözü zaten bir kez duyulmuştur. Bizde bitti ya da bitmedi vardır. Nasıl çalıştığımızı mevcut projeyi devralma sayfasında anlattık. Proje ayağa kalktıktan sonra düzenli destek isterseniz bakım ve destek sayfasına bakabilirsiniz.

Bir projenin tıkandığını gösteren işaretler nelerdir?

Bir proje, söz verilen tarihler art arda kayıyor ve neyin bittiği gösterilemiyorsa tıkanmıştır. Proje resmen yarım kalmadan önce de bu işaretler görülür. Ne kadar erken fark edilirse kurtarmak o kadar kolaydır. Şu işaretlere dikkat edin:

• Durum sorulduğunda cevap hep yüzde olarak veriliyor, çalışan bir ekran gösterilmiyor.
• Test adresi yok ya da uzun süredir güncellenmiyor.
• Düzeltilen bir hata başka bir yerde yeni hata çıkarıyor.
• Kod deposuna erişim istediğinizde bahane üretiliyor.
• Projeyi sadece bir kişi biliyor ve o kişiye ulaşmak giderek zorlaşıyor.
• Yeni istekler için verilen süreler, işin büyüklüğüyle orantısız biçimde uzuyor.

Bu işaretlerden birkaçını görüyorsanız proje bitmeden erişimleri toplamaya başlayın. Bu adım kimseyi suçlamak değildir. Her iki taraf için de güvencedir.

Durum raporunda neler yazmalı?

Durum raporunda projenin bugünkü hâli, riskleri ve önerilen yol teknik bilgi gerektirmeden okunacak biçimde yazmalıdır. Rapor, karar vermeniz için vardır. Kod parçaları ve teknik terimlerle dolu bir belge bu işi görmez. Bizim raporlarımızda şu başlıklar bulunur:

Devralma sürecinde sık yapılan hatalar nelerdir?

En sık hata, erişimler toplanmadan yeni ekibe işe başlatmaktır. Bu durumda yeni ekip de eski ekip gibi başkasının hesabına bağımlı kalır. Sık gördüğümüz diğer hatalar şunlar:

• İncelemeden fiyat istemek: Kod okunmadan verilen fiyat tahmindir. Ya çok yüksek çıkar ya da sonradan değişir.
• Canlı sistemde deneme yapmak: Test ortamı kurulmadan yapılan her düzeltme, müşterilerinizin kullandığı sistemi riske atar.
• Yedeği denememek: Yedek alınmış olması yetmez. Geri dönüşün çalıştığı en az bir kez denenmelidir.
• Açık işleri listelememek: Eski ekibe söz verilmiş ama yapılmamış işler yazılmazsa yeni ekibin kapsamı belirsiz kalır.
• Yeni bitiş tanımı yazmamak: Eski projenin belirsizliği yeni ekiple de devam eder.

Sözleşmede kod hakları için neye bakmalı?

Sözleşmede kodun ve tasarımın kime ait olduğunu, teslimde neyin verileceğini yazan maddelere bakmalısınız. Bazı sözleşmeler kodun kullanım hakkını müşteriye verir ama kaynak kodun teslimini ayrıca düzenlemez. Bazıları ödemenin tamamlanmasını şart koşar. Eski sözleşmenizi yeni ekiple paylaşmadan önce bu maddeleri okuyun. Hakların kime geçtiği ve anlaşmazlık durumunda ne yapılacağı hukuki bir konudur. Ayrıntı için hukuk danışmanınıza sorun.

Yeni işte bu belirsizliği baştan kaldırırız. Bizde kod deposu ilk günden müşterinin adına açılır. Kod, yazıldığı gün sizin deponuzdadır.

Devraldıktan sonraki ilk ay nasıl planlanır?

İlk ay, sistemi dengeye getirmek için kullanılır. Yeni özellik ikinci sıradadır. İlk haftalarda en kritik hatalar ve güvenlik açıkları kapatılır. Desteği biten sürümler güncellenir. Otomatik yedek ve hata izleme kurulur. Bu adımlar tamamlanınca proje yeniden öngörülebilir hâle gelir ve yeni özellikler bitiş tanımıyla planlanır.

Bu sırayı atlamak cazip gelebilir. Yarım kalan projelerde genellikle bekleyen bir iş listesi vardır ve herkes hemen ilerlemek ister. Ama sağlam olmayan bir temelin üstüne eklenen her özellik, teknik borcu büyütür. İşi başka firmalarla da konuşuyorsanız tekliflerde bu dengeleme adımının yer alıp almadığına bakın. Neye dikkat edeceğinizi yazılım teklifi karşılaştırma yazısında anlattık.