Yazılımınızı başka bir ekibe devredebilir misiniz?
Bir yazılımın kalitesini ölçmenin en pratik yolu şunu sormak: bu sistemi yazan ekip yarın işi bıraksa, başka bir ekip devralıp yürütebilir mi? Cevap evetse elinizde bir varlık var; hayırsa elinizde bir bağımlılık var. Teslimde kaynak kodun tamamı, veritabanı şeması ve kurulum adımları müşteride kalıyor; yazılım bizim sunucumuzda kilitli durmuyor.
Devredilebilirlik neden bir kalite ölçütü
Devredilebilirlik tek başına bir özellik değil, başka birçok şeyin birlikte doğru yapıldığının göstergesi. Bir sistemi başka bir ekibin devralabilmesi için kodun okunabilir olması, kararların yazılı olması, kurulumun tekrarlanabilir olması ve dışarıya giden bağlantıların belgelenmiş olması gerekiyor. Bu dördü sağlanmışsa sistem zaten bakımı kolay bir sistem.
Tersi de geçerli: devri zorlaştıran her şey aslında günlük bakımı da zorlaştırıyor. Belgesiz bir entegrasyon yalnızca yeni ekip için değil, onu yazan kişi için de altı ay sonra belirsiz hale geliyor. Dolayısıyla devredilebilirlik için yapılan iş, müşteriye bir güvence vermekten çok sistemin kendi ömrünü uzatıyor.
Bunu bir risk olarak görmüyoruz. Müşterinin istediği zaman ayrılabileceğini bilmek, kaliteyi sözleşmeyle değil işin kendisiyle sürdürmek anlamına geliyor.
Teslim paketinde ne bulunmalı
Devir konuşulurken genellikle yalnızca kaynak kod akla geliyor. Oysa kod, paketin yarısı. Eksiksiz bir teslim şunları içeriyor:
- Kaynak kodun tamamı: yorumlanmış, çalışır ve derlenmesi ya da kurulması belgelenmiş durumda.
- Veritabanı şeması: tablolar, ilişkiler, indeksler ve varsa başlangıç verisi.
- Kurulum adımları: sıfırdan bir ortamın nasıl kurulduğu, hangi sürümlerin gerektiği.
- Ortam ayarları listesi: hangi ayarın ne işe yaradığı. Değerlerin kendisi ayrı ve güvenli biçimde devrediliyor.
- Dış bağlantıların belgesi: hangi servise hangi uç üzerinden gidildiği, alan eşleme tabloları, hata durumunda ne olduğu.
- Yedek ve geri dönme yöntemi: yedeğin nereden alındığı ve nasıl geri yüklendiği. Denenmemiş yedek, yedek sayılmıyor.
- Bilinen eksikler listesi: tamamlanmamış kısımlar ve bilerek ertelenmiş işler. Bu listeyi vermemek, devralan ekibi aynı sorunu ikinci kez keşfetmeye zorluyor.
Kilitlenmenin sessiz biçimleri
Kilitlenme çoğu zaman sözleşmeden değil, pratik ayrıntılardan doğuyor. En sık karşılaştıklarımız:
| Durum | Neden sorun | Doğrusu |
|---|---|---|
| Kod yalnızca geliştiricinin sunucusunda | Kopyası olmayan koda sahip olunamaz | Kod müşterinin erişebildiği bir depoda durur |
| Alan adı ya da hosting ajans adına kayıtlı | Ayrılma anında sistemin anahtarı başkasında kalır | Hesaplar işletme adına açılır, yetki paylaşılır |
| API anahtarları kod dosyalarının içinde | Hem güvenlik açığı hem devirde karışıklık | Ayarlar koddan ayrı, web'den okunamayan yerde tutulur |
| Kurulum yalnızca bir kişinin bilgisayarında çalışıyor | Yeni ortam kurulamaz | Kurulum adımları yazılır ve sıfırdan denenir |
| Belgesiz entegrasyon | Hangi alanın neye gittiği bilinmez | Alan eşleme tablosu teslimin parçasıdır |
| Veri yalnızca dışarıdaki bir serviste | Dışa aktarma yolu yoksa veri rehin kalır | Verinin tamamı alınabilir biçimde durur |
Tablodaki üçüncü satırı özellikle vurguluyoruz, çünkü devraldığımız sistemlerde tam bu durumla karşılaşıyoruz: veritabanı kullanıcı adı ve parolası, site dosyalarının içinde ve bazen web üzerinden okunabilecek bir yerde duruyor. Bu hem acil bir güvenlik sorunu hem de devri zorlaştıran bir düzensizlik.
Devralınan bir sistem nasıl ölçülüyor
Bazı projelerde iş sıfırdan yazmak değil, çalışan ama kimsenin tam olarak anlamadığı bir sistemi devralmak oluyor. Bu durumda önce ölçüm yapıyoruz:
- Kodun hangi bölümleri gerçekten çalışıyor, hangileri ölü kod? Çağrılmayan dosyalar ve hiç kullanılmayan tablolar listeleniyor.
- Hangi dış servislere gidiliyor ve her çağrı ne döndürüyor? Belgelenmemiş bağlantılar canlıdan doğrulanıyor.
- Veri modeli hangi varsayımlar üzerine kurulmuş? Düzeltilmesi gereken yapısal kararlar işaretleniyor.
- Yedek alınıyor mu ve geri yükleme hiç denendi mi?
- Sırlar nerede duruyor ve kimlerin erişimi var?
Çıktı, hangi parçanın korunacağını ve hangisinin sökülüp yeniden yazılacağını söyleyen bir plan oluyor. Söküm sırası konusunda net bir kuralımız var: bir bağlantı sökülmeden önce yerine geçecek olanın hazır ve ölçülmüş olması gerekiyor. Önce yeni uç yazılır, çalıştığı doğrulanır, sonra eski bağ kaldırılır. Tersini yapmak sistemi kaynaksız bırakıyor.
Bakım anlaşması devri engellemiyor
Yayından sonra genelde aylık bir bakım ve geliştirme anlaşmasıyla devam ediyoruz: hata düzeltme, sürüm güncellemeleri, yedek kontrolü ve yeni istekler. İsteklerin sırasını müşteri belirliyor. Bu anlaşma bir bağlılık şartı değil; teslim paketi her an elinizde durduğu için bakımı başka bir ekibe devretmek teknik bir engele takılmıyor.
Aynı mantık silme işlemleri için de geçerli: bir şeyi silmeden önce yedek alıyoruz ve gerçek kayıtları geri dönüşü olmayan biçimde silmiyoruz. Bu, devir anında da işe yarıyor; devralan ekibin geriye dönebileceği bir nokta kalıyor.
Kısa kontrol listesi
- Kaynak kodun kopyası sizin erişebildiğiniz bir yerde mi?
- Veritabanı şeması ve kurulum adımları yazılı mı?
- Alan adı, hosting ve servis hesapları işletme adına mı kayıtlı?
- API anahtarları kod dosyalarının dışında mı tutuluyor?
- Dış bağlantıların belgesi ve alan eşleme tabloları var mı?
- Yedekten geri yükleme en az bir kez denendi mi?
- Bilinen eksikler listesi teslim edildi mi?
KAV Yazılım teslimde kaynak kodu, veritabanı şemasını ve kurulum adımlarını müşteriye bırakıyor; aynı yöntemi grup içinde işlettiği sistemlerde de uyguluyor.
Sık sorulan sorular
Kaynak kod teslimde gerçekten bana mı geçiyor?
Bulut modüllerinde de kod teslim ediliyor mu?
Verimi istediğim zaman dışa aktarabilir miyim?
Alan adı ve hosting kimin adına açılmalı?
Belgeleme ayrı ücretlendiriliyor mu?
- belgeleme
- devir
- kaynak kod sahipligi
- yazilim bakimi
