Bir mobilya üreticisinin bayi sipariş sistemini düşünün. Dört yıl önce bir serbest geliştiriciye yaptırılmış, o günden beri her ay birkaç küçük değişiklik istenmiş ve hepsi aynı kişi tarafından yapılmış. Sonra geliştirici başka bir işe geçiyor. Vedalaşma kibar geçiyor, "bir şey olursa ararsınız" deniyor. Üç hafta sonra bayilerden biri sipariş ekranının açılmadığını söylüyor ve şirkette kimse sunucuya nasıl girileceğini bilmiyor.
Bu senaryo sanıldığından sık yaşanır. Yazılımı yapan firma kapanır, ajans başka işlere odaklanır, şirket içindeki tek yazılımcı istifa eder. Kod genelde bir yerlerde durur; asıl kaybolan, sistemin nasıl ayakta durduğuna dair bilgidir. Bu yazıda böyle bir projeyi yeni bir ekibe ya da yeni bir firmaya devrederken ilk iki haftada hangi adımları, hangi sırayla atmanız gerektiğini anlatıyoruz. Amaç henüz yeni bir şey geliştirmek değil; neyin elinizde olduğunu bilmek.
1. Önce erişimlerin listesini çıkarın
Koddan önce hesaplar gelir, çünkü kodu olan ama alan adına erişemeyen bir şirket, kodu olmayan ama her hesabı elinde tutan bir şirketten daha zor durumdadır. Bir tabloya şunları yazın: alan adının kayıtlı olduğu firma ve hesabın kimin e-postasında olduğu, DNS'in nerede yönetildiği, sunucu ya da bulut hesabı, veritabanı, kodun durduğu depo (GitHub, GitLab, Bitbucket), App Store Connect ve Google Play hesapları, e-posta gönderen servis, ödeme altyapısı, SMS sağlayıcısı, harita ya da yapay zekâ gibi ücretli API anahtarları.
Her satırın yanına iki soru ekleyin: hesap şirketin adına mı, yoksa ayrılan kişinin kişisel hesabında mı? Ve bugün şirketten biri bu hesaba girebiliyor mu? Kişisel hesapta duran her şey, ilişki iyiyken şirkete devredilmelidir. Devrin ardından ayrılan kişinin yetkilerini kaldırın ve şifreleri, API anahtarlarını yenileyin. Bunu kimseyi suçlamak için değil, sistemin kimin elinde olduğunu netleştirmek için yapıyorsunuz.
2. Hangi kodun gerçekten çalıştığını bulun
Depoda duran kod ile sunucuda çalışan kod her zaman aynı değildir. Acil bir düzeltme doğrudan sunucuda yapılmış, depoya hiç gönderilmemiş olabilir. Ya da depoda yarım kalmış, hiç yayına çıkmamış bir dal en güncel görünüyor olabilir.
Bunu anlamanın en sağlam yolu karşılaştırmaktır: sunucudaki dosyaları indirip depodaki son yayın sürümüyle farklarına bakmak. Mobil uygulamada aynı soru mağazadaki sürüm numarası için sorulur: App Store'daki 2.4.1 sürümü hangi commit'ten derlendi? Bu soruya cevap bulamıyorsanız, sonraki her değişiklik bilinmeyen bir kod tabanının üzerine yapılmış olur. Farkları bulduğunuzda hepsini depoya alın ve "şu anda yayında olan" diye etiketleyin; bundan sonraki her iş bu noktadan başlar.
3. Sistemi sıfırdan bir bilgisayarda kurup çalıştırın
Yeni ekibin ilk somut işi, projeyi temiz bir makinede kurup çalıştırmak olmalı. Bu adım, yazılmamış her bilginin ortaya çıktığı yerdir: hangi PHP ya da Node.js sürümü gerekiyor, hangi ortam değişkenleri tanımlı olmalı, veritabanı nasıl oluşturuluyor, hangi servis yerel ortamda taklit edilmeli.
Kurulum sırasında takılınan her noktayı not edin ve o notları projenin kök dizinine bir README olarak koyun. İş bittiğinde elinizde, ekibe katılan bir sonraki kişinin bir günde ayağa kaldırabileceği bir sistem olur. Kurulum hiç başarılamıyorsa bu da değerli bir bulgudur; sistemin yalnızca o sunucuda, o hâliyle çalıştığını ve en küçük sunucu sorununun büyük bir kesintiye dönüşebileceğini gösterir.
4. Yedeği alın ve geri yüklemeyi deneyin
"Yedek alınıyor mu?" sorusunun cevabı genelde "evet, sanırım" olur. Doğru soru şudur: o yedekten sistemi geri kurabiliyor musunuz? Veritabanının ve kullanıcıların yüklediği dosyaların güncel bir kopyasını alın, ayrı bir ortamda geri yükleyin ve uygulamanın bu veriyle açıldığını görün.
Bu deneme size iki şey söyler: yedeğin gerçekten işe yarayıp yaramadığını ve bir felakette sistemin ne kadar sürede geri gelebileceğini. Ardından yedeklemenin otomatik çalıştığından, kopyanın aynı sunucudan başka bir yerde durduğundan ve birinin ayda bir geri yükleme denemesi yaptığından emin olun.
5. Bağımlılıkları ve bilinen açıkları tarayın
Uzun süre tek bir kişinin baktığı projelerde çerçeve ve kütüphane güncellemeleri genelde ertelenir. Paket listesini çıkarın, her birinin kullanılan sürümünü ve güncel sürümünü yan yana koyun. npm audit, composer audit ya da GitHub'ın bağımlılık uyarıları gibi araçlar bilinen güvenlik açıklarını hızlıca listeler.
Bu listeyi hemen güncellemeye girişmek için değil, riski görmek için çıkarıyorsunuz. Bir kütüphanenin iki küçük sürüm geride olması ile sunucunun artık güvenlik güncellemesi almayan bir işletim sisteminde çalışması aynı aciliyette değildir. Mobil uygulamalarda buna mağazaların yıllık gereksinimleri de eklenir; hedef SDK sürümü geride kalan bir uygulamanın bir sonraki güncellemesi mağazaya hiç kabul edilmeyebilir.
6. Kullananlarla konuşun
Kod, sistemin ne yaptığını söyler; neden öyle yaptığını her zaman söylemez. Muhasebede, depoda ya da sahada sistemi her gün kullanan iki üç kişiyle yarım saatlik görüşmeler yapın. Hangi ekranı en çok kullandıklarını, hangi işi sistemin dışında Excel'de çözdüklerini, hangi hatayı artık "normal" kabul ettiklerini sorun.
Bu görüşmelerde çoğu zaman kodda bir yere gömülmüş iş kuralları ortaya çıkar: belirli bir bayi grubuna farklı iskonto uygulanması, ay sonunda elle tetiklenen bir aktarım, bir raporun yalnızca belirli bir kişi tarafından anlaşılabilmesi. Bunları yazıya geçirmek, yeni ekibin farkında olmadan bir kuralı bozmasını engeller.
7. Her şeyi tek bir yazılı rapora toplayın
İki haftanın sonunda elinizde kısa bir belge olmalı: erişim tablosu ve hangi hesapların devredildiği, yayındaki kodun hangi sürüm olduğu, kurulum adımları, yedek denemesinin sonucu, bağımlılık listesi ve bulunan riskler, kullanıcı görüşmelerinden çıkan iş kuralları. Son bölümde riskleri üç gruba ayırın: bu hafta düzeltilmesi gerekenler, önümüzdeki üç ay içinde planlanacaklar ve şimdilik beklemesinde sakınca olmayanlar.
Bu rapor, sonraki bütün kararların zeminidir. Bakım sözleşmesinin kapsamı, ilk ayın iş listesi, hatta sistemin yenilenmesi gerekip gerekmediği sorusu bu belgeye bakılarak konuşulur. Yazılı bir değerlendirme olmadan verilen fiyat da, verilen süre de tahminden öteye geçmez.
Kısaca
Yazılımı yapan kişi ya da firma gittiğinde ilk iş yeni özellik eklemek değil, elinizde ne olduğunu öğrenmektir. Önce hesapları şirkete alın ve şifreleri yenileyin, sonra yayındaki kodun hangisi olduğunu bulun, sistemi temiz bir makinede kurun, yedekten geri yüklemeyi deneyin, bağımlılıkları tarayın, kullananları dinleyin ve hepsini tek bir raporda toplayın. Bu iki hafta, sonraki yılların bakımını tahminden plana çevirir.
Yazılım bakım ve destek hizmetimiz de tam olarak bu adımlarla başlıyor: kaynak kodu, bağımlılıkları, sunucuları ve erişimleri inceleyip riskleri ve öncelikleri gösteren yazılı bir rapor paylaşıyor, bakımı ancak bundan sonra devralıyoruz.
Böyle bir proje mi planlıyorsun?
10 adımda planla