Teknik Yaklaşımlar

Mükemmellik Bir Tesadüf Değil; Yıllarca Sürdürülen Bir Disiplinin Çıktısıdır

Bir kodun çalışması bir günlük iş; o kodun yıllarca hatasız çalışması bir disiplinin meyvesidir.

Yazılım dünyasının üzerine yıllar boyunca bina ettiğimiz tek bir öğreti var: 'çalışıyor' yeterli değil. Bir projenin sahnede 'çalışıyor' diye görünmesiyle, üç yıl sonra hâlâ kolayca geliştirilebilir, güvenli ve hızlı olması arasında milyonlarca dolarlık bir uçurum var. Bu uçurumun bir tarafında günü kurtarmaya çalışan kod, diğer tarafında yarınları kuran kod duruyor. Partnerfy'da yazdığımız her satır, bu uçurumun doğru tarafında durması için belirli prensiplere göre yazılıyor. Bu prensipleri kendimiz icat etmedik — uluslararası mühendislik literatüründen aldık, sahada test ettik, sözleşmemize gömdük. Sonuç: ajansınızın müşterisine teslim edilen kod, ilk gün çalışan değil; on yıl sonra da çalışacak olan. Bu sayfa, bu disiplinin tek tek nasıl uygulandığını ve sizin onayınız olmadan hiçbir satırın canlıya çıkmamasını sağlayan filtre mekanizmalarını anlatıyor.

'Çalışan Kod' ile 'Kaliteli Kod' Arasında Bir Uçurum Var

Sektörde 'çalışan kod' sahibi olmak için yetkin bir junior geliştirici bile yeterli. 'Çalışan kod', tek bir sprint için, tek bir feature için, tek bir kullanıcı senaryosu için doğru sonuç üretiyor demektir. Ama yazılımın yaşamı tek bir sprint değil. Üç ay sonra projeye yeni bir feature eklenmek istendiğinde, altı ay sonra trafik patlamasıyla başa çıkması gerektiğinde, bir yıl sonra teknik borçların faturası geldiğinde — işte o anlar 'çalışan kod' ile 'kaliteli kod' arasındaki uçurumu gösteriyor. Birincisi her dokunulduğunda yeni bir hata üretirken, ikincisi sessizce büyümeye devam ediyor. Partnerfy mühendislik kültüründe 'çalışıyor' kelimesi tek başına kullanılmaz; 'çalışıyor ve bakım maliyeti düşük' olarak yazılı bir taahhüde dönüştürülür. İlk teslim günü kadar, üçüncü yıl da sözleşmemizin parçasıdır.
'Çalışan Kod' ile 'Kaliteli Kod' Arasında Bir Uçurum Var

Üç Modern Mühendislik Metodolojisi Üzerine Kuruluyuz

Her satır kodun nasıl yazılacağına dair sözleşmedeki temel disiplin. Kullandığımız değil, kabul ettiğimiz yöntemler.

Agile / Scrum

İki haftalık sprintler, story-point hesabı, retrospektifler ve velocity ölçümü. Projenin ilerleyişi her hafta görünür, sapma çıkması durumunda sprint günü içinde devreye giren kontrol kapısı çalışır.

TDD / BDD

Kodu yazmadan önce testini yazıyoruz. Bir özellik geliştirilmeden önce, o özelliğin nasıl davranması gerektiğine dair test senaryoları yazılıdır. Bug oluşmadan önce yakalanır, sonra düzeltilmez.

CI/CD & DevOps

Her commit otomatik olarak test edilir, paketlenir ve staging ortamına atılır. Manuel deploy yoktur; insan hatası, deploy aşamasında yoktur. Bir özelliğin canlıya çıkması bir komut değil; bir butondur.

Spagetti Kodun Bedeli, İlk Teslim Gününde Görünmez

Spagetti Kodun Bedeli, İlk Teslim Gününde Görünmez

Yazılım sektörünün uzun yıllar görmezden geldiği bir gerçek var: hızlıca yazılmış, yapısal olmayan, dökümante edilmemiş kod ilk teslim günü 'çalışıyor' gibi görünür. Müşteri memnun, ajans memnun, geliştirici memnun. Ama o gün bir saat bombası ayarlanmıştır. Bu sektörde 'Spagetti Kod' olarak anılan yapılar, ilk gün hatasız çalışsa bile zamanla üzerine çivi bile çakılamaz halde, hantal ve maliyetli yapılara dönüşür. Yeni bir özellik eklemek 'kodu önce anlamak' demektir; mevcut bir hatayı düzeltmek 'önce nereye dokunulduğunu öğrenmek' demektir. Mühendislik literatüründe buna 'Teknik Borç' denir. Partnerfy'da yazdığımız her modülün üzerine düşen sorumluluğun farkındayız. Bu yüzden her sınıfa bir tek görev veririz, her fonksiyonu olabildiğince küçük tutarız, her isim için literatürdeki standardı uygularız. Üç yıl sonra başka bir mühendis projeyi açtığında, biz orada olmasak da kodun ne yaptığını okuyabilmesi için.

Bir Satır Kodun Canlıya Yolculuğu: Üç Acımasız Filtre

Partnerfy mühendislik ekibinde hiçbir geliştirici yazdığı kodu doğrudan ana sisteme gönderemez. Her satır, canlıya çıkmadan üç farklı kapıdan geçmek zorundadır.

1. İnsan İncelemesi (Code Review)

Yazılan kod önce başka bir kıdemli mühendis tarafından incelenir. Mantık hatası var mı? Güvenlik açığı var mı? Standartlara uygun mu? Mimari prensiplerimize aykırı bir adım atıldı mı? Onay almayan kod bir sonraki aşamaya geçemez. Yazan ile inceleyen farklı insanlardır — kimse kendi kodunu kendisi onaylamaz.

2. Otomatik Testler (CI Pipeline)

İnsan onayından geçen kod otomatik test sunucularına alınır. Unit Tests, Integration Tests ve E2E senaryoları saniyeler içinde simüle edilir. Kodun sistemin başka bir yerini bozup bozmadığı yüzlerce senaryoda kontrol edilir. Tek bir test başarısız olursa, kod geriye gönderilir.

3. Staging Deploy + Zero-Downtime

Testleri geçen kod, canlı sistemin birebir kopyası olan Staging ortamına alınır. Burada gerçek veriye yakın koşullarla son kez kontrol edildikten sonra, kullanıcıya hissettirmeden (Zero-Downtime) canlıya alınır. Bir şey ters giderse, otomatik rollback ile dakikalar içinde önceki sürüme dönülür.

Sizin Onayınız Olmadan Hiçbir Şey Canlıya Çıkmaz

Üç teknik filtreden geçen kusursuz bir proje bile, sizin imzanız sisteme düşmeden müşterinizin gözünün önüne çıkmaz.

Üç aşamalı teknik filtremiz bir projeyi 'yayına hazır' hale getirir — ama bizim için 'hazır' demek 'gönderildi' anlamına gelmez. Her geliştirilen proje, önce size özel, dışarıya kapalı bir Staging URL üzerinden ID.Partnerfy paneliniz üzerinden sunulur. Bu aşamada müşteriniz hâlâ hiçbir şey görmüyor. Siz, paneliniz üzerinden tasarımı, fonksiyonları ve içerikleri bizzat denetlersiniz. Eğer bir revize talebiniz varsa panel üzerinden iletirsiniz; yoksa 'Yayına Al' butonuna basarak onayı verirsiniz. Sizin dijital imzanız ve onayınız sisteme düştüğü saniye, proje otomatik olarak gerçek domain adresinde yayına girer. Bu mekanizma sadece bir görsellik değil; üç ayrı disiplinin bir araya geldiği bir mimari karar. Birincisi, müşterinizle aramızda bir adım daha geçirir; ikincisi, sizin teknik karara verdiğiniz son sözü garantilemiş olur; üçüncüsü, geri dönüşü olabilecek bir teknik hatayı 'sahnede değil arkada' yakalanmasını sağlar. 'Yayına Al' bir buton değil; sizin bir kararınızdır.

ID.Partnerfy'da Tek Bir Buton: 'Yayına Al'

ID.Partnerfy panelinin onay ekranı, partnerlik mimarimizin en somut çıktısı. Her geliştirilen modül için panelde dört şey görürsünüz: (1) Staging URL — projenin yayın öncesi son halini gösteren önizleme bağlantısı; (2) Geliştirme notları — bu sprintte hangi özelliklerin eklendiği ya da düzeltildiği; (3) Test raporları — otomatik testlerin sonuçları; (4) Yayına Al butonu — kırmızı, büyük, vurgulu. Bu butona basmadığınız sürece, modül müşterinizin gördüğü canlı sistemde değişiklik üretmez. Bastığınız saniye otomatik deploy süreci başlar; zero-downtime ile sürüm değişikliği gerçekleşir; bittiğinde size panelden bildirim gelir. Yetki istediğiniz takdirde bu butona ekibinizdeki belirli kişilere de açabilirsiniz. Bir müşteri ilişkileri yöneticinizin, bir ürün müdürünüzün, hatta nihai müşterinizin bu butona basabilmesi sizin organizasyonel tercihiniz. Ama kim basarsa bassın, basıldığı an yetkilendirme zinciri kayıt altına alınır.
ID.Partnerfy'da Tek Bir Buton: 'Yayına Al'

Mühendislik disiplinimizin dışsal göstergeleri: süreçlerimizden topladığımız üç somut metrik. Sayılar tek başına anlam ifade etmiyorsa, sözleşmenin gerçek dünyada nasıl yürüdüğüne bakmanın belki en hızlı yolu.

%100
Code Review Geçişi
İnsan onaysız kod yok
%85+
Test Kapsamı
Otomatik test pipeline
<5dk
Rollback Süresi
Bir şey ters gittiğinde

Kodun Yanında Teslim Edilen Altı Belge

Bir yazılımı 'teslim etmek', sadece çalışan kod göndermek değildir. Üç yıl sonra başka bir mühendis projeyi açtığında ondan beklenen anlama hızı, teslim ettiğimiz dokümantasyonun kalitesinde gizlidir.

API Dokümantasyonu

OpenAPI / Swagger formatında, her endpoint için input ve output şemaları, örnek istek/yanıt çiftleri, hata kodu listesi ve yetkilendirme şartları. Front-end ekipler ya da entegrasyon partnerleri başka bir konuşma yapmadan koda başlayabilir.

Mimari Şeması

Yüksek seviyeli sistem diyagramı: hangi servis hangi servisle konuşuyor, veri nereden nereye akıyor, hangi entegrasyon hangi katmanı kullanıyor. Mimari kararların gerekçeleri (Architecture Decision Records) ekli.

Veri Tabanı Şeması

ER diyagramı, tablo açıklamaları, ilişki haritaları, index stratejisi ve veri tipleri. Migration dosyaları repository içinde versiyon kontrollü ve sıralı.

Deploy Rehberi

Projenin nasıl yayına alınacağı adım adım yazılı: hangi env değişkenleri, hangi build komutları, hangi cache temizliği, hangi DB migration sırası. Rollback prosedürü de aynı belgede.

Operasyonel Runbook

Yaygın senaryoların çözümü: nasıl yedek alınır, nasıl log incelenir, nasıl ölçeklenir, bir incident anında hangi adımlar atılır. Bir DevOps mühendisinin gece yarısı arandığında ona yol gösteren belge.

Kod İçi Açıklamalar

Fonksiyon bazında JSDoc / PHPDoc / KDoc yorumları, kritik mimari kararların gerekçeleri kod satırının hemen yanında. Kod kendi kendini anlatır; dokümantasyonu okumak için ayrı bir sekmeye geçmek gerekmez.

Yıllar Sonra Başka Bir Mühendis Bu Kodu Açtığında — Biz Orada Olmasak Da — Kod Kendi Kendini Anlatır

İyi yazılmış bir kod, en iyi dokümantasyondur.

Bir mühendisin kendine sorması gereken son soru şudur: 'Beş yıl sonra hiç tanımadığım bir geliştirici bu kodu açtığında, ben yokken bile o anlayabilecek mi?' Eğer cevap 'hayır' ise, kod yeterince iyi yazılmamıştır. Partnerfy'da bu sorunun cevabını her commit'te yeniden veririz. Yazdığımız her sınıf, her fonksiyon, her değişken — sanki bizden sonra projeyi devralacak biri için yazılmıştır. İsimler ne yaptıklarını anlatır, mimari kararların gerekçesi koddadır, dokümantasyon koddan kopuk bir Word dosyası değildir; kodun yanında, koddaki yorum satırlarında, repository'deki README'de yaşar. Bir ajansın bizimle çalışmasının uzun vadeli kazancı şudur: bizimle çalışmayı bıraksanız bile, geride bıraktığımız kod ajansınızda kalır ve başka bir ekiple devam edebilir. Çünkü o kod kendi kendini anlatacak şekilde yazıldı. Bizim itibarımız, sadece bizimle çalışırken sahip olduğunuz değil; ayrılırken arkamızda bıraktığımız kalite katmanıdır.

Teknik Yaklaşımımızı Detaylı Görmek İçin İletişime Geçin

Aşağıdaki formu doldurun; size mühendislik standartlarımızı içeren detaylı bir teknik white-paper, örnek API dokümantasyonu ve geliştirme süreç akış şeması gönderelim. 0850 259 30 04 numarasından da doğrudan ulaşabilirsiniz.

Aklınıza takılan sorular için bize her zaman ulaşabilirsiniz: [email protected]

Başvurunuz tarafımıza ulaştı!

Partnerlik başvurunuzu inceleyip en kısa sürede numaranız üzerinden size dönüş yapacağız.

🇹🇷+90

Şirket Türünüz Nedir?

Hangi konularda desteğe ihtiyacınız var?

500
1 1.000

Aylık olarak hedeflediğiniz tahmini müşteri sayısı (1 – 1.000)

Bölüm Tipi Seç

Eklemek istediğiniz bölüm tipini seçin

Eklendikten sonra Filament admin'den içeriği düzenleyebilirsiniz.

sonuç