Yarım Kalan Yazılım Projesini Devralma

Devralma işlerinde bir firmanın kodu görmeden fiyat vermesi kötü bir işarettir. Elindeki proje iki uçtan birinde olabilir: makul kurulmuş, okunabilir ve eksikleri belli bir kod tabanı; ya da dağınık, belgesiz, kimsenin dokunmaya cesaret edemediği bir yığın. İkisinin maliyeti arasında kat farkı var.

Bu yüzden işe kısa bir inceleme ile başlıyoruz. Sonunda sana yazılı bir teşhis veriyoruz: hangi kısımlar çalışıyor, hangileri yarım, mimari sağlıklı mı, güvenlik açısından acil bir şey var mı ve tamamlamak için gerçekçi olarak ne kadar iş kaldı.

Bu incelemenin sonucu bazen "devralalım" olur, bazen "bu kodu kurtarmak baştan yazmaktan pahalıya gelir" olur. İkincisini söylemek işimizi kaybettirse de söylüyoruz — çünkü kurtarılamaz bir kodu devralmak iki tarafı da altı ay sonra aynı yere getiriyor.

Hesaplar sende değil. Sunucu, alan adı, mağaza hesabı ya da kod deposu eski geliştiricinin adına açılmış. Teknik olarak çözülebilir ama önce fark edilmesi gerekiyor — çoğu işletme bunu ancak geliştiriciyle yolları ayrılınca öğreniyor.

Kaynak kod yok, sadece çalışan sistem var. Bu durumda yazılımı kullanabilir ama geliştiremezsin. Sözleşmende kaynak kod devri yazıyorsa talep hakkın var; yazmıyorsa hukuki tarafı tartışmalı ve bir avukata danışman gerekir.

Yüzde 80 bitmiş görünüyor ama son yüzde 20 yok. Devralma projelerinin klasiği. Ekranlar duruyor, akış tamamlanmamış. Genelde kalan işin büyüklüğü sanıldığından fazla oluyor çünkü zor kısımlar sona bırakılmış.

Belge yok. Kimse neyin neden öyle yapıldığını bilmiyor. Devralma süresinin önemli bir kısmı bunu çözmeye gidiyor; bu yüzden analiz aşamasını atlamıyoruz.

Güvenlik ve veri riski. Açıkta kalmış anahtar, korumasız uç nokta ya da KVKK açısından sorunlu veri saklama. Devralırken ilk baktığımız yerlerden biri.

Bu kararı duyguyla değil üç kriterle veriyoruz.

Kod okunabilir mi? Bir geliştirici makul sürede ne olduğunu anlayabiliyorsa devralmak mantıklı. Her değişiklik arkeolojik kazıya dönüşüyorsa değil.

Veri modeli sağlam mı? Arayüz kötüyse yeniden yazılır, bu ucuzdur. Ama veri modeli yanlış kurulmuşsa üstüne inşa edilen her şey de yanlış olur; bu durumda devralmak borç almaktır.

Ne kadarı gerçekten bitmiş? "Bitti" denen kısımların gerçekten çalışıp çalışmadığını test ederiz. Genelde tablo iddia edilenden daha az iyimser çıkar.

Üçünde de yanıt olumluysa devralmak ciddi tasarruf sağlar. İkisi olumsuzsa dürüst olan, seçici bir yeniden yazım önermek — çalışan parçaları korumak, sorunlu çekirdeği değiştirmek.

Projeyi devralmak yarısı; ikinci yarısı aynı durumun tekrarlanmaması. Bunun için baştan üç şeyi kuruyoruz: tüm hesaplar senin adına, kod deposu senin erişiminde ve temel bir belgelendirme.

Böylece yarın bizimle çalışmayı bıraksan bile projeni başka bir ekibe sorunsuz devredebilirsin. Müşteriyi teknik bağımlılıkla tutmak kısa vadede işe yarayan ama uzun vadede itibar bitiren bir yöntem; biz o tarafta durmuyoruz.

Devralınan projelerin çoğu sonrasında düzenli bir bakım ve destek ilişkisine dönüşüyor — ki bu ikisi için de daha sağlıklı bir düzen.

Devralma işleri büyük ajanslar için cazip değildir — belirsizdir, standart bir sürece oturmaz ve satış tarafında hikâyesi zayıftır. Tek freelancer'lar ise çoğu zaman devralmaktansa baştan yazmayı tercih eder, çünkü başkasının kodunu okumak zor iştir.

Bağımsız stüdyo bu iki uç arasındaki yer: doğrudan konuşursun, işi aynı ekip sahiplenir ve kararı ticari kaygıyla değil teknik gerçeklikle veririz. Yayındaki işlerimiz ne tür sistemlere hâkim olduğumuzu gösteriyor.