Yazılım projesi yarıda kaldı: buradan nasıl devam edilir

Yarıda kalmış bir yazılım projesinde atılacak ilk adım kod yazmak değil, elde ne olduğunu saymaktır. Önce çalışan parçaları, içeri girmiş veriyi ve sistem üzerindeki erişimleri güvenceye alın; ancak bu envanter çıktıktan sonra devam mı yoksa yeniden mi yazılacağına karar verin. Proje neden durursa dursun — firma değişti, bütçe kesildi, geliştirici ayrıldı ya da taraflar anlaşamadı — durduğu andaki tablo aşağı yukarı aynıdır: yarım bir kod tabanı, içine gerçek veri girilmiş bir veritabanı ve o sisteme alışmış birkaç kullanıcı. Bu üçünün değeri birbirinden farklıdır ve en çok değer taşıyan genellikle kod değil, veridir.

Duran projede en sık yapılan hata, karar vermeden harekete geçmektir. Yeni bir geliştiriciye "şuradan devam et" denir, o da ne devraldığını tam bilmeden üstüne yazmaya başlar. Birkaç hafta sonra ikinci bir yarım sistem ortaya çıkar. Sıra şöyle olmalı: tespit, kurtarma, erişim, yeniden tanımlama, karar.

Neyin çalıştığını nasıl tespit edersiniz

Tespit işi belgeden değil, sistemin kendisinden yapılır. Elinizdeki analiz dosyasında yazan şeyin gerçekten kodlanmış olduğunu varsaymayın; duran projelerde belgeyle gerçek arasındaki fark neredeyse her zaman büyüktür. Bunun yerine sistemi açın ve ekran ekran gezin.

Şunları ayrı ayrı işaretleyin:

• Uçtan uca çalışan ekranlar: veri giriliyor, kaydediliyor, sonra geri okunabiliyor.
• Görsel olarak var ama arkası boş ekranlar: buton var, tıklayınca bir şey olmuyor ya da hata veriyor.
• Hiç başlanmamış bölümler: menüde bile yok.
• Yalnızca test verisiyle çalışmış, gerçek kullanımı hiç görmemiş bölümler.

Bu ayrımın pratik karşılığı şudur: birinci gruptaki ekranlar korunmaya değer, ikinci gruptakiler çoğu zaman yeniden yazılır. Bir de kimin neyi kullandığını sorun. Sistemde on ekran olabilir ama kullanıcılar günlük işini üçüyle görüyor olabilir. Devam kararının ağırlığı, o üç ekranın durumuna göre değişir.

Veriyi kurtarmak ve dışarı almak neden ilk sırada

Kod yeniden yazılabilir, veri yeniden yazılamaz. Sisteme girilmiş cari kayıtları, ürün kartları, geçmiş işlemler ve bunların birbirine bağlanma biçimi — bu, aylara yayılmış bir emeğin sonucudur. Proje durduğu anda bu verinin bulunduğu sunucu, sizin kontrolünüzde olmayabilir. Fatura ödenmediğinde kapanan bir barındırma hesabı, verinin tamamını götürebilir.

Bu yüzden ilk somut iş, veritabanının tam bir kopyasını almak ve o kopyayı kendi kontrolünüzdeki bir yere indirmektir. Kopyayı aldıktan sonra açıp içine bakın: tablolar boş mu dolu mu, hangi tarihe kadar kayıt var, dosya ekleri veritabanının içinde mi yoksa ayrı bir klasörde mi duruyor. Dosya ekleri sık atlanan kalemdir; veritabanı yedeği alınır ama yüklenen belgeler sunucuda unutulur.

Aynı anda veriyi okunabilir bir biçime de çıkarın. Ham veritabanı yedeği teknik bir dosyadır; onu açacak kimse yoksa güvence sağlamaz. Ana tabloları elektronik tablo dosyası olarak dışarı alın. Böylece sistem hiç açılmasa bile işletme kendi bilgisine ulaşabilir.

Erişimleri toplamak: kimde ne var

Duran projelerde erişimler dağılmış olur. Alan adı bir yerde, barındırma hesabı başka yerde, kod deposu geliştiricinin kişisel hesabında durur. Ayrılan kişi kötü niyetli olmasa bile, ulaşılamadığı bir dönemde bu kalemler tek tek kilitlenir.

Toplanması gereken liste kısadır ama eksiksiz olmalı: alan adı kaydı ve yönetim paneli, sunucu ya da bulut hesabı, kod deposu, veritabanı erişimi, e-posta gönderim servisi, ödeme ya da mesajlaşma servisi anahtarları, uygulama mağazası hesapları. Her kalem için tek soru sorun: bu hesap şirketin kurumsal e-posta adresine mi bağlı, yoksa bir kişinin adresine mi? Kişiye bağlı olan her şey, şirket adresine taşınmalı.

Bu iş teknik olmaktan çok idari bir iştir ve devralan geliştiriciyi beklemeden başlatılabilir. Erişimler toplanmadan yapılan her teknik çalışma, üstünde durduğu zemin size ait olmadığı için risklidir.

Kalan işi yeniden tanımlamak

Eski proje kapsamını olduğu gibi devam ettirmek nadiren doğru olur. O kapsam, projenin başındaki koşullara göre yazılmıştı; aradan geçen sürede iş akışı değişmiş, bazı ihtiyaçlar kendiliğinden çözülmüş, bazıları önem kazanmış olabilir. Ayrıca ilk kapsamın şişkin olması, projenin durma nedenlerinden biri bile olabilir.

Kalan işi yeniden tanımlarken eski belgeyi kaynak değil, girdi olarak kullanın. Maddeleri üç kovaya ayırın: hâlâ gerekli olanlar, artık gereksiz olanlar, ve gerekliliği belirsiz olanlar. Belirsiz kovasındakileri şimdilik dışarıda bırakın. Hedef, sistemi tamamlamak değil, sistemi kullanılabilir hale getirmektir. Bu ikisi çok farklı büyüklüktedir.

Somut bir ölçüt işe yarar: hangi ekranlar tamamlanırsa, bugün elle yürüyen bir iş sistemden yürümeye başlar? Sadece onları tanımlayın. Geri kalanı ikinci aşamaya bırakın; ikinci aşama gelmezse bile elinizde çalışan bir şey kalır.

Sıfırdan yazmak mı, devam etmek mi

Bu karar duygusal verilmeye çok müsaittir. Devralan geliştirici çoğunlukla "bu kodu anlamak yazmaktan uzun sürer" der; bu bazen doğrudur, bazen tanımadığı koda duyulan doğal isteksizliktir. Kararı şu sorularla verin.

Devam etmek lehine olan işaretler: Veri modeli makul kurulmuş ve gerçek veriyle dolu. Kullanıcılar bazı ekranları fiilen kullanıyor. Kod, yaygın ve hâlâ desteklenen bir teknolojiyle yazılmış. Eksik olan şey mimari değil, tamamlanmamış ekranlar.

Yeniden yazmak lehine olan işaretler: Veri modeli yanlış kurulmuş, temel kayıtlar birbirine tutarsız bağlanmış. Kullanan kimse yok, yani korunacak alışkanlık da yok. Kullanılan teknoloji artık destek almıyor ya da o teknolojiyi bilen kimse bulunamıyor. Sistem yerel bir bilgisayarda tek kişiyle çalışacak şekilde kurulmuş, çok kullanıcıya taşınması ayrı bir proje.

Üçüncü bir yol daha var ve çoğu durumda en gerçekçi olan budur: veriyi taşıyıp arayüzü yeniden yazmak. Böylece en değerli varlık korunur, en sorunlu kısım tazelenir. Kararı verirken teknik değerlendirmeyi yapan kişinin, işi devralacak kişi olmasına dikkat edin — bir başkasının "devam edilebilir" raporuyla işe girip sonra devam edemeyen bir ekip, sizi başa döndürür.

Devralan tarafın ilk haftası

İlk haftanın çıktısı kod değil, netliktir. Sıralama şöyle işler: sistemi kendi ortamlarında ayağa kaldırmak, veri kopyasını inceleyip modeli çıkarmak, çalışan ve çalışmayan ekranların listesini üretmek, mevcut kullanıcılardan işin gerçekte nasıl yürüdüğünü dinlemek.

Bu haftanın sonunda devralan taraftan iki şey istenmelidir: elde olanın dürüst bir özeti ve kalan iş için bir sıralama önerisi. Süre ve bütçe konuşması bundan sonra yapılır. İlk gün süre soran bir yaklaşım, cevap alsa bile o cevap tahminden ibaret olur.

Bir uyarı: devralan tarafın ilk haftada üretime dokunmasına gerek yoktur. Mevcut sistem hâlâ kullanılıyorsa, inceleme kopya üzerinden yapılmalı. Devir sırasında çıkan veri kayıpları genellikle acele edilmiş ilk müdahalelerden çıkar.

İkinci denemede neyi değiştirmeli

Aynı hatanın tekrarlanmaması, ilk denemede neyin yanlış gittiğine bakmayı gerektirir. Birkaç değişiklik, duran projelerin çoğunda işe yarar.

Parçalı teslim isteyin. Proje tek seferde bitip teslim edilecek bir bütün olarak kurgulanırsa, ortasında durduğunda elinizde kullanılabilir hiçbir şey kalmaz. Her teslimde çalışır bir parça devreye girsin; proje yine dursa bile o parça elinizde kalır.

Erişimleri baştan şirket adına açın. Alan adı, sunucu, kod deposu; hepsi kurumsal e-posta adresiyle kurulsun, geliştirici davet edilen kullanıcı olsun.

Veri ve yedeği kendi kontrolünüzde tutun. Yedeğin alındığını duymak yetmez; ara ara bir kopyasını kendi tarafınıza indirin.

Kapsamı küçültün ve bir iç sahibi belirleyin. Projenin işletme tarafında karar verebilen tek bir sahibi yoksa, kapsam sürekli büyür ve kimse durduramaz. Bu kişi teknik olmak zorunda değil; işi bilen ve karar verebilen biri olması yeterli.

Kısaca

• Önce elde ne olduğunu tespit edin; belgeye değil, çalışan sistemin kendisine bakın.
• Verinin tam kopyasını ve okunabilir bir dışa aktarımını kendi kontrolünüzdeki bir yere alın; dosya eklerini unutmayın.
• Alan adı, sunucu, kod deposu ve servis anahtarlarını kişisel hesaplardan şirket hesabına taşıyın.
• Kalan işi eski kapsamdan değil, bugün elle yürüyen işlerden yola çıkarak yeniden tanımlayın.
• Devam mı yeniden mi kararını veri modelinin sağlığına ve fiili kullanıma bakarak verin; sık çıkan cevap veriyi taşıyıp arayüzü yenilemektir.
• İkinci denemede parçalı teslim, şirket adına erişim ve tek bir iç sahip belirleyin.