Kaynak kod teslimi, bir uygulamanın geliştirilmesinde kullanılan dosyaların kararlaştırılmış kapsam ve yöntemle ilgili tarafa verilmesidir. Ancak dosyaların kopyalanması tek başına çalışır sistemi devralmak anlamına gelmez. Hangi sürümün paylaşıldığı, uygulamanın nasıl kurulacağı, hangi dış hizmetlere bağlı olduğu ve gerekli erişimlerin nasıl yönetileceği de önemlidir. Teknik teslim ile kullanım ve hak koşulları ayrı değerlendirilmelidir. Bunların kapsamı gerçek teklif ve sözleşmede netleştirilmelidir.

İçindekiler

Bir işletme uygulamanın bütün dosyalarını aldığını düşünebilir. Sonradan başka ekip sistemi kurmak istediğinde veri tabanı yapısının, ayar açıklamalarının veya belirli dosyaların eksik olduğu anlaşılabilir. Tersi durumda, gerekli teknik bilgiler mevcutken hak ve lisans koşulları yeterince açıklanmamış olabilir. Bu iki sorun birbirinin aynısı değildir. Sağlıklı devir için dosya kapsamı, kurulabilirlik, erişim ve sözleşmesel koşullar birlikte fakat birbirine karıştırılmadan ele alınmalıdır.

Kaynak kod teslimi konusunu yalnızca proje bittiğinde açmayın. Geliştirme başlangıcında neyin beklendiğini konuşmak daha anlaşılır bir plan oluşturur. Program yaptırmak isteyenler için ihtiyaç rehberi içinde proje sonrası sorumluluklarınızı da değerlendirebilirsiniz. Burada her projede aynı dosyaların veya hakların zorunlu teslim edildiği söylenmez. Uygulamanın yapısı, kullanılan bileşenler ve anlaşma koşulları değişebilir. Amaç, ne aldığınızı ve neyin ayrıca açıklanması gerektiğini anlayabilmenizdir.

Kaynak kod teslimi ile uygulama kullanımı arasındaki fark

Bir uygulamayı kullanmak, onun geliştirme dosyalarını yönetmekle aynı şey değildir. Tarayıcı üzerinden çalışan sisteme giriş yapabiliyor olabilirsiniz; bu, sunucu tarafındaki bütün geliştirme dosyalarına sahip olduğunuzu göstermez. Kurulabilir program dosyası da kaynak kodun kendisi olmayabilir. Çalıştırılabilir paket, belirli işlemler sonucunda oluşturulmuş çıktı olabilir. Dosya adlarına bakarak tahmin yürütmek yerine hangi tür teslim yapıldığını ve bunun ne amaçla kullanılabileceğini açıklatın.

Kaynak kod teslimi ayrıca verinin devriyle aynı değildir. Müşteri kayıtları, belgeler ve işlem geçmişi ayrı kaynaklarda bulunabilir. Uygulama dosyaları olmadan veri kullanımı zorlaşabilir; veri olmadan da sistem yalnızca boş kurulum olarak açılabilir. Hangilerinin kapsamda olduğu ayrı listelenmelidir. İşletme geçmiş kayıtlarına hangi biçimde erişeceğini konuşmalıdır. Veri paylaşımının ve saklanmasının koşulları somut uygulamayla değerlendirilir; yalnızca teknik dosya verilmesi bu soruları otomatik çözmez.

Teknik devir ile hak koşullarını ayırın

Dosyalara erişmek belirli kullanım, değiştirme veya dağıtım haklarının otomatik olarak verildiğini göstermez. Hakların kapsamı, sözleşme ve kullanılan bileşenlerin koşullarıyla birlikte değerlendirilmelidir. Bir projede işletmeye özel geliştirilen kısım, hazır ürün, açık kaynak bileşen ve üçüncü taraf hizmet birlikte bulunabilir. Bunların hepsi aynı sahiplik yapısına sahip olmayabilir. Genel blogdan hukuki sonuç çıkarmak yerine gerekli koşulları yetkin değerlendirmeyle netleştirin. Teknik ekip de bileşenleri açıklamalıdır.

Kaynak kod teslimi konuşulurken “tamamı sizin” gibi geniş ifadeleri somutlaştırın. Hangi dosyalar, hangi sürüm ve hangi hak kapsamı kastediliyor? Hazır bileşenlerin lisansları, dış hizmet hesapları ve geliştirme araçları ayrıca ele alınabilir. Her aracın hesabını devralmak gerekmeyebilir; ancak uygulamayı sürdürebilmek için hangi bağımlılıkların bulunduğu bilinmelidir. Teknik açıdan gereken bilgiyle sözleşmesel hakların aynı listede birbirine karışması, sonradan yanlış beklenti oluşturabilir.

Dokuz kontrolle teknik teslimi değerlendirin

1. Teslim edilecek bileşenleri listeleyin

Uygulamanın hangi parçalardan oluştuğunu öğrenin. Kullanıcı arayüzü, sunucu tarafı, zamanlanmış görevler, veri tabanı değişiklikleri ve yardımcı araçlar farklı yerlerde olabilir. Tek klasörün bütün sistemi temsil ettiği varsayılmamalıdır. Projeye göre birden fazla depo veya dosya kümesi bulunabilir. Her parçanın amacı ve nerede tutulduğu açıklanmalıdır. Liste aşırı teknik ayrıntıya boğulmadan hangi bileşenin hangi işi yaptığına cevap vermelidir. Kapsam dışında kalan parçalar da belirtilmelidir.

Kaynak kod teslimi için canlı ortamda kullanılan sürümle paylaşılan sürümün ilişkisi önemlidir. Eski deneme dosyaları teslim ediliyorsa uygulamanın son davranışı yeniden oluşturulamayabilir. Hangi tarihteki veya hangi sürüm işaretindeki dosyaların verildiği kaydedilmelidir. Açık kalan geliştirmeler ve kullanılmayan denemeler varsa ayrılabilir. Sürüm bilgisi yalnızca dosya adında bulunmak zorunda değildir; kullanılan çalışma düzenine uygun izlenebilir kayıt yeterli olabilir. Önemli olan hangi sonucun devralındığının anlaşılmasıdır.

2. Kod deposu ve erişim sahipliğini açıklayın

Geliştirme dosyaları sürüm geçmişi tutan bir kod deposunda bulunabilir. Depoya erişim verilmesi, sahipliğin devredilmesi ve dosyaların arşiv olarak paylaşılması farklı yöntemlerdir. Her birinin avantajı ve sınırı vardır. Hangi yöntemin kullanılacağını ve hangi bilgilerin birlikte geleceğini sorun. Depoyu kimin yöneteceği, yeni kullanıcıları kimin ekleyeceği ve ayrılan kişilerin erişiminin nasıl kaldırılacağı belirtilmelidir. Bütün çalışanlara yönetici yetkisi vermek gerekli bir devir koşulu değildir.

Kaynak kod teslimi sırasında kişisel hesapla kurumsal sahipliği ayırın. İşletmenin kontrol etmesi gereken varlıklar tek kişinin özel hesabına bağımlı kalmamalıdır; uygun hesap düzeni proje koşullarıyla değerlendirilir. Devralan kişi erişimini gerçekten denemelidir. Bağlantının gönderilmiş olması, gerekli izinlerin çalıştığını kanıtlamaz. Ayrıca eski erişimlerin hangi koşulda devam edeceği veya kaldırılacağı konuşulmalıdır. Amaç bütün iş birliğini aniden kesmek değil, sorumluluk ve yetkinin anlaşılır biçimde yönetilmesidir.

GitHub’ın resmî depo aktarımı belgesi, depoların hesaplar arasında aktarılmasını ve bu işlemle ilişkili yönetim koşullarını açıklar. Bu yöntem her projede kullanılmak zorunda değildir; başka araçlar da bulunabilir. Kaynağın burada gösterdiği sınırlı nokta, dosyayı indirmek ile depo yönetimini devralmanın farklı işlemler olduğudur. Kullanılan hizmetin güncel koşulları kontrol edilmeli, aktarım sonrası gerekli erişimler ve ilişkili ayarlar ayrıca incelenmelidir.

3. Kurulum ve çalıştırma açıklamasını isteyin

Dosyaların nerede olduğu kadar nasıl çalıştırılacağı da önemlidir. Gerekli yazılım sürümleri, kurulum sırası ve temel komutlar açıklanabilir. Her ayrıntının uzun kitap halinde verilmesi gerekmez; başka bir yetkin kişinin kurulumu takip edebilmesi hedeflenebilir. Açıklamanın güncel dosyalara uygun olması gerekir. Eski sürüm için yazılmış notlar sonraki değişiklikleri karşılamayabilir. Kurulumda hangi adımın işletmeye, hangi adımın teknik ekibe ait olduğu belirtilmelidir.

Kaynak kod teslimi ile birlikte yalnızca “kurulum kolay” sözü verilmesi yeterli açıklama değildir. Gerekli bağımlılıklar nereden alınacak, hangi ayarlar yapılacak ve başarılı kurulum nasıl anlaşılacak? Bu soruların cevabı uygulamanın yapısına göre değişir. Teknik ekip işletme yöneticisinin bütün komutları ezberlemesini beklememelidir. İhtiyaç, devralacak yetkin kişinin gerekli bilgiye ulaşabilmesidir. Kurulum yetkisi ve çalışma ortamı gibi koşullar da önceden konuşulursa devir günü gereksiz bekleme azalabilir.

4. Yapılandırma ve gizli bilgileri güvenle ayırın

Uygulama çalışmak için veri tabanı bağlantısı, dış hizmet anahtarı veya farklı ayarlar kullanabilir. Bunların hepsini kaynak dosyalarının içine açıkça koymak güvenli devir anlamına gelmez. Gizli değerler ile örnek ayar dosyası ayrılabilir. Hangi ayarın ne işe yaradığı ve gerçek değerin hangi güvenli yöntemle sağlanacağı açıklanmalıdır. Parolaları genel e-posta eklerinde veya herkese açık depoda paylaşmak zorunda değilsiniz. Uygun yöntem teknik güvenlik koşullarıyla belirlenmelidir.

Kaynak kod teslimi sırasında hangi gizli bilgilerin değiştirilmesi gerektiğini de değerlendirin. Depo veya hesap devri bütün eski erişimlerin kendiliğinden kalktığı anlamına gelmeyebilir. Dış servis anahtarları, kurulum yetkileri ve otomatik işlem hesapları ayrıca incelenebilir. Burada bütün anahtarların her durumda aynı anda değiştirilmesi gerektiği söylenmez; bağımlılıkların bilinmesi ve geçişin planlanması önemlidir. Güvenlik kontrolü yapılırken çalışan uygulamanın hangi erişimlere bağlı olduğu da dikkate alınmalıdır.

5. Veri tabanı yapısını ve değişikliklerini açıklayın

Uygulama dosyaları, veri tabanının yapısını tek başına oluşturmayabilir. Tabloların, ilişkilerin veya sürüm değişikliklerinin nasıl hazırlanacağı açıklanmalıdır. Bazı projelerde bunlar kodla birlikte tutulabilir; bazılarında ayrı betik veya belgeler bulunabilir. Hangisinin geçerli olduğu öğrenilmelidir. Boş kurulum için gereken yapı ile gerçek müşteri verileri birbirinden ayrılmalıdır. Gerçek verinin güvenli paylaşımı ve kullanımı ayrı sorumluluk gerektirir. Teknik devri göstermek için gereksiz kişisel bilgi çoğaltılmamalıdır.

Kaynak kod teslimi kapsamında veri tabanı yedeği verilecekse bunun hangi ortama, hangi tarihe ve hangi kullanım amacına ait olduğu belirtilmelidir. Yedek alınmış olması geri yükleme adımlarının bilindiği anlamına gelmez. Devralan ekip hangi sürümle uyumlu olduğunu anlamalıdır. Güncel sistemde veri değişmeye devam ediyorsa son geçiş planı ayrıca yapılmalıdır. Eski yedeği yeni kodla birleştirmek her zaman sorunsuz sonuç vermez; uygunluk teknik olarak doğrulanmalıdır.

6. Dış bileşen ve hizmet bağımlılıklarını kaydedin

Uygulama başka paketler, ücretli bileşenler veya çevrim içi hizmetler kullanabilir. Hangi bağımlılığın hangi işleve hizmet ettiği anlaşılmalıdır. Kaynak dosyaları alınsa bile dış hizmet hesabı kapalıysa belirli özellikler çalışmayabilir. Bazı bileşenlerin kullanımı özel lisans koşullarına bağlı olabilir. Bunların güncel koşulları ilgili kaynaklardan kontrol edilmelidir. “Açık kaynak kullanıldı” veya “lisans dahil” gibi genel ifadelerin projede hangi bileşenleri anlattığını açıklatın.

Kaynak kod teslimi için bağımlılık listesinin güncelliği önemlidir. Kullanılmayan eski paketler veya farklı sürümdeki araçlar yanlış yönlendirebilir. Gerekli bileşenlerin sürümleri ve edinilme yöntemi kayıt altına alınabilir. Ancak her paket dosyasının elle kopyalanması zorunlu değildir; kullanılan ekosisteme uygun yöntem tercih edilir. İşletme açısından kritik soru, sistemi sürdürecek yetkin kişinin bu bağımlılıkları anlayıp uygun koşullarda temin edebilmesidir. Lisans yorumu gereken konular teknik kurulum sorusundan ayrı değerlendirilmelidir.

7. Derleme ve yayınlama adımlarını doğrulayın

Bazı uygulamalarda kaynak dosyalarının çalıştırılabilir pakete dönüştürülmesi gerekir. Bu süreç derleme veya paketleme adımları içerebilir. Hangi araç ve ayarların gerektiği açıklanmalıdır. Yayınlama ise uygulamanın kullanım ortamına alınmasıdır; derlemeyle aynı işlem olmayabilir. Devralan ekip bu iki aşamayı ayırt edebilmelidir. Otomatik süreçler kullanılıyorsa bunların nerede bulunduğu ve hangi erişimlere ihtiyaç duyduğu da belirtilmelidir. Otomasyon adının verilmesi tek başına yeterli devir bilgisi değildir.

Kaynak kod teslimi değerlendirmesinde boş bir deneme ortamında kurulum veya derleme kontrolü yapılması düşünülebilir. Bu kontrolün kapsamı ve sorumlusu baştan belirlenmelidir. Canlı sistemi gereksiz riske sokmadan dosyaların kullanılabilirliği hakkında bilgi edinilebilir. Başarılı test, bütün gelecekteki ortamlarda sorunsuz çalışma garantisi değildir. Ancak eksik dosya veya unutulmuş ayar gibi konuların görünmesine yardımcı olabilir. Kontrol sonucunda hangi sürümün hangi ortamda denendiği kısa notla saklanmalıdır.

8. Testler, bilinen sorunlar ve kullanım sınırlarını paylaşın

Devralan kişinin yalnızca dosyaları değil, önemli kontrol noktalarını da anlaması yararlıdır. Otomatik testler varsa nasıl çalıştırılacakları açıklanabilir. Manuel kabul örnekleri veya kritik iş akışları ayrıca paylaşılabilir. Bilinen sorunlar gizlenmemelidir; hangi durumun neyi etkilediği ve nasıl ele alınacağı belirtilmelidir. Bu liste bütün yazılımın kusursuz olduğunu kanıtlamaz. Ancak yeni ekip veya sorumlu kişinin mevcut sınırları öğrenmesini kolaylaştırır. Açıklanmayan sorunlar sonradan tekrar keşfedilmek zorunda kalabilir.

Kaynak kod teslimi belgelerinde tamamlanmış iş ile taslak geliştirmeler ayrılmalıdır. Devam eden bir özellik yanlışlıkla canlı sürümün parçası sanılabilir. Bekleyen talepler, ertelenmiş işler ve bilinen sınırlamalar farklı başlıklarda tutulabilir. Sorunların önceliği projeye göre değerlendirilir; bütün küçük ayrıntılar aynı etkiye sahip değildir. Teslim sonunda hangi konuların açık kaldığını tarafların aynı şekilde anlaması önemlidir. Gerekli destek veya düzeltme koşulları gerçek anlaşmada ayrıca açıklanmalıdır.

9. Teslim kaydını ve sonraki sorumluluğu belirleyin

Hangi dosyanın, deponun veya belgenin ne zaman verildiği kaydedilebilir. Devralan kişinin erişimi doğrulaması ve eksik gördüğü başlıkları bildirmesi için yöntem belirlenmelidir. Bir arşivin gönderilmesiyle bütün devir işleminin tamamlandığı varsayılmamalıdır. Sonraki bakım sorumlusu, erişim yöneticisi ve açık konuların takipçisi belli olmalıdır. Teslim kaydı hukuki değerlendirme gerektirebilir; burada amaç günlük işte hangi sonucun paylaşıldığının izlenebilir olmasıdır. Bilgiler güncel tutulmalıdır.

Kaynak kod teslimi sonrasında geliştiriciyle ilişki devam edebilir veya başka ekibe geçilebilir. Her iki durumda görev ve erişim sınırları konuşulmalıdır. Devralınan dosyaların kopyalanma, değiştirilme veya dağıtılma koşulları sözleşme ve lisanslarla değerlendirilir. Teknik ekip bu konuda genel varsayımla hareket etmemelidir. İşletmenin de yalnızca dosyayı aldığı için her kullanımın serbest olduğunu düşünmemesi gerekir. Açık koşullar, gelecekteki çalışmanın daha anlaşılır biçimde planlanmasına yardımcı olur.

Teslim denemesinde hangi soruları sorun?

Kaynak kod teslimi için yetkin kişiyle sınırlı bir deneme planlayabilirsiniz. Yeni ortam hazırlanabiliyor mu, gerekli bağımlılıklar bulunuyor mu ve uygulama temel işlemi yapabiliyor mu? Bu kontrolün kapsamı canlı sistemin tam kopyasını kurmak olmak zorunda değildir. Hangi bilginin doğrulanmak istendiği baştan belirlenmelidir. Teknik devrin incelenmesi ile güvenlik testi aynı şey değildir. İzin, ortam ve sorumluluk uygun biçimde belirlenmeden canlı sistemde deneme yapılmamalıdır.

Deneme sırasında ortaya çıkan soruları tek listede toplayın. “Çalışmadı” yerine hangi adımın hangi mesajla durduğunu kaydetmek teknik ekibin değerlendirmesini kolaylaştırır. Gerekli erişim eksikse bununla kod sorunu aynı kategoriye konmamalıdır. Açıklama güncellendikten sonra ilgili adım tekrar denenebilir. Böylece teslim yalnızca bir gösterim anına dayanmaz; takip edilebilir küçük kontrol adımlarına dönüşür. Her proje için aynı ayrıntıda test gerekmez, ancak kritik bağımlılıklar görünmez bırakılmamalıdır.

Varsayımsal senaryo: Yönetim panelini başka ekibe devretmek

Bir işletmenin yıllardır kullandığı yönetim panelini yeni ekiple sürdüreceğini varsayalım. Eski ekip kaynak dosyalarını arşiv olarak paylaşır. Yeni ekip başlangıçta yalnızca bu arşivle kuruluma çalışır; fakat zamanlanmış rapor görevinin farklı sunucuda bulunduğu anlaşılır. Ayrıca bildirim hizmeti hesabı tek bir çalışanın özel adresindedir. Buradaki sorun yalnızca kodun eksik olması değildir. Uygulamanın bütün çalışma bileşenlerinin ve erişim düzeninin açıklanmamış olmasıdır. Devir kapsamı yeniden gözden geçirilir.

Kaynak kod teslimi bu senaryoda bileşen listesiyle tamamlanır. Rapor görevinin dosyaları, çalıştırma düzeni ve gerekli ayarları açıklanır. Bildirim hesabının nasıl yönetileceği uygun izin ve hizmet koşullarıyla değerlendirilir. Yeni ekip deneme ortamında temel işlemleri kontrol eder. Bu çalışma belirli bir maliyet veya süre sonucu göstermez. Senaryo, tek arşivin neden bütün işletim bilgisinin yerine geçmeyebileceğini anlatır. Gerçek projede gerekli bileşenler ve devir koşulları farklı olabilir.

Kaynak kod teslimi görüşmesinde aynı işletmenin veri ihtiyacı ayrıca ele alınır. Gerçek kayıtların hangi yöntemle alınacağı ve yeni ekibin hangi verilere erişeceği belirlenir. Kişisel bilgilerin gereksiz kopyalarının oluşturulmaması için paylaşım sınırı konuşulur. İşletme eski ve yeni sistem arasında hangi tarihte geçiş yapacağını planlar. Böylece teknik dosya devri, veri geçişi ve erişim değişikliği ayrı işler olarak görülür. Birinin tamamlanmış olması diğerlerinin otomatik bittiği anlamına gelmez.

Günlük işlerin arka planındaki görevleri unutmayın

Kaynak kod teslimi incelemesinde kullanıcıların görmediği otomatik işler özellikle sorulmalıdır. Belirli saatte rapor hazırlayan görev, dosya dönüştüren işlem veya dış sistemden kayıt alan çalışma ayrı kurulumda bulunabilir. Ana uygulama açılıyor diye bunların da devralındığı varsayılmamalıdır. Hangi görevin ne zaman çalıştığı, başarısız olduğunda nasıl anlaşılacağı ve hangi yetkileri kullandığı açıklanmalıdır. Bazı projelerde görevler aynı dosya deposunda, bazılarında farklı hizmetlerde olabilir. Teknik ekipten bütün işletim bileşenlerini aynı iş akışı içinde göstermesini isteyebilirsiniz. Amaç araçları ezberlemek değil, günlük işin hangi parçalarla sürdüğünü anlamaktır.

Kaynak kod teslimi için bu otomatik görevlerin deneme ortamında çalıştırılmasına ilişkin sınırlar da önemlidir. Gerçek müşteriye bildirim göndermek veya canlı sisteme kayıt yazmak istemeyebilirsiniz. Test ayarlarının hangi işlemleri engellediği ve hangi verilerin örnek olduğu açıklanmalıdır. Bilinmeyen bir komutu yalnızca belgede yazıyor diye canlı ortamda çalıştırmak doğru yaklaşım değildir. Devralan yetkin kişi gerekli izin ve etkileri değerlendirmelidir. Deneme sonucunda hangi otomatik işin kontrol edildiği kaydedilebilir. Böylece uygulamanın ekranları çalışırken arka plandaki önemli işlerin unutulması riski daha erken görünür hale gelir. Kapsam, gerçek sistemin yapısına göre belirlenir.

Devir sonrasında bilgiyi güncel tutun

Kaynak kod teslimi tek bir tarihte gerçekleşebilir; fakat uygulama kullanılmaya ve değişmeye devam edebilir. Sonraki ekip yeni bir hizmet eklerse eski bağımlılık listesi eksik kalır. Kurulum adımı değişirse belge güncellenmelidir. Hangi kayıtların kim tarafından düzenleneceği konuşulmalıdır. Belgenin yalnızca ilk geliştiricide kalması veya birbirinden farklı kopyaların dolaşması bilgi kaybına yol açabilir. Güncel açıklamalar, sürüm bilgisi ve erişim sorumluları uygun bir yerde tutulabilir. Her küçük değişiklikte uzun rapor gerekmez; sistemi yeniden kurmak veya sürdürmek için gerekli bilgilerin kaybolmaması önemlidir. Bu sorumluluk bakım düzeniyle birlikte ele alınabilir.

Kaynak kod teslimi sonrasında yeni ekip eski varsayımları anlamaya da ihtiyaç duyabilir. Belirli veri alanının neden zorunlu olduğu veya bir dış bağlantının neden farklı çalıştığı kısa kararla açıklanabilir. Karar gerekçesi bulunmadığında aynı konu tekrar araştırılabilir. Bununla birlikte geçmişteki her yazışmayı sınırsız saklamak veya herkese açmak gerektiği sonucu çıkarılmamalıdır. İlgili bilgi, uygun erişim sınırıyla ve gerçek ihtiyaçla değerlendirilir. Teknik açıklamayla müşteri verisini aynı dosyada toplamak zorunda değilsiniz. İyi düzenlenmiş bilgi, devralan kişinin sorumluluğunu anlamasına yardımcı olur; yeterli uzmanlık ve gerekli incelemenin yerine geçmez. Süreklilik yalnızca dosyaların varlığına değil bu düzenin kullanılmasına da bağlıdır.

Teslim öncesi kontrol listesi

Kaynak kod teslimi için aşağıdaki başlıkları proje sorumlusuyla birlikte inceleyin. Liste bütün yazılımlar için eksiksiz teknik veya hukuki şablon değildir. Uygulamanın yapısına göre ek sorular gerekebilir. Her maddenin cevabının aynı dosyada bulunması zorunlu değildir; fakat nerede olduğu ve kimin sorumlu olduğu anlaşılmalıdır. Bilinmeyen konuları tahminle doldurmayın. Karar için önemli başlıkların ilgili yetkin kişilerce açıklığa kavuşturulmasını isteyin.

• Teslim kapsamındaki bütün uygulama parçaları listelendi mi?
• Paylaşılan sürümün canlı sürümle ilişkisi açık mı?
• Depo erişimi, sahiplik ve kullanıcı yetkileri doğrulandı mı?
• Kurulum ve çalıştırma adımları güncel biçimde açıklandı mı?
• Gizli ayarlar güvenli yöntemle ve uygun sınırla ele alındı mı?
• Veri tabanı yapısı, değişiklikleri ve veri kapsamı belirtildi mi?
• Dış bağımlılıklar, hesaplar ve lisans soruları kaydedildi mi?
• Derleme, yayınlama ve kontrol adımları değerlendirildi mi?
• Bilinen sorunlar ve sonraki sorumluluklar paylaşıldı mı?

Kaynak kod teslimi listesini geliştiriciyle konuşurken devralacak teknik kişinin katılımı yararlı olabilir. İşletme yöneticisinin hangi dosyanın eksik olduğunu tek başına anlaması beklenmemelidir. Yönetici iş devamlılığı ve sorumlulukları sorabilir; teknik kişi kurulum ve bağımlılıkları değerlendirebilir. Gerekli hak koşulları ise uygun uzmanlıkla ayrıca ele alınır. Farklı sorumlulukların tek kişide toplanması şart değildir. Önemli olan aralarında bilgi boşluğu kalmaması ve sonuçların ortak kayıtta görünmesidir.

Yaygın yanlış inanışlar

“Kaynak dosyalarını aldıysam bütün haklar bendedir” sonucu otomatik çıkarılamaz. Teknik teslim ve hak koşulları ayrı değerlendirilmelidir. “Çalışan program varsa kaynak kod da verilmiştir” düşüncesi de her zaman doğru değildir. Kullanılan dosyanın türü açıklanmalıdır. Kaynak kod teslimi hakkında genel sözler yerine hangi bileşenlerin ve hangi koşulların kastedildiğini sorun. Böylece bir tarafın teknik dosya paylaşımından, diğerinin geniş kullanım yetkisinden söz etmesi daha erken fark edilebilir.

Kaynak kod teslimi için “bir başka yazılımcı zaten her şeyi çözer” varsayımı da risklidir. Yetkin ekip birçok konuyu inceleyebilir; ancak eksik yapılandırma ve açıklanmamış hizmetler ek araştırma gerektirebilir. İyi belge, bütün uzmanlık ihtiyacını ortadan kaldırmaz ama doğru başlangıç bilgisi sağlar. “Belge varsa kesin kurulur” düşüncesi de aşırıdır; belgenin güncelliği ve ortam koşulları önemlidir. Uygun kapsamlı deneme, açıklamaların kullanılabilirliği hakkında daha somut bilgi sağlayabilir.

Yerel ve uzaktan devir görüşmesi

Maltepe, İdealtepe ve Anadolu Yakası içinde yüz yüze görüşmede mevcut uygulamanın bileşenleri anlatılabilir; İstanbul dışında veya Türkiye genelinde uzaktan görüşmelerde de aynı belge düzeni kullanılabilir. Kaynak kod teslimi için önce uygulamanın neden devralınacağını ve sonraki sorumlunun kim olacağını açıklayın. HD Bilgisayar özel yazılım geliştirme hizmeti üzerinden görüşürken teknik dosyalarla veri ve hesap ihtiyaçlarını ayrı başlıklarda ele alabilirsiniz. Gerçek kapsam inceleme ve anlaşmayla belirlenmelidir.

Sık sorulan sorular

Kurulabilir program kaynak kod sayılır mı?

Her zaman değil. Çalıştırılabilir paket, kaynak dosyalarından oluşturulmuş farklı bir çıktı olabilir. Kaynak kod teslimi için hangi dosya türlerinin verildiği açıklanmalıdır. İşletme yönetiminin bütün teknik biçimleri bilmesi gerekmez; yetkin kişiden teslimin amacını ve kullanılabilirliğini değerlendirmesi istenebilir. Dosya adından tek başına kesin sonuç çıkarılmamalıdır.

Kaynak dosyası alınca bütün haklar geçer mi?

Bu otomatik kabul edilmemelidir. Kullanım, değiştirme ve dağıtım koşulları sözleşme ve ilgili lisanslarla değerlendirilmelidir. Kaynak kod teslimi teknik bir işlem olabilir; hak kapsamı ayrı sorudur. Hazır bileşenler ve işletmeye özel geliştirilen parçalar farklı koşullara sahip olabilir. Somut durum için gerekli uzman değerlendirmesi alınmalıdır.

Depo erişimi verilmesi yeterli mi?

Kapsama bağlıdır. Dosyaları görmek, depoyu yönetmek ve hesabın sahipliğini devralmak farklı yetkilerdir. Kaynak kod teslimi sırasında hangi erişimin neden gerektiği belirlenmelidir. Devralan kişinin hesabıyla kontrol yapılması yararlıdır. Ayrıca ayarlar, dış hizmetler ve kurulum bilgileri başka yerde bulunabilir; depo bütün çalışma ortamını tek başına açıklamayabilir.

Parolalar da kodun içinde mi olmalı?

Gizli değerlerin kaynak dosyalarında açıkça tutulması zorunlu değildir ve uygun olmayabilir. Hangi ayarın gerekli olduğu örnek dosya veya açıklamayla belirtilebilir. Kaynak kod teslimi sırasında gerçek değerlerin güvenli biçimde nasıl sağlanacağı konuşulur. Gereksiz kişilere erişim verilmemesi ve devir sonrası yetkilerin gözden geçirilmesi önemlidir. Yöntem teknik güvenlik koşullarına göre belirlenir.

Teslimin kullanılabilirliği nasıl anlaşılır?

Uygun kapsamlı kurulum veya derleme denemesi yapılabilir. Hangi sürümün hangi ortamda kontrol edileceği ve kimin değerlendireceği önceden belirlenmelidir. Kaynak kod teslimi testi bütün gelecekteki kullanımın garantisi değildir; eksik dosya ve açıklamaları görmeye yardımcı olabilir. Canlı sistemde izinsiz deneme yapmak yerine uygun test ortamı ve yetki kullanılmalıdır.

Veri tabanı yedeği de mutlaka alınmalı mı?

İhtiyaç ve anlaşmaya göre değişir. Boş yapı, örnek veri ve gerçek kayıtlar ayrı konulardır. Kaynak kod teslimi kapsamındaki veri ihtiyaçları açıkça belirtilmelidir. Gerçek kayıtların paylaşımı güvenlik ve ilgili koşullarla değerlendirilir. Bir yedeğin varlığı, güncel kodla uyumlu ve kullanılabilir olduğunu tek başına göstermez; gerekli teknik kontrol ayrıca yapılabilir.

Dosyayı değil, anlaşılır bir devri hedefleyin

Kaynak kod teslimi, uygulamanın geliştirme dosyalarını açıklanmış kapsamla devralmak için önemli bir adımdır. Ancak kurulum, veri yapısı, dış bağımlılıklar ve erişimler bilinmiyorsa yalnızca arşiv almak yeterli olmayabilir. Teknik devirle hak koşullarını ayırmak, yanlış beklentilerin önüne geçmeye yardımcı olur. Her proje aynı teslim düzenini gerektirmez. İşin devamını üstlenecek kişinin hangi bilgiye ihtiyaç duyduğu ve bunun nasıl doğrulanacağı önceden konuşulmalıdır.

Kaynak kod teslimi hakkında ilk görüşmeye uygulamanızın amacını, mevcut bileşenlerini ve devri neden istediğinizi yazarak hazırlanabilirsiniz. Bilmediğiniz alanları açıkça belirtmeniz yeterlidir; eksik bilgiyi tahminle doldurmanız gerekmez. HD Bilgisayar’a 0532 396 34 71 üzerinden ulaşarak özel yazılım ihtiyacınızı değerlendirebilirsiniz. Gerçek teslim ve kullanım koşulları ilgili belgelerde netleştirilir. Amaç yalnızca bir dosya edinmek değil, sonraki çalışmanın sorumluluklarını anlayarak ilerlemektir.