Şirket İçi Proje Yönergelerinin (Guidelines) Hazırlanma Süreçleri

Bir şirkette proje yönergesi hazırlamak, birkaç sayfalık kural listesi yazmaktan çok daha fazlasıdır. İyi tasarlanmış bir guideline, ekiplerin aynı konuları tekrar tekrar tartışmasını azaltır, karar alma hızını artırır ve yeni çalışanların sisteme daha hızlı uyum sağlamasına yardımcı olur. Yaklaşık on yıllık yazılım, ekip koordinasyonu ve süreç geliştirme deneyimimde gördüğüm en önemli nokta şudur: İnsanların neden var olduğunu anlamadığı bir kural uzun süre yaşayamaz. Bu nedenle Şirket İçi Proje Yönergelerinin (Guidelines) Hazırlanma Süreçleri, doküman yazımından önce gerçek problemi tanımlamakla başlamalıdır. Bu rehberde şirket içi proje yönetimi yönergesi nasıl hazırlanır, kurumsal proje yönetimi standartları ve prosedürleri nasıl oluşturulur ve proje yönergesinde görev yetki sorumluluk ve onay süreçleri nasıl belirlenir gibi pratik sorulara mühendislik odaklı yanıtlar bulacaksınız.

Şirket İçi Proje Yönergesi (Guideline) Nedir?

Şirket içi proje yönergesi, ekiplerin belirli durumlarda nasıl hareket etmesi gerektiğini açıklayan ortak çalışma referansıdır. Yönerge yalnızca yasaklardan veya zorunluluklardan oluşmamalıdır. İyi bir metin, kuralın neden var olduğunu, hangi kapsamda uygulandığını ve gerektiğinde nasıl istisna talep edileceğini de açıklar. Böylece ekip üyeleri sadece talimat uygulamaz, kararın arkasındaki mühendislik düşüncesini de öğrenir. Özellikle büyüyen yazılım ekiplerinde ortak bir guideline sistemi, kişilere bağlı çalışma biçimlerinin kurumsal bilgiye dönüşmesini sağlar.

Project Guideline Nedir?

Project guideline, bir projenin başlatılmasından geliştirilmesine, test edilmesinden yayınlanmasına kadar uygulanacak ortak prensipleri tanımlar. Örneğin yeni bir repository açılırken hangi dosyaların bulunacağı, pull request için kaç reviewer gerektiği veya release öncesinde hangi kontrollerin yapılacağı bu kapsamda belirlenebilir. Buradaki amaç çalışanların her seferinde sıfırdan yöntem icat etmesini önlemektir. Aynı zamanda ekipler arasında minimum kalite beklentisinin oluşmasını sağlar. Project guideline ne kadar açık yazılırsa proje başlangıcındaki belirsizlik de o kadar azalır.

Engineering Guideline Nedir?

Engineering guideline, yazılım geliştirme ve teknik operasyon süreçlerini kapsayan mühendislik kuralları bütünüdür. Kod kalitesi, mimari, test, güvenlik, CI/CD, gözlemlenebilirlik ve dokümantasyon gibi başlıklar bu yapının içinde yer alabilir. Engineering guideline ile geliştiricilere sadece ne yapacakları değil, hangi yaklaşımın hangi koşulda tercih edildiği de anlatılır. Böylece deneyimli geliştiricilerin kişisel bilgi birikimi daha geniş ekipler tarafından kullanılabilir hale gelir. Benim deneyimimde en etkili engineering guideline'lar kısa örneklerle desteklenen ve doğrudan geliştirme akışına bağlanan kurallardır.

Şirketler Neden Proje Yönergelerine İhtiyaç Duyar?

Takım sayısı arttıkça aynı probleme farklı çözümler üretilmesi doğal hale gelir. Bir ekip secrets yönetimini doğru yaparken başka bir ekip hassas bilgileri yanlışlıkla repository içinde tutabilir. Bir takım kapsamlı test yazarken başka bir takım release öncesinde yalnızca manuel kontrol yapabilir. Proje yönergeleri bu farklılıkların işletme açısından risk yaratan kısmını sınırlar. Böylece kurumsal proje yönetimi standartları ve prosedürleri nasıl oluşturulur sorusu, ortak beklentilerin açık biçimde yazılması ve uygulanabilir hale getirilmesi üzerinden yanıtlanır.

Guideline'ın Temel Hedefleri

Bir guideline yazmaya başlamadan önce hedefinin açık olması gerekir. Kuralın hedefi anlaşılmıyorsa ekip üyeleri onu yalnızca ek yük olarak görebilir. İyi bir guideline kaliteyi yükseltirken geliştiricinin işini gereksiz yere zorlaştırmamalıdır. Aynı zamanda ölçeklenebilir, ölçülebilir ve gerektiğinde değiştirilebilir olmalıdır. Bu nedenle temel hedefler yalnızca teknik doğruluk değil, sürdürülebilir ekip davranışı oluşturmak üzerinden düşünülmelidir.

Tutarlılık

Tutarlılık, farklı ekiplerin benzer durumlarda benzer kararlar verebilmesini sağlar. Aynı şirket içinde beş farklı repository oluşturma yöntemi bulunması bakım maliyetini artırabilir. Ortak naming, branching ve release kuralları sayesinde projeler arasında geçiş yapmak kolaylaşır. Yeni bir geliştirici başka takıma geçtiğinde temel akışları yeniden öğrenmek zorunda kalmaz. Tutarlılık bu nedenle yalnızca düzen değil, operasyonel verimlilik anlamına da gelir.

Kalite

Kalite hedefi, minimum mühendislik beklentisinin açık hale getirilmesini sağlar. Test, review, hata yönetimi ve dokümantasyon gibi konular kişisel tercihten çıkarak ortak ekip davranışına dönüşür. Burada kaliteyi soyut ifadelerle anlatmak yerine ölçülebilir kurallar oluşturmak gerekir. Örneğin “iyi test yazın” yerine kritik business logic değişikliklerinde ilgili testlerin güncellenmesini zorunlu tutmak daha uygulanabilir bir yaklaşımdır. Bu tür kurallar ekiplerin kalite anlayışını günlük geliştirme sürecine taşır.

Güvenlik

Güvenlik yönergeleri, güvenli davranışın yalnızca security ekibinin sorumluluğu olmadığını gösterir. Secret yönetimi, authentication, authorization, dependency kontrolü ve input validation gibi konuların ekip seviyesinde standartlaştırılması gerekir. Kritik kurallar mümkün olduğunda otomatik kontrollerle desteklenmelidir. Örneğin repository içinde secret bulunduğunda pipeline'ın hata vermesi yazılı uyarıdan daha etkilidir. Böylece güvenlik günlük geliştirme akışının doğal bir parçasına dönüşür.

Ölçeklenebilirlik

Beş kişilik ekipte sözlü olarak yürüyen bir süreç elli kişilik organizasyonda çalışmayabilir. İnsan sayısı arttıkça bilginin yalnızca deneyimli kişilerin hafızasında kalması ciddi bağımlılık yaratır. Guideline sistemi bu bilgiyi yazılı, aranabilir ve tekrar kullanılabilir hale getirir. Aynı zamanda yeni ekiplerin mevcut pratikleri hızlı şekilde benimsemesine yardımcı olur. Ölçeklenebilir bir guideline sistemi büyürken her kararın merkezi ekipten geçmesini gerektirmez.

Bilgi Paylaşımı

Guideline'lar deneyim sonucunda öğrenilen dersleri kurumsal hafızaya aktarır. Bir production incident sonrasında bulunan önemli bir ders yalnızca toplantıda kalırsa zamanla unutulabilir. Aynı ders guideline maddesine, otomatik kontrole veya starter template'e dönüştürüldüğünde daha kalıcı hale gelir. Böylece farklı ekipler aynı hatayı tekrar etmek zorunda kalmaz. Bilgi paylaşımı güçlü olduğunda kurumun öğrenme hızı da artar.

Hızlı Onboarding

Yeni çalışanların ilk haftalarda sürekli “Burada nasıl yapıyoruz?” sorusunu sorması beklenen bir durumdur. Ancak bu soruların tamamı kişiden kişiye cevaplanıyorsa onboarding süreci gereğinden fazla yorucu olur. Merkezi guideline kataloğu yeni çalışana repository, pull request, test, security ve release beklentilerini tek yerden öğretir. İlk pull request sırasında ilgili kuralların doğrudan görünür olması öğrenmeyi daha da hızlandırır. Böylece onboarding sözlü aktarımdan sistematik öğrenmeye dönüşür.

Policy, Standard, Guideline ve Procedure Arasındaki Fark

Kurumsal dokümantasyon sistemlerinde en sık yapılan hatalardan biri farklı doküman türlerini aynı anlamda kullanmaktır. Policy, standard, guideline ve procedure aynı şeyi ifade etmez. Aralarındaki fark özellikle zorunluluk seviyesi ve uygulama biçiminde ortaya çıkar. Bu ayrım yapılmadığında çalışanlar hangi kuralın zorunlu, hangisinin tavsiye olduğunu anlamakta zorlanabilir. Sağlıklı bir sistemde her doküman türünün amacı açıkça tanımlanmalıdır.

Policy Nedir?

Policy, kurumun temel kararını veya zorunlu ilkesini tanımlar. Genellikle “ne yapılmalıdır?” sorusuna üst seviyeden cevap verir. Örneğin hassas müşteri verilerinin korunması bir policy konusu olabilir. Policy çoğu durumda altındaki standard ve procedure belgelerine yön verir. Bu nedenle sık değişen teknik detaylar policy içine doldurulmamalıdır.

Standard Nedir?

Standard, policy tarafından belirlenen hedefin hangi teknik veya operasyonel şartlarla karşılanacağını açıklar. Örneğin verinin belirli sınıflarda şifrelenmesi veya belirli authentication yöntemlerinin kullanılması standard seviyesinde tanımlanabilir. Standard genellikle guideline'a göre daha bağlayıcıdır. Kontrol edilebilir ve mümkün olduğunca ölçülebilir olması beklenir. Böylece kurum farklı ekiplerde minimum ortak kalite seviyesini koruyabilir.

Guideline Nedir?

Guideline, ekiplerin tercih edilen yaklaşımı anlamasına yardımcı olan rehber niteliğindeki kuralları içerir. Bazı maddeler zorunlu olabilirken bazıları güçlü öneri seviyesinde tutulabilir. Burada MUST, SHOULD ve MAY gibi açık ifadeler kullanmak önemlidir. Guideline özellikle bir standardın nasıl uygulanabileceğini örneklerle göstermek için etkilidir. Bu yapı çalışanların sadece sonucu değil, tercih edilen yöntemin nedenini de anlamasını sağlar.

Procedure / SOP Nedir?

Procedure veya SOP, belirli bir işlemin adım adım nasıl yürütüleceğini açıklar. Örneğin emergency release yapmak için takip edilmesi gereken onay ve deployment adımları SOP kapsamında tanımlanabilir. Guideline yaklaşımı açıklarken procedure daha operasyonel bir yol tarif eder. Bu nedenle procedure mümkün olduğunca açık ve uygulanabilir olmalıdır. Kritik prosedürlerin düzenli olarak gerçek senaryolarla test edilmesi de faydalıdır.

Checklist Nedir?

Checklist, belirli bir işlemin önemli noktalarının unutulmaması için kullanılan kısa kontrol listesidir. Release, security review veya proje başlangıcı gibi süreçlerde oldukça kullanışlıdır. Checklist tek başına guideline'ın yerini almaz çünkü çoğu zaman maddelerin nedenini açıklamaz. Ancak doğru guideline ve procedure ile birlikte kullanıldığında uygulamayı hızlandırır. Özellikle tekrar eden operasyonlarda insan hatasını azaltmaya yardımcı olur.

Pattern Nedir?

Pattern, tekrar eden bir probleme daha önce başarıyla uygulanmış çözüm yaklaşımını ifade eder. Architecture pattern, integration pattern veya deployment pattern bu yapıya örnek olabilir. Pattern her durumda zorunlu kural olmak zorunda değildir. Bunun yerine ekiplerin kanıtlanmış seçenekler arasından bilinçli tercih yapmasını kolaylaştırır. Guideline içinde uygun pattern'lere referans verilmesi teknik karar süresini azaltabilir.

Architecture Decision Record (ADR) Nedir?

ADR, önemli bir mimari kararın neden alındığını kayıt altına alan kısa belgedir. Karar, alternatifler, gerekçeler ve sonuçlar genellikle aynı belge içinde yer alır. Aylar sonra “Neden bu teknolojiyi seçtik?” sorusunun cevabı ADR üzerinden bulunabilir. Böylece geçmiş kararların arkasındaki bağlam kaybolmaz. Guideline genel kuralı tanımlarken ADR belirli proje veya mimari kararın tarihçesini açıklar.

Bu Doküman Türleri Birbirine Nasıl Bağlanır?

Sağlıklı bir dokümantasyon sisteminde bu belgeler birbirini tamamlar. Policy üst seviyede kurumsal hedefi belirler, standard minimum şartları tanımlar ve guideline uygulanabilecek yöntemleri açıklar. Procedure işlemin nasıl yapılacağını gösterirken checklist kritik noktaların unutulmamasını sağlar. Pattern çözüm yaklaşımı sunar, ADR ise alınan özel kararın kaydını tutar. Bu ilişki açık kurulduğunda çalışanlar ihtiyaç duyduğu bilgiyi hangi belge içinde araması gerektiğini bilir.

Zorunluluk Seviyeleri Nasıl Tanımlanmalı?

Guideline maddelerinin en önemli özelliklerinden biri zorunluluk seviyesinin açık olmasıdır. Her cümlenin aynı ağırlıkta yazılması ekiplerin önceliklendirme yapmasını zorlaştırır. Güvenlik açısından kritik bir kural ile stil tercihini aynı seviyeye koymak doğru değildir. MUST, SHOULD ve MAY gibi terimler bu ayrımı görünür hale getirir. Şirket içi proje yönetimi guideline şablonu ve örnekleri hazırlanırken bu seviyelerin açıklaması belgenin başında verilmelidir.

MUST — Zorunlu

MUST, uygulanması zorunlu olan maddeler için kullanılmalıdır. Bu seviyedeki kurallar ihlal edildiğinde açık risk, güvenlik problemi veya iş gereksinimi ortaya çıkmalıdır. Örneğin production secret'larının kaynak kod içine yazılmaması MUST seviyesinde olabilir. Bu kurallar mümkün olduğunda otomatik kontrol edilmelidir. MUST seviyesinin gereksiz kullanılması zamanla kuralın değerini azaltabilir.

SHOULD — Güçlü Öneri

SHOULD, çoğu durumda uygulanması beklenen ancak makul istisnaları bulunabilen kuralları ifade eder. Ekip farklı bir yöntem kullandığında gerekçesini açıklayabilmelidir. Örneğin belirli bir logging pattern'i standart projelerde SHOULD olarak tanımlanabilir. Bu yaklaşım mühendislik esnekliğini tamamen ortadan kaldırmadan ortak davranış oluşturur. İyi yazılmış SHOULD maddeleri gerekçeyi ve olası istisnaları açıkça belirtir.

MAY — Opsiyonel

MAY, ekiplerin tercih edebileceği ancak zorunlu olmayan seçenekleri tanımlar. Bu seviyedeki maddeler faydalı pratikleri paylaşmak için kullanılabilir. Örneğin belirli bir yardımcı geliştirme aracının kullanılması MAY olarak tanımlanabilir. Böylece öneri ile zorunluluk birbirine karışmaz. Ekipler kendi bağlamına uygun seçeneği daha rahat değerlendirebilir.

“Recommended” ile “Required” Aynı Şey Değildir

Recommended bir yaklaşımın tercih edildiğini, required ise uygulanmasının zorunlu olduğunu ifade eder. Bu iki kavramın aynı cümle içinde belirsiz kullanılması ekiplerde gereksiz tartışma yaratır. Bir geliştirici öneri olduğunu düşündüğü madde nedeniyle merge engeliyle karşılaşırsa guideline'a olan güven azalabilir. Bu nedenle her kuralın enforcement biçimi zorunluluk seviyesiyle uyumlu olmalıdır. Dil ne kadar net olursa uygulama süreci de o kadar sağlıklı yürür.

Her Maddenin Aynı Zorunlulukta Olmasının Yarattığı Sorunlar

Her kuralı zorunlu yapmak ilk bakışta düzen sağlayacak gibi görünebilir. Fakat düşük riskli konular için ağır onay süreçleri oluşturmak ekiplerin işini yavaşlatır. Zamanla çalışanlar gerçekten önemli maddeler ile tercihe dayalı maddeler arasındaki farkı göremez. Bunun sonucu workaround ve gereksiz exception talepleri olabilir. Risk bazlı zorunluluk modeli bu nedenle daha sürdürülebilir bir yaklaşımdır.

Şirket İçi Guideline Neden Sadece Dokümantasyon Değildir?

Bir guideline'ın wiki üzerinde yayınlanmış olması onun hayata geçtiği anlamına gelmez. Gerçek değer, kuralın günlük geliştirme davranışına dönüşmesiyle ortaya çıkar. Çalışanların belgeyi bulabilmesi, anlaması ve gerektiğinde otomatik sistemlerden destek alması gerekir. Ayrıca compliance ve gerçek iş etkisi düzenli olarak ölçülmelidir. Bu nedenle guideline yönetimi yazım, uygulama, ölçüm ve iyileştirme döngüsünden oluşur.

Dokümanın Yazılması

İlk aşama problemin ve önerilen kuralın anlaşılır biçimde yazılmasıdır. Metin mümkün olduğunca somut olmalıdır. Belirsiz kavramlar yerine gerçek kullanım senaryoları verilmelidir. Her önemli madde gerekçe ve örnekle desteklenmelidir. İyi yazım sonraki adoption çalışmalarının temelini oluşturur.

Kurala Dönüştürülmesi

Dokümanda bulunan tavsiyelerin uygulanabilir kurallara dönüşmesi gerekir. Örneğin “PR'lar review edilmelidir” ifadesi yerine minimum reviewer sayısı ve exception koşulları belirtilebilir. Böylece ekip neyin beklendiğini net biçimde anlar. Kontrol edilebilir maddeler otomasyon için de uygun hale gelir. Kuralın sınırları açık olduğunda gereksiz yorum farkları azalır.

Ekiplere Yayılması

Yeni guideline'ın yalnızca e-posta ile duyurulması çoğu durumda yeterli değildir. Etkilenen takımlara neden değişiklik yapıldığı anlatılmalıdır. Kısa workshop, ekip toplantısı veya örnek repository gösterimi adoption için faydalı olabilir. Özellikle davranış değişikliği gerektiren maddelerde ekip geri bildirimi önemlidir. İnsanların sürece katılması sahiplenmeyi artırır.

Geliştirme Akışına Entegre Edilmesi

Guideline mümkün olduğunca geliştiricinin zaten kullandığı araçlarda görünür olmalıdır. Pull request template, CI kontrolü, starter repository ve developer portal bu amaçla kullanılabilir. Böylece çalışan ayrı bir belgeyi sürekli hatırlamak zorunda kalmaz. Doğru davranış geliştirme akışının doğal parçasına dönüşür. Bu yaklaşım manuel kontrol ihtiyacını da azaltır.

Uyumluluğun Ölçülmesi

Bir guideline'ın gerçekten uygulanıp uygulanmadığını anlamak için ölçüm gerekir. Repository coverage, compliance rate, exception sayısı ve violation trend gibi göstergeler kullanılabilir. Ancak yalnızca yüksek compliance oranına bakmak yeterli değildir. Kuralın incident, defect veya onboarding süresine etkisi de incelenmelidir. Ölçüm sayesinde işe yaramayan kurallar erken fark edilir.

Güncelliğinin Korunması

Teknoloji ve iş gereksinimleri değiştikçe guideline'lar da güncellenmelidir. Her belge için owner ve next review date belirlemek bu süreci kolaylaştırır. Incident, audit veya büyük teknoloji değişiklikleri normal takvim beklenmeden review tetikleyebilir. Eski kalan belgeler kısa sürede ekiplerin güvenini kaybeder. Bu nedenle guideline bakım işi de mühendislik backlog'unun parçası olarak görülmelidir.

Davranış Değişikliği Oluşturması

Guideline'ın gerçek başarısı insanların davranışında kalıcı değişiklik oluşturmasıdır. Bir kural yalnızca denetim sırasında uygulanıyorsa kültürün parçası haline gelmemiş demektir. Doğru tasarım, araç entegrasyonu ve eğitim birlikte çalışmalıdır. Ekipler kuralın nedenini anladığında uygulama isteği daha yüksek olur. Bu yaklaşım zorunlu kontrollerin yanında doğal mühendislik alışkanlıkları oluşturur.

Guideline Hazırlama Süreci Nereden Başlamalı?

Şirket İçi Proje Yönergelerinin (Guidelines) Hazırlanma Süreçleri gerçek bir ihtiyaçtan başlamalıdır. Yalnızca “kurumsal görünelim” düşüncesiyle onlarca kural yazmak çoğu şirkette okunmayan belgeler üretir. En iyi kaynaklar code review tartışmaları, incident kayıtları, postmortem sonuçları ve geliştirici geri bildirimleridir. Bu veriler hangi konularda ortak standarda ihtiyaç olduğunu gösterir. İlk soru her zaman “Bu kural hangi problemi çözüyor?” olmalıdır.

Gerçek Bir Problemi Tanımlamak

Guideline talebinin arkasında somut problem bulunmalıdır. Problem bir incident, tekrar eden hata, yüksek bakım maliyeti veya ekipler arası tutarsızlık olabilir. Sorun ölçülebiliyorsa guideline sonrasında iyileşme de ölçülebilir. Belirsiz problem tanımı genellikle belirsiz kurallar üretir. Bu nedenle taslağa başlamadan önce problem kısa ve anlaşılır cümlelerle yazılmalıdır.

Tekrarlanan Code Review Tartışmalarını Analiz Etmek

Aynı konu farklı pull request'lerde tekrar tekrar tartışılıyorsa ortak guideline ihtiyacı olabilir. Naming, error handling veya dependency kullanımı buna örnek verilebilir. Review yorumlarını kategorize etmek tekrar eden anlaşmazlıkları görünür hale getirir. Daha sonra ekip ortak karar vererek bu kararı guideline'a taşıyabilir. Böylece code review aynı tartışmanın yapıldığı yer olmaktan çıkar ve gerçek kod kalitesine odaklanır.

Postmortem Bulgularını İncelemek

Postmortem belgeleri guideline üretmek için değerli kaynaklardan biridir. Tekrar yaşanması istenmeyen davranışlar burada açık biçimde görülebilir. Örneğin rollback planı olmadığı için uzayan bir incident, release guideline içinde yeni bir zorunluluk doğurabilir. Ancak her postmortem maddesini otomatik olarak kural haline getirmek doğru değildir. Kuralın tekrar eden riski gerçekten azaltıp azaltmadığı değerlendirilmelidir.

Incident'ları İncelemek

Incident geçmişi kurumun zayıf noktalarını gösterir. Benzer incident'ların ortak nedenleri varsa guideline ile azaltılabilecek davranışlar belirlenebilir. Monitoring eksikliği, yanlış deployment adımı veya yetersiz access control buna örnek olabilir. Kritik riskler önce ele alınmalıdır. Incident verisinden üretilen guideline'ın etkisi sonraki olay sıklığı üzerinden ölçülebilir.

Teknik Borç Kaynaklarını İncelemek

Teknik borç çoğu zaman ortak standardın olmadığı alanlarda birikir. Farklı dependency versiyonları, tutarsız logging veya belirsiz service ownership uzun vadede bakım maliyetini artırabilir. Teknik borç backlog'u incelenerek tekrar eden kaynaklar belirlenebilir. Bunların bazıları guideline, bazıları starter template veya otomatik kontrol ile azaltılabilir. Amaç mevcut borcu belgelemek değil, yenisinin oluşmasını önlemektir.

Audit Bulgularını İncelemek

Audit sonuçları özellikle compliance ve güvenlik alanında önemli sinyaller verir. Aynı bulgu farklı projelerde tekrarlanıyorsa ortak bir control eksikliği olabilir. Guideline bu eksikliği ekiplerin anlayacağı ve uygulayacağı biçime çevirebilir. Gerekli durumlarda otomatik enforcement eklenmelidir. Böylece audit bulgusu yalnızca rapor olarak kalmaz, operasyonel iyileştirmeye dönüşür.

Developer Feedback Toplamak

Geliştiriciler günlük akışta nerede zaman kaybettiklerini doğrudan görür. Bu nedenle guideline tasarımında developer feedback önemli bir veri kaynağıdır. Kısa anketler, ekip görüşmeleri veya workshop'lar kullanılabilir. İnsanların “hangi konuda ortak karar olsa işimiz kolaylaşır?” sorusuna verdiği cevaplar güçlü ipuçları sunar. Feedback toplamak aynı zamanda ileride adoption seviyesini de yükseltir.

“Bu Kural Hangi Problemi Çözüyor?” Sorusunu Cevaplamak

Her guideline maddesi bu soruya net cevap verebilmelidir. Cevap verilemiyorsa kural muhtemelen gereksiz veya yeterince olgun değildir. Problem tanımı kuralın rationale bölümünde kısa şekilde açıklanabilir. Böylece ekip üyeleri kuralı ezberlemek yerine mantığını anlayabilir. Bu yaklaşım gelecekte guideline'ın kaldırılması veya değiştirilmesi gerektiğinde de karar vermeyi kolaylaştırır.

Guideline Talep Süreci Nasıl Çalışmalı?

Guideline oluşturma süreci yalnızca belirli yöneticilerin kontrolünde olmamalıdır. Gerçek problem gören çalışanların yeni kural veya değişiklik önerebilmesi gerekir. Bunun için hafif ve anlaşılır bir talep mekanizması oluşturulabilir. Talep formunda problem, etkilenen ekipler, risk ve önerilen yaklaşım gibi bilgiler bulunmalıdır. Böylece her fikir doğrudan zorunlu kural haline gelmeden önce değerlendirilebilir.

Yeni Guideline Talebi

Yeni guideline talebi mümkün olduğunca basit yapılmalıdır. Çalışanın uzun bir resmi doküman hazırlaması zorunlu tutulursa değerli öneriler hiç gelmeyebilir. Kısa bir issue, RFC taslağı veya standart form yeterli olabilir. Talep daha sonra ilgili owner veya guild tarafından değerlendirilir. Sürecin açık olması çalışanların katılımını teşvik eder.

Talep Sahibi

Her talebin belirli bir sahibi bulunmalıdır. Bu kişi problemi açıklayabilmeli ve değerlendirme sırasında gerekli bağlamı sağlamalıdır. Talep sahibinin guideline'ın kalıcı owner'ı olması zorunlu değildir. Ancak önerinin ilk aşamada sahipsiz kalmasını önler. İsimsiz talepler çoğu zaman takip edilmeden kaybolur.

Problem Tanımı

Problem tanımı gözlemlenebilir bir durumu açıklamalıdır. “Kod kalitemiz iyi değil” gibi genel ifadeler yerine tekrar eden hata veya maliyet gösterilmelidir. Örneğin son üç release içinde aynı configuration problemi yaşandıysa bu açık bir sinyaldir. Problem ölçülebilir olduğunda çözümün etkisi de daha sonra değerlendirilebilir. Kısa ama somut problem tanımı iyi guideline taslağının temelidir.

Etkilenen Takımlar

Guideline'ın hangi takımları etkilediği baştan belirlenmelidir. Bazı kurallar tüm şirketi ilgilendirirken bazıları yalnızca belirli teknoloji kullanan ekipleri kapsar. Etkilenen takımlar review ve pilot sürecine dahil edilmelidir. Bu yaklaşım merkezi kararların sahadaki gerçek ihtiyaçlardan kopmasını önler. Scope belirlemek gereksiz uygulama yükünü de azaltır.

Risk ve İş Etkisi

Talebin teknik risk kadar iş etkisini de açıklaması faydalıdır. Production kesintisi, veri kaybı, müşteri memnuniyetsizliği veya bakım maliyeti gibi sonuçlar değerlendirilebilir. Yüksek risk taşıyan talepler daha hızlı önceliklendirilebilir. Düşük riskli konular ise hafif süreçlerle ele alınabilir. Bu yaklaşım guideline backlog'unun iş değeri üzerinden yönetilmesini sağlar.

Önerilen Çözüm

Talep sahibi mümkünse bir çözüm yaklaşımı önermelidir. Ancak bu öneri ilk andan itibaren kesin karar olarak görülmemelidir. Review sırasında daha basit veya daha etkili seçenekler ortaya çıkabilir. Önerilen çözüm teknik örneklerle desteklenirse tartışma daha verimli olur. Amaç problemi çözen en uygun yöntemi bulmaktır.

Alternatifler

İyi bir guideline önerisi alternatifleri de değerlendirir. Belki yeni bir zorunlu kural yerine template değişikliği aynı sorunu çözebilir. Belki manuel review yerine otomatik lint kontrolü kullanılabilir. Alternatiflerin yazılması kararın neden seçildiğini gelecekte anlamayı kolaylaştırır. Bu bilgi ADR veya RFC kaydında tutulabilir.

Önceliklendirme

Tüm guideline talepleri aynı anda uygulanamaz. Güvenlik, production riski ve yüksek tekrar maliyeti bulunan konular genellikle daha yüksek öncelik almalıdır. Basit stil tercihleri daha düşük seviyede tutulabilir. Önceliklendirme şeffaf kriterlerle yapılırsa ekiplerin sürece güveni artar. Böylece governance kurulu gerçekten değer yaratan konulara odaklanabilir.

Guideline Lifecycle

Guideline oluşturulduğu gün tamamlanmış sayılmaz. İhtiyacın belirlenmesinden kullanım dışına alınmasına kadar bütün bir yaşam döngüsü bulunur. Bu yaşam döngüsü proposal, draft, review, pilot, approval, adoption, enforcement ve measurement gibi aşamalar içerebilir. Her aşamanın sahibi ve çıkış kriteri belirlenirse süreç daha görünür olur. Yaşam döngüsü yaklaşımı guideline'ların yıllarca güncellenmeden kalmasını önlemeye yardımcı olur.

Aşama 1 — Need Identification

İlk aşamada gerçek ihtiyaç tanımlanır. Incident, developer feedback, audit veya teknik borç verisi kullanılabilir. Problem yeterince açık değilse kural yazmaya başlanmamalıdır. İhtiyacın kapsamı ve riski değerlendirilir. Böylece sonraki aşamalarda neyin çözülmek istendiği unutulmaz.

Aşama 2 — Proposal

Proposal aşamasında çözüm fikri ve alternatifler yazılır. Etkilenen ekipler ve olası maliyetler değerlendirilir. Büyük değişikliklerde RFC formatı kullanılabilir. Buradaki amaç karar vermeden önce tartışmayı görünür hale getirmektir. Proposal kabul edilirse taslak hazırlama aşamasına geçilir.

Aşama 3 — Draft

Draft aşamasında guideline'ın ilk uygulanabilir versiyonu hazırlanır. Problem, scope, zorunluluk seviyesi, örnekler ve exception süreci açıkça yazılır. Metin mümkün olduğunca gerçek kullanım durumlarıyla desteklenir. Henüz kesinleşmemiş noktalar görünür biçimde işaretlenir. Taslak review için paylaşılabilecek seviyeye geldiğinde sonraki aşamaya geçilir.

Aşama 4 — Stakeholder Review

Stakeholder review, karardan etkilenecek kişilerin taslağı değerlendirmesini sağlar. Engineering, security, product veya compliance ekipleri konuya göre sürece dahil olabilir. Review yalnızca dil kontrolü değil, uygulanabilirlik değerlendirmesidir. Çelişen ihtiyaçlar bu aşamada ortaya çıkar. Sağlıklı review gelecekteki exception sayısını azaltabilir.

Aşama 5 — Pilot

Pilot, guideline'ın sınırlı sayıda ekipte gerçek iş üzerinde test edilmesidir. Dokümanda iyi görünen bir kural pratikte beklenmedik zaman kaybı yaratabilir. Pilot sırasında friction, başarısız kontroller ve developer feedback toplanmalıdır. Gerektiğinde guideline revize edilmelidir. Pilot aşaması büyük rollout öncesinde düşük maliyetli öğrenme sağlar.

Aşama 6 — Approval

Approval aşamasında yetkili owner veya kurul guideline'ın aktif hale gelmesini onaylar. Onay seviyesi kuralın riskine göre değişebilir. Küçük coding önerileri için leadership onayı gerekmeyebilir. Security veya compliance açısından kritik maddelerde ek onay gerekebilir. Kimlerin onay vereceği önceden RACI içinde tanımlanmalıdır.

Aşama 7 — Publication

Publication yalnızca dosyayı bir wiki sayfasına koymak değildir. Guideline aranabilir, erişilebilir ve doğru katalog altında bulunabilir olmalıdır. Version, effective date ve owner bilgileri görünür olmalıdır. İlgili örnekler ve bağlantılar aynı yerde tutulmalıdır. Yayınlama süreci otomatikleştirilirse eski sürümlerin yanlışlıkla kullanılma riski azalır.

Aşama 8 — Adoption

Adoption aşaması ekiplerin guideline'ı gerçek çalışma biçimine dönüştürdüğü dönemdir. Eğitim, workshop, starter repository ve migration guide gibi araçlar burada önem kazanır. Yeni kuralın yalnızca duyurulması genellikle yeterli olmaz. Ekiplerin sorularına hızlı cevap verilmesi gerekir. Adoption oranı zaman içinde takip edilmelidir.

Aşama 9 — Enforcement

Enforcement kuralın uygun yöntemlerle kontrol edilmesini ifade eder. Bazı maddeler lint veya CI ile otomatik doğrulanabilir. Bazı maddeler ise architecture review gibi insan kararı gerektirir. Her şeyi hard gate yapmak doğru değildir. Risk bazlı soft gate ve hard gate dengesi kurulmalıdır.

Aşama 10 — Measurement

Measurement aşamasında guideline'ın gerçekten değer üretip üretmediği değerlendirilir. Compliance oranı tek başına başarı göstergesi değildir. Incident, defect, review süresi ve developer satisfaction gibi metrikler birlikte incelenebilir. Önceki baseline ile sonraki durum karşılaştırılmalıdır. Böylece etkisiz kuralların değiştirilmesi mümkün olur.

Aşama 11 — Review

Her aktif guideline belirli aralıklarla gözden geçirilmelidir. Review tarihi belge metadata'sında bulunmalıdır. Teknoloji değişikliği veya incident gibi olaylar erken review tetikleyebilir. Review sırasında kuralın hâlâ gerekli olup olmadığı da sorulmalıdır. Gereksiz maddeleri tutmak governance yükünü artırır.

Aşama 12 — Revision veya Deprecation

Guideline ihtiyaç değiştiğinde revize veya deprecated edilmelidir. Değişiklik davranışsal etki yaratıyorsa migration plan hazırlanmalıdır. Eski kuralın yerine geçen yeni belge açıkça gösterilmelidir. Removal date ve end-of-support gibi tarihler gerektiğinde belirtilmelidir. Böylece ekiplerin farklı sürümleri aynı anda kullanması önlenir.

Guideline Hazırlama Ekibinde Kimler Olmalı?

Guideline hazırlama ekibi konunun kapsamına göre değişmelidir. Her kuralı aynı komitenin yazması hem yavaş hem de verimsiz olabilir. Teknik konuya yakın uzmanların yanında uygulamadan etkilenecek ekiplerin temsil edilmesi önemlidir. Proje yönergesinde görev yetki sorumluluk ve onay süreçleri nasıl belirlenir sorusunun cevabı da bu rolleri açık hale getirmekten geçer. Aşağıdaki roller ihtiyaca göre sürece dahil edilebilir.

Engineering Lead

Engineering Lead teknik yön ve ekip ihtiyaçları arasında bağlantı kurar. Kuralın günlük geliştirme akışına etkisini değerlendirebilir. Ayrıca farklı ekiplerden gelen geri bildirimlerin ortak noktalarını belirleyebilir. Büyük değişikliklerde adoption planına destek olur. Ancak guideline'ın tek başına Engineering Lead tarafından yazılması gerekli değildir.

Senior Developer

Senior Developer gerçek geliştirme deneyimini taslağa taşır. Code review ve production sorunlarında tekrar eden problemleri iyi gözlemleyebilir. Kuralların uygulanabilir olup olmadığını erken aşamada test edebilir. Özellikle örneklerin ve edge case'lerin hazırlanmasında katkısı değerlidir. Böylece belge masa başında hazırlanmış soyut talimatlara dönüşmez.

Architect

Architect özellikle service boundary, dependency ve integration kurallarında önemli rol oynar. Guideline'ın kurumun genel mimari yaklaşımıyla çelişmemesini sağlar. Yeni teknoloji veya pattern kararlarının uzun vadeli etkisini değerlendirebilir. Gereksiz merkezi kontrol oluşturmadan ortak sınırlar belirlenmesine yardımcı olur. Kritik architecture guideline'larında Consulted veya Accountable rolü üstlenebilir.

QA

QA ekipleri test stratejisi ve kalite kontrollerinin gerçekçi olmasını sağlar. Her projede aynı test tipinin zorunlu tutulmasının yarattığı maliyetleri değerlendirebilir. Regression, E2E ve test coverage gibi konularda risk bazlı yaklaşım geliştirilmesine katkı sunar. Ayrıca guideline'ın doğrulanabilir olması açısından güçlü geri bildirim verir. Kalite kurallarının yalnızca geliştirici perspektifiyle yazılmasını önler.

DevOps / Platform

DevOps veya Platform ekipleri CI/CD, deployment, infrastructure ve self-service süreçlerinde önemli katkı sağlar. Yazılı guideline'ın otomatik guardrail'e dönüşebileceği noktaları belirleyebilir. Starter repository ve preconfigured pipeline gibi çözümler bu ekiplerin desteğiyle oluşturulabilir. Böylece geliştiricilerin manuel iş yükü azalır. Enforcement sürecinin sürdürülebilir olması için platform perspektifi önemlidir.

Security

Security ekibi riskli alanlarda minimum zorunlu kontrolleri tanımlar. Authentication, secrets, dependency security ve vulnerability management gibi konular bu kapsama girer. Ancak güvenlik kuralları uygulanabilirliği düşünmeden yazılmamalıdır. Security ekibinin geliştiricilerle birlikte çalışması daha dengeli sonuç verir. Özellikle yüksek riskli sistemlerde approval ve exception süreçlerinde aktif rol alabilir.

Product

Product ekibi guideline'ın teslimat ve kullanıcı değeri üzerindeki etkisini değerlendirebilir. Teknik ekiplerin önerdiği ağır süreçlerin iş hızına maliyetini görünür hale getirir. Bazı kuralların tüm projeler yerine yalnızca yüksek riskli alanlarda uygulanmasını önerebilir. Bu bakış açısı teknik kalite ile iş öncelikleri arasında denge sağlar. Özellikle release ve customer communication kurallarında katkısı önemlidir.

Compliance / Legal

Compliance veya Legal, regülasyon ve lisans gerektiren konularda sürece dahil edilmelidir. Her guideline için bu ekiplerin onayını istemek gereksiz yavaşlık yaratabilir. Ancak kişisel veri, açık kaynak lisansları veya yasal zorunluluklar söz konusuysa görüşleri kritik olabilir. Kuralların gereksiz yorumla ağırlaştırılmasını önlemek için gerçek yükümlülük açık biçimde belirtilmelidir. Böylece ekipler yasal gereklilik ile kurumsal tercih arasındaki farkı bilir.

Developer Experience

Developer Experience perspektifi guideline'ın anlaşılabilir ve uygulanabilir olmasına odaklanır. Dokümanı bulmak, kuralı anlamak ve gerekli değişikliği yapmak ne kadar kolay soruları bu kapsamda değerlendirilir. Developer friction yüksekse doğru kural bile düşük adoption ile sonuçlanabilir. Otomatik fix, template ve self-service araçları önemli destek sağlar. Bu nedenle DX, governance tasarımının ayrı bir bileşeni olarak ele alınmalıdır.

Gerektiğinde Son Kullanıcı Takımları

Guideline'ın uygulanacağı gerçek ekipler review ve pilot sürecine dahil edilmelidir. Çünkü merkez ekiplerin görmediği operasyonel detayları onlar yaşayabilir. Bir kural teorik olarak doğru olsa da günlük geliştirme akışında gereksiz iş yaratabilir. Son kullanıcı takımlarından erken feedback almak büyük rollout riskini azaltır. Ayrıca ekiplerin guideline'ı sahiplenmesini kolaylaştırır.

Guideline Owner Kim Olmalı?

Her guideline için adı açık biçimde belirtilmiş bir owner bulunmalıdır. Owner belgenin yazarı olmak zorunda değildir. Temel sorumluluğu içeriğin güncel kalmasını ve soruların doğru yere yönlendirilmesini sağlamaktır. Owner bulunmayan belgeler birkaç yıl içinde eski bilgi kaynağına dönüşebilir. Bu nedenle ownership, guideline metadata'sının zorunlu parçalarından biri olmalıdır.

Named Owner Prensibi

Named Owner prensibi, her guideline'ın belirli kişi veya sürdürülebilir ekip tarafından sahiplenilmesini ifade eder. Yalnızca “Engineering” gibi genel bir ifade sorumluluğu belirsiz bırakabilir. Daha iyi model belirli rol, ekip ve yedek sahiplik tanımlamaktır. Böylece soru geldiğinde kimin karar vereceği bilinmiş olur. Owner değişiklikleri de version history içinde takip edilmelidir.

Owner'ın Sorumlulukları

Owner içeriğin günlük editörü olmak zorunda değildir. Ancak guideline'ın yaşam döngüsünden sorumlu kişidir. Review organizasyonu, değişiklik değerlendirmesi ve exception kararları bu sorumluluklara dahil olabilir. Gerektiğinde uzmanlardan görüş toplar. Böylece guideline kurumsal olarak sahipsiz kalmaz.

İçeriğin Güncelliği

Owner mevcut teknolojilerin ve süreçlerin guideline ile uyumunu takip etmelidir. Kullanımdan kalkmış araçların hâlâ zorunlu görünmesi çalışanlarda güven kaybı yaratır. Düzenli review tarihleri bu riski azaltır. Büyük değişiklikler beklenmeden ara kontrol yapılabilir. Güncellik aktif bakım gerektirir.

Soruları Yanıtlama

Ekipler guideline'ı uygularken yorum gerektiren durumlarla karşılaşabilir. Owner bu soruların cevapsız kalmamasını sağlamalıdır. Her soruyu tek başına yanıtlaması gerekmez. Konu uzmanlarını sürece dahil edebilir. Sık gelen sorular daha sonra belgeye eklenerek tekrar eden destek yükü azaltılabilir.

Exception Kararları

Bazı durumlarda guideline'a uymamak daha doğru mühendislik kararı olabilir. Owner exception talebinin gerekçesini ve riskini değerlendirmelidir. Yüksek riskli istisnalarda ek onay mekanizması kullanılabilir. Her exception için expiry date belirlemek faydalıdır. Böylece geçici istisnaların kalıcı hale gelmesi önlenir.

Review Organizasyonu

Owner review takvimini takip eder. İlgili stakeholder'ları bir araya getirir ve gerekli kararların kayda alınmasını sağlar. Review sırasında yalnızca yazım değil, guideline'ın etkisi değerlendirilmelidir. Compliance, friction ve incident verileri bu toplantıya girdi sağlayabilir. Kararlar version history içinde görünür tutulmalıdır.

Migration İletişimi

Breaking guideline değişikliklerinde ekiplerin geçiş planına ihtiyacı olabilir. Owner kimlerin etkilendiğini ve hangi tarihe kadar değişiklik yapılması gerektiğini açıklamalıdır. Migration guide, örnek ve otomatik fix imkanları paylaşılabilir. Support kanalı da açıkça belirtilmelidir. Böylece değişiklik yalnızca duyuru olarak kalmaz.

Owner Ayrılırsa Ne Olmalı?

Owner şirketten veya ekipten ayrıldığında guideline sahipsiz kalmamalıdır. Offboarding sürecinde aktif guideline ownership listesi kontrol edilmelidir. Yeni owner resmi olarak atanmalı ve metadata güncellenmelidir. Gerekirse geçici sahiplik ilgili guild veya platform ekibine verilebilir. Bu süreç otomatik kontrol listesine bağlanırsa unutulma riski azalır.

Ownerless Guideline Problemi

Ownerless guideline zaman içinde eski ve güvenilmez bilgiye dönüşebilir. Ekipler sorularına cevap bulamadığında kendi yorumlarını üretmeye başlar. Farklı yorumlar standardın parçalanmasına yol açar. Sonunda belge varlığını sürdürürken pratikte kimse onu kullanmaz. Bu nedenle owner eksikliği guideline health check sırasında violation olarak görülebilir.

Guideline Governance Kurulu Gerekli mi?

Her şirketin ağır bir governance kuruluna ihtiyacı yoktur. Organizasyonun büyüklüğü, risk seviyesi ve ekip sayısı modele yön vermelidir. Küçük şirketlerde birkaç owner ile hafif süreç yeterli olabilir. Büyük kurumlarda farklı domain'leri temsil eden standards council daha uygun olabilir. Asıl hedef karar kalitesini artırırken ekiplerin iş akışını gereksiz şekilde yavaşlatmamaktır.

Küçük Şirketlerde Hafif Model

Küçük ekiplerde uzun approval zincirleri oluşturmak genellikle gereksizdir. Engineering Lead, security sorumlusu ve ilgili geliştiriciler kısa review ile karar verebilir. Guideline'lar Git repository içinde pull request ile yönetilebilir. Değişiklik geçmişi doğal olarak korunur. Bu model hızlı karar almayı destekler.

Orta Ölçekli Şirketlerde Engineering Guild

Orta ölçekli yapılarda farklı ekiplerden uzmanların katıldığı engineering guild modeli etkili olabilir. Guild ortak sorunları toplar ve guideline önerilerini tartışır. Üyeler kendi ekiplerinin gerçek ihtiyaçlarını masaya getirir. Böylece merkezi ekip ile uygulama ekipleri arasında bağ kurulur. Guild zorunlu onay merkezi olmak yerine ortak karar ve bilgi paylaşım alanı olarak kullanılmalıdır.

Büyük Kurumlarda Standards Council

Büyük kurumlarda güvenlik, architecture, platform ve compliance temsilcilerinin yer aldığı standards council gerekebilir. Özellikle şirket geneline etki eden yüksek riskli kurallarda ortak karar mekanizması faydalıdır. Ancak her küçük değişiklik council gündemine taşınmamalıdır. Yetki seviyeleri açık biçimde ayrılmalıdır. Böylece kurul darboğaz oluşturmadan stratejik standardizasyon sağlar.

Merkezi Governance ile Ekip Özerkliği

Merkezi governance minimum güvenlik ve kalite sınırlarını belirlemelidir. Takımlar bu sınırlar içinde kendi teknik kararlarını verebilmelidir. Her tercihin merkezden onay beklemesi inovasyon ve teslimat hızını düşürür. Buna karşılık tamamen serbest model architecture ve security drift yaratabilir. Sağlıklı sistem zorunlu global kurallar ile yerel karar alanlarını net ayırır.

Her Değişikliği Komiteye Taşımamak

Küçük editorial değişikliklerin resmi kurul onayı gerektirmesi süreç maliyetini yükseltir. Değişiklik türleri minor, behavioral ve breaking olarak sınıflandırılabilir. Minor düzenlemeler owner tarafından hızlı şekilde onaylanabilir. Breaking değişikliklerde daha kapsamlı review uygulanabilir. Risk bazlı governance karar akışını önemli ölçüde kolaylaştırır.

Guideline RACI Matrisi

RACI matrisi guideline yaşam döngüsündeki sorumlulukları açık hale getirir. Responsible işi yapan, Accountable nihai sorumluluğu taşıyan, Consulted görüşü alınan ve Informed bilgilendirilen tarafı ifade eder. Özellikle proje yönergesinde görev yetki sorumluluk ve onay süreçleri nasıl belirlenir sorusuna pratik bir çerçeve sunar. Her aşamada kimin karar vereceği belli olduğunda gecikmeler azalır. RACI basit tutulmalı ve gereksiz rol kalabalığından kaçınılmalıdır.

Responsible

Responsible, ilgili işi doğrudan gerçekleştiren kişi veya ekiptir. Örneğin taslağın hazırlanmasından Senior Developer sorumlu olabilir. Birden fazla Responsible tanımlanabilir ancak koordinasyonun nasıl yürütüleceği açık olmalıdır. Responsible kararın son sahibi olmayabilir. Bu ayrım özellikle büyük ekiplerde önemlidir.

Accountable

Accountable, nihai sonucu sahiplenen roldür. Genellikle her faaliyet için tek bir Accountable bulunması daha açıktır. Guideline owner çoğu durumda bu role yakın konumdadır. Approval veya exception kararlarında son sorumluluğu taşıyabilir. Accountable rolü belirsizse kararlar kolayca askıda kalır.

Consulted

Consulted tarafların görüşü karar öncesinde alınır. Security, architecture, product veya compliance konuya göre bu rolde olabilir. Her konu için herkesi Consulted yapmak süreci ağırlaştırır. Yalnızca kararı gerçekten etkileyen uzmanlar dahil edilmelidir. Consultation sonuçları mümkün olduğunda kayıt altında tutulmalıdır.

Informed

Informed taraflar karar sonrasında bilgilendirilir. Bu kişilerden resmi onay beklenmez. Etkilenen takımlar, support ekipleri veya yönetim konuya göre bu grupta olabilir. Bilgilendirme değişikliğin ne zaman yürürlüğe gireceğini ve kimin etkilendiğini açıklamalıdır. Böylece iletişim eksikliği nedeniyle adoption sorunu yaşanmaz.

Taslaktan Kim Sorumlu?

Taslak genellikle probleme en yakın teknik kişi veya küçük çalışma grubu tarafından hazırlanmalıdır. Konu merkezi platformu ilgilendiriyorsa platform ekibi Responsible olabilir. Security ağırlıklı bir kuralda security uzmanı taslağa liderlik edebilir. Taslağın tek kişinin kişisel görüşüne dönüşmemesi için peer review yapılmalıdır. İlk yazar ile nihai owner aynı kişi olmak zorunda değildir.

Kim Onaylar?

Onaylayan kişi kuralın kapsamı ve riskine göre belirlenmelidir. Düşük riskli coding guideline için ilgili guild owner yeterli olabilir. Şirket genelini etkileyen güvenlik standardında daha üst seviye onay gerekebilir. Onay zinciri olabildiğince kısa tutulmalıdır. Fazla approval guideline değişikliklerini gereksiz şekilde yavaşlatır.

Kim Uygular?

Guideline'ı etkilenen geliştirme ekipleri uygular. Platform ekibi otomatik guardrail sağlayarak uygulamayı kolaylaştırabilir. Kuralın gerçek kullanıcılarının sürece erken dahil edilmesi adoption açısından önemlidir. Ekiplerin yalnızca sonuçtan haberdar edilmesi yeterli değildir. Uygulama sırasında support mekanizması sağlanmalıdır.

Kim Ölçer?

Ölçüm sorumluluğu guideline owner, platform veya governance ekibinde olabilir. Metriklerin merkezi dashboard üzerinden görünür olması faydalıdır. Ancak her kural için aynı KPI kullanılmamalıdır. Security kuralı ile documentation kuralının etkisi farklı göstergelerle ölçülür. Ölçüm sorumluluğu belirlenmezse guideline'ın gerçekten işe yarayıp yaramadığı bilinmez.

Guideline Taslağı Nasıl Yazılır?

İyi bir taslak aynı yapıyı tekrar tekrar kullanan standart şablona sahip olmalıdır. Böylece okuyucu her guideline'da problemi, kuralı, gerekçeyi ve owner bilgisini nerede bulacağını bilir. Şirket içi proje yönetimi guideline şablonu ve örnekleri hazırlanırken aşağıdaki alanlar güçlü bir başlangıç noktası oluşturur. Template çok ağır olmamalı, ancak karar vermek için gerekli bağlamı içermelidir. Gereksiz alanlar zaman içinde sadeleştirilebilir.

Problem

Problem bölümü kuralın neden gerekli olduğunu açıklar. Gerçek olay, tekrar eden hata veya ölçülebilir maliyet kullanılabilir. Soyut ifadeler yerine somut sonuçlar tercih edilmelidir. Problem birkaç cümlede anlaşılabilmelidir. Okuyucu bu bölümü gördüğünde kuralın amacını hemen kavramalıdır.

Amaç

Amaç bölümü guideline'ın hangi sonucu üretmek istediğini açıklar. Güvenliği artırmak, review süresini azaltmak veya release kalitesini yükseltmek gibi hedefler yazılabilir. Amaç mümkünse ölçülebilir bir sonuçla ilişkilendirilmelidir. Çok geniş amaçlar belgenin scope'unu belirsizleştirir. Tek guideline için birkaç net hedef yeterlidir.

Scope

Scope, guideline'ın hangi ekip, proje, repository veya risk seviyesinde geçerli olduğunu tanımlar. Tüm şirketi kapsayan ifadeler gerçekten gerekiyorsa kullanılmalıdır. Belirli teknoloji veya veri sınıfı için özel kapsam belirlenebilir. Scope dışında kalan alanlar da gerektiğinde belirtilmelidir. Bu yaklaşım yanlış uygulamayı azaltır.

Zorunluluk Seviyesi

Her kuralın MUST, SHOULD veya MAY seviyesi açık olmalıdır. Bunun yanında enforcement yönteminin de aynı seviyeye uygun olması gerekir. Tavsiye niteliğindeki bir madde hard gate ile engellenmemelidir. Zorunlu güvenlik kuralları ise yalnızca dokümana bırakılmamalıdır. Bu uyum guideline sistemine duyulan güveni artırır.

Kural

Kural bölümü uygulanması beklenen davranışı kısa ve açık biçimde ifade eder. Tek maddede birden fazla konu birleştirilmemelidir. Mümkünse kontrol edilebilir şartlar kullanılmalıdır. Belirsiz sıfatlardan kaçınılmalıdır. Okuyucu maddeyi gördüğünde ne yapması gerektiğini anlamalıdır.

Gerekçe

Gerekçe, kuralın arkasındaki nedeni açıklar. Bu bölüm özellikle deneyimli mühendislerin farklı bir yaklaşım düşündüğü durumlarda önemlidir. Rationale bilinirse ekip gerektiğinde doğru exception talebi hazırlayabilir. Aynı zamanda gelecekte kuralın hâlâ geçerli olup olmadığını değerlendirmek kolaylaşır. Nedeni bilinmeyen kurallar zamanla sorgusuz alışkanlıklara dönüşebilir.

Doğru Örnek

Doğru örnek kuralın pratikte nasıl uygulanacağını gösterir. Kod, configuration, repository yapısı veya iş akışı örneği kullanılabilir. Örneğin gerçek projeye yakın olması öğrenmeyi hızlandırır. Çok idealize edilmiş örnekler günlük kullanımda faydasız kalabilir. Kısa açıklama eklemek örneğin neden doğru olduğunu da görünür hale getirir.

Yanlış Örnek

Yanlış örnek sık yapılan hatayı görünür hale getirir. İnsanlar çoğu zaman ne yapmamaları gerektiğini örnek üzerinden daha hızlı anlar. Ancak yanlış örnek yalnızca yasak göstermek için kullanılmamalıdır. Neden sorun yarattığı açıklanmalıdır. Böylece geliştirici benzer durumlarda kendi kararını daha doğru verebilir.

Enforcement Yöntemi

Enforcement yöntemi kuralın nasıl kontrol edileceğini belirtir. Lint, CI, branch protection, review veya audit gibi seçenekler kullanılabilir. Otomatik kontrol mümkünse manuel denetim yerine tercih edilmelidir. Ancak insan yargısı gereken mimari kararlar zorla otomatikleştirilmemelidir. Kural ile kontrol yöntemi arasında dengeli ilişki kurulmalıdır.

Exception Süreci

Exception süreci gerçek hayattaki özel durumların yönetilmesini sağlar. Talepte business justification, technical justification ve risk bilgisi bulunabilir. Onaylayan rol açıkça belirtilmelidir. İstisnalar mümkünse expiry date içermelidir. Çok fazla exception oluşuyorsa guideline'ın kendisi yeniden değerlendirilmelidir.

Owner

Owner guideline'ın yaşam döngüsünü sahiplenir. Soruların cevaplanması, review organizasyonu ve değişikliklerin takibi bu kapsamda olabilir. Owner adı veya sorumlu ekip açıkça belirtilmelidir. Sahip değişikliğinde metadata güncellenmelidir. Bu alan hiçbir aktif guideline'da boş bırakılmamalıdır.

Version

Version değişikliklerin takip edilmesini sağlar. Davranışsal değişiklikler ile küçük editorial değişiklikler farklı version artışlarıyla gösterilebilir. Ekip hangi sürümü uyguladığını anlayabilmelidir. Otomatik publishing sistemleri eski sürümlere erişimi de koruyabilir. Version history kurumun karar geçmişini görünür hale getirir.

Review Date

Review Date guideline'ın bir sonraki değerlendirme zamanını gösterir. Her belge için aynı süre kullanılmak zorunda değildir. Security ve teknoloji kuralları daha sık kontrol edilebilir. Stable process guideline daha uzun aralıklarla gözden geçirilebilir. Review tarihi yaklaşırken owner'a otomatik hatırlatma gönderilmesi faydalıdır.

İyi Bir Guideline Maddesinin Yapısı

İyi guideline maddesi okuyucunun yorum yapmasına mümkün olduğunca az ihtiyaç bırakır. Bunun için tek konuya odaklanmalı, açık yazılmalı ve uygulanabilir olmalıdır. Kuralın neden var olduğu ve nasıl doğrulanacağı da belirtilmelidir. Örnekler özellikle teknik maddelerde büyük fark yaratır. Exception durumları varsa bunlar da madde tasarımının parçası olmalıdır.

Tek Bir Konuya Odaklanmalı

Bir guideline maddesi aynı anda beş farklı davranışı zorunlu tutmamalıdır. Tek konuya odaklanmak review ve enforcement sürecini kolaylaştırır. İhlal edildiğinde hangi kısmın sorun olduğu net biçimde görülür. Ayrıca gelecekte yalnızca ilgili bölüm değiştirilebilir. Bu yapı version yönetimini de sadeleştirir.

Açık ve Belirsizlikten Uzak Olmalı

“Uygun”, “yeterli” veya “iyi” gibi bağlama göre değişen ifadeler dikkatli kullanılmalıdır. Mümkün olduğunda açık kriter verilmelidir. Örneğin “yeterli reviewer” yerine “en az bir reviewer” denilebilir. Belirsizlik azaldıkça ekipler arasındaki yorum farkı azalır. Review tartışmaları da daha verimli hale gelir.

Nedenini Açıklamalı

Geliştiriciler özellikle deneyimli ekiplerde kuralların nedenini bilmek ister. Bu beklenti sağlıklıdır. Rationale kuralın arkasındaki risk veya faydayı açıklar. İnsanlar gerekçeyi anladığında doğru exception kararları da verebilir. Nedeni açıklanan kurallar daha güçlü adoption oluşturur.

Uygulanabilir Olmalı

Bir kural teorik olarak doğru olsa da mevcut araçlarla uygulanamıyorsa sorun yaratır. Örneğin tüm ekiplerden belirli security taramasını istemeden önce gerekli sistem sağlanmalıdır. Geliştiriciyi manuel ve tekrarlı işlere zorlamak friction yaratır. Mümkün olduğunda otomasyon ve template desteği verilmelidir. Uygulanabilirlik pilot aşamasında mutlaka test edilmelidir.

Kontrol Edilebilir Olmalı

Kontrol edilebilir kural neyin uyumlu sayıldığını açıkça gösterir. Otomatik kontrol mümkün olan alanlarda bu avantaj daha da büyür. Ancak her konu sayısal metriğe indirgenmemelidir. Architecture trade-off gibi kararlar uzman review gerektirebilir. Önemli olan değerlendirmenin hangi kriterle yapılacağının bilinmesidir.

Örnek İçermeli

Örnekler soyut kuralı günlük işe dönüştürür. Doğru ve yanlış örnek birlikte verildiğinde öğrenme daha hızlı olabilir. Kod standardında kısa snippet, process standardında akış örneği kullanılabilir. Örnekler mümkün olduğunca güncel tutulmalıdır. Eski framework veya yöntem kullanan örnekler guideline'ın güvenilirliğini azaltır.

Exception Durumlarını Belirtmeli

Gerçek sistemlerde hiçbir kural her senaryoyu kapsamayabilir. İstisnaların hangi şartlarda kabul edilebileceği baştan açıklanmalıdır. Böylece ekipler gizli workaround yerine resmi süreci kullanır. Risk ve compensating control kaydı tutulabilir. Exception verileri guideline'ın kalitesini değerlendirmek için de kullanılabilir.

Kötü Guideline Örnekleri

Kötü guideline'ların ortak özelliği kulağa doğru gelmelerine rağmen uygulanabilir davranış tanımlamamalarıdır. “Kaliteli kod yazın” veya “güvenli olun” gibi ifadeler kimsenin itiraz etmeyeceği kadar geneldir. Fakat bu cümleler review sırasında neyin doğru olduğunu belirlemeye yardımcı olmaz. İyi guideline soyut ilkeyi belirli davranış ve kontrol kriterine dönüştürmelidir. Aşağıdaki örnekler bu farkı gösterir.

“Kaliteli Kod Yazın”

Bu ifade iyi niyetlidir ancak kaliteyi nasıl değerlendireceğimizi söylemez. Farklı geliştiricilerin kalite tanımı farklı olabilir. Bunun yerine complexity sınırı, review gereksinimi veya test beklentisi tanımlanabilir. Böylece davranış daha görünür hale gelir. Kalite kavramı somut mühendislik pratiklerine bağlanmalıdır.

“Güvenli Olun”

Bu cümle güvenli davranış için hiçbir uygulanabilir adım sunmaz. Secret yönetimi, input validation veya access control gibi gerçek risk alanları belirtilmelidir. Örneğin production credential'larının repository içinde tutulması açık biçimde yasaklanabilir. Otomatik secret scan eklenerek kontrol güçlendirilebilir. Böylece güvenlik soyut beklentiden pratik kurala dönüşür.

“Performansa Dikkat Edin”

Performans hedefi ölçülebilir şartlarla ilişkilendirilmelidir. Hangi endpoint veya sistem için hangi SLO'nun geçerli olduğu belirtilmelidir. Kritik değişikliklerde performance test gereksinimi tanımlanabilir. Her küçük internal tool için aynı test zorunluluğu uygulanmamalıdır. Risk ve kullanım profili performans kuralının kapsamını belirlemelidir.

“Gerekli Testleri Yapın”

Bu ifade hangi testlerin gerekli olduğunu açıklamaz. Unit, integration, API veya E2E beklentileri risk ve değişiklik tipine göre tanımlanabilir. Kritik business logic değişikliklerinde ilgili otomatik testlerin güncellenmesi zorunlu tutulabilir. Bug fix için regression test beklentisi eklenebilir. Böylece review sırasında ortak kriter oluşur.

“Dokümantasyon Ekleyin”

Hangi dokümantasyonun gerektiği belirtilmediğinde ekiplerin yaklaşımı farklılaşır. Yeni service için README, runbook ve ownership bilgisi zorunlu tutulabilir. Public API değişikliğinde API documentation güncellemesi istenebilir. Küçük internal refactor için aynı belge seti gerekmeyebilir. Scope'a göre açık dokümantasyon şartı daha doğru sonuç verir.

Bu İfadeler Neden Kontrol Edilemez?

Bu cümlelerin ortak sorunu başarı kriterinin belirsiz olmasıdır. Reviewer ile geliştirici aynı ifadeyi farklı yorumlayabilir. Otomatik kontrol oluşturmak da neredeyse imkansız hale gelir. Sonuçta guideline bilgi vermek yerine yeni tartışmalar üretir. İyi kural net davranış, kapsam ve kontrol yöntemi tanımlar.

İyi Guideline Örneklerine Dönüşüm

Soyut ifadeleri iyi guideline'a dönüştürmenin yolu davranışı görünür hale getirmektir. Kural belirli scope, requirement level ve kontrol kriteri içermelidir. Gerekirse örnek ve exception eklenmelidir. Böylece ekip ne yapacağını ve neden yapacağını bilir. Aşağıdaki alanlar bu dönüşüm için pratik örnekler sunar.

Soyut İlkeyi Ölçülebilir Kurala Çevirmek

“Test yazın” yerine “bug fix içeren pull request ilgili regression testini MUST içermelidir” denilebilir. Bu ifade davranışı açık hale getirir. Reviewer neyi kontrol edeceğini bilir. Gerektiğinde istisna süreci tanımlanabilir. Böylece genel ilke gerçek iş akışına bağlanır.

Security Örneği

“Secret'ları güvenli tutun” yerine production secret'larının Git repository içinde tutulmaması MUST olarak tanımlanabilir. Tüm pull request'lerde secret scan otomatik çalıştırılabilir. Bulgu olduğunda merge engellenebilir. False positive durumları için exception mekanizması bulunabilir. Böylece kural doğrudan enforcement ile desteklenir.

Testing Örneği

“Yeterli test yapın” yerine kritik business logic değişikliklerinde ilgili unit veya integration testlerinin güncellenmesi SHOULD olarak yazılabilir. Bug fix için regression testi MUST yapılabilir. Test türü proje riskine göre değişebilir. Coverage yüzdesi tek başarı kriteri haline getirilmemelidir. Kural gerçek kalite sonucuna odaklanmalıdır.

Code Review Örneği

“Kod review edilmeli” yerine protected branch'e merge öncesinde en az bir bağımsız reviewer onayı MUST denilebilir. Hassas alanlarda CODEOWNER review eklenebilir. Küçük dokümantasyon değişiklikleri için farklı politika uygulanabilir. Review SLA ayrıca belirtilirse teslimat gecikmeleri azaltılabilir. Böylece beklenti açık hale gelir.

Logging Örneği

“Yeterli log ekleyin” yerine production servislerinde request correlation ID kullanımı SHOULD olarak tanımlanabilir. Kritik hata durumlarında yapılandırılmış error log zorunlu tutulabilir. Hassas veri ve credential loglanması MUST NOT olarak belirtilmelidir. Log formatı merkezi observability sistemine uygun olmalıdır. Bu yapı troubleshooting süresini azaltır.

Documentation Örneği

“Dokümantasyon yazın” yerine yeni servislerde README içinde purpose, local setup ve owner bilgisi MUST bulunmalıdır denilebilir. Operasyonel servislerde runbook ayrıca zorunlu tutulabilir. Public API değişikliğinde API documentation aynı pull request içinde güncellenmelidir. Böylece bilgi güncelliği kod değişikliğiyle birlikte korunur. Gereksiz dokümantasyon yükü scope ile sınırlandırılır.

Release Örneği

“Dikkatli release yapın” yerine yüksek riskli production release için rollback planı ve monitoring dashboard bağlantısı zorunlu tutulabilir. Release readiness checklist kullanılabilir. Acil release için ayrı hızlı süreç tanımlanabilir. Deployment sonrası belirli süre gözlem yapılması istenebilir. Böylece operasyonel risk görünür kontrollerle yönetilir.

Guideline Scope Nasıl Belirlenmeli?

Scope yanlış belirlenirse iyi guideline bile gereksiz maliyet yaratabilir. Her kuralın tüm şirkete uygulanması gerekmez. Belirli departman, repository, teknoloji veya risk seviyesi için farklı scope tanımlanabilir. En geniş kapsam ancak gerçek ihtiyaç varsa kullanılmalıdır. Bu yaklaşım risk bazlı governance modelinin temelini oluşturur.

Tüm Şirket

Şirket genelindeki guideline'lar yalnızca ortak ve yüksek değerli kurallar için kullanılmalıdır. Security minimumları, secret yönetimi veya temel ownership kuralları buna örnek olabilir. Bu seviyedeki kurallar farklı teknoloji stack'lerinde uygulanabilir olmalıdır. Çok spesifik teknik tercihlerin company-wide hale getirilmesi gereksiz kısıt oluşturabilir. Scope açıkça “all engineering repositories” gibi tanımlanmalıdır.

Belirli Departman

Bazı guideline'lar yalnızca belirli departmanın iş yapış biçimini ilgilendirir. Data engineering veya mobile ekipleri farklı standartlara ihtiyaç duyabilir. Bu kurallar şirket genelindeki zorunlu maddelerle çelişmemelidir. Departman owner'ı bakım sorumluluğunu üstlenebilir. Daha dar scope ekiplerin gerçek ihtiyacına uygun esneklik sağlar.

Belirli Takımlar

Takım seviyesinde guideline belirli domain veya operasyonel gereksinime göre yazılabilir. Örneğin ödeme takımının release süreci diğer ekiplerden daha sıkı olabilir. Takım kuralları merkezi minimumları geçersiz kılamaz. Ancak daha güçlü kontrol ekleyebilir. Yerel kurallar merkezi katalog içinde ilişkili guideline olarak gösterilebilir.

Belirli Repository'ler

Bazı kurallar yalnızca belirli repository için anlamlıdır. Monorepo, legacy sistem veya kritik deployment repository özel kural gerektirebilir. Repository-specific instruction dosyaları bu durumda etkilidir. Merkezi guideline ile bağlantı açık tutulmalıdır. Böylece geliştirici bağlama göre doğru kuralı görebilir.

Belirli Teknoloji Stack'i

Language-specific coding ve dependency kuralları teknoloji stack'ine göre değişebilir. Java, .NET veya frontend ekosisteminin aynı teknik detaylara sahip olması beklenemez. Merkezi standard genel prensibi verirken stack-specific guideline uygulama detayını tanımlayabilir. Bu ayrım gereksiz genellemeyi önler. Teknoloji değiştiğinde yalnızca ilgili guideline güncellenebilir.

Belirli Veri Sınıfı

Hassas veya kişisel veri işleyen sistemler daha güçlü kontrole ihtiyaç duyabilir. Encryption, logging ve access yönetimi veri sınıfına göre farklılaştırılabilir. Düşük riskli public veri için aynı ağırlıkta kontrol gerekmeyebilir. Veri sınıfı repository metadata içinde tanımlanırsa otomatik policy uygulamak kolaylaşır. Böylece risk seviyesi teknik akışa bağlanır.

Belirli Risk Seviyesi

Risk seviyesi guideline kapsamını belirlemek için güçlü bir araçtır. Düşük riskli internal tool ile finansal kritik sistem aynı süreç yüküne sahip olmamalıdır. Risk sınıflandırması proje başlangıcında yapılabilir. Daha yüksek seviyelerde ek review, test ve approval devreye alınabilir. Bu model hem güvenliği hem geliştirme hızını korur.

Her Projeye Aynı Guideline Uygulanmalı mı?

Her projeye aynı kuralları uygulamak çoğu organizasyonda doğru değildir. Projelerin kullanıcı sayısı, veri hassasiyeti ve iş etkisi farklıdır. Küçük proof of concept için gerekli olmayan ağır kontroller kritik finansal sistem için zorunlu olabilir. Risk bazlı guideline profilleri bu farkı sistematik hale getirir. Böylece düşük riskli işlerde hız korunurken kritik sistemlerde daha güçlü koruma sağlanır.

Küçük Internal Tool

Küçük internal tool sınırlı kullanıcı ve düşük iş etkisine sahip olabilir. Bu nedenle minimum repository, security ve ownership kuralları yeterli olabilir. Ağır architecture review süreci gereksiz olabilir. Ancak secrets ve temel access control gibi kritik kurallar yine korunmalıdır. Scope ve risk seviyesi açık biçimde kaydedilmelidir.

Public Web Application

Public web application internet üzerinden erişilebilir olduğu için daha geniş saldırı yüzeyine sahiptir. Security review, dependency scan ve observability gereksinimleri daha güçlü olabilir. Availability ve performance hedefleri de açık tanımlanmalıdır. Release süreci rollback planı içermelidir. Kullanıcı etkisi arttıkça kontrol seviyesi de yükselmelidir.

Finansal Sistem

Finansal sistemler işlem doğruluğu ve audit açısından yüksek risk taşıyabilir. Yetki yönetimi, audit trail ve değişiklik onayı daha güçlü olmalıdır. Kritik business logic için kapsamlı test stratejisi gerekebilir. Emergency release süreçleri dahi kayıt altında tutulmalıdır. Bu sistemlerde exception kararları daha yüksek seviyede değerlendirilebilir.

Kişisel Veri İşleyen Sistem

Kişisel veri işleyen projelerde veri sınıflandırması ve erişim yönetimi önemli hale gelir. Logging sırasında hassas veri sızıntısının önlenmesi gerekir. Encryption ve retention kuralları açık biçimde tanımlanmalıdır. Gerekli durumlarda compliance veya legal review yapılabilir. Veri riskine göre daha sık guideline review uygulanabilir.

Kritik Operasyon Sistemi

Kritik operasyon sistemi kesinti durumunda doğrudan iş kaybı yaratabilir. Reliability, observability ve rollback gereksinimleri bu nedenle daha güçlü tutulmalıdır. SLI ve SLO hedefleri açıkça tanımlanabilir. Production değişiklikleri için ek approval gerekebilir. Incident sonrası guideline review otomatik olarak tetiklenebilir.

Proof of Concept

Proof of concept temel amacı hızlı öğrenme olan geçici çalışma olabilir. Bu tür projelerde tam production standardı uygulamak gereksiz maliyet yaratabilir. Ancak hassas veri ve security minimumları yine korunmalıdır. POC production'a dönüşürse risk seviyesi yeniden değerlendirilmelidir. Geçici statünün kalıcı sistem haline gelmemesi için review tarihi konulabilir.

Risk Bazlı Guideline Profilleri

Risk bazlı profiller projeleri birkaç seviyeye ayırarak farklı kontrol setleri uygular. Her seviyede hangi guideline'ların mandatory olduğu merkezi katalogda gösterilebilir. Repository metadata üzerinden profile otomatik bağlanabilir. Böylece geliştirici hangi kuralların kendisini ilgilendirdiğini kolayca görür. Bu yaklaşım governance yükünü önemli ölçüde azaltır.

Risk Bazlı Guideline Modeli

Risk bazlı model, tüm projeleri aynı süreç yüküyle yönetmek yerine kontrol seviyesini iş ve teknik etkiye göre ayarlar. Bu yöntem özellikle büyüyen şirketlerde faydalıdır. Düşük riskli projelerde hız korunurken kritik sistemlerde daha güçlü güvenlik ve kalite kontrolleri uygulanabilir. Risk sınıflandırması anlaşılır kriterlerle yapılmalıdır. Seviyeler düzenli olarak yeniden değerlendirilmelidir.

Level 1 — Düşük Risk

Level 1 projeler sınırlı kullanıcıya ve düşük iş etkisine sahip olabilir. Minimum repository, ownership ve secrets kuralları uygulanır. Basit CI ve temel test kontrolü yeterli olabilir. Ek architecture kuruluna ihtiyaç duyulmayabilir. Proje büyüdüğünde risk seviyesi yeniden değerlendirilmelidir.

Level 2 — Standart Kurumsal Proje

Level 2 günlük iş uygulamalarının büyük bölümünü kapsayabilir. Code review, CI testleri, security scan ve standart observability kuralları beklenir. Release ve documentation minimumları uygulanır. Architecture kararları ihtiyaç halinde ADR ile kayıt altına alınır. Bu seviye çoğu kurumsal proje için varsayılan profil olabilir.

Level 3 — Yüksek Risk

Level 3 sistemlerde daha güçlü security ve reliability kontrolleri gerekir. Ek reviewer veya CODEOWNER onayı zorunlu tutulabilir. Performance ve security testleri risk alanına göre devreye girebilir. Release öncesinde rollback planı ve readiness kontrolü yapılabilir. Exception kararları daha sıkı onaya bağlanabilir.

Level 4 — Kritik / Regüle Sistem

Level 4 en yüksek operasyonel veya düzenleyici riske sahip sistemler için kullanılabilir. Audit trail, segregation of duties ve güçlü access control gibi kontroller uygulanabilir. Release süreçleri ek approval içerebilir. Guideline uyumu daha sık ölçülür. Bu seviyedeki değişiklikler compliance ve security review gerektirebilir.

Risk Arttıkça Kontrol Seviyesini Artırmak

Risk arttıkça daha güçlü guardrail kullanmak mantıklıdır. Ancak her kontrolün hangi riski azalttığı açıkça açıklanmalıdır. Gereksiz kontrol eklemek yalnızca süreç maliyeti oluşturur. Level değişiklikleri ölçülebilir kriterlere bağlanmalıdır. Böylece ekipler neden farklı süreçlere tabi olduğunu anlayabilir.

Düşük Riskli İşlerde Gereksiz Bürokrasi Oluşturmamak

Düşük riskli projelerde ağır approval süreçleri çalışanların guideline'a karşı olumsuz tutum geliştirmesine yol açabilir. Kritik olmayan değişiklikler hızlı şekilde ilerleyebilmelidir. Minimum güvenlik kuralları korunurken ek kontroller azaltılabilir. Bu yaklaşım ekip özerkliğini destekler. Risk bazlı modelin temel faydalarından biri budur.

Şirket İçi Guideline Kataloğunda Hangi Alanlar Bulunmalı?

Merkezi guideline kataloğu geliştiricinin ihtiyaç duyduğu kuralı hızlı şekilde bulmasını sağlamalıdır. Domain bazlı kategoriler bu nedenle faydalıdır. Architecture, security, testing, observability ve release gibi alanlar ayrı başlıklar halinde organize edilebilir. Her kategoride owner ve scope görünür olmalıdır. İyi katalog yalnızca doküman deposu değil, günlük mühendislik referansıdır.

Architecture

Architecture kategorisi service boundaries, API design ve dependency kurallarını içerebilir. Ortak integration pattern'leri burada tanımlanabilir. Architecture Decision Record kullanımı da bu bölümde açıklanabilir. Global kurallar ile proje özelindeki kararlar ayrılmalıdır. Bu yapı architecture drift riskini azaltır.

Code Quality

Code Quality alanı naming, complexity, error handling ve review beklentilerini kapsayabilir. Language-specific kurallar ayrı alt dokümanlarda tutulabilir. Soyut kalite beklentileri yerine kontrol edilebilir kriterler kullanılmalıdır. Otomatik lint kuralları mümkün olduğunda guideline ile ilişkilendirilmelidir. Böylece kod standardı günlük geliştirme akışına bağlanır.

Security

Security kategorisinde authentication, authorization, secrets ve dependency güvenliği gibi alanlar bulunur. Kural seviyeleri risk bazlı tanımlanmalıdır. Kritik maddeler otomatik security scan ile desteklenebilir. Exception mekanizması açık olmalıdır. Security guideline'ları diğer kategorilere göre daha sık review gerektirebilir.

Testing

Testing alanı farklı test türlerinin hangi durumda kullanılacağını açıklar. Unit, integration ve end-to-end test beklentileri risk seviyesine göre ayrılabilir. Coverage tek başarı ölçütü yapılmamalıdır. Bug fix için regression test politikası tanımlanabilir. Böylece kalite beklentisi daha anlaşılır hale gelir.

Data

Data guideline'ları veri sahipliği, sınıflandırma ve retention gibi konuları kapsar. Hassas verinin nasıl saklanacağı ve taşınacağı açıklanmalıdır. Schema değişiklikleri için migration yaklaşımı tanımlanabilir. Data ownership service boundary ile uyumlu tutulmalıdır. Bu alan özellikle büyüyen sistemlerde kritik hale gelir.

Infrastructure

Infrastructure kuralları IaC, environment yönetimi ve cloud resource standartlarını kapsayabilir. Resource naming ve tagging bu bölümde tanımlanabilir. Production erişimi için güvenlik kontrolleri eklenebilir. Infrastructure policy mümkün olduğunda otomatik policy engine ile doğrulanabilir. Böylece manuel kontrol yükü azalır.

Observability

Observability kategorisi log, metric, tracing ve alert standartlarını bir araya getirir. Yeni service için minimum dashboard ve alert seti tanımlanabilir. Correlation ID gibi ortak pattern'ler burada açıklanabilir. SLI ve SLO yaklaşımı risk seviyesine göre uygulanabilir. Bu standartlar incident çözüm süresini kısaltır.

Performance

Performance guideline hangi sistemlerde performans hedefi gerektiğini açıklar. Her uygulama için aynı latency hedefini kullanmak doğru değildir. Kritik endpoint ve batch süreçleri ayrı değerlendirilmelidir. Load test gereksinimleri risk ve trafik seviyesine göre belirlenebilir. Ölçüm sonuçları release readiness sürecine bağlanabilir.

Reliability

Reliability alanında availability, retry, timeout ve failure handling kuralları bulunabilir. Kritik sistemlerde SLO ve error budget yaklaşımı kullanılabilir. Dependency failure durumları için fallback stratejileri tanımlanabilir. Rollback ve recovery beklentileri de bu alanla ilişkilidir. Reliability guideline production davranışına doğrudan etki eder.

Documentation

Documentation kategorisi README, ADR, runbook ve API documentation beklentilerini belirler. Her belge tipi için owner ve güncelleme sorumluluğu tanımlanmalıdır. Doküman mümkün olduğunca kod değişikliğiyle birlikte güncellenmelidir. Docs-as-code yaklaşımı burada güçlü avantaj sağlar. Böylece bilgi güncelliği daha kolay korunur.

Version Control

Version Control alanı branch strategy, commit standardı ve merge policy gibi konuları kapsar. Protected branch kuralları bu bölümde açıklanabilir. Force push gibi riskli davranışlar için açık politika bulunmalıdır. Commit history'nin audit veya troubleshooting açısından önemi belirtilmelidir. Ortak Git akışı ekip geçişlerini kolaylaştırır.

Release

Release guideline readiness, versioning ve rollback beklentilerini tanımlar. Release notes ve changelog kullanım şartları belirlenebilir. Emergency release için ayrı hızlı süreç oluşturulabilir. Customer communication gerektiren değişiklikler ayrıca tanımlanmalıdır. Bu alan development ile operations arasında ortak çalışma biçimi oluşturur.

Operations

Operations kategorisi production ownership ve incident süreçlerini kapsayabilir. Runbook, on-call ve escalation bilgileri burada ilişkilendirilebilir. Kritik servislerde support sorumluluğu açık olmalıdır. Operasyonel değişiklikler audit trail ile takip edilebilir. Böylece hizmetin koddan production davranışına kadar sahibi belirgin hale gelir.

Proje Başlatma Yönergeleri

Proje başlangıcı ileride oluşacak teknik ve operasyonel yapının temelini oluşturur. Bu nedenle minimum başlangıç şartları standartlaştırılabilir. Charter, owner, repository, risk sınıfı ve Definition of Done gibi alanlar proje başlamadan önce netleşmelidir. Amaç projeyi ağır form süreçlerine sokmak değil, kritik belirsizlikleri azaltmaktır. İyi başlangıç yönergesi sonraki aylarda yaşanacak ownership ve bakım sorunlarını önleyebilir.

Proje Charter

Project Charter projenin amacı, kapsamı ve temel sorumlularını özetler. Çok uzun bir belge olmak zorunda değildir. Hangi problemi çözdüğü, business owner ve technical owner bilgisi bulunmalıdır. Kritik risk ve başarı kriterleri de eklenebilir. Bu belge proje boyunca ortak referans sağlar.

Problem Tanımı

Proje gerçek bir problemi çözmelidir. Problem tanımı kullanıcı veya iş ihtiyacını açık biçimde göstermelidir. Çözüm detayına erken girmeden önce problemin kendisi anlaşılmalıdır. Ölçülebilir etki varsa belirtilmelidir. Bu yaklaşım gereksiz proje başlatma riskini azaltır.

Business Owner

Business Owner projenin iş sonucunu sahiplenir. Öncelik ve kapsam kararlarında temel rol oynar. Teknik detayların tamamından sorumlu değildir. Ancak projenin neden var olduğunu ve hangi değeri üretmesi gerektiğini açıklar. Business ownership belirsiz projeler zaman içinde yön kaybedebilir.

Technical Owner

Technical Owner sistemin teknik yaşam döngüsünden sorumludur. Architecture, quality ve production ownership gibi alanlarda koordinasyon sağlar. Tek başına tüm kodu yazması gerekmez. Kritik kararların kayıt altına alınmasını destekler. Owner değişikliğinde devir süreci uygulanmalıdır.

Repository Oluşturma

Yeni proje için repository merkezi template üzerinden oluşturulabilir. Naming, visibility ve branch protection otomatik ayarlanabilir. README ve CODEOWNERS gibi temel dosyalar başlangıçta eklenebilir. Bu yaklaşım manuel kurulum hatalarını azaltır. Starter repository doğru davranışı en kolay seçenek haline getirir.

README

README projenin ilk giriş noktasıdır. Purpose, local setup, owner ve temel kullanım bilgileri burada yer almalıdır. Gereksiz ayrıntı yerine geliştiricinin ilk ihtiyacı olan bilgiler verilmelidir. Daha kapsamlı dokümanlara bağlantılar eklenebilir. README güncelliği proje yaşam döngüsü boyunca korunmalıdır.

Architecture Context

Architecture Context projenin çevresindeki sistemlerle ilişkisini açıklar. Hangi servislerle konuştuğu ve hangi veriyi sahiplediği belirtilmelidir. Basit diagram bu bilgiyi hızlı şekilde anlatabilir. Kritik bağımlılıklar görünür hale gelir. Bu bağlam yeni geliştiricilerin sistemi anlamasını kolaylaştırır.

Risk Classification

Risk Classification proje başlangıcında uygulanacak guideline profilini belirleyebilir. Veri hassasiyeti, kullanıcı etkisi ve operasyonel önem değerlendirilir. Seviye zaman içinde değişebilir. Risk arttığında ek security veya reliability kontrolü devreye girer. Bu bilgi repository metadata içinde saklanabilir.

Definition of Done

Definition of Done işin ne zaman tamamlanmış sayılacağını açıklar. Kod yazılması tek başına tamamlanma kriteri değildir. Test, review, documentation ve deployment gibi beklentiler eklenebilir. Proje riskine göre farklı maddeler kullanılabilir. Ortak DoD ekip içinde kalite beklentisini netleştirir.

Repository Oluşturma Yönergeleri

Repository standartları projelerin ilk günden ortak yapıya sahip olmasını sağlar. Naming, visibility, branch protection ve CI gibi alanlar mümkün olduğunda otomatik oluşturulmalıdır. Manuel kurulum arttıkça unutulan güvenlik ve kalite ayarları da artar. Starter repository veya scaffolding bu nedenle büyük değer yaratır. Merkezi standardın yanında repository'ye özel kurallar ayrıca tanımlanabilir.

Repository Naming

Repository naming basit ve tutarlı olmalıdır. İsim proje veya servis amacını anlaşılır biçimde göstermelidir. Takım adını zorunlu prefix yapmak uzun vadede ekip değişikliklerinde sorun yaratabilir. Naming standardı aranabilirliği desteklemelidir. Kural birkaç net örnekle gösterilebilir.

Visibility

Repository visibility varsayılan olarak şirketin güvenlik modeline uygun ayarlanmalıdır. Public repository açılması ayrı review gerektirebilir. Hassas kodun yanlışlıkla public hale gelmesini önlemek için guardrail kullanılabilir. Visibility değişiklikleri audit trail içinde tutulmalıdır. Open source projeler için ayrı politika uygulanabilir.

Default Branch

Default branch tüm repository'lerde ortak isim kullanabilir. Bu sayede CI ve otomasyon araçları daha kolay standartlaştırılır. Branch adı organizasyonun tercihine göre belirlenebilir. Yeni repository template bu ayarı otomatik yapmalıdır. Legacy projeler kademeli migration ile uyumlu hale getirilebilir.

Branch Protection

Protected branch doğrudan riskli değişiklikleri sınırlar. Review, başarılı CI ve belirli status check şartları zorunlu tutulabilir. Force push varsayılan olarak kapatılabilir. Kritik repository'lerde daha güçlü approval şartı uygulanabilir. Bu kontroller manuel hatayı azaltır.

CODEOWNERS

CODEOWNERS belirli dosya veya dizinler için review sorumluluğunu tanımlar. Security-sensitive veya platform alanlarında oldukça faydalıdır. Her dosyayı çok sayıda owner'a bağlamak approval süresini artırabilir. Scope dikkatli tasarlanmalıdır. Owner değiştiğinde dosya da güncellenmelidir.

README

Repository README dosyası projenin hızlı anlaşılmasını sağlamalıdır. Purpose, setup, run, test ve owner bilgileri temel içerik olabilir. Uzun tasarım detayları ayrı dokümana taşınabilir. README içinde güncel olmayan komutlar developer friction yaratır. CI ile link veya örnek komut kontrolü yapılabilir.

LICENSE

LICENSE özellikle open source veya dış paylaşıma açık repository'lerde önemlidir. Şirket içi özel repository'lerde de lisans ve kullanım politikası kurumsal modele göre tanımlanabilir. Rastgele lisans seçimi yapılmamalıdır. Gerektiğinde legal review uygulanmalıdır. Lisans bilgisi dependency policy ile de ilişkilendirilebilir.

SECURITY

SECURITY dosyası güvenlik açığı bildirim sürecini açıklayabilir. Open source projelerde iletişim kanalı ve disclosure süreci görünür olmalıdır. Şirket içi projelerde ilgili security kanalına yönlendirme yapılabilir. Hassas bilgi paylaşım yöntemi açıkça belirtilmelidir. Bu dosya security response sürecinin giriş noktasıdır.

CONTRIBUTING

CONTRIBUTING yeni katkı yapan geliştiricinin takip edeceği kuralları açıklar. Local setup, test, branch ve pull request beklentileri burada özetlenebilir. Ayrıntılı guideline'lara bağlantılar verilebilir. Open source projelerde community süreçleri ayrıca anlatılmalıdır. İyi CONTRIBUTING dosyası onboarding yükünü azaltır.

CI Pipeline

Yeni repository mümkünse temel CI pipeline ile birlikte oluşturulmalıdır. Build, test, lint ve minimum security kontrolleri hazır gelebilir. Ekipler her projede pipeline'ı sıfırdan yazmak zorunda kalmamalıdır. Merkezi template bakım maliyetini azaltır. Risk seviyesine göre ek kontroller otomatik eklenebilir.

Git ve Version Control Guidelines

Git standartları ekiplerin ortak bir değişiklik geçmişi oluşturmasını sağlar. Branch, commit, pull request ve merge davranışları açık biçimde tanımlanmalıdır. Amaç geliştiricilere gereksiz kısıt koymak değil, review ve release sürecini öngörülebilir hale getirmektir. Otomatik branch protection bu kuralların önemli bölümünü destekleyebilir. Standardın farklı proje türlerine göre esnek olmasına dikkat edilmelidir.

Branch Strategy

Branch strategy organizasyonun release modeline uygun olmalıdır. Trunk-based veya farklı branching modeli kullanılabilir. Tek bir yöntemi her projeye zorlamak yerine ihtiyaç ve risk değerlendirilmelidir. Branch ömrü mümkün olduğunca kısa tutulabilir. Uzun yaşayan branch'ler merge riskini artırabilir.

Commit Standardı

Commit mesajları değişikliğin amacını anlaşılır biçimde göstermelidir. Gereksiz uzun formatlar geliştiriciler için ek yük yaratabilir. Otomatik changelog veya semantic release kullanılıyorsa belirli convention gerekli olabilir. Commit mesajı mümkünse “ne” kadar “neden” bilgisini de taşımalıdır. Standard birkaç örnekle açıklanmalıdır.

Pull Request

Pull request değişikliğin review edilebilir birimidir. Açıklama problem, çözüm ve test bilgisini içerebilir. Büyük PR'ların review süresini artırdığı unutulmamalıdır. Template önemli bilgileri hatırlatabilir ancak aşırı uzun olmamalıdır. İlgili issue veya ADR bağlantısı gerektiğinde eklenebilir.

Merge Strategy

Merge strategy history'nin nasıl tutulacağını belirler. Squash, merge commit veya rebase seçenekleri ekip ihtiyacına göre seçilebilir. Otomatik release sistemi bu seçimden etkilenebilir. Ortak yaklaşım repository'ler arasında geçmişi daha okunabilir kılar. İstisnalar açıkça tanımlanmalıdır.

Tagging

Tagging release veya önemli milestone'ların takip edilmesini kolaylaştırır. Tag formatı versioning standardıyla uyumlu olmalıdır. Otomatik pipeline tag üzerinden deployment başlatabilir. Production tag'larının değiştirilmesi sınırlandırılabilir. İmzalı tag gereksinimi risk seviyesine göre değerlendirilebilir.

Versioning

Versioning değişikliklerin tüketiciler tarafından anlaşılmasını sağlar. Semantic Versioning uygun projelerde kullanılabilir. Ancak internal uygulamalarda farklı model daha pratik olabilir. Breaking change açık biçimde işaretlenmelidir. Version ile release notes arasında bağlantı kurulmalıdır.

Protected Branches

Protected branch doğrudan merge ve force push risklerini sınırlar. Minimum review ve başarılı pipeline şartı eklenebilir. Kritik projelerde CODEOWNER approval zorunlu olabilir. Kurallar merkezi repository policy ile uygulanabilir. Manuel konfigürasyon yerine otomasyon tercih edilmelidir.

Force Push Politikası

Force push özellikle shared branch üzerinde geçmişi bozabilir. Bu nedenle protected branch'lerde varsayılan olarak engellenebilir. Feature branch'lerde kontrollü kullanım mümkün olabilir. Guideline hangi durumda izin verildiğini açıkça belirtmelidir. Gereksiz mutlak yasak yerine risk bazlı yaklaşım daha sağlıklıdır.

Code Review Guidelines

Code review yalnızca hata arama faaliyeti değildir. Bilgi paylaşımı, tasarım değerlendirmesi ve ortak kod sahipliği açısından önemli bir süreçtir. Ancak belirsiz review beklentileri gereksiz tartışmaya ve uzun bekleme sürelerine yol açabilir. Minimum reviewer, SLA ve blocking comment yaklaşımı açıkça tanımlanmalıdır. Review kalitesi kadar developer experience da izlenmelidir.

Review Ne Zaman Zorunlu?

Production koduna giden değişikliklerde review genel olarak zorunlu olabilir. Dokümantasyon veya otomatik üretilen dosyalar için farklı kurallar uygulanabilir. Emergency change için hızlı ancak kayıtlı süreç tasarlanabilir. Riskli alanlarda ek reviewer gerekebilir. Kapsam açık olmazsa ekipler farklı uygulama geliştirir.

Minimum Reviewer Sayısı

Minimum reviewer sayısı proje riskine göre belirlenmelidir. Her PR için üç reviewer zorunluluğu küçük ekiplerde ciddi darboğaz yaratabilir. Standart projelerde bir bağımsız review yeterli olabilir. Kritik değişikliklerde iki veya daha fazla onay istenebilir. Kural gerçek kapasite ile uyumlu olmalıdır.

CODEOWNER Review

CODEOWNER review hassas alanlarda uzman görüşü sağlar. Security config, deployment manifest veya core platform kodu buna örnek olabilir. Her dizini CODEOWNER zorunluluğuna bağlamak approval süresini uzatır. Bu nedenle scope dikkatli seçilmelidir. Owner availability de düzenli olarak kontrol edilmelidir.

Review SLA

Review SLA pull request'lerin uzun süre beklemesini önlemeye yardımcı olur. Örneğin çalışma saatleri içinde belirli süre içinde ilk geri dönüş hedeflenebilir. SLA cezalandırma aracı değil, ekip akışını iyileştirme göstergesi olmalıdır. Büyük veya riskli PR'lar daha uzun inceleme gerektirebilir. Dashboard üzerinden bekleyen review sayısı takip edilebilir.

İncelenecek Alanlar

Reviewer yalnızca syntax kontrolü yapmamalıdır. Design, functionality, complexity, tests ve security gibi alanlar değerlendirilmelidir. Her PR için tüm başlıklarda aynı derinlik gerekmeyebilir. Riskli değişikliklerde daha kapsamlı review yapılabilir. Checklist reviewer'a düşünmesi gereken noktaları hatırlatabilir.

Design

Design review değişikliğin sistem yapısıyla uyumunu değerlendirir. Yeni dependency veya service boundary kararı sorgulanabilir. Gereksiz abstraction olup olmadığı incelenir. Daha basit çözüm seçeneği varsa tartışılır. Büyük kararlar ADR ile kayıt altına alınabilir.

Functionality

Functionality incelemesi kodun beklenen davranışı üretip üretmediğine odaklanır. Edge case'ler değerlendirilir. Error handling akışı kontrol edilir. İş gereksinimi ile implementasyonun uyumu incelenir. Test sonuçları bu değerlendirmeyi destekler.

Complexity

Complexity kodun gereğinden fazla zor anlaşılır hale gelip gelmediğini değerlendirir. Gereksiz nested yapı veya abstraction sorgulanabilir. Ancak düşük satır sayısı tek kalite kriteri değildir. Okunabilirlik ve bakım maliyeti birlikte düşünülmelidir. Reviewer alternatif önerirken nedenini açıklamalıdır.

Tests

Reviewer değişikliğin uygun testlerle desteklenip desteklenmediğini değerlendirir. Test yalnızca coverage yükseltmek için yazılmamalıdır. Kritik davranış ve regression riski önceliklendirilmelidir. Flaky test'ler ayrıca işaretlenmelidir. Testin okunabilirliği de production kodu kadar önemlidir.

Security

Security review input, authorization ve secret kullanımı gibi alanları kontrol eder. Her reviewer güvenlik uzmanı olmak zorunda değildir. Kritik değişiklikler için security SME review gerekebilir. Otomatik scanner sonuçları review'a destek verir. High-risk bulgular merge öncesinde çözülmelidir.

Naming

Naming kodun anlaşılabilirliğini doğrudan etkiler. İsimler domain dilini yansıtmalıdır. Gereksiz kısaltmalar yeni geliştiriciler için öğrenme maliyeti yaratabilir. Language-specific convention'lar otomatik lint ile desteklenebilir. Review yorumları küçük stil tercihlerini kişisel tartışmaya dönüştürmemelidir.

Documentation

Değişiklik kullanıcı veya geliştirici davranışını etkiliyorsa ilgili dokümantasyon güncellenmelidir. Public API değişikliği buna açık örnektir. README veya runbook etkileniyorsa aynı PR içinde değiştirilebilir. Ayrı ticket oluşturmak bilgi drift riskini artırır. Documentation review kod review'ın doğal parçası olabilir.

Review Yorumlarının Dili

Review yorumları kişiye değil koda odaklanmalıdır. Emir veya küçümseyici ifade yerine gerekçe ve öneri verilmelidir. “Bunu değiştir” yerine riskin neden önemli olduğu açıklanabilir. Ekip ortak review dili belirleyebilir. Sağlıklı iletişim code review'ın bilgi paylaşım işlevini güçlendirir.

Blocking ve Non-Blocking Comment

Her review yorumu merge engeli olmamalıdır. Blocking comment correctness, security veya zorunlu standard ihlalinde kullanılabilir. Non-blocking yorum tercih veya gelecekteki iyileştirme önerisini gösterebilir. Prefix veya platform özelliği ile ayrım görünür yapılabilir. Bu uygulama gereksiz review ping-pong'unu azaltır.

Coding Guidelines

Coding guideline kodun anlaşılabilir, sürdürülebilir ve güvenli şekilde geliştirilmesini destekler. Her ayrıntıyı el ile yazmak yerine language tooling ve formatter kullanılmalıdır. İnsan review'u anlam, tasarım ve risk gibi yüksek değerli konulara bırakmak daha verimlidir. Ortak kurallar gerekçeleriyle birlikte açıklanmalıdır. Language-specific detaylar merkezi prensiplerden ayrılabilir.

Naming

Naming domain kavramlarını açık biçimde yansıtmalıdır. Değişken ve fonksiyon isimleri gereksiz kısaltmalardan kaçınmalıdır. Takımın kullandığı language convention esas alınabilir. Otomatik lint desteklenebilen noktalar manuel review'a bırakılmamalıdır. İyi isimlendirme kodun açıklama ihtiyacını azaltır.

Formatting

Formatting kişisel tercih konusu olmaktan çıkarılmalıdır. Otomatik formatter standart hale getirilebilir. Böylece review yorumlarında boşluk ve satır düzeni tartışılmaz. Tool konfigürasyonu repository içinde version-controlled tutulmalıdır. Format kontrolü CI içinde otomatik çalıştırılabilir.

Complexity

Complexity yönetimi bakım maliyetini azaltmayı hedefler. Tek bir sayısal eşik her dil ve proje için doğru olmayabilir. Cyclomatic complexity gibi metrikler warning üretmek için kullanılabilir. Review sırasında okunabilirlik ve sorumluluk ayrımı değerlendirilmelidir. Amaç geliştiriciyi sayı peşinde koşturmak değil, anlaşılır kod üretmektir.

Error Handling

Error handling uygulamanın failure davranışını belirler. Hatalar sessizce yutulmamalıdır. Retry yalnızca uygun ve idempotent operasyonlarda kullanılmalıdır. Kullanıcıya dönen hata ile internal log ayrılmalıdır. Ortak exception pattern'leri starter library ile desteklenebilir.

Dependency Kullanımı

Her küçük ihtiyaç için yeni dependency eklemek uzun vadeli bakım ve güvenlik maliyeti yaratabilir. Yeni dependency'nin lisansı, bakım durumu ve güvenlik geçmişi değerlendirilmelidir. Approved library listesi tekrar eden kararları azaltabilir. Kritik dependency'ler için owner belirlenebilir. Otomatik dependency scan uygulanmalıdır.

Configuration

Configuration kod içine dağınık biçimde gömülmemelidir. Environment-specific değerler açık yöntemle yönetilmelidir. Varsayılan değerlerin güvenli olması önemlidir. Configuration schema veya validation kullanılabilir. Değişikliklerin audit edilebilir olması production riskini azaltır.

Secrets

Secrets kaynak kod veya normal configuration dosyasında tutulmamalıdır. Merkezi secret manager kullanımı zorunlu hale getirilebilir. CI secret scan merge öncesinde çalıştırılabilir. Credential rotation süreci ayrıca tanımlanmalıdır. Test ortamlarında da gerçek production secret kullanılmamalıdır.

Logging

Logging troubleshooting için yeterli bağlam sağlamalıdır. Hassas veri log içine yazılmamalıdır. Structured log formatı merkezi analiz araçlarında büyük avantaj sağlar. Correlation ID dağıtık sistemlerde request takibini kolaylaştırır. Log seviyesi doğru kullanılmalıdır.

Comments

Comment kodun ne yaptığını tekrar etmek yerine nedenini açıklamalıdır. Karmaşık business rule veya geçici workaround için bağlam verilebilir. Güncel olmayan comment yanlış bilgi üretir. Kod değiştiğinde ilgili comment de güncellenmelidir. Açık kod yazmak gereksiz comment ihtiyacını azaltır.

Language-Specific Rules

Her programlama dilinin kendi ekosistem alışkanlıkları bulunur. Bu nedenle merkezi coding guideline genel prensibi tanımlarken dil özelindeki detaylar ayrı belgede tutulabilir. Formatter, package manager ve test framework tercihleri burada açıklanabilir. Yeni sürümler geldikçe kurallar review edilmelidir. Language owner veya guild bakım sorumluluğu üstlenebilir.

“En İyi Programlama Dili” Yerine Teknoloji Seçim Yönergesi

Şirketlerde “en iyi dil hangisi?” tartışması çoğu zaman verimli sonuç üretmez. Teknoloji seçimi bağlama bağlıdır. İş gereksinimi, ekip yetkinliği, güvenlik, bakım ve toplam sahip olma maliyeti birlikte değerlendirilmelidir. Bu nedenle tek bir favori dil belirlemek yerine teknoloji seçim yönergesi oluşturmak daha sağlıklıdır. Teknoloji radar modeli bu kararları görünür hale getirebilir.

Tek Bir En İyi Programlama Dili Neden Yok?

Her programlama dili farklı güçlü ve zayıf yönlere sahiptir. Backend servis, data pipeline ve mobile uygulama aynı ihtiyaçlara sahip değildir. Ekibin deneyimi de seçim üzerinde doğrudan etkilidir. Popülerlik tek başına kurumsal uygunluk göstergesi değildir. Seçim kullanım senaryosu ve uzun vadeli bakım üzerinden yapılmalıdır.

Approved Technologies

Approved Technologies production kullanımında kabul edilmiş araçları gösterir. Bu teknolojiler için security, platform ve hiring desteği bulunmalıdır. Yeni projeler varsayılan olarak bu listeden seçim yapabilir. Liste çok dar tutulursa innovation zorlaşabilir. Düzenli review ile yeni seçenekler eklenebilir.

Preferred Technologies

Preferred Technologies belirli problem türü için kurumun önerdiği varsayılan seçeneklerdir. Amaç zorunlu tek çözüm yaratmak değildir. Starter template ve internal library desteği bu teknolojilerde daha güçlü olabilir. Ekip farklı teknoloji seçiyorsa gerekçesini RFC ile açıklayabilir. Böylece standardizasyon ile özerklik dengelenir.

Trial Technologies

Trial kategorisi kontrollü pilot için uygun görülen teknolojileri içerir. Production kullanımından önce belirli scope içinde denenebilir. Pilot sonucu performans, bakım ve developer experience açısından değerlendirilir. Başarılı olursa preferred veya approved kategorisine taşınabilir. Başarısız olursa kullanım sınırlandırılabilir.

Deprecated Technologies

Deprecated technology yeni projelerde tercih edilmemesi gereken araçları gösterir. Mevcut projeler için migration plan hazırlanabilir. Bir anda yasaklamak büyük teknik borç maliyeti yaratabilir. End-of-support tarihi gerektiğinde tanımlanmalıdır. Yeni kullanım otomatik repository kontrolüyle sınırlandırılabilir.

Teknoloji Radar Modeli

Teknoloji radar modeli araçları farklı benimseme seviyelerinde gösterir. Adopt, Trial, Assess ve Hold gibi kategoriler kullanılabilir. Bu yapı ekiplerin hangi teknolojinin ne kadar olgun olduğunu hızlıca anlamasını sağlar. Her karar kısa rationale ile desteklenmelidir. Radar belirli aralıklarla review edilmelidir.

Adopt

Adopt kategorisi güvenle kullanılabilecek ve kurum tarafından desteklenen teknolojileri içerir. Platform template'leri bu araçlara öncelik verebilir. Support ve monitoring entegrasyonları hazır olabilir. Yeni projelerde güçlü varsayılan seçenek olarak sunulabilir. Ancak hiçbir kategori sonsuza kadar kalıcı kabul edilmemelidir.

Trial

Trial kontrollü kullanım için yeterli güven oluşmuş teknolojileri içerir. Kullanım kapsamı sınırlı tutulabilir. Pilot ekipler gözlem ve feedback toplar. Üretim riskleri açıkça değerlendirilir. Sonuçlar sonraki radar kararına veri sağlar.

Assess

Assess henüz üretim standardı olmayan ancak araştırmaya değer teknolojileri gösterir. Küçük spike veya POC yapılabilir. Kritik sistemlerde erken kullanım sınırlandırılabilir. Teknik ve operasyonel maliyetler değerlendirilir. Yeterli kanıt oluşursa Trial seviyesine geçilebilir.

Hold

Hold yeni kullanımının önerilmediği teknolojileri gösterir. Bunun nedeni güvenlik, bakım veya daha iyi alternatiflerin bulunması olabilir. Mevcut sistemler için migration yol haritası oluşturulabilir. Hold kararı gerekçesiz verilmemelidir. Takımlar ne zaman ve nasıl geçiş yapacağını bilmelidir.

Yeni Teknoloji Kullanmak İçin RFC

Yeni teknoloji kullanımı belirli etkiyi aşıyorsa RFC sürecine bağlanabilir. RFC iş ihtiyacını, alternatifleri, trade-off'ları ve bakım planını açıklamalıdır. “Yeni olduğu için kullanmak istiyoruz” tek başına yeterli gerekçe değildir. Pilot ve exit strategy düşünülmelidir. Karar sonrasında sonuç ADR veya technology radar içinde kayıt altına alınabilir.

Teknoloji Seçiminde Hangi Kriterler Bulunmalı?

Teknoloji seçimi yalnızca performans benchmark'ına göre yapılmamalıdır. İş gereksinimi, ekip yetkinliği ve uzun vadeli bakım maliyeti birlikte değerlendirilmelidir. Güvenlik ve lisans riskleri de önemli kriterlerdir. Vendor bağımlılığı ve hiring etkisi yıllar sonra daha büyük maliyet yaratabilir. Bu nedenle karar matrisi çok boyutlu olmalıdır.

İş Gereksinimi

Teknoloji seçiminin ilk sorusu hangi problemi çözmek istediğimiz olmalıdır. Gereksinim düşük latency, hızlı geliştirme veya data processing olabilir. Araç bu ihtiyaca doğrudan katkı sağlamalıdır. Popülerlik iş ihtiyacının önüne geçmemelidir. Gereksinim değişirse teknoloji kararı da yeniden değerlendirilebilir.

Ekibin Yetkinliği

Ekibin mevcut yetkinliği teslimat ve bakım hızını etkiler. Tamamen yeni teknoloji önemli öğrenme maliyeti yaratabilir. Ancak mevcut yetkinlik gelecekteki gelişimi tamamen engellememelidir. Eğitim ve hiring planı değerlendirmeye dahil edilmelidir. Kritik sistemlerde yeterli uzman bulunması önemlidir.

Security

Teknolojinin bilinen güvenlik modeli incelenmelidir. Dependency ekosistemi ve patch yayın hızı önemlidir. Kurumun security tooling'i ile entegrasyon yeteneği değerlendirilmelidir. Security ekibinin destekleyemediği egzotik araçlar ek risk yaratabilir. Risk karar içinde görünür biçimde kaydedilmelidir.

Performance

Performance gerçek kullanım senaryosu üzerinden ölçülmelidir. Mikro benchmark sonuçları her zaman production davranışını temsil etmez. Latency, throughput ve resource tüketimi birlikte değerlendirilebilir. Gereksinimi karşılayan en basit seçenek tercih edilebilir. Aşırı optimizasyon bakım maliyetini gereksiz artırabilir.

Maintenance

Maintenance uzun vadeli sahip olma maliyetinin önemli bölümüdür. Teknolojinin release sıklığı, backward compatibility ve upgrade yolu incelenmelidir. Az bilinen araç için iç destek oluşturmak zor olabilir. Dependency sayısı ve operational tooling etkisi değerlendirilmelidir. Seçim yalnızca ilk geliştirme hızına göre yapılmamalıdır.

Community

Community büyüklüğü sorun çözme ve bilgi bulma hızını etkileyebilir. Ancak yalnızca GitHub yıldızı karar kriteri değildir. Aktif maintainer, release düzeni ve issue çözüm hızı daha anlamlı olabilir. Kurumsal kullanım örnekleri incelenebilir. Sağlıklı community uzun vadeli sürdürülebilirlik sinyali verir.

Lisans

Lisans şartları özellikle ticari ve open source kullanımlarda önemlidir. Dependency lisansı şirket politikasıyla uyumlu olmalıdır. Gerekli durumlarda legal review yapılmalıdır. Lisans değişiklikleri otomatik dependency scanner üzerinden izlenebilir. Erken kontrol ileride migration maliyetini azaltır.

Hiring

Nadir teknoloji için deneyimli çalışan bulmak daha zor olabilir. Ancak hiring tek başına teknik kararı belirlememelidir. Eğitim kapasitesi ve mevcut ekip yetkinliği birlikte değerlendirilmelidir. Uzun vadeli büyüme planı düşünülmelidir. Kritik sistemlerde tek kişiye bağımlılık yaratılmamalıdır.

Vendor Lock-In

Vendor lock-in bazı durumlarda kabul edilebilir iş kararı olabilir. Önemli olan bağımlılığın bilinçli değerlendirilmesidir. Migration maliyeti, data portability ve alternatifler incelenmelidir. Kritik iş süreçlerinde exit strategy oluşturulabilir. Lock-in riski tamamen kaçınılacak bir durum olarak görülmemelidir.

Total Cost of Ownership

Total Cost of Ownership yalnızca lisans ücretini içermez. Infrastructure, bakım, eğitim, support ve migration maliyetleri de hesaplanmalıdır. Ucuz görünen bir teknoloji operasyonel olarak pahalı olabilir. Platform entegrasyonu ve hiring etkisi de maliyete dahildir. Uzun vadeli kararlar bu toplam resim üzerinden verilmelidir.

Architecture Guidelines

Architecture guideline tüm sistemleri aynı mimariye zorlamak için kullanılmamalıdır. Asıl amaç servis sınırları, dependency ve integration gibi yüksek etkili konularda ortak prensip oluşturmaktır. Büyük kararlar gerekçeleriyle birlikte ADR üzerinden kaydedilebilir. Merkezi guideline genel sınırları, proje kararları ise bağlama özel çözümü tanımlar. Böylece architecture drift azaltılırken ekiplerin mühendislik alanı korunur.

Service Boundaries

Service boundary business capability ve ownership ile uyumlu olmalıdır. Gereksiz küçük servisler operasyonel yük yaratabilir. Çok büyük servisler ise değişiklik bağımlılığını artırabilir. Domain ve ekip yapısı birlikte değerlendirilmelidir. Boundary değişiklikleri ADR ile kayıt altına alınabilir.

API Design

API design ortak naming, versioning ve error response prensipleri içerebilir. Public veya internal API ayrımı yapılmalıdır. Breaking change politikası açık olmalıdır. API documentation otomatik üretilen kaynakla desteklenebilir. Tüketici deneyimi tasarımın önemli parçasıdır.

Dependency Rules

Dependency rules hangi katmanın hangi bileşene bağımlı olabileceğini açıklar. Circular dependency riskini azaltır. Ortak library kullanımında ownership belirlenmelidir. Static analysis ile bazı kurallar otomatik kontrol edilebilir. Architecture sınırları kod seviyesinde görünür hale gelir.

Data Ownership

Her kritik veri setinin sahibi belirli olmalıdır. Farklı servislerin aynı veritabanı tablolarına doğrudan yazması güçlü coupling yaratabilir. Data contract yaklaşımı kullanılabilir. Ownership access ve schema değişikliklerini de yönlendirir. Bu bilgi architecture catalog içinde tutulabilir.

Integration Patterns

Integration pattern senkron API, messaging veya batch paylaşımı gibi seçeneklerin hangi durumda kullanılacağını anlatır. Tek pattern her probleme uygulanmamalıdır. Reliability, latency ve consistency ihtiyacı değerlendirilmelidir. Approved integration araçları listelenebilir. Örnek referans mimariler ekiplerin kararını hızlandırır.

Authentication

Authentication merkezi identity altyapısıyla uyumlu olmalıdır. Her ekip kendi login mekanizmasını sıfırdan geliştirmemelidir. Service-to-service authentication için standart pattern tanımlanabilir. Secret rotation ve token lifetime gibi konular security guideline ile ilişkilendirilir. Hazır platform bileşenleri kullanım kolaylığı sağlar.

Caching

Caching performans kazandırırken data consistency riskleri yaratabilir. Cache invalidation yaklaşımı açık olmalıdır. Hassas verinin cache içinde saklanma şartları belirlenmelidir. TTL ve fallback davranışı tanımlanabilir. Cache kullanımı gerçek performans ihtiyacına dayanmalıdır.

Messaging

Messaging asenkron sistemlerde önemli integration aracıdır. Message schema, retry ve dead-letter yaklaşımı standardize edilebilir. Idempotency beklentisi açık biçimde tanımlanmalıdır. Sensitive data taşıyan mesajlar için security kuralları uygulanır. Observability için correlation ID kullanılabilir.

Architecture Decision Records

ADR önemli mimari kararları kalıcı hale getirir. Problem, seçenekler, karar ve sonuçlar kısa biçimde yazılabilir. Her küçük kod tercihi ADR gerektirmez. Uzun vadeli etki yaratan kararlar önceliklendirilmelidir. Repository içinde tutulması kod ve karar geçmişini yakınlaştırır.

Security Guidelines

Security guideline geliştiricinin günlük kararlarında güvenli varsayılanlar oluşturmalıdır. Yalnızca yasak listesi sunmak yerine uygun araç ve örnekler sağlanmalıdır. Riskli kontroller mümkün olduğunda CI ve platform seviyesinde otomatik hale getirilmelidir. İnsan review'u yüksek bağlam gerektiren konulara odaklanmalıdır. Security standardı geliştirici deneyimini göz ardı etmeden tasarlanmalıdır.

Authentication

Authentication kullanıcı veya servis kimliğini doğrular. Merkezi identity çözümü tercih edilmelidir. Custom authentication yalnızca güçlü gerekçe varsa kullanılmalıdır. Credential lifecycle açık biçimde yönetilmelidir. MFA gereksinimi risk seviyesine göre tanımlanabilir.

Authorization

Authorization kimliği doğrulanmış aktörün hangi işlemi yapabileceğini belirler. Least privilege temel prensip olabilir. Role veya policy tabanlı model kurum ihtiyacına göre seçilebilir. Kritik yetki değişiklikleri audit edilmelidir. Authorization kontrolü yalnızca frontend'e bırakılmamalıdır.

Input Validation

Dışarıdan gelen veri güvenilmez kabul edilmelidir. Validation server tarafında yapılmalıdır. Uygun encoding ve parsing yöntemleri kullanılmalıdır. Framework'ün güvenli mekanizmaları tercih edilmelidir. Tekrarlanan validation pattern'leri ortak library ile desteklenebilir.

Secrets Management

Secret'lar merkezi ve erişim kontrollü sistemde tutulmalıdır. Repository içine credential eklenmesi otomatik scan ile engellenebilir. Rotation süreci ve owner belirlenmelidir. Local development için güvenli yöntem sağlanmalıdır. Incident durumunda revocation prosedürü açık olmalıdır.

Dependency Security

Dependency'ler düzenli olarak vulnerability açısından taranmalıdır. Critical bulgular için çözüm SLA'sı tanımlanabilir. Otomatik update araçları kontrollü şekilde kullanılabilir. Abandoned dependency'ler ayrıca izlenmelidir. Yeni dependency ekleme kriterleri guideline içinde bulunmalıdır.

Encryption

Encryption gereksinimi veri sınıfına göre belirlenmelidir. Transit ve at-rest koruma ayrımı yapılabilir. Custom cryptography geliştirmek yerine desteklenen library kullanılmalıdır. Key management merkezi sistem üzerinden yürütülmelidir. Encryption tek başına access control yerine geçmez.

Logging

Security logging olay incelemesi için yeterli bilgi sağlamalıdır. Authentication failure ve yetki değişiklikleri gibi olaylar kaydedilebilir. Password, token veya hassas kişisel veri loglanmamalıdır. Log retention risk ve yasal gereksinime göre belirlenir. Audit log değiştirilmeye karşı korunmalıdır.

Vulnerability Management

Vulnerability bulguları severity ve exploitability üzerinden önceliklendirilmelidir. Her bulgu aynı aciliyette ele alınmamalıdır. Remediation SLA risk seviyesine göre belirlenebilir. False positive için kayıtlı exception mekanizması kullanılmalıdır. Trend analizi tekrarlanan zayıflıkları gösterebilir.

Security Review

Security review yüksek riskli değişikliklerde uzman kontrolü sağlar. Her küçük PR için manuel security onayı gerekmemelidir. Risk bazlı trigger kullanılabilir. Threat modeling yeni kritik sistemlerde faydalı olabilir. Review sonucundaki kararlar kayıt altında tutulmalıdır.

Testing Guidelines

Testing guideline test sayısını artırmak yerine doğru riskleri doğrulamayı hedeflemelidir. Her projeye aynı test piramidini zorlamak gerçekçi değildir. Unit, integration, API ve end-to-end testler farklı amaçlara hizmet eder. Risk, değişiklik tipi ve sistem yapısı test stratejisini belirlemelidir. Coverage yüzdesi tek başına kalite hedefi yapılmamalıdır.

Unit Test

Unit test küçük davranış birimlerini hızlı şekilde doğrular. Kritik business logic için oldukça değerlidir. Implementation detail'e aşırı bağlı testler refactor maliyetini artırabilir. Testler deterministik ve hızlı olmalıdır. Hangi alanlarda zorunlu olduğu guideline içinde açıkça belirtilmelidir.

Integration Test

Integration test birden fazla bileşenin birlikte davranışını kontrol eder. Database, message broker veya external service integration bu kapsama girebilir. Unit test'in yakalayamadığı contract sorunlarını ortaya çıkarabilir. Test environment yönetimi önemlidir. Flaky integration test'ler ayrıca izlenmelidir.

API Test

API test endpoint contract ve davranışını doğrular. Status code, schema ve authorization senaryoları test edilebilir. Consumer beklentileri contract test ile desteklenebilir. Breaking change riski olan API'lerde güçlü fayda sağlar. Testler CI içinde otomatik çalıştırılabilir.

End-to-End Test

End-to-end test gerçek kullanıcı akışını uçtan uca doğrular. Değerli olmasına rağmen yavaş ve bakım maliyetli olabilir. Bu nedenle kritik journey'lere odaklanmak daha doğrudur. Her senaryoyu E2E ile test etmek gereksiz maliyet yaratır. Flaky sonuçlar düzenli olarak ele alınmalıdır.

Regression

Regression test daha önce düzeltilen hatanın tekrar oluşmasını önlemeye yardımcı olur. Kritik bug fix'lerde ilgili test eklenmesi zorunlu tutulabilir. Test hatanın gerçek davranışını temsil etmelidir. Yalnızca coverage artırmak için yapay test yazılmamalıdır. Regression suite zaman içinde sadeleştirilmelidir.

Performance Test

Performance test yüksek trafik veya latency gereksinimi olan sistemlerde kullanılmalıdır. Tüm internal tool'lar için zorunlu olması gereksizdir. Baseline ve hedef değerler önceden tanımlanmalıdır. Test ortamının production davranışına ne kadar yakın olduğu bilinmelidir. Sonuçlar release kararı için veri sağlayabilir.

Security Test

Security test automated scan ve gerektiğinde manuel değerlendirme içerebilir. Dependency, static code ve dynamic test araçları kullanılabilir. Kritik sistemlerde penetration test gerekebilir. Her test türünün neyi yakaladığı bilinmelidir. Tool çıktısı bağlamdan bağımsız mutlak gerçek olarak görülmemelidir.

Test Coverage

Coverage hangi kod alanlarının test sırasında çalıştığını gösterir. Faydalı bir sinyal olabilir ancak kaliteyi tek başına ölçmez. Yüksek coverage yanlış assertion'larla bile elde edilebilir. Kritik branch ve business rule daha önemli olabilir. Coverage trend olarak izlenebilir.

Coverage Yüzdesini Kör KPI Haline Getirmemek

Tek hedef olarak yüzde belirlemek ekipleri yanlış davranışa yönlendirebilir. İnsanlar gerçek riski test etmek yerine sayıyı yükseltmeye çalışabilir. Coverage minimum eşiği gerekiyorsa bağlamla birlikte kullanılmalıdır. Mutation testing veya defect trend gibi ek sinyaller değerlendirilebilir. Asıl amaç üretimdeki hata oranını azaltmaktır.

CI/CD Guidelines

CI/CD guideline geliştirme değişikliklerinin güvenli ve tekrarlanabilir biçimde production'a ulaşmasını sağlar. Pipeline mümkün olduğunca standard template üzerinden oluşturulmalıdır. Build, test, security scan ve deployment adımları risk seviyesine göre farklılaştırılabilir. Manuel approval yalnızca gerçek risk bulunduğunda kullanılmalıdır. Rollback ve audit trail sürecin doğal parçalarıdır.

Build

Build süreci deterministik olmalıdır. Aynı commit mümkün olduğunca aynı artifact'i üretmelidir. Dependency versiyonları kontrol altında tutulmalıdır. Build log'ları troubleshooting için yeterli bilgi içermelidir. Artifact bütünlüğü gerektiğinde doğrulanabilir.

Test

CI içinde hızlı ve güvenilir testler çalıştırılmalıdır. Flaky test'ler pipeline'a olan güveni azaltır. Test katmanları süreye göre ayrılabilir. Kritik smoke test deployment sonrası çalıştırılabilir. Başarısız test durumunda merge veya deployment politikası açık olmalıdır.

Security Scan

Security scan dependency ve code risklerini erken aşamada bulmayı amaçlar. High severity bulgular için gate uygulanabilir. False positive yönetimi kayıtlı exception üzerinden yürütülmelidir. Tarama süreleri pipeline'ı gereksiz yavaşlatmamalıdır. Kritik kontroller merkezi template içinde hazır gelmelidir.

Package

Package adımı deploy edilecek artifact'i üretir. Artifact version ve source commit arasında açık bağlantı kurulmalıdır. Immutable package yaklaşımı güvenliği ve izlenebilirliği artırabilir. Registry access kontrolü uygulanmalıdır. Dependency metadata gerektiğinde SBOM ile desteklenebilir.

Deployment

Deployment mümkün olduğunca otomatik ve tekrarlanabilir olmalıdır. Environment-specific manuel adımlar azaltılmalıdır. Progressive delivery yüksek riskli sistemlerde değerlendirilebilir. Deployment sonucu monitoring ile doğrulanmalıdır. Hata durumunda rollback yolu hazır olmalıdır.

Approval

Approval yalnızca gerçek risk azaltıyorsa kullanılmalıdır. Her deployment için manuel yönetici onayı hız ve kalite sağlamayabilir. Kritik production veya regüle sistemlerde ek kontrol gerekebilir. Onay veren kişinin neyi kontrol ettiği tanımlanmalıdır. Approval kayıtları audit trail içinde tutulmalıdır.

Rollback

Rollback planı production değişikliğinin güvenli geri dönüş yolunu tanımlar. Her sistemde rollback aynı şekilde çalışmayabilir. Database migration gibi durumlarda forward fix gerekebilir. Plan release öncesinde düşünülmelidir. Gerekirse düzenli game day ile test edilebilir.

Audit Trail

Audit trail hangi değişikliğin kim tarafından ve ne zaman yapıldığını gösterir. Production deployment'larda bu bilgi otomatik kaydedilmelidir. Manuel log tutmak yerine pipeline metadata kullanılabilir. Compliance gereksinimleri retention süresini etkileyebilir. İyi audit trail incident investigation süresini azaltır.

Release Guidelines

Release guideline kodun kullanıcıya güvenli biçimde ulaşmasını destekler. Versioning, readiness, rollback ve monitoring bu sürecin temel parçalarıdır. Her release için aynı ağır süreç uygulanmamalıdır. Risk seviyesine göre farklı kontrol profilleri kullanılabilir. Emergency release için hızlı ancak kayıtlı ayrı akış bulunmalıdır.

Semantic Versioning

Semantic Versioning özellikle tüketicisi olan library ve API'lerde değişiklik etkisini anlatır. Major, minor ve patch ayrımı açık iletişim sağlar. Ancak her internal uygulamada zorunlu olmayabilir. Release tooling ile otomatik hale getirilebilir. Breaking change tanımı kurum içinde örneklerle açıklanmalıdır.

Release Readiness

Release readiness değişikliğin production'a hazır olup olmadığını değerlendirir. Test, security, documentation ve rollback gibi maddeler kontrol edilebilir. Checklist proje riskine göre değişebilir. Her release için uzun toplantı yapılması gerekmemelidir. Otomatik sinyaller mümkün olduğunda kullanılır.

Release Notes

Release notes kullanıcı veya ekip için önemli değişiklikleri özetler. Teknik commit listesini olduğu gibi kopyalamak yeterli değildir. Breaking change ve migration adımları açıkça belirtilmelidir. Internal service release'lerinde daha kısa format kullanılabilir. Otomatik oluşturma insan review ile desteklenebilir.

Changelog

Changelog sürümler arasındaki değişiklik geçmişini görünür hale getirir. Library ve public API projelerinde özellikle faydalıdır. Format mümkün olduğunca standart tutulmalıdır. Otomatik tooling ile üretilebilir. Gereksiz ayrıntı okunabilirliği azaltabilir.

Rollback Plan

Rollback Plan hatalı release durumunda izlenecek yolu açıklar. Hangi koşulda rollback kararı verileceği belirtilmelidir. Data migration içeren sürümlerde özel dikkat gerekir. Plan teorik olarak kalmamalı, kritik sistemlerde test edilmelidir. Owner bilgisi de görünür olmalıdır.

Monitoring

Release sonrasında sistemin health göstergeleri takip edilmelidir. Error rate, latency ve business metric birlikte değerlendirilebilir. Değişiklikle ilgili dashboard linki release kaydında bulunabilir. Otomatik alert erken sorun tespitini sağlar. Belirli gözlem süresi kritik release'lerde faydalı olabilir.

Customer Communication

Kullanıcıyı etkileyen değişikliklerde communication plan gerekebilir. Maintenance, breaking API veya büyük özellik değişikliği önceden duyurulabilir. Teknik ekip ile product iletişimi birlikte planlamalıdır. Mesaj kullanıcı açısından gerekli aksiyonu açıkça anlatmalıdır. Gereksiz teknik ayrıntıdan kaçınılmalıdır.

Emergency Release

Emergency release normal sürecin hızlandırılmış versiyonu olmalıdır. Kontroller tamamen kaldırılmamalıdır. Minimum reviewer ve audit trail korunabilir. Sonrasında retrospective ve eksik kontroller tamamlanmalıdır. Bu süreç normal deployment shortcut'ına dönüşmemelidir.

Observability Guidelines

Observability guideline sistemlerin production davranışını anlaşılır hale getirmeyi amaçlar. Log, metric, tracing ve alert birlikte düşünülmelidir. Her servisin aynı sayıda dashboard'a sahip olması gerekmez. Kritik user journey ve failure mode'lara odaklanılmalıdır. İyi observability incident çözüm süresini ve belirsizliği azaltır.

Log Format

Structured log formatı merkezi analiz için güçlü avantaj sağlar. JSON benzeri standart yapı kullanılabilir. Timestamp, service ve correlation bilgileri ortak alanlar olabilir. Hassas veri loglanmamalıdır. Format library ile otomatik hale getirilebilir.

Log Level

Log level doğru kullanılmadığında production log'ları gürültülü hale gelir. Error gerçekten müdahale gerektiren durumları göstermelidir. Debug production'da varsayılan olarak kapalı olabilir. Warning sık kullanılırsa anlamını kaybedebilir. Kısa örnekler geliştiricilerin doğru seviye seçmesini kolaylaştırır.

Correlation ID

Correlation ID dağıtık request akışını servisler arasında takip etmeyi kolaylaştırır. Gateway veya ilk giriş noktası ID üretebilir. Alt servisler aynı değeri propagate etmelidir. Logging ve tracing sistemleri bu alanı kullanabilir. Ortak middleware bunu otomatik hale getirebilir.

Metrics

Metrics sistem davranışını zaman içinde ölçer. CPU gibi teknik metriklerin yanında request ve business metric de kullanılabilir. Çok fazla anlamsız metric bakım yükü yaratır. Kritik göstergeler service objective ile ilişkilendirilmelidir. Naming ve label standardı merkezi hale getirilebilir.

Tracing

Distributed tracing servisler arası latency ve dependency sorunlarını görmeyi kolaylaştırır. Her request'i tam örneklemek maliyetli olabilir. Sampling stratejisi sistem hacmine göre seçilmelidir. Hassas veri trace içine yazılmamalıdır. Ortak instrumentation library adoption'ı hızlandırır.

Alerts

Alert gerçek müdahale gerektiren durumu temsil etmelidir. Sürekli false positive üreten alarm kısa sürede göz ardı edilir. User impact ve SLO ihlali iyi trigger olabilir. Alert owner ve runbook bağlantısı içermelidir. Düzenli alert review gürültüyü azaltır.

Dashboard

Dashboard servis health durumunu hızlı göstermelidir. Her metriği tek ekrana koymak okunabilirliği azaltır. Golden signals veya domain-specific göstergeler kullanılabilir. Release sırasında ilgili dashboard kolayca erişilebilir olmalıdır. Dashboard owner bilgisi tutulmalıdır.

SLI / SLO

SLI ölçülen servis göstergesini, SLO ise hedef seviyeyi ifade eder. Availability ve latency buna örnek olabilir. Hedefler gerçek kullanıcı ihtiyacına dayanmalıdır. Her servis için yüzde 99.99 zorunluluğu gereksiz maliyet yaratabilir. Error budget yaklaşımı delivery ve reliability arasında denge sağlayabilir.

Documentation Guidelines

Dokümantasyonun amacı bilgi üretmek değil, doğru bilgiyi ihtiyaç anında erişilebilir hale getirmektir. README, API documentation, ADR ve runbook farklı ihtiyaçlara hizmet eder. Her doküman türünün owner'ı ve güncelleme tetikleyicisi olmalıdır. Kod ile birlikte değişmesi gereken belgeler aynı pull request içinde güncellenebilir. Docs-as-code yaklaşımı bu süreci kolaylaştırır.

README

README projenin hızlı başlangıç belgesidir. Purpose, setup, run, test ve owner bilgileri temel içerik olabilir. Uzun mimari açıklamalar ayrı dokümana taşınabilir. Komutların güncel olması önemlidir. Yeni çalışan deneyimi üzerinden düzenli olarak test edilebilir.

API Documentation

API documentation consumer'ın entegrasyon yapmasını sağlar. Endpoint, schema, error ve authentication bilgileri bulunmalıdır. Mümkün olduğunda source code üzerinden otomatik üretilebilir. Breaking change açıkça işaretlenmelidir. Örnek request ve response kullanım kolaylığı sağlar.

Architecture Documentation

Architecture documentation sistemin ana bileşenlerini ve ilişkilerini açıklar. Çok ayrıntılı diagram kısa sürede eskiyebilir. Context ve container seviyesinde basit görseller çoğu zaman yeterlidir. Kritik dependency ve data flow gösterilmelidir. Doküman gerçek sistem değiştiğinde güncellenmelidir.

ADR

ADR önemli mimari kararın nedenini saklar. Kararın tarihi ve durumu görünür olmalıdır. Superseded kararlar silinmemeli, yeni ADR ile ilişkilendirilmelidir. Kısa format kullanım kolaylığı sağlar. Böylece geçmiş teknik kararların bağlamı kaybolmaz.

Runbook

Runbook operasyonel olaylarda izlenecek pratik adımları açıklar. Alert'ten doğrudan ilgili runbook'a bağlantı verilebilir. Komutlar ve escalation bilgileri güncel tutulmalıdır. Kritik runbook'lar game day sırasında test edilebilir. Owner ve last review tarihi görünür olmalıdır.

Troubleshooting Guide

Troubleshooting Guide tekrar eden sorunları çözme yöntemlerini toplar. Belirti, olası neden ve çözüm adımları kullanılabilir. Support ticket verileri yeni içerik için kaynak olabilir. Çözümler çalışmıyorsa belge güncellenmelidir. İyi rehber support bağımlılığını azaltır.

User Documentation

User Documentation ürünün nasıl kullanılacağını son kullanıcı açısından açıklar. Teknik detay yerine görev odaklı anlatım tercih edilir. Ürün değişiklikleriyle birlikte güncellenmelidir. Geri bildirim ve support soruları belge iyileştirmesine veri sağlar. Sahiplik product veya ilgili ekip tarafından üstlenilebilir.

Documentation Owner

Her önemli dokümanın owner'ı bulunmalıdır. Owner bilginin güncel kalmasını sağlar. Yazarı değişse bile sahiplik devam eder. Review tarihi yaklaşırken otomatik bildirim kullanılabilir. Sahipsiz dokümanlar guideline debt olarak izlenebilir.

Dokümantasyonun Tek Doğru Kaynağı Nasıl Oluşturulur?

Tek doğru kaynak yaklaşımı aynı kuralın farklı sistemlerde farklı sürümlerinin oluşmasını önler. Bunun için şirketin resmi dokümantasyon kaynağı açık biçimde tanımlanmalıdır. Wiki, Git repository veya developer portal seçeneklerinden biri merkezi referans olabilir. Diğer sistemler kopya üretmek yerine ana kaynağa bağlantı vermelidir. Böylece shadow documentation riski azalır.

Single Source of Truth

Single Source of Truth her resmi bilginin tek otoriter kaynağını belirtir. Aynı guideline'ın üç wiki sayfasında kopyalanması önlenmelidir. Diğer sayfalar canonical kaynağa yönlendirme yapabilir. Version bilgisi bu kaynağa bağlıdır. Böylece ekip hangi belgenin güncel olduğunu sorgulamak zorunda kalmaz.

Confluence

Confluence ekipler için erişilebilir merkezi wiki sağlayabilir. Arama ve sayfa organizasyonu avantaj sunar. Ancak kodla ilişkili belgelerde güncelleme disiplini zayıflayabilir. Owner ve review date metadata'sı kullanılmalıdır. Kritik guideline'lar için Git tabanlı review süreci ayrıca değerlendirilebilir.

Git Repository

Git repository guideline'ları version-controlled tutmak için uygundur. Değişiklikler pull request üzerinden review edilebilir. History doğal olarak korunur. Developer'lar mevcut araçlarıyla katkı yapabilir. Otomatik site generation ile okunabilir portal oluşturulabilir.

Internal Developer Portal

Internal Developer Portal guideline, service catalog ve ownership bilgisini tek yerde birleştirebilir. Developer hangi repository'nin hangi kurallara tabi olduğunu doğrudan görebilir. Search ve tagging kullanım kolaylığı sağlar. Otomatik compliance score da aynı ekranda gösterilebilir. Portal kaynak olmaktan çok farklı kaynakları bir araya getiren arayüz olabilir.

Dağınık Dokümantasyonu Önlemek

Her ekip farklı yerde doküman tutarsa bilgi bulmak zorlaşır. Merkezi katalog ve naming standardı bu problemi azaltır. Eski alanlar deprecated edilip yeni kaynağa yönlendirilebilir. Search sonuçlarında eski içerik görünmemelidir. Düzenli dead-link ve orphan page kontrolü yapılabilir.

Shadow Documentation Problemi

Shadow documentation resmi kaynağın dışında oluşan kopya bilgidir. Chat mesajı, kişisel not veya eski sunum zamanla “gerçek kural” gibi kullanılabilir. Bunun nedeni resmi belgenin bulunmasının zor olması olabilir. Canonical link paylaşımı teşvik edilmelidir. Resmi guideline kolay erişilebilir olduğunda shadow kaynak ihtiyacı azalır.

Guideline'lar Nerede Saklanmalı?

Guideline saklama yeri ekiplerin çalışma biçimine yakın olmalıdır. Kullanıcı kuralı bulmak için birden fazla sistem arasında dolaşmamalıdır. Wiki kullanım kolaylığı, Git güçlü version control, developer portal ise keşfedilebilirlik sağlar. Hibrit model de kullanılabilir. Önemli olan canonical kaynağın açık ve aranabilir olmasıdır.

Wiki

Wiki teknik olmayan paydaşlar için kolay katkı imkanı sağlar. Rich text düzenleme onboarding maliyetini düşürür. Ancak review ve version süreçleri dikkatli kurulmalıdır. Owner ve review date görünür tutulmalıdır. Teknik guideline'lar code review akışına yakınlaştırılabilir.

Git Repository

Git teknik ekipler için doğal contribution modeli sunar. Markdown belgeler pull request ile değiştirilebilir. CODEOWNERS guideline review için kullanılabilir. Otomatik lint ve link checking eklenebilir. Version history güvenilir biçimde korunur.

Developer Portal

Developer Portal farklı guideline kaynaklarını tek arayüzde gösterebilir. Kullanıcı takım veya repository seçerek ilgili kuralları filtreleyebilir. Search ve tagging erişimi hızlandırır. Scorecard ve ownership bilgisi aynı yerde sunulabilir. Böylece portal günlük çalışma noktası haline gelir.

Docs-as-Code

Docs-as-Code dokümantasyonu kod benzeri geliştirme süreciyle yönetir. Markdown, Git, pull request ve CI kullanılır. Review ve version history standart hale gelir. Otomatik yayınlama süreç maliyetini azaltır. Teknik guideline sistemleri için özellikle uygundur.

Merkezi Katalog + Repository-Specific Kurallar

Merkezi katalog company-wide kuralları barındırabilir. Repository-specific kurallar yerel bağlamı açıklayabilir. İki seviye arasındaki precedence açıkça tanımlanmalıdır. Üst seviye zorunlu security kuralı yerel belgeyle devre dışı bırakılamamalıdır. Developer portal her iki kaynağı birlikte gösterebilir.

Aranabilirlik

Guideline bulunamıyorsa pratikte yok kabul edilebilir. Search title kadar keyword ve tag alanlarını da kullanmalıdır. Eski veya deprecated belgeler sonuçlarda açık biçimde işaretlenmelidir. Synonym desteği geliştiricilerin farklı terimlerle arama yapmasına yardımcı olur. Search analytics eksik içerikleri gösterebilir.

Docs-as-Code Yaklaşımı

Docs-as-Code dokümantasyonun yazılım geliştirme prensipleriyle yönetilmesini sağlar. Markdown dosyaları Git içinde saklanır ve değişiklikler pull request üzerinden review edilir. CI link, format ve bazı içerik kontrollerini çalıştırabilir. Merge sonrasında doküman otomatik yayınlanabilir. Bu model guideline yönetimini geliştiricilerin günlük akışına yakınlaştırır.

Markdown

Markdown sade ve version-control dostu format sağlar. Diff üzerinden değişiklikler kolayca görülebilir. Çoğu developer tool tarafından desteklenir. Gereksiz karmaşık editör bağımlılığını azaltır. Otomatik site generator ile okunabilir arayüze dönüştürülebilir.

Git

Git dokümantasyon değişikliklerinin geçmişini tutar. Kimin hangi değişikliği ne zaman yaptığı görülebilir. Branch ve pull request modeli review sağlar. Tag veya release ile version oluşturulabilir. Böylece belge yaşam döngüsü daha güvenilir hale gelir.

Pull Request Review

Guideline değişikliği PR üzerinden ilgili owner'lara gösterilebilir. CODEOWNERS otomatik reviewer atayabilir. Discussion kayıt altında kalır. Breaking değişiklikler daha geniş review gerektirebilir. Minor editorial düzenlemeler hafif süreçle ilerleyebilir.

Version History

Version history kuralın zaman içinde nasıl değiştiğini gösterir. Eski davranışın neden değiştirildiğini anlamak kolaylaşır. Incident veya RFC bağlantıları commit mesajına eklenebilir. Kullanıcı belirli tarihte hangi kuralın geçerli olduğunu görebilir. Audit gereksinimleri açısından da faydalıdır.

Automated Publishing

Merge edilen değişiklik otomatik olarak dokümantasyon sitesine yayınlanabilir. Manuel kopyalama ihtiyacı ortadan kalkar. Preview environment review sırasında içerik görünümünü kontrol etmeyi sağlar. Failed build yayınlamayı durdurabilir. Böylece kaynak ile yayınlanan içerik arasında drift azalır.

Link Checking

Dead link'ler dokümantasyon güvenini azaltır. CI içinde link checker çalıştırılabilir. Internal ve external bağlantılar farklı kurallarla kontrol edilebilir. Geçici network hataları uygun retry ile yönetilmelidir. Broken link owner'a otomatik issue olarak atanabilir.

Documentation Tests

Documentation test kod örneklerinin çalışıp çalışmadığını kontrol edebilir. Command snippet veya configuration schema doğrulanabilir. Bu yaklaşım özellikle geliştirici rehberlerinde faydalıdır. Her doküman otomatik test edilemeyebilir. Yüksek değerli örnekler önceliklendirilmelidir.

Guidelines-as-Code Nedir?

Guidelines-as-Code, yazılı kuralların mümkün olan kısmını makine tarafından kontrol edilebilir hale getiren yaklaşımdır. Amaç insan dokümanını ortadan kaldırmak değildir. İnsan açıklaması ve otomatik enforcement aynı kuralın iki yüzü olarak düşünülür. Böylece geliştirici neyin neden engellendiğini görebilir. CI, repository policy ve policy engine bu yaklaşımın temel araçlarıdır.

İnsan Tarafından Okunan Kural

İnsan dokümanı kuralın amacı ve bağlamını açıklar. Geliştirici yalnızca error mesajı görmemelidir. Rationale, örnek ve exception süreci belge içinde bulunmalıdır. Bu bilgi öğrenme ve mühendislik yargısı için gereklidir. Otomasyon insan açıklamasının yerine geçmez.

Makine Tarafından Kontrol Edilen Kural

Makine kontrolü net şartları otomatik doğrular. Formatting, branch protection ve dependency scan buna örnek olabilir. Sonuç hızlı ve tutarlı olur. Manuel reviewer aynı kontrolü tekrar yapmak zorunda kalmaz. Böylece insan zamanı daha yüksek değerli kararlara ayrılır.

Tek Kaynaktan İnsan ve Otomasyon

En güçlü model kural tanımının insan ve makine tarafında drift etmesini önlemektir. Metadata veya merkezi policy kaynağı kullanılabilir. Dokümantasyon hangi otomatik kontrolün ilgili kuralı uyguladığını göstermelidir. Kontrol değiştiğinde belge de aynı değişiklik içinde güncellenmelidir. Böylece iki gerçeklik oluşmaz.

CI Entegrasyonu

CI guideline enforcement için doğal noktadır. Lint, test, security scan ve policy check pull request aşamasında çalışabilir. Hata mesajı ilgili guideline bağlantısını göstermelidir. Otomatik fix varsa doğrudan önerilebilir. Böylece geliştirici sorunu çözmek için başka yerde araştırma yapmak zorunda kalmaz.

Policy Engines

Policy engine infrastructure veya deployment kurallarını kod olarak ifade edebilir. Resource configuration belirli şartlara göre doğrulanabilir. Merkezi policy değişikliği geniş scope'a uygulanabilir. Ancak yanlış policy büyük sayıda ekibi etkileyebilir. Bu nedenle test ve staged rollout önemlidir.

Repository Rules

Repository rules branch protection, required review ve status check gibi kontrolleri otomatik uygular. Yeni repository açıldığında varsayılan politika devreye girebilir. Risk seviyesine göre rule set değişebilir. Manuel ayar farkları azaltılır. Compliance merkezi olarak izlenebilir.

Hangi Guideline'lar Otomatikleştirilebilir?

Tekrarlanabilir ve açık koşula sahip guideline'lar otomasyon için güçlü adaydır. Formatting, lint, branch protection ve security scan gibi alanlarda makine kontrolü insan review'undan daha tutarlı olabilir. Otomasyon geliştiriciyi cezalandırmak yerine doğru davranışa yönlendirmelidir. Error mesajları çözüm adımını açıklamalıdır. Otomatik fix bulunduğunda adoption daha da kolaylaşır.

Formatting

Formatting tamamen otomatik hale getirilebilir. Standard formatter repository içinde config ile tutulabilir. Pre-commit veya CI çalıştırılabilir. Reviewer format yorumu yapmak zorunda kalmaz. Geliştirici IDE entegrasyonu ile otomatik düzeltme kullanabilir.

Lint

Lint birçok coding rule'u otomatik kontrol eder. Severity seviyeleri warning ve error olarak ayrılabilir. Yeni rule önce warning modunda pilot edilebilir. False positive oranı takip edilmelidir. Gereksiz gürültü lint'e olan güveni azaltır.

Branch Protection

Branch protection merkezi repository policy ile otomatik uygulanabilir. Direct push, review ve status check şartları tanımlanabilir. Yeni repository oluşturulduğunda rule otomatik bağlanabilir. Exception kontrollü şekilde verilebilir. Böylece manuel ayar hatası azalır.

Required Review

Required review platform seviyesinde kontrol edilebilir. Minimum reviewer sayısı risk profile göre belirlenebilir. CODEOWNER alanları için ek review gerekebilir. Bot veya self-approval şartları ayrıca düzenlenebilir. Kuralın geliştiriciye neden uygulandığı gösterilmelidir.

Dependency Scan

Dependency scan bilinen vulnerability ve lisans risklerini otomatik bulabilir. Severity threshold merkezi standarda bağlanabilir. Critical bulgular merge engeli olabilir. Düşük riskli bulgular backlog'a otomatik eklenebilir. Exception süreli olarak kaydedilmelidir.

Security Scan

Static, dynamic ve secret scan farklı riskleri kontrol eder. Hepsini her projede aynı şekilde çalıştırmak gerekli olmayabilir. Risk profiline göre scan seti belirlenebilir. Sonuçlar developer'ın anlayacağı biçimde sunulmalıdır. False positive feedback loop kurulmalıdır.

Test

Test suite pull request ve release pipeline içinde otomatik çalıştırılabilir. Gerekli test seti değişiklik tipine göre seçilebilir. Flaky test'ler güveni azaltacağı için ayrı takip edilmelidir. Başarısız test merge'i engelleyebilir. Test süresi developer experience KPI olarak izlenebilir.

License Check

Dependency lisansları otomatik policy ile karşılaştırılabilir. Approved ve restricted license listeleri merkezi tutulabilir. Yeni riskli lisans bulunduğunda review tetiklenebilir. Legal kararlar policy listesine dönüştürülebilir. Böylece her dependency için manuel kontrol gerekmez.

Infrastructure Policy

Infrastructure configuration policy engine ile doğrulanabilir. Public access, encryption ve tagging gibi kurallar otomatik kontrol edilebilir. Pull request aşamasında feedback verilmesi production hatasını azaltır. Policy testleri de yazılmalıdır. Büyük değişiklikler staged rollout ile uygulanmalıdır.

Deployment Policy

Deployment policy environment ve risk seviyesine göre otomatik gate uygulayabilir. Production için belirli test ve approval şartları aranabilir. Emergency flow ayrı policy ile tanımlanabilir. Deployment artifact ve source commit doğrulanabilir. Audit trail otomatik üretilir.

Hangi Guideline'lar İnsan Kararı Gerektirir?

Her mühendislik kararı makine tarafından değerlendirilemez. Architecture trade-off, product kararı ve ethics gibi alanlar bağlam gerektirir. Otomasyon bu kararlara veri sağlayabilir ancak nihai hüküm insan yargısına ihtiyaç duyar. Bu tür guideline'lar kontrol listesinden çok düşünme çerçevesi sunmalıdır. Reviewer'a hangi soruları değerlendireceğini anlatmak daha faydalıdır.

Architecture Trade-Off

Architecture kararları maliyet, performans ve bakım gibi birden fazla faktörü dengeler. Tek bir lint kuralı bu değerlendirmeyi yapamaz. Guideline sorulması gereken soruları ve tercih edilen pattern'leri sunabilir. Büyük kararlar architecture review veya ADR ile değerlendirilebilir. Sonuç bağlama göre değişebilir.

Product Decision

Product kararı kullanıcı değeri ve iş önceliğine dayanır. Teknik metrikler karar için veri sağlayabilir. Ancak hangi özelliğin yapılacağı otomatik rule ile belirlenemez. Guideline karar prensiplerini açıklayabilir. Son sorumluluk ilgili product ve business owner'da kalmalıdır.

UX

UX değerlendirmesi kullanıcı davranışı ve bağlam gerektirir. Accessibility gibi bazı kurallar otomatik kontrol edilebilir. Ancak bütün deneyimin iyi olup olmadığını tek araç belirleyemez. Design review ve kullanıcı testi gerekebilir. Guideline minimum accessibility ve design prensiplerini tanımlayabilir.

Karmaşık Security Risk

Bazı security riskleri yalnızca scanner çıktısıyla değerlendirilemez. Threat model ve business context gerekir. Security expert farklı compensating control seçeneklerini inceleyebilir. Exception kararı bu nedenle insan review'u gerektirebilir. Risk kaydı ileride tekrar değerlendirme için saklanmalıdır.

Yeni Teknoloji

Yeni teknoloji adoption kararı çok boyutludur. Performance, bakım, security ve ekip yetkinliği birlikte değerlendirilir. Otomatik metrikler veri sağlar ancak nihai kararı vermez. RFC ve pilot süreci bu yüzden önemlidir. Karar daha sonra technology radar'a işlenebilir.

Exception

Exception özel bağlam içerir. Otomatik sistem talebi kaydedebilir ancak business ve technical justification değerlendirmesi insan ister. Risk, süre ve compensating control incelenmelidir. Approver rolü açık olmalıdır. Tekrarlanan exception'lar guideline review tetikleyebilir.

Ethics

Ethics kararları yalnızca teknik uygunluk üzerinden verilemez. Kullanıcı etkisi, adalet ve sosyal sonuçlar değerlendirilebilir. Şirket ilkeleri düşünme çerçevesi sağlayabilir. Hassas konularda farklı disiplinlerden görüş alınabilir. Kararlar ve gerekçeler uygun seviyede kayıt altına alınmalıdır.

Guideline ile Guardrail Arasındaki Fark

Guideline davranışı açıklar, guardrail ise belirli davranışı sistem seviyesinde yönlendirir veya sınırlar. Her guideline guardrail olmak zorunda değildir. Otomasyona uygun net kurallar guardrail'e dönüştürülebilir. İnsan yargısı gereken alanlar yazılı guidance olarak kalabilir. Warning, soft gate ve hard gate seviyeleri risk bazlı seçilmelidir.

Yazılı Tavsiye

Yazılı tavsiye tercih edilen davranışı anlatır. Uygulama geliştiricinin kararına bırakılabilir. Rationale ve örnekler öğrenmeyi destekler. SHOULD veya MAY seviyesinde kullanılabilir. Her tavsiye için otomatik kontrol gerekmez.

Otomatik Guardrail

Otomatik guardrail belirli kuralı tool seviyesinde uygular. Branch protection veya secret scan buna örnektir. Kullanıcı hatasını erken aşamada önler. Hata mesajı guideline ve çözüm bağlantısını göstermelidir. Guardrail gereksiz friction üretmemelidir.

Warning

Warning geliştiriciyi potansiyel problem hakkında bilgilendirir. Merge veya deployment'ı engellemez. Yeni kuralların pilot aşamasında faydalıdır. Warning oranı ve developer feedback izlenebilir. Kural olgunlaştığında daha güçlü gate'e geçilebilir.

Soft Gate

Soft gate işlem için ek onay veya gerekçe isteyebilir. Tam engel oluşturmaz. Orta riskli durumlarda esneklik sağlar. Exception veya acknowledgement kaydı tutulabilir. Çok sık tetikleniyorsa kural yeniden değerlendirilmelidir.

Hard Gate

Hard gate şart sağlanmadığında işlemi durdurur. Critical security veya compliance kurallarında gerekli olabilir. Her kuralın hard gate olması developer friction yaratır. False positive oranı çok düşük tutulmalıdır. Bypass süreci kontrollü ve kayıtlı olmalıdır.

Risk Bazlı Enforcement

Enforcement seviyesi riskle orantılı olmalıdır. Düşük riskli stil kuralı warning olabilir. Kritik secret exposure hard gate gerektirebilir. Risk seviyesi proje metadata'sından otomatik okunabilir. Böylece aynı rule farklı project profile'da farklı davranabilir.

Doğru Davranışı En Kolay Yol Haline Getirmek

Guideline adoption'ını artırmanın en etkili yollarından biri doğru davranışı varsayılan hale getirmektir. İnsanlara otuz sayfa kural okutmak yerine starter repository ve hazır CI sunulabilir. Approved library ve scaffolding de aynı amaca hizmet eder. Geliştirici güvenli ve doğru yöntemi kullanmak için ekstra çaba harcamıyorsa compliance doğal olarak artar. Bu yaklaşım developer experience ile governance'ı bir araya getirir.

Starter Repository

Starter repository temel dosya ve ayarları hazır sağlar. Branch protection, CI ve README template başlangıçtan itibaren bulunabilir. Ekipler her projede aynı kurulumu tekrar yapmaz. Merkezi template güncellendiğinde yeni projeler otomatik iyileşir. Legacy projeler için migration aracı sağlanabilir.

Project Template

Project template teknoloji stack'ine göre hazır proje yapısı sunar. Logging, testing ve configuration pattern'leri önceden eklenebilir. Guideline'ın doğru örneği doğrudan çalışan kod içinde gösterilir. Developer'ın başlangıç süresi azalır. Template version yönetimi önemlidir.

Golden Path

Golden Path en sık kullanılan proje türü için desteklenen ideal yolu tanımlar. Zorunlu tek seçenek olmak yerine en kolay ve desteklenen yol olmalıdır. Platform tooling, template ve observability hazır gelir. Ekip farklı yol seçebilir ancak ek bakım maliyetini sahiplenir. Bu model merkezi standardizasyonu doğal hale getirir.

Scaffolding

Scaffolding komut veya portal üzerinden yeni proje bileşenleri üretir. Dosya yapısı, CI ve metadata otomatik hazırlanabilir. İnsan hatası azalır. Guideline güncellemeleri generator'a aktarılabilir. Böylece doğru davranış dokümandan gerçek çıktıya dönüşür.

Preconfigured CI

Preconfigured CI temel build, test ve security adımlarını hazır sunar. Ekipler pipeline syntax öğrenmek zorunda kalmadan başlayabilir. Risk seviyesine göre modüller otomatik eklenebilir. Merkezi güncellemeler versioned template ile dağıtılabilir. Developer yalnızca proje özelindeki adımlara odaklanır.

Approved Libraries

Approved library listesi tekrar eden teknik kararları azaltır. Authentication, logging veya retry için desteklenen package'lar belirlenebilir. Bu library'ler security ve maintenance açısından düzenli review edilir. Kullanım örnekleri starter project içinde bulunabilir. Ekip farklı library kullanmak isterse RFC süreci uygulanabilir.

Self-Service Platform

Self-Service Platform geliştiricinin onay beklemeden standart kaynak oluşturmasını sağlar. Repository, database veya deployment environment birkaç adımla hazırlanabilir. Arkadaki guardrail güvenlik ve naming kurallarını otomatik uygular. Böylece governance hızın karşıtı olmaktan çıkar. Platform usage verisi guideline adoption hakkında da sinyal verir.

Otomatik Fix

Bir kural ihlal edildiğinde yalnızca hata göstermek yerine otomatik düzeltme sunmak güçlü developer experience sağlar. Formatter bunun en basit örneğidir. Dependency update veya config migration için de bot kullanılabilir. Fix güvenli olduğunda tek tıkla uygulanabilir. Bu yaklaşım manuel compliance süresini azaltır.

Guideline Pilot Süreci

Pilot süreci geniş rollout öncesinde kuralın gerçek etkisini görmek için kullanılır. Küçük ve temsil edici birkaç takım seçilebilir. Baseline ölçümü alınarak guideline sonrası değişim takip edilir. Developer friction ve beklenmeyen sonuçlar özellikle not edilmelidir. Pilot sonuçları taslağın revize edilmesi için veri sağlar.

Pilot Takım Seçimi

Pilot takım yalnızca guideline'ı yazan ekip olmamalıdır. Farklı deneyim ve proje tiplerinden temsil alınması faydalıdır. Takım feedback vermeye istekli olmalıdır. Çok kritik production sistemi ilk pilot için uygun olmayabilir. Sonuçların genellenebilir olması önemlidir.

Mevcut Durum Ölçümü

Pilot öncesinde baseline alınmalıdır. Review süresi, incident, compliance veya manuel işlem süresi ölçülebilir. Baseline olmadan iyileşmeyi kanıtlamak zordur. Her guideline için farklı metrik seçilebilir. Ölçüm kolay ve düşük maliyetli olmalıdır.

Yeni Guideline'ın Uygulanması

Pilot takıma guideline ve amacı açıkça anlatılmalıdır. Gerekli araç ve template hazır olmalıdır. Enforcement başlangıçta warning modunda çalıştırılabilir. Sorular hızlı şekilde cevaplanmalıdır. Pilot gerçek iş akışı içinde yapılmalıdır.

Developer Feedback

Developer feedback pilotun temel çıktılarından biridir. Kural anlaşılır mı, kolay uygulanıyor mu ve gereksiz iş üretiyor mu soruları sorulmalıdır. Yalnızca memnuniyet değil, gerçek örnekler toplanmalıdır. Anonymous feedback kanalı faydalı olabilir. Sonuçlar review sırasında açıkça değerlendirilmelidir.

Oluşan Friction

Friction yeni kuralın getirdiği ek zaman ve zihinsel yükü gösterir. Approval bekleme, uzun pipeline veya zor exception süreci buna örnektir. Bu maliyet ölçülmelidir. Kuralın azalttığı risk ile karşılaştırılmalıdır. Gereksiz friction azaltılmadan rollout yapılmamalıdır.

Beklenmeyen Sonuçlar

Yeni guideline bazen ekipleri istenmeyen workaround'lara yönlendirebilir. Örneğin ağır review süreci insanların büyük PR'ları daha seyrek açmasına yol açabilir. Bu etkiler pilotta gözlemlenmelidir. Metrikler tek başına yeterli olmayabilir. Nitel feedback beklenmeyen davranışları ortaya çıkarır.

Guideline'ın Revize Edilmesi

Pilot sonunda guideline değiştirilebilir. Requirement level düşürülebilir veya scope daraltılabilir. Otomatik kontrolün hata mesajı iyileştirilebilir. Bazı maddeler tamamen kaldırılabilir. Pilotun amacı ilk taslağı doğrulamak değil, daha iyi kural üretmektir.

Guideline Onay Süreci

Onay süreci riskle uyumlu olmalıdır. Her guideline'ın tüm yönetim katmanlarından geçmesi gerekmez. Peer review ve konu uzmanı değerlendirmesi çoğu teknik kural için yeterli olabilir. Security veya legal etkisi varsa ilgili uzmanlar sürece eklenir. Leadership approval yalnızca geniş organizasyonel veya önemli risk etkisi bulunduğunda kullanılmalıdır.

Peer Review

Peer review taslağın başka mühendisler tarafından değerlendirilmesini sağlar. Belirsiz cümleler ve uygulanabilirlik sorunları erken bulunabilir. Yazarın göremediği edge case'ler ortaya çıkar. Review yorumları Git üzerinde kayıtlı tutulabilir. En az bir peer review iyi varsayılan olabilir.

Subject Matter Expert Review

SME review teknik doğruluk için kullanılır. Security, database veya observability gibi özel uzmanlık gerektiren konularda önemlidir. Her guideline'a her SME dahil edilmemelidir. Konuya göre gerekli uzman seçilmelidir. Böylece süreç gereksiz büyümez.

Architecture Review

Architecture review şirket genelindeki service boundary veya teknoloji seçimlerini etkileyen kurallar için gerekebilir. Küçük coding standardı bu sürece ihtiyaç duymaz. Review mevcut architecture principle'larla uyumu değerlendirir. Büyük trade-off'lar kayıt altına alınır. Review komitesi darboğaz oluşturmamalıdır.

Security Review

Security review hassas veri veya access control gibi alanlarda uygulanır. Security ekibi kuralın gerçek riski azaltıp azaltmadığını değerlendirir. Developer experience maliyeti de dikkate alınmalıdır. Otomatik control fırsatları belirlenebilir. Sonuç ve exception yaklaşımı kaydedilmelidir.

Legal / Compliance Review

Legal veya compliance review yalnızca gerçekten yasal veya düzenleyici etki bulunan konularda kullanılmalıdır. Open source license, kişisel veri veya regüle süreçler buna örnektir. Her teknik guideline'ı bu onaya bağlamak gereksiz gecikme yaratır. Gerçek zorunluluk ile kurum tercihi ayrılmalıdır. Böylece ekip neyin neden required olduğunu anlayabilir.

Final Owner Approval

Final Owner Approval guideline'ın yayınlanmaya hazır olduğunu doğrular. Owner review sonuçlarının işlendiğini kontrol eder. Scope, version ve effective date tamamlanmış olmalıdır. Enforcement ve communication plan hazır olmalıdır. Approval kaydı version history içinde tutulabilir.

Leadership Approval Ne Zaman Gereklidir?

Leadership approval geniş organizasyonel etki veya önemli yatırım gerektiren değişikliklerde kullanılabilir. Örneğin şirket genelindeki yeni deployment platformu buna dahil olabilir. Küçük teknik standardlar için yöneticiyi zorunlu reviewer yapmak süreci yavaşlatır. Approval threshold önceden tanımlanmalıdır. Böylece governance öngörülebilir olur.

RFC ile Guideline Hazırlama

RFC, geniş etkiye sahip guideline değişikliklerini açık tartışmaya açmak için etkili yöntemdir. Problem, proposal, alternatives ve trade-off'lar aynı belgede toplanır. Ekipler belirli discussion period içinde yorum yapabilir. Nihai karar ve gerekçe daha sonra kayıt altında tutulur. Bu yaklaşım özellikle yeni teknoloji ve architecture standartlarında faydalıdır.

Request for Comments Nedir?

Request for Comments önerinin karar verilmeden önce topluluk görüşüne açıldığı süreçtir. Amaç herkesin veto hakkına sahip olması değildir. İlgili uzmanların risk ve fırsatları görünür hale getirmesidir. RFC formatı kısa ve standart tutulmalıdır. Süreç sonunda karar verecek rol belli olmalıdır.

Problem

RFC problem bölümü çözülmek istenen durumu açıklar. Mevcut süreçteki maliyet veya risk belirtilmelidir. Çözüm önerisi problem tanımına karışmamalıdır. Veri ve örnek kullanmak tartışmayı güçlendirir. Problem üzerinde uzlaşma çözüm tartışmasını kolaylaştırır.

Proposal

Proposal önerilen guideline veya teknik yaklaşımı açıklar. Scope ve beklenen davranış belirtilir. Enforcement planı varsa eklenir. Migration ihtiyacı değerlendirilir. Taslak karar olarak görülmeli, feedback'e açık olmalıdır.

Alternatives

Alternatives bölümü değerlendirilen diğer seçenekleri gösterir. Hiçbir değişiklik yapmamak da bir alternatif olabilir. Her seçeneğin artı ve eksi yönleri yazılır. Bu bölüm karar kalitesini artırır. Gelecekte neden belirli yolun seçildiğini anlamayı kolaylaştırır.

Trade-Offs

Her guideline bir maliyet ve fayda dengesi yaratır. Daha güçlü security kontrolü deployment süresini artırabilir. Daha esnek teknoloji seçimi bakım maliyetini yükseltebilir. Trade-off'ların açık yazılması tartışmayı gerçekçi hale getirir. Tek taraflı fayda anlatımı güveni azaltabilir.

Impact

Impact hangi takım, repository ve süreçlerin etkileneceğini açıklar. Migration maliyeti burada değerlendirilebilir. Developer training ihtiyacı belirtilir. Risk seviyesine göre rollout planı hazırlanabilir. Etki analizi approval kararını destekler.

Discussion Period

Discussion period geri bildirim için belirli süre sağlar. Çok kısa süre ekiplerin katkısını engelleyebilir. Çok uzun süre kararı gereksiz geciktirebilir. Değişiklik büyüklüğüne göre süre seçilmelidir. Kritik security emergency durumunda daha hızlı süreç kullanılabilir.

Decision

RFC sonunda karar açık biçimde yazılmalıdır. Accepted, rejected veya revised gibi status kullanılabilir. Kararı veren kişi veya grup görünür olmalıdır. Ana gerekçe birkaç cümleyle özetlenmelidir. Böylece tartışma sonsuza kadar açık kalmaz.

Decision Record

Decision Record geçmiş kararların bulunmasını sağlar. RFC veya ADR repository içinde saklanabilir. Superseded kararlar silinmemelidir. Yeni karar eski kayıtla ilişkilendirilmelidir. Bu yaklaşım kurumsal hafızayı güçlendirir.

Guideline'ın Ekiplerle Birlikte Yazılması Neden Önemlidir?

Ekiplerin katkı sağlamadığı merkezi guideline'lar çoğu zaman düşük adoption üretir. Çünkü günlük iş akışındaki sorunlar belgenin dışında kalabilir. Developer katılımı hem kaliteyi hem sahiplenmeyi artırır. Workshop, RFC ve pilot bu katılım için pratik yöntemlerdir. Merkezi ekip son kararı verebilir ancak saha geri bildirimini aktif şekilde kullanmalıdır.

Merkezi Dayatma Problemi

Merkezi ekip gerçek kullanım bağlamını görmeden kural yazarsa gereksiz friction oluşabilir. İnsanlar nedenini anlamadığı kuralı workaround ile aşmaya çalışabilir. Bu durum compliance oranını görünürde yüksek tutarken gerçek davranışı bozabilir. Erken feedback bu riski azaltır. Governance güvene dayalı olmalıdır.

Developer Katılımı

Developer'lar tekrar eden problemleri günlük işte doğrudan görür. Bu nedenle kural tasarımında güçlü veri sağlar. Katılım yalnızca review istemekle sınırlı olmamalıdır. Problem discovery ve pilot aşamasında da ekiplerden görüş alınmalıdır. Böylece guideline gerçek süreçlere uyum sağlar.

Guild / Community of Practice

Guild farklı takımlardaki benzer uzmanları bir araya getirir. Ortak sorunlar burada tartışılabilir. Guideline taslakları peer review alabilir. Bilgi tek merkezi ekipte toplanmaz. Dağıtık ownership adoption'ı güçlendirir.

Workshop

Workshop belirsiz konularda ortak karar üretmek için etkilidir. Gerçek case'ler üzerinden tartışma yapılabilir. Farklı ekiplerin ihtiyaçları görünür hale gelir. Sonuçlar doğrudan taslağa dönüştürülebilir. Workshop tek başına karar mekanizması olmak zorunda değildir.

RFC

RFC daha geniş ve kayıtlı tartışma sağlar. Async contribution farklı saatlerde çalışan ekipler için faydalıdır. Proposal ve alternatives açık biçimde görülebilir. Karar sonrası tartışma geçmişi korunur. Bu yöntem büyük değişikliklerde şeffaflığı artırır.

Pilot

Pilot gerçek kullanım üzerinden öğrenme sağlar. Ekiplerin yalnızca tahmini görüşüne değil, gerçek davranış verisine bakılır. Friction ve exception noktaları görünür olur. Guideline revize edilir. Daha sonra rollout daha güvenli yapılır.

Adoption'ın Artması

İnsanlar katkı sağladığı kararı daha kolay benimser. Bu yalnızca psikolojik sahiplenme değildir. Kuralın gerçek ihtiyaca daha uygun hale gelmesi adoption'ı artırır. Açık communication ve araç desteği bu etkiyi güçlendirir. Adoption ölçümleri pilot ve rollout sonrasında takip edilmelidir.

Engineering Guild Modeli

Engineering Guild modeli farklı takımlardaki uzmanları ortak teknik konular etrafında birleştirir. Guild yönetim hiyerarşisinin yerine geçmez. Ortak öğrenme, guideline üretimi ve pattern paylaşımı sağlar. Her guild'in scope'u ve karar yetkisi açık olmalıdır. Zorunlu onay merkezi olmaktan çok knowledge network olarak değer üretmesi beklenir.

Architecture Guild

Architecture Guild service boundary ve integration pattern gibi konuları tartışabilir. Ortak referans architecture örnekleri üretebilir. Büyük RFC'lere review sağlayabilir. Takımların benzer problemleri tekrar çözmesini azaltır. Kararların uygulanabilirliği düzenli olarak değerlendirilmelidir.

Security Guild

Security Guild güvenlik farkındalığını ekipler arasında dağıtır. Security champion modeliyle birlikte çalışabilir. Tekrarlanan vulnerability pattern'leri guideline'a dönüştürülebilir. Merkezi security ekibiyle iletişim köprüsü kurar. Böylece güvenlik yalnızca tek ekibin işi olmaktan çıkar.

Quality Guild

Quality Guild testing ve code review pratiklerini paylaşabilir. Flaky test veya defect trend gibi ortak sorunları inceleyebilir. Yeni test guideline taslakları hazırlayabilir. Takımlardan gerçek feedback toplar. Kaliteyi yalnızca coverage yüzdesine indirgemeden daha geniş bakış sağlar.

DevOps Guild

DevOps Guild CI/CD ve operations pratiklerini ortaklaştırabilir. Pipeline template ve deployment pattern geliştirebilir. Incident'lardan öğrenilen dersleri paylaşır. Self-service platform ihtiyaçlarını belirleyebilir. Böylece operasyonel bilgi ekipler arasında yayılır.

Frontend Guild

Frontend Guild accessibility, performance ve component standardı gibi konuları ele alabilir. Ortak UI library kullanımını destekleyebilir. Browser support ve testing yaklaşımı burada tartışılabilir. Yeni framework kararlarına RFC hazırlayabilir. Takımlar arası frontend standardını güçlendirir.

Backend Guild

Backend Guild API, database ve service design konularında ortak pattern geliştirebilir. Error handling ve observability pratiklerini paylaşabilir. Yeni dependency veya framework değerlendirmesi yapabilir. Production incident'lardan öğrenilen dersleri guideline'a taşıyabilir. Böylece backend ekipleri arasında bilgi akışı hızlanır.

Guild'lerin Guideline Üretimindeki Rolü

Guild guideline için problem keşfi, draft ve peer review sağlayabilir. Ancak her kararın guild onayına bağlanması gerekmez. Scope ve yetki seviyesi açık olmalıdır. Guild gerçek ekiplerden feedback toplayarak merkezi governance'a veri sağlar. Bu model dağıtık ownership oluşturur.

Guideline Versiyonlama

Guideline'lar değiştikçe hangi sürümün ne zaman geçerli olduğu bilinmelidir. Version numarası, effective date ve change history bu nedenle metadata'nın parçasıdır. Breaking değişikliklerde migration period ayrıca belirtilmelidir. Author ve approver bilgisi karar geçmişini görünür kılar. Next review date belgenin güncelliğini korumaya yardımcı olur.

Version Numarası

Version numarası guideline değişikliklerini takip eder. Basit semantic yaklaşım kullanılabilir. Büyük davranış değişiklikleri major artış olarak işaretlenebilir. Editorial değişiklikler minor veya patch olabilir. Kurum kendi basit convention'ını tanımlamalıdır.

Effective Date

Effective Date yeni kuralın ne zaman uygulanmaya başlayacağını gösterir. Yayın tarihi ile aynı olmak zorunda değildir. Migration gerektiren değişikliklerde hazırlık süresi bırakılabilir. CI enforcement effective date sonrasında aktive edilebilir. Bu tarih communication mesajında açıkça belirtilmelidir.

Change History

Change History önemli değişiklikleri kısa biçimde listeler. Nelerin değiştiği ve neden değiştiği açıklanabilir. Git history ayrıntılı teknik kayıt sağlarken changelog kullanıcıya okunabilir özet verir. Breaking change özellikle işaretlenmelidir. Eski karar bağlantıları korunmalıdır.

Author

Author ilk taslağı hazırlayan kişiyi gösterir. Owner ile aynı kişi olmak zorunda değildir. Geçmiş bağlam için faydalı olabilir. Ekip değişse bile author bilgisinin kalması sorun değildir. Güncel sorumluluk için her zaman owner alanı esas alınmalıdır.

Approver

Approver guideline sürümünü resmi olarak onaylayan roldür. Approval tipi risk seviyesine göre değişebilir. Birden fazla approver gerekiyorsa nedenleri açık olmalıdır. Kayıt audit açısından faydalıdır. Gereksiz approval zincirinden kaçınılmalıdır.

Migration Period

Migration Period mevcut projelerin yeni guideline'a uyum sağlaması için verilen süredir. Kural etkisine göre birkaç gün veya daha uzun olabilir. Yeni projeler için kural hemen geçerli olabilir. Legacy repository'lerde planlı geçiş uygulanabilir. Süre boyunca progress dashboard kullanılabilir.

Next Review Date

Next Review Date belgenin tekrar değerlendirileceği zamanı gösterir. Tarih guideline türüne göre belirlenmelidir. Technology ve security alanları daha sık review edilebilir. Event-driven review bu tarihi beklemeden tetiklenebilir. Otomatik reminder owner'a gönderilebilir.

Guideline Değişikliği Nasıl Yapılmalı?

Her değişikliğe aynı süreç uygulanmamalıdır. Küçük dil düzeltmesi ile developer davranışını değiştiren yeni zorunluluk aynı riskte değildir. Değişiklikler editorial, behavioral, breaking veya security emergency olarak sınıflandırılabilir. Etki arttıkça review ve migration planı da güçlendirilmelidir. Böylece guideline yönetimi gereksiz yavaşlamadan kontrollü kalır.

Minor Editorial Change

Minor editorial change anlamı değiştirmeyen yazım veya açıklık düzeltmesidir. Owner veya peer review ile hızlı şekilde merge edilebilir. Geniş communication gerektirmeyebilir. Version patch seviyesi artırılabilir. Ancak anlam değiştiği anda artık behavioral change olarak değerlendirilmelidir.

Behavioral Change

Behavioral change ekipten farklı davranış bekleyen değişikliktir. Yeni review şartı buna örnek olabilir. Etkilenen ekiplerden feedback alınmalıdır. Effective date ve communication hazırlanmalıdır. Gerekirse pilot uygulanabilir.

Breaking Guideline Change

Breaking change daha önce kabul edilen davranışı artık geçersiz hale getirir. Legacy repository'lerde ciddi migration maliyeti yaratabilir. Gap analysis yapılmalıdır. Otomatik fix veya tooling desteği sağlanmalıdır. Migration period açıkça belirtilmelidir.

Security Emergency Change

Security emergency change kritik vulnerability durumunda hızlı uygulanabilir. Normal discussion period kısaltılabilir. Ancak karar ve gerekçe sonradan kayıt altına alınmalıdır. Gerekli ekipler hızlı communication ile bilgilendirilmelidir. Olay sonrasında retrospective yapılmalıdır.

Etki Analizi

Etki analizi kaç repository ve takımın değişiklikten etkileneceğini gösterir. Otomatik query veya inventory kullanılabilir. Migration maliyeti tahmin edilir. Kritik sistemler ayrıca değerlendirilir. Sonuç rollout yöntemini belirler.

Review

Review değişikliğin türüne göre farklı derinlikte yapılmalıdır. Editorial değişiklik için hafif peer review yeterlidir. Security veya breaking değişiklikte uzman review gerekir. Yorumlar kayıt altında tutulmalıdır. Son karar owner tarafından görünür hale getirilmelidir.

Migration

Migration mevcut projeleri yeni standarda taşır. Repository listesi, owner ve deadline belirlenmelidir. Otomatik fix varsa süreç önemli ölçüde hızlanır. Progress dashboard görünürlük sağlar. Deadline sonrası enforcement artırılabilir.

Breaking Guideline Change Nedir?

Breaking guideline change daha önce uyumlu kabul edilen davranışın yeni sürümde uyumsuz sayılmasıdır. Bu değişiklik teknik migration gerektirebilir. Yalnızca belgenin version numarasını artırmak yeterli değildir. Etkilenen repository'ler, deadline ve support planı belirlenmelidir. Yeni security veya compliance gereksinimleri breaking değişiklik oluşturabilir.

Önceden Geçerli Olan Pattern'in Yasaklanması

Eski pattern yeni risk veya bakım maliyeti nedeniyle yasaklanabilir. Mevcut kullanım inventory üzerinden tespit edilmelidir. Replacement pattern açıkça gösterilmelidir. Migration guide sağlanmalıdır. Legacy sistemler için zaman sınırlı exception gerekebilir.

Teknoloji Değişikliği

Deprecated teknoloji yerine yeni platforma geçiş breaking guideline değişikliği yaratabilir. Tüm projeleri bir anda taşımak gerçekçi olmayabilir. Öncelik risk ve bakım maliyetine göre belirlenmelidir. Otomatik migration tool geliştirilebilir. End-of-support tarihi communication içinde yer almalıdır.

Yeni Security Requirement

Yeni security requirement mevcut repository'lerde değişiklik gerektirebilir. Örneğin yeni authentication control eklenmesi kapsamlı migration yaratabilir. Risk yüksekse rollout daha hızlı yapılabilir. Gerekli compensating control geçici olarak kullanılabilir. Security ekibi support sağlamalıdır.

Yeni Compliance Requirement

Yeni compliance gereksinimi audit veya yasal değişiklik sonucunda ortaya çıkabilir. Hangi sistemlerin kapsama girdiği netleştirilmelidir. Gerçek zorunluluk ile kurumun tercih ettiği ek kontrol ayrılmalıdır. Deadline dış gereksinimlere göre belirlenebilir. Evidence üretimi mümkün olduğunda otomatikleştirilmelidir.

Repository'lere Etki

Breaking change öncesinde etkilenen repository'ler otomatik olarak listelenmelidir. Risk ve owner bilgileri inventory'den alınabilir. Her repository için gap belirlenmelidir. Progress merkezi dashboard'da takip edilebilir. Sahipsiz repository'ler ayrıca ele alınmalıdır.

Migration Plan

Migration Plan yapılacak teknik adımları, owner'ı ve deadline'ı gösterir. Büyük geçişler fazlara ayrılabilir. Otomatik fix ve example PR sağlanabilir. Support channel ekiplerin soru sormasını kolaylaştırır. Tamamlanma kriteri açık olmalıdır.

Guideline Değişiklikleri Nasıl İletişime Açılmalı?

İyi teknik değişiklik kötü communication nedeniyle başarısız olabilir. Ekipler neyin değiştiğini, neden değiştiğini ve hangi aksiyonu almaları gerektiğini bilmelidir. Duyurular kısa ve hedefli olmalıdır. Migration guide ve support kanalı kolay erişilebilir olmalıdır. Effective date ve deadline özellikle görünür tutulmalıdır.

Announcement

Announcement değişikliğin temel özetini verir. Gereksiz ayrıntı yerine kimlerin etkilendiğini belirtmelidir. Canonical guideline linki eklenmelidir. Büyük değişikliklerde toplantı veya workshop ile desteklenebilir. Mesaj farklı kanallarda aynı kaynağa yönlendirmelidir.

Change Summary

Change Summary eski ve yeni davranış arasındaki farkı açıklar. Birkaç örnek kullanmak faydalıdır. Breaking noktalar özellikle işaretlenmelidir. Kullanıcı bütün guideline'ı baştan okumadan önemli değişikliği anlayabilmelidir. Ayrıntılı history canonical belgede kalabilir.

Neden Değişti?

Değişiklik gerekçesi adoption açısından önemlidir. Incident, security riski veya bakım maliyeti gibi nedenler açıklanabilir. İnsanlar nedenini bildiğinde migration yükünü daha anlamlı görür. Gereksiz dramatik dil kullanılmamalıdır. Kısa ve gerçek gerekçe yeterlidir.

Kim Etkileniyor?

Hangi takım veya repository'nin etkilendiği açıkça belirtilmelidir. Mümkünse otomatik liste sağlanabilir. Etkilenmeyen ekiplerin gereksiz alarm yaşaması önlenir. Risk seviyesi de bilgiye eklenebilir. Owner'lara doğrudan bildirim yapılabilir.

Developer'ın Yapması Gerekenler

İletişim net aksiyon içermelidir. Geliştiricinin hangi dosyayı değiştireceği veya hangi tool'u çalıştıracağı açıklanabilir. Example command veya PR sağlanabilir. Otomatik fix varsa ön plana çıkarılmalıdır. Belirsiz “uyum sağlayın” mesajından kaçınılmalıdır.

Deadline

Deadline açık tarih olarak verilmelidir. “Yakında” veya “en kısa sürede” gibi belirsiz ifadeler kullanılmamalıdır. Riskli değişikliklerde tarih daha yakın olabilir. Migration period ekip kapasitesini dikkate almalıdır. Deadline sonrası enforcement davranışı da açıklanmalıdır.

Migration Guide

Migration Guide adım adım geçiş yolunu açıklar. Common errors ve troubleshooting bölümü faydalıdır. Örnek before/after gösterilebilir. Otomatik script veya codemod varsa eklenmelidir. Guide gerçek proje üzerinde test edilmelidir.

Support Kanalı

Support channel migration sırasında soruların doğru yere ulaşmasını sağlar. Chat kanalı, issue queue veya office hours kullanılabilir. Owner ve çalışma saatleri belirtilmelidir. Sık gelen sorular guideline'a eklenebilir. Migration tamamlandıktan sonra geçici kanal kapatılabilir.

Guideline Deprecation Süreci

Kullanım dışına çıkan guideline sessizce silinmemelidir. Deprecated status, replacement ve removal date açıkça belirtilmelidir. Ekiplerin geçiş yapması için migration window sağlanmalıdır. Eski bağlantılar replacement belgeye yönlendirilmelidir. Arşiv geçmiş kararları korurken aktif katalogdan ayrılmalıdır.

Deprecated Status

Deprecated status belgenin yeni kullanım için artık önerilmediğini gösterir. Başlık ve metadata içinde görünür olmalıdır. Yeni projeler replacement guideline'a yönlendirilir. Mevcut sistemlerin geçiş durumu ayrıca takip edilebilir. Search sonuçlarında deprecated belgeler açık biçimde işaretlenmelidir.

Replacement Guideline

Eski kuralın yerine geçen yeni guideline açıkça bağlantılanmalıdır. Kullanıcı neden değişiklik yapıldığını görebilmelidir. Migration farkları özetlenebilir. Replacement bulunmuyorsa guideline neden kaldırıldığı açıklanmalıdır. Bu bilgi shadow documentation oluşmasını azaltır.

Migration Window

Migration Window mevcut projelerin geçiş için sahip olduğu süredir. Risk ve iş yüküne göre belirlenmelidir. Yeni projeler eski guideline'ı kullanmamalıdır. Otomatik reminder yaklaşan deadline'ları hatırlatabilir. Büyük migration'larda fazlı takvim kullanılabilir.

End-of-Support

End-of-Support tarihinden sonra eski yönteme aktif destek verilmeyebilir. Tarih önceden duyurulmalıdır. Kritik security patch'leri için ayrı politika gerekebilir. Takımlar migration planını bu tarihe göre yapmalıdır. Destek durumu developer portal içinde görünür olmalıdır.

Removal Date

Removal Date guideline'ın aktif sistemden kaldırılacağı tarihi gösterir. Enforcement ve template'ler aynı tarihe göre güncellenmelidir. Eski referanslar kırılmamalıdır. Redirect veya archived page kullanılabilir. Removal sonrası inventory kontrolü yapılmalıdır.

Arşivleme

Arşivleme geçmiş kararların tamamen kaybolmasını önler. Deprecated belge active catalog içinde normal guideline gibi görünmemelidir. Archive alanı yalnızca referans amacıyla kullanılabilir. Version history korunmalıdır. Eski incident veya audit araştırmalarında bu kayıtlar değerli olabilir.

Exception Management

İyi guideline sistemi istisnaların var olabileceğini kabul eder. Gerçek mühendislik ortamında bazı projeler standart kurala uymadan da güvenli biçimde çalışabilir. Önemli olan exception'ın kayıtlı, gerekçeli ve süreli olmasıdır. Gizli workaround yerine şeffaf exception süreci teşvik edilmelidir. Tekrarlanan istisnalar guideline'ın yanlış tasarlandığına dair güçlü sinyal olabilir.

Guideline'a Uymamanın Meşru Olduğu Durumlar

Teknik kısıt, legacy bağımlılık veya acil iş ihtiyacı geçici exception gerekçesi olabilir. Ancak yalnızca “daha kolay” olması yeterli olmayabilir. Risk değerlendirilmelidir. Gerekirse compensating control uygulanır. İstisna belirli tarihte yeniden gözden geçirilmelidir.

Exception Request

Exception Request kısa standart form üzerinden yapılabilir. Guideline ID, repository ve talep sahibi belirtilmelidir. Gerekçe ve süre yazılmalıdır. Approval seviyesi riskle uyumlu olmalıdır. Süreç geliştiriciyi gizli workaround'a zorlayacak kadar ağır olmamalıdır.

Business Justification

Business Justification istisnanın iş açısından neden gerekli olduğunu açıklar. Deadline, müşteri etkisi veya önemli operasyonel ihtiyaç olabilir. Yalnızca teknik kolaylıkla karıştırılmamalıdır. İş faydası riskle birlikte değerlendirilmelidir. Geçici çözümse sonrasında normal standarda dönüş planı bulunmalıdır.

Technical Justification

Technical Justification standardın neden uygulanamadığını açıklar. Legacy limitation veya platform desteği eksikliği örnek olabilir. Alternatiflerin neden uygun olmadığı yazılmalıdır. Gerekçe gelecekte guideline improvement için veri sağlar. Tekrarlanan teknik gerekçeler platform eksikliğini gösterebilir.

Risk

Exception kabul edildiğinde oluşan risk açık biçimde kaydedilmelidir. Security, reliability veya maintenance etkisi değerlendirilebilir. Risk seviyesi approval threshold belirleyebilir. Yüksek riskli exception daha kısa süreli olabilir. Risk gerçekleşirse incident review sırasında kayıt incelenebilir.

Compensating Control

Compensating Control ana kural uygulanamadığında riski başka yöntemle azaltır. Otomatik kontrol yerine geçici manuel review kullanılabilir. Kontrolün etkinliği açıkça değerlendirilmelidir. Gereksiz şekilde kalıcı hale getirilmemelidir. Exception sona erdiğinde control de kaldırılabilir.

Approver

Approver exception riskini kabul etme yetkisine sahip olmalıdır. Düşük riskli istisnalarda guideline owner yeterli olabilir. Kritik security istisnasında ek onay gerekebilir. Kimlerin approver olduğu önceden tanımlanmalıdır. Onay kayıt altında tutulmalıdır.

Expiry Date

Expiry Date exception'ın otomatik olarak sona ereceği tarihi gösterir. Süresiz istisnalar zamanla kalıcı sapmaya dönüşebilir. Yaklaşan expiry için reminder gönderilebilir. Devam gerekiyorsa yeniden değerlendirme yapılmalıdır. Yenileme otomatik kabul edilmemelidir.

Review Date

Review Date exception'ın durumunun ara değerlendirmesini sağlar. Uzun migration süreçlerinde faydalıdır. Risk, progress ve replacement planı kontrol edilir. Koşullar değiştiyse exception erken kapatılabilir. Review kaydı exception register içinde tutulmalıdır.

Kalıcı Exception Nasıl Önlenir?

Geçici exception'ların kalıcı hale gelmesi guideline sistemlerinde sık görülen problemdir. Bunun temel nedeni expiry ve ownership eksikliğidir. Merkezi exception register, otomatik reminder ve reassessment süreci kullanılmalıdır. Aynı exception tekrar tekrar yenileniyorsa guideline veya platform desteği sorgulanmalıdır. Amaç istisnayı cezalandırmak değil, geçici sapmayı görünür ve yönetilebilir tutmaktır.

Exception Register

Exception Register tüm aktif istisnaları tek yerde gösterir. Guideline ID, repository, owner ve expiry bilgileri bulunmalıdır. Search ve filter desteği governance işini kolaylaştırır. Yüksek riskli kayıtlar ayrıca raporlanabilir. Register otomatik ticket sistemine bağlanabilir.

Otomatik Expiry

Otomatik expiry süresiz exception oluşmasını önler. Tarih geldiğinde kontrol tekrar aktif hale gelebilir veya review ticket açılabilir. Kritik sistemlerde doğrudan hard fail yerine önceden warning süresi verilebilir. Owner'a yeterli bildirim yapılmalıdır. Süre uzatımı yeni risk değerlendirmesi gerektirmelidir.

Reminder

Reminder yaklaşan exception süresini hatırlatır. Birkaç hafta ve birkaç gün önce bildirim gönderilebilir. Mesaj gerekli migration adımını içermelidir. Owner değişmişse güncel sorumlu bulunmalıdır. Bu küçük otomasyon kalıcı istisnaları ciddi ölçüde azaltabilir.

Reassessment

Reassessment exception gerekçesinin hâlâ geçerli olup olmadığını kontrol eder. Platform desteği artık mevcut olabilir. Risk seviyesi değişmiş olabilir. Alternatif çözüm daha ucuz hale gelmiş olabilir. Yeni bilgiye göre exception kapatılabilir veya sınırlı süre uzatılabilir.

Tekrarlanan Exception'lar

Aynı sebeple çok sayıda ekip exception istiyorsa sistemsel problem bulunabilir. Guideline gereğinden fazla katı olabilir. Gerekli tooling desteği eksik olabilir. Exception verisi retrospective için önemli girdidir. Tek tek talepleri yönetmek yerine kök nedeni çözmek daha değerlidir.

Çok Fazla Exception Varsa Guideline'ı Sorgulamak

Yüksek exception oranı yalnızca ekiplerin uyumsuz olduğunu göstermez. Kural gerçek çalışma biçimine uygun olmayabilir. Risk yanlış değerlendirilmiş olabilir. Owner bu durumu ölçüm verileriyle incelemelidir. Gerektiğinde guideline scope'u veya requirement level değiştirilmelidir.

Guideline Compliance Nasıl Ölçülür?

Compliance ölçümü guideline'ın ne kadar uygulandığını gösterir. Ancak oran tek başına başarı anlamına gelmez. Repository coverage, team coverage, violation trend ve exception rate birlikte değerlendirilmelidir. Otomatik kontroller güvenilir veri üretir. Manuel değerlendirme gereken kurallarda sampling yaklaşımı kullanılabilir.

Compliance Rate

Compliance Rate kontrol edilen maddelerin ne kadarının sağlandığını gösterir. Yüzde yüksek görünse de kritik tek violation önemli olabilir. Severity bazlı weighting kullanılabilir. Trend zaman içindeki gelişimi gösterir. Hedefler gerçekçi ve risk bazlı olmalıdır.

Repository Coverage

Repository Coverage kaç projenin guideline ölçüm sistemine dahil olduğunu gösterir. Ölçülmeyen repository'ler görünmez risk oluşturabilir. Active ve archived repository ayrılmalıdır. Ownerless repository ayrıca işaretlenebilir. Coverage arttıkça compliance verisi daha anlamlı hale gelir.

Team Coverage

Team Coverage kaç ekibin guideline sistemini kullandığını gösterir. Farklı organizasyonların adoption seviyeleri karşılaştırılabilir. Amaç ekipleri sıralamak değil, support ihtiyacını bulmaktır. Düşük coverage nedenleri nitel feedback ile araştırılmalıdır. Platform eksikliği veya communication sorunu olabilir.

Open Violation

Open Violation henüz çözülmemiş guideline ihlalidir. Severity ve age bilgisi birlikte izlenebilir. Critical violation hızlı ele alınmalıdır. Düşük riskli maddeler backlog içinde planlanabilir. Çok eski ihlaller ownership problemini gösterebilir.

Fix Time

Fix Time violation tespitinden çözümüne kadar geçen süreyi ölçer. Uzun süre guideline'ın uygulanmasının zor olduğunu gösterebilir. Otomatik fix bu süreyi azaltabilir. Severity bazlı farklı hedefler belirlenebilir. Trend developer experience hakkında değerli bilgi sağlar.

Exception Rate

Exception Rate kaç uygulamanın standart kuraldan sapma talep ettiğini gösterir. Yüksek oran guideline tasarım problemini işaret edebilir. Takım veya kural bazında analiz yapılmalıdır. Gerekçeler kategorize edilebilir. Sonuçlar retrospective sırasında kullanılmalıdır.

Guideline Adoption

Adoption yalnızca compliance değildir. Ekiplerin guideline'ı kendi çalışma biçiminde gerçekten kullanıp kullanmadığını gösterir. Template usage, portal visit veya otomatik rule coverage sinyal olabilir. Developer survey ile desteklenebilir. Adoption düşükse iletişim veya tooling iyileştirilmelidir.

Sadece Compliance Yüzdesi Yeterli midir?

Yüksek compliance oranı her zaman iyi sonuç anlamına gelmez. Ekipler kurala uyarken delivery süresi ciddi şekilde uzuyor olabilir. Incident ve defect oranı değişmiyorsa kuralın gerçek etkisi sorgulanmalıdır. Developer friction ve onboarding süresi de önemli göstergelerdir. Guideline gerçek iş sonucuna katkı sağlamıyorsa yalnızca uyum yüzdesini yükseltmek değer yaratmaz.

Developer Friction

Developer Friction guideline'a uymak için harcanan ek zamanı gösterir. Uzun approval ve manuel form süreçleri friction yaratabilir. Ölçüm survey ve workflow verisiyle yapılabilir. Yüksek friction olan kurallar otomasyon için adaydır. Risk azaltımı ile maliyet dengelenmelidir.

Delivery Speed

Guideline delivery speed üzerinde etki yaratabilir. Güvenli süreç uzun vadede rework azaltarak hızı artırabilir. Ancak aşırı approval kısa vadede ciddi gecikme oluşturabilir. Lead time ve deployment frequency gibi göstergeler izlenebilir. Değişiklik öncesi ve sonrası karşılaştırılmalıdır.

Incident Rate

Bir reliability guideline'ın amacı incident azaltmaksa ilgili oran izlenmelidir. Sadece compliance yüksek diye kural başarılı sayılmamalıdır. Incident severity ve root cause birlikte değerlendirilir. Tek değişikliğe doğrudan nedensellik atfetmek zor olabilir. Uzun dönem trend daha anlamlıdır.

Security Findings

Security guideline sonrası finding trend takip edilebilir. Critical bulgular azalıyor mu sorusu önemlidir. Scanner sayısının artması geçici olarak bulgu sayısını yükseltebilir. Bu nedenle veri bağlam içinde yorumlanmalıdır. Remediation time da güçlü göstergedir.

Defect Rate

Testing veya review guideline'ı defect rate'i azaltmayı hedefleyebilir. Production bug ve escaped defect trendi izlenebilir. Takım ve proje riskine göre normalize etmek gerekebilir. Yalnızca issue sayısı kaliteyi tam göstermez. Severity ve kullanıcı etkisi birlikte değerlendirilmelidir.

Onboarding Time

Guideline sistemi yeni geliştiricilerin productive olma süresini azaltabilir. İlk PR süresi veya bağımsız deployment yapma zamanı ölçülebilir. Çok fazla belge onboarding'i tam tersine zorlaştırabilir. Guided checklist ve golden path faydalıdır. New hire feedback önemli veri sağlar.

Guideline'ın Gerçek İş Sonucuna Etkisi

Son amaç compliance değil, daha iyi iş ve mühendislik sonucudur. Kural risk azaltıyor, kalite artırıyor veya öğrenmeyi hızlandırıyor olmalıdır. Bu bağlantı her guideline'ın rationale bölümünde belirtilmelidir. Ölçüm planı buna göre oluşturulur. Değer üretmeyen kural kaldırılmaya adaydır.

Guideline Scorecard

Guideline Scorecard repository veya takımın farklı engineering alanlarındaki durumunu özetleyebilir. Security, reliability, quality ve documentation gibi kategoriler ayrı puanlanabilir. Tek bir toplam skor gerçeği aşırı basitleştirebilir. Maturity seviyeleri ve kritik violation'lar ayrıca gösterilmelidir. Scorecard cezalandırma aracı değil, iyileştirme rehberi olarak kullanılmalıdır.

Security

Security score secret scan, dependency vulnerability ve access policy gibi göstergelerden oluşabilir. Critical issue diğer maddelerden daha yüksek ağırlık taşıyabilir. Score otomatik veriyle güncellenebilir. False positive exception'ları doğru işlenmelidir. Takım hangi aksiyonla skoru iyileştireceğini görebilmelidir.

Reliability

Reliability score monitoring, SLO ve rollback readiness gibi alanları değerlendirebilir. Her internal tool için aynı kriter kullanılmamalıdır. Risk seviyesine göre requirement değişebilir. Incident trend ek bağlam sağlar. Score operasyonel olgunluğu görünür hale getirir.

Quality

Quality score test, review ve defect göstergelerini bir araya getirebilir. Coverage tek başına kullanılmamalıdır. Flaky test ve escaped defect gibi sinyaller eklenebilir. Takımın proje tipine uygun kriter seçilmelidir. Score iyileştirme fırsatını göstermelidir.

Documentation

Documentation score README, owner ve runbook bulunurluğunu kontrol edebilir. Dead link veya overdue review negatif sinyal olabilir. Kritik servisler için daha güçlü requirement kullanılabilir. Otomatik metadata kontrolü mümkündür. Dokümanın gerçekten kullanılıp kullanılmadığı ayrıca değerlendirilebilir.

Observability

Observability score log, metric, alert ve dashboard minimumlarını değerlendirebilir. Correlation ID veya SLO gereksinimi risk seviyesine göre değişir. Sadece araç kurulu olması yeterli değildir. Alert quality ve dashboard usage da önemli olabilir. Operasyonel sorunlarla score ilişkisi takip edilmelidir.

Delivery

Delivery score CI, deployment ve rollback readiness gibi alanları kapsar. Manual deployment oranı değerli sinyal olabilir. Lead time ve failed deployment trendleri eklenebilir. Amaç hızlı delivery ile güvenli delivery arasında denge kurmaktır. Score tek başına performans değerlendirmesi olarak kullanılmamalıdır.

Maturity Levels

Maturity level scorecard'ın gelişim aşamasını açıklar. Başlangıç seviyesinde temel dokümantasyon yeterli olabilir. İleri seviyede otomatik guardrail ve impact metric beklenebilir. Takımların tek seferde en üst seviyeye çıkması gerekmemelidir. Roadmap kademeli iyileştirme sunmalıdır.

Guideline Etkinliği Nasıl Ölçülür?

Guideline etkinliği kuralın hedeflediği sonucu üretip üretmediği üzerinden ölçülmelidir. Kural öncesi baseline alınması önemlidir. Production incident, review süresi, onboarding veya support soru sayısı gibi göstergeler kullanılabilir. Ölçüm guideline türüne göre değişir. Sonuç beklenen etkiyi üretmiyorsa kural revize edilmeli veya kaldırılmalıdır.

Kural Öncesi Baseline

Baseline mevcut durumu gösterir. Yeni guideline öncesinde aynı metrik birkaç hafta veya ay ölçülebilir. Böylece değişim karşılaştırılabilir. Baseline yoksa sonucun gerçekten iyileşme olup olmadığını anlamak zordur. Ölçüm maliyeti faydayı aşmamalıdır.

Kural Sonrası Sonuç

Yeni guideline sonrası aynı metrik tekrar ölçülür. İlk haftalardaki adoption etkisi ayrı değerlendirilebilir. Uzun vadeli trend daha güvenilir olabilir. Sonuç developer feedback ile birlikte incelenmelidir. Beklenmeyen olumsuz etkiler de kaydedilmelidir.

Production Incident Azaldı mı?

Reliability veya security guideline sonrası ilgili incident kategorileri izlenebilir. Toplam incident sayısı her zaman doğru karşılaştırma olmayabilir. Severity ve root cause ayrımı yapılmalıdır. Trafik veya sistem sayısı arttıysa normalize etmek gerekebilir. Kuralın belirli failure mode üzerindeki etkisine bakmak daha anlamlıdır.

Review Süresi Azaldı mı?

Code review guideline tekrar eden tartışmaları azaltıyorsa review cycle time iyileşebilir. İlk response ve merge süresi ayrı ölçülebilir. PR size gibi faktörler sonucu etkiler. Düşük review süresi kalite kaybı anlamına gelmemelidir. Defect trend ile birlikte yorumlanmalıdır.

Onboarding Hızlandı mı?

Onboarding guideline yeni çalışanların temel akışları öğrenmesini kolaylaştırmalıdır. İlk PR, ilk deployment veya bağımsız task süresi ölçülebilir. New hire survey ile dokümanların faydası sorulabilir. Support sorularının azalması ek sinyal olabilir. Gereksiz guideline sayısı onboarding'i yavaşlatıyorsa sadeleştirme yapılmalıdır.

Support Soruları Azaldı mı?

Aynı guideline hakkında tekrar eden sorular belgenin anlaşılmadığını gösterebilir. Support ticket ve chat soru kategorileri takip edilebilir. Yeni örnek veya FAQ eklenerek eksikler giderilebilir. Tool error mesajları da iyileştirilebilir. Soruların tamamen sıfırlanması hedef olmak zorunda değildir.

Kalite Arttı mı?

Kalite tek metrikle ölçülmez. Defect, incident, rework ve customer impact birlikte değerlendirilebilir. Code review veya testing guideline'ın etkisi belirli problem türünde aranmalıdır. Yüksek compliance düşük kalite ile birlikteyse kural yeniden düşünülmelidir. Ölçüm öğrenme amacıyla kullanılmalıdır.

Developer Experience Guideline Tasarımının Parçası Olmalı mı?

Evet, developer experience guideline tasarımının temel parçası olmalıdır. Uygulanması çok zor olan doğru kural bile düşük adoption üretir. Geliştirici dokümanı kolay bulabilmeli, anlayabilmeli ve mümkün olduğunca otomatik şekilde uygulayabilmelidir. Hata mesajları çözüm yolunu göstermelidir. Support ihtiyacını azaltmak governance'ın kalitesini yükseltir.

Guideline'ı Bulmak Kolay mı?

Kuralın bulunabilirliği ilk DX testidir. Search birkaç saniye içinde doğru belgeyi göstermelidir. Repository içinden ilgili guideline'a bağlantı verilebilir. Developer portal context-aware sonuç sunabilir. Bulunamayan guideline uygulanamaz.

Anlamak Kolay mı?

Metin kısa cümleler ve gerçek örneklerle açıklanmalıdır. Gereksiz kurumsal jargon öğrenme süresini artırır. MUST ve SHOULD gibi terimler başta tanımlanmalıdır. Her kural rationale içermelidir. Yeni çalışanla yapılan usability testi değerli sonuç verir.

Uygulamak Kolay mı?

Doğru davranış mümkün olduğunda tek komut veya template ile uygulanmalıdır. Uzun manuel checklist adoption'ı düşürür. Platform ve automation desteği verilmelidir. Kullanıcıdan aynı bilgiyi farklı sistemlerde tekrar istememek önemlidir. Manual compliance time KPI olarak ölçülebilir.

Hata Mesajı Açık mı?

Guardrail hata mesajı yalnızca “failed” dememelidir. Hangi kuralın ihlal edildiğini açıkça göstermelidir. Neden önemli olduğu kısa biçimde açıklanabilir. Fix komutu veya ilgili guideline bağlantısı eklenmelidir. İyi hata mesajı support ihtiyacını ciddi biçimde azaltır.

Fix Kolay mı?

Fix için mümkünse otomatik öneri sağlanmalıdır. Formatter veya codemod kullanılabilir. Çok sayıda repository'yi etkileyen migration için bot PR açabilir. Manual adım gerekiyorsa kısa rehber hazırlanmalıdır. Zor fix yüksek exception oranına yol açabilir.

Support Gerektiriyor mu?

Guideline sürekli support gerektiriyorsa tasarım problemi olabilir. Belge belirsiz olabilir veya tooling eksik olabilir. Sık sorular analiz edilmelidir. Self-service çözüm geliştirilebilir. Support yükünün zaman içindeki trendi ölçülmelidir.

Developer Feedback Loop

Feedback loop geliştiricilerin kural hakkında kolayca yorum yapmasını sağlar. Her guideline sayfasında issue veya feedback bağlantısı bulunabilir. Suggestions düzenli review edilir. Değişiklik sonucu kullanıcıya geri bildirilir. Bu döngü living documentation kültürünü güçlendirir.

Guideline Friction KPI'ları

Guideline friction, bir kurala uymak için harcanan gereksiz ek maliyeti ölçer. Dokümanı bulma süresi, approval bekleme ve manuel compliance süresi gibi göstergeler kullanılabilir. Support ticket ve exception sayısı da güçlü sinyaldir. Workaround kullanımı çoğu zaman görünmeyen friction'ı ortaya çıkarır. Bu KPI'lar kuralın developer experience üzerindeki etkisini anlamaya yardımcı olur.

Dokümanı Bulma Süresi

Developer gerekli guideline'ı ne kadar sürede buluyor sorusu basit ama değerlidir. Search analytics ve kullanıcı testi kullanılabilir. Dakikalar süren arama ciddi verimsizlik yaratır. Tagging ve context-aware linkler süreyi azaltabilir. Hedef mümkün olduğunca birkaç adım içinde doğru kaynağa ulaşmaktır.

Anlama Süresi

Kuralı bulmak kadar anlamak da önemlidir. Uzun ve belirsiz metin öğrenme süresini artırır. Örnekler ve kısa rationale bu süreyi azaltabilir. New hire feedback iyi test alanıdır. Karmaşık konular step-by-step rehberle desteklenebilir.

Compliance İçin Harcanan Manuel Süre

Manuel compliance time geliştiricinin kuralı karşılamak için yaptığı tekrar eden işi ölçer. Form doldurma, config kopyalama ve manuel check örnek olabilir. Yüksek süre otomasyon fırsatını gösterir. Starter template ve self-service platform bu maliyeti azaltır. Zaman kazancı guideline programının değerini de gösterir.

Approval Süresi

Approval süresi teslimat akışındaki beklemeyi ölçer. Ortalama ve yüzde 95 değerleri birlikte incelenebilir. Uzun süre reviewer kapasitesi veya gereksiz approval requirement gösterebilir. Risk seviyesi düşük değişikliklerde approval kaldırılabilir. Otomatik policy check insan beklemesini azaltabilir.

Support Ticket Sayısı

Sık support ticket aynı konunun anlaşılmadığını gösterebilir. Ticket'lar guideline ID ile etiketlenebilir. En fazla soru üreten kurallar öncelikli iyileştirme adayıdır. Doküman, tool veya error message güncellenebilir. Amaç support ekibini azaltmak değil, tekrarlanan bilgi ihtiyacını çözmektir.

Exception Sayısı

Exception sayısı kuralın gerçek çalışma biçimiyle uyumunu gösterir. Ani artış breaking change sonrası normal olabilir. Uzun süre yüksek kalıyorsa yeniden değerlendirme gerekir. Gerekçeler kategorize edilmelidir. Kural, scope veya tooling sorunu ayrıştırılabilir.

Workaround Kullanımı

Workaround resmi sürecin dışındaki davranışları gösterir. İnsanlar kuralı bypass etmek için özel script veya manuel yol kullanıyorsa friction yüksek olabilir. Bu davranışı tespit etmek her zaman kolay değildir. Developer interview ve retrospective faydalıdır. Güvenli ve kolay resmi yol sunmak workaround ihtiyacını azaltır.

Guideline'ların Onboarding'de Kullanımı

Onboarding guideline kültürünün en görünür kullanım alanlarından biridir. Yeni çalışan ilk haftada yüzlerce belge okumak zorunda bırakılmamalıdır. Rol ve proje türüne göre en kritik kurallar seçilmelidir. İlk pull request ve deployment sırasında bağlamsal öğrenme sağlanabilir. Engineering handbook temel çerçeveyi sunarken detaylı guideline'lara gerektiğinde gidilmelidir.

New Hire Engineering Handbook

Engineering Handbook şirketin teknik çalışma biçimini genel olarak tanıtır. Repository, review, security ve release başlıklarına kısa giriş sunar. Ayrıntılı guideline linkleri verilebilir. İlk hafta için okuma sırası önerilebilir. Handbook'un güncelliği belirli owner tarafından korunmalıdır.

İlk Hafta Öğrenilecek Kurallar

İlk hafta yalnızca yüksek değerli minimum kurallara odaklanılmalıdır. Git workflow, code review ve secrets gibi konular öncelikli olabilir. Uzun guideline kataloğunun tamamını ezberlemek beklenmemelidir. Role-specific checklist kullanılabilir. Öğrenme gerçek task ile birlikte yapılmalıdır.

İlk Pull Request

İlk PR guideline kültürünü öğretmek için iyi fırsattır. Template gerekli bilgileri hatırlatır. Reviewer açıklayıcı ve destekleyici yorum yapmalıdır. Lint ve CI otomatik feedback sağlar. Böylece yeni çalışan kuralı teorik değil pratik olarak öğrenir.

Code Review

Code review onboarding sırasında bilgi paylaşım aracıdır. Yeni çalışan yalnızca hatalarının düzeltilmesini değil, şirketin neden belirli pattern kullandığını öğrenmelidir. Blocking ve suggestion ayrımı açıklanmalıdır. Review culture güvenli iletişim oluşturmalıdır. İlk haftalarda reviewer daha fazla bağlam verebilir.

Security

Yeni çalışan temel security kurallarını erken öğrenmelidir. Secrets, access ve hassas veri davranışları önceliklidir. Uzun security training yerine gerçek geliştirme örnekleri kullanılabilir. Tooling güvenli davranışı varsayılan hale getirmelidir. Şüpheli durumda başvurulacak kanal açıkça belirtilmelidir.

CI/CD

Yeni geliştirici kodun production'a nasıl ulaştığını bilmelidir. Pipeline aşamaları kısa biçimde anlatılabilir. Hangi kontrollerin neden bulunduğu açıklanmalıdır. İlk deployment deneyimi mentor desteğiyle yapılabilir. Runbook ve release guideline bağlamsal şekilde gösterilebilir.

Documentation

Yeni çalışan dokümanı nerede bulacağını öğrenmelidir. Her şeyi ilk hafta okumak yerine search ve catalog kullanımı gösterilebilir. README ve ADR yapısı tanıtılmalıdır. Değişiklik yaparken dokümanı güncelleme beklentisi açıklanmalıdır. Böylece documentation kültürü erken oluşur.

Service Ownership

Service Ownership production sorumluluğunu açıklar. Yeni çalışan hangi takımın hangi servisten sorumlu olduğunu görebilmelidir. On-call ve escalation bilgisi portal üzerinden bulunabilir. Ownership yalnızca manager seviyesinde kalmamalıdır. Mühendis kendi değişikliğinin production etkisini anlamalıdır.

Yazılımcı Olmak İçin Şirket Standartlarını Bilmek Neden Önemlidir?

Profesyonel yazılım geliştirme yalnızca çalışan kod üretmekten ibaret değildir. Git workflow, review, testing, security ve documentation gibi ortak pratikler takım çalışmasını mümkün kılar. Şirket standardını bilen geliştirici değişikliğini mevcut sistemle daha uyumlu biçimde tasarlar. Bununla birlikte kör uyum yerine kuralın nedenini anlamak önemlidir. İyi mühendis gerektiğinde standardı sorgular ve daha iyi yaklaşım önerir.

Kod Yazmanın Ötesinde Çalışmak

Yazılım geliştirme ekip içinde yapılan ortak üretim faaliyetidir. Kodun review edilmesi, deploy edilmesi ve işletilmesi gerekir. Bu nedenle sadece syntax bilgisi yeterli değildir. Ownership ve communication becerileri önemlidir. Guideline kültürü bu geniş sorumluluk alanını görünür hale getirir.

Git Workflow

Git workflow ekiplerin değişiklikleri güvenli şekilde birleştirmesini sağlar. Branch, PR ve merge kurallarını bilmek günlük işin temelidir. Yanlış kullanım history ve release riskleri yaratabilir. Otomatik branch protection öğrenmeyi kolaylaştırır. Yeni çalışan bu akışı ilk task'larda pratik etmelidir.

Code Review

Code review yalnızca senior kişinin junior kodunu kontrol etmesi değildir. Tüm geliştiriciler bilgi paylaşımına katkı sağlayabilir. Review standardını bilmek yorum kalitesini artırır. Blocking ve preference ayrımını anlamak önemlidir. İyi reviewer aynı zamanda iyi takım arkadaşıdır.

Testing

Testing değişikliğin riskini yönetmenin temel araçlarından biridir. Hangi test türünün ne amaçla kullanıldığını bilmek gerekir. Gereksiz test kadar eksik test de maliyet yaratır. Guideline risk bazlı beklenti sunmalıdır. Geliştirici test stratejisine aktif katkı sağlamalıdır.

Security

Her geliştirici temel security davranışlarını bilmelidir. Secret, authorization ve input handling yalnızca security ekibine bırakılmaz. Güvenli library ve template kullanmak riski azaltır. Şüpheli durumda destek istemek normalleştirilmelidir. Security guideline günlük coding pratiğiyle ilişkilendirilmelidir.

Dokümantasyon

İyi geliştirici değişikliğin gelecekte anlaşılmasını da düşünür. README, ADR ve runbook doğru yerde güncellenmelidir. Gereksiz belge üretmek yerine ihtiyaç anında kullanılan bilgi yazılmalıdır. Kod ve doküman birlikte değişmelidir. Bu yaklaşım tribal knowledge'ı azaltır.

Takım Çalışması

Standartlar ekiplerin ortak dil geliştirmesini sağlar. Farklı kişisel tercihlerin her PR'da tartışılmasını azaltır. Geliştirici gerektiğinde feedback verir ve alır. Kararların gerekçesini paylaşır. Guideline ortak çalışma kültürünü destekler.

Production Ownership

Production Ownership geliştiricinin yaptığı değişikliğin operasyonel sonucunu sahiplenmesini ifade eder. Monitoring ve incident süreçlerini bilmek bu nedenle önemlidir. “Kod merge edildi, benim işim bitti” yaklaşımı sürdürülebilir değildir. Runbook ve observability bilgisi geliştiriciye destek olur. Ownership kalite kararlarını da iyileştirir.

İyi Bir Yazılımcı Guideline Kültürüne Nasıl Katkı Sağlar?

Guideline kültürü yalnızca yönetim veya platform ekiplerinin sorumluluğu değildir. Her geliştirici mevcut standardı uygulayabilir, sorun gördüğünde feedback verebilir ve daha iyi çözüm önerebilir. RFC, code review ve dokümantasyon katkısı bu kültürü canlı tutar. Junior geliştiricilere gerekçeleri anlatmak bilgi paylaşımını güçlendirir. Böylece guideline statik belge değil, ekip tarafından sürekli geliştirilen ortak çalışma sistemi olur.

Mevcut Standardı Uygular

İlk adım geçerli standardı bilmektir. Geliştirici kuralı günlük işte tutarlı şekilde uygular. Belirsiz noktada varsayım yapmak yerine owner veya dokümana başvurur. Tooling'deki guardrail'leri bypass etmeye çalışmaz. Sorun varsa resmi feedback sürecini kullanır.

Mantığını Anlar

Kuralın neden var olduğunu anlamak mühendislik yargısını güçlendirir. Sadece checklist uygulamak yerine risk değerlendirilir. Yeni senaryoda benzer prensip kullanılabilir. Rationale belirsizse soru sorulur. Bu yaklaşım kör compliance yerine bilinçli çalışma oluşturur.

Hatalı Standardı Sorgular

Standartlar her zaman doğru kalmaz. Teknoloji ve iş ihtiyacı değişebilir. Geliştirici sürekli friction veya yanlış sonuç gördüğünde bunu görünür hale getirmelidir. Eleştiri gerçek örnek ve alternatifle desteklenmelidir. İyi governance sorgulamayı tehdit değil iyileştirme kaynağı olarak görür.

RFC Yazar

Büyük değişiklik önerileri RFC ile paylaşılabilir. Problem ve mevcut maliyet açıkça yazılır. Alternatifler ve trade-off'lar değerlendirilir. Ekip feedback'i alınır. Böylece kişisel tercih kurumsal karara dönüşmeden önce ortak düşünme sürecinden geçer.

Code Review ile Bilgi Paylaşır

Review yorumları mini öğrenme fırsatı olabilir. Kuralın linki ve gerekçesi paylaşılabilir. Aynı yorum tekrar ediyorsa guideline'a dönüştürme önerisi yapılabilir. Preference blocking yorum gibi sunulmamalıdır. Sağlıklı review kültürü standardın günlük uygulamasını güçlendirir.

Dokümantasyonu Günceller

Geliştirici sistem davranışını değiştirdiğinde ilgili belgeyi de güncellemelidir. Eski README veya runbook uzun vadede ciddi problem yaratabilir. Küçük düzeltmeler için ayrı ekip beklenmemelidir. Docs-as-code katkıyı kolaylaştırır. Documentation shared ownership olarak görülmelidir.

Junior'lara Mentorluk Yapar

Mentorluk sadece kod tekniği öğretmek değildir. Şirketin neden belirli süreçleri kullandığını açıklamak da önemlidir. Junior geliştirici guideline'ı nerede bulacağını öğrenmelidir. Mentor her cevabı ezberden vermek yerine canonical kaynağa yönlendirebilir. Böylece bilgi kişiye bağımlı kalmaz.

“En İyi Yazılımcı” Guideline Uyumuyla mı Ölçülmeli?

İyi yazılımcıyı yalnızca compliance yüzdesiyle değerlendirmek doğru değildir. Mühendislik yargısı, ownership, review katkısı ve risk bilinci daha geniş resmi oluşturur. Bir geliştirici gerektiğinde yanlış standardı sorgulayabilmelidir. Önemli olan kuralları bilinçli kullanmak ve iyileştirmeye katkı sağlamaktır. Kör uyum yaratıcı problem çözmenin önüne geçmemelidir.

Kör Uyum Değil Mühendislik Yargısı

Guideline karar vermeyi destekler, düşünmenin yerine geçmez. Geliştirici risk ve bağlamı değerlendirmelidir. Uygun exception gerektiğinde bunu gerekçelendirebilmelidir. Yanlış kural gördüğünde evidence ile feedback vermelidir. Bu davranış olgun mühendislik kültürünün işaretidir.

Kod Kalitesi

Kod kalitesi anlaşılabilirlik, correctness ve bakım kolaylığını içerir. Formatter'a uyum tek başına kalite değildir. Geliştirici doğru abstraction ve test stratejisini seçmelidir. Production defect trendi gerçek sonuç hakkında bilgi verir. Guideline bu kaliteyi destekleyen çerçeve sunar.

Ownership

Ownership geliştiricinin yaptığı işin sonucunu sahiplenmesidir. Production sorununu başka ekibe bırakmak yerine çözüm sürecine katkı sağlar. Documentation ve monitoring güncelliğini düşünür. Teknik borcu görünür hale getirir. Bu davranış guideline compliance'dan daha geniş bir sorumluluktur.

Review Katkısı

İyi geliştirici yalnızca kendi PR'larını tamamlamaz. Diğer ekip üyelerinin review sürecine de katkı verir. Tasarım ve risk hakkında yapıcı feedback sunar. Review SLA'ya destek olur. Bilgiyi paylaşarak takımın genel kapasitesini artırır.

Dokümantasyon

Dokümantasyon katkısı bilginin sürdürülebilirliğini sağlar. Geliştirici değişiklik sonrası eski bilgiyi günceller. ADR ile önemli kararı kaydeder. Runbook'a production deneyimini ekler. Böylece sonraki ekip üyelerinin öğrenme süresi azalır.

İşbirliği

İşbirliği teknik kararların farklı perspektiflerle değerlendirilmesini sağlar. Geliştirici security, product ve platform ekipleriyle açık iletişim kurar. Görüş ayrılığını kişisel çatışmaya dönüştürmez. Karar sonrası ortak sonucu destekler. Guideline kültürü bu iletişim için ortak referans sağlar.

Standardı İyileştirme Katkısı

Olgun mühendis mevcut standardı yalnızca tüketmez. Eksik gördüğünde issue veya RFC açar. Otomasyon fırsatı önerir. Eski guideline'ı günceller. Böylece kurumun çalışma sistemi sürekli iyileşir.

Risk Bilinci

Risk bilinci hangi değişikliğin daha fazla kontrol gerektirdiğini anlamayı sağlar. Her değişikliği aynı ağırlıkta görmez. Security, data ve operations etkisini değerlendirir. Gerektiğinde uzman görüşü ister. Risk bazlı guideline modelinin doğru çalışması bu kültüre bağlıdır.

Open Source Projelerde Guidelines

Open source projelerde guideline katkı yapan kişilere projenin nasıl çalıştığını anlatır. CONTRIBUTING, Code of Conduct, security policy ve release process bu yapının temel parçalarıdır. Kurallar yalnızca şirket çalışanlarına değil, dünyanın farklı yerlerindeki contributor'lara açık olmalıdır. Bu nedenle anlaşılabilirlik ve şeffaflık daha da önem kazanır. Açık kaynak proje planlaması hakkında https://www.diyarbakiryazilim.com.tr/posts/acik-kaynak-projelerde-ekip-planlamasi-ve-dagitim-zaman-cizelgeleri adresindeki içerikten de yararlanabilirsiniz.

CONTRIBUTING

CONTRIBUTING projeye nasıl katkı yapılacağını açıklar. Setup, issue, branch ve pull request süreci anlatılabilir. Contributor'ın ilk katkısını kolaylaştırmak önemlidir. Gerekli test ve review beklentileri belirtilmelidir. Linkler güncel tutulmalıdır.

Code of Conduct

Code of Conduct topluluk içindeki davranış beklentilerini açıklar. Saygılı iletişim ve moderasyon çerçevesi sağlar. İhlal bildirim kanalı bulunmalıdır. Maintainer'ların uygulama sorumluluğu açıklanmalıdır. Belge yalnızca formalite olarak kalmamalıdır.

Coding Guidelines

Coding guideline contributor'ların ortak kod standardını anlamasını sağlar. Formatter ve lint mümkün olduğunda otomatik çalıştırılmalıdır. Geliştirici local olarak aynı kontrolleri çalıştırabilmelidir. Örnek kod sunulabilir. Gereksiz kişisel stil tartışmaları azaltılır.

Pull Request Guidelines

PR guideline başlık, açıklama ve test beklentilerini gösterir. Küçük ve review edilebilir değişiklikler teşvik edilebilir. Contributor hangi durumlarda maintainer review bekleyeceğini bilmelidir. Template gerekli bilgileri hatırlatabilir. Review communication açık ve yapıcı olmalıdır.

Issue Guidelines

Issue guideline bug report ve feature request için gerekli bilgiyi açıklar. Reproduction steps ve environment bilgisi istenebilir. Çok uzun form contributor'ı zorlayabilir. Template problem türüne göre farklılaştırılabilir. İyi issue kalitesi çözüm süresini azaltır.

Security Policy

Security Policy vulnerability'nin public issue yerine güvenli kanaldan nasıl bildirileceğini açıklar. Response beklentisi belirtilmelidir. Supported version listesi eklenebilir. Hassas bilgi paylaşım yöntemi tanımlanmalıdır. Maintainer düzenli olarak politikayı review etmelidir.

Governance

Governance projede kararların kim tarafından ve nasıl verildiğini açıklar. Maintainer rolü, voting veya consensus modeli kullanılabilir. Yeni maintainer seçimi tanımlanabilir. Conflict resolution yolu bulunmalıdır. Şeffaf governance contributor güvenini artırır.

Release Process

Release process versioning ve yayın adımlarını açıklar. Maintainer hangi kontrolün zorunlu olduğunu bilir. Changelog ve artifact üretimi otomatikleştirilebilir. Security veya breaking change ayrıca işaretlenir. Release sorumluluğu belirli owner tarafından yürütülmelidir.

Şirket İçi Guideline ile Open Source Contribution Guideline Arasındaki Fark

Şirket içi guideline ile open source contribution guideline benzer teknik konuları ele alsa da hedef kitlesi ve erişim modeli farklıdır. Şirket içi belgeler özel infrastructure ve business context içerebilir. Open source guideline ise public contributor'ların anlayacağı ve erişebileceği şekilde yazılmalıdır. IP, licensing ve security gereksinimleri de farklılaşır. Bu nedenle aynı belgeyi doğrudan iki ortamda kullanmak her zaman doğru değildir.

Hedef Kitle

Şirket içi guideline çalışanları ve contractor'ları hedefleyebilir. Open source guideline ise bilinmeyen deneyim seviyesindeki global contributor'lara açıktır. Daha fazla bağlam vermek gerekebilir. Internal jargon azaltılmalıdır. İlk katkı deneyimi özellikle düşünülmelidir.

Erişim

Internal belgeler authentication arkasında olabilir. Open source guideline public erişilebilir olmalıdır. Hassas şirket bilgileri açık belgeye taşınmamalıdır. Public repo içindeki linkler anonim kullanıcı tarafından açılabilmelidir. Broken internal link contributor deneyimini bozar.

IP ve Licensing

Open source contribution intellectual property ve license gereksinimlerini içerir. CLA veya DCO modeli kullanılabilir. Şirket içi katkıda bu süreç farklı olabilir. Contributor'ın gönderdiği kodun hangi lisans altında kullanılacağı açık olmalıdır. Legal policy sade dille anlatılmalıdır.

Security

Public repository security açısından farklı risk taşır. Vulnerability reporting özel kanal üzerinden yapılmalıdır. Secret veya internal endpoint yanlışlıkla paylaşılmamalıdır. Release artifact güvenliği düşünülmelidir. Security policy public kullanım için açık olmalıdır.

Approval

Internal approval organizasyon rol ve yetkisine dayanır. Open source projede maintainer review veya community governance kullanılabilir. Contributor şirket çalışanı olmadığı için klasik yönetim zinciri çalışmaz. Karar yetkisi public governance içinde tanımlanmalıdır. Review standardı herkese eşit uygulanmalıdır.

Community Governance

Community Governance katkı ve karar süreçlerini şeffaf hale getirir. Maintainer rolü ve contributor pathway açıklanabilir. Büyük kararlar RFC üzerinden tartışılabilir. Community feedback proje yönünü etkileyebilir. Açık karar geçmişi güven oluşturur.

Şeffaflık

Open source projelerde kararların görünür olması önemlidir. Issue, PR ve RFC geçmişi public olabilir. Internal projede bazı kararlar business confidentiality nedeniyle kapalı kalabilir. Yine de gerekçeler ekip içinde görünür tutulmalıdır. Her iki modelde de karar kaydı öğrenmeyi güçlendirir.

Şirket İçinden Open Source Projeye Katkı Yönergesi

Çalışanların open source projelere katkısı teknik topluluğa ve şirketin mühendislik gelişimine değer katabilir. Bununla birlikte intellectual property, license ve security konuları açık kurallara ihtiyaç duyar. Katkı yapılabilecek proje türleri ve şirket adına iletişim sınırları belirlenmelidir. Süreç gereksiz ağırlaştırılmamalıdır. Düşük riskli katkılar için self-service approval modeli kullanılabilir.

Hangi Projelere Katkı Yapılabilir?

Şirket approved veya restricted proje kategorileri tanımlayabilir. Kullanılan dependency'lere upstream bug fix göndermek güçlü adaydır. Hassas iş bilgisini açığa çıkaran projeler ayrı review gerektirebilir. Risk bazlı kriter kullanılmalıdır. Çalışan hangi durumda ek onay gerektiğini kolayca anlayabilmelidir.

Çalışma Saatinde Katkı

Çalışma saatinde contribution için açık politika bulunmalıdır. İşle ilgili dependency fix'leri doğal görev olarak görülebilir. Kişisel projeler farklı kapsama girebilir. Manager approval yalnızca gerekli durumlarda kullanılmalıdır. Belirsizlik çalışanların faydalı katkıdan kaçınmasına yol açabilir.

Intellectual Property

IP konusu şirket kodunun veya gizli bilginin yanlışlıkla paylaşılmasını önlemeyi amaçlar. Contributor hangi içeriğin public olabileceğini bilmelidir. Generic utility ile business-specific logic ayrılabilir. Gerekirse legal guidance sağlanmalıdır. Süreç örneklerle açıklanmalıdır.

License Review

Katkı yapılan projenin lisansı şirket politikasıyla uyumlu olmalıdır. Her küçük değişiklik için manuel legal onay gerekmez. Approved license listesi oluşturulabilir. Belirsiz durumlarda review yapılabilir. Katkının downstream kullanım etkisi değerlendirilmelidir.

Security

Open source contribution içinde secret ve internal endpoint bulunmamalıdır. Automated secret scan local ve CI seviyesinde çalıştırılabilir. Security-sensitive fix coordinated disclosure gerektirebilir. Public issue açmadan önce proje security policy kontrol edilmelidir. Çalışanlara kısa security checklist sağlanabilir.

CLA / DCO

Bazı projeler Contributor License Agreement veya Developer Certificate of Origin kullanır. Çalışan hangi belgeyi imzalayabileceğini bilmelidir. Şirket adına imza yetkisi gerekiyorsa süreç açıklanmalıdır. DCO sign-off otomatik Git workflow'a dahil edilebilir. Legal belirsizlik önceden giderilmelidir.

Şirket Adına İletişim

Contributor kişisel görüşü ile şirket resmi görüşünü ayırmalıdır. Şirket adına açıklama yapma yetkisi açık biçimde tanımlanabilir. Teknik PR tartışmalarında normal contributor davranışı yeterlidir. Hassas incident veya security konusu farklı iletişim gerektirebilir. Guideline örnek senaryolar içermelidir.

Upstream Contribution

Upstream contribution internal fork bakım maliyetini azaltabilir. Bug fix veya feature değişikliğinin ana projeye gönderilmesi uzun vadede değerlidir. Maintainer beklentilerine uygun PR hazırlanmalıdır. Internal patch public hale gelmeden önce hassas bilgi kontrolü yapılmalıdır. Kabul edilmeyen katkı için fallback planı bulunmalıdır.

Şirket Projesini Open Source Yapma Yönergesi

Şirket içi projenin open source yapılması yalnızca repository visibility değiştirmek değildir. Business case, security, legal ve maintenance planı birlikte değerlendirilmelidir. Public hale gelen proje için maintainer ve governance modeli gerekir. Hassas bilgi ve internal dependency temizlenmelidir. Community launch sonrası sürdürülebilir bakım sorumluluğu açık olmalıdır.

Business Case

Open source kararının iş veya engineering faydası açıklanmalıdır. Hiring, ecosystem contribution veya shared tooling buna örnek olabilir. Her internal proje open source olmak zorunda değildir. Bakım maliyeti hesaba katılmalıdır. Başarı kriterleri önceden belirlenebilir.

Teknik Değerlendirme

Projenin external kullanıcılar için kullanılabilir olup olmadığı değerlendirilir. Internal dependency ve hard-coded configuration temizlenmelidir. Setup dokümantasyonu hazırlanmalıdır. Build ve test dış ortamda çalışmalıdır. Repository history hassas bilgi açısından kontrol edilmelidir.

Security Review

Public release öncesinde secret ve sensitive information kontrolü yapılmalıdır. History scanning gerekebilir. Vulnerability reporting policy hazırlanmalıdır. Dependency riskleri değerlendirilmelidir. Security review release öncesinde tamamlanmalıdır.

Code Cleanup

Code cleanup yalnızca görünüş için yapılmamalıdır. Internal endpoint, debug code ve private configuration kaldırılmalıdır. Gereksiz şirket içi jargon dış kullanıcı için açıklanmalıdır. Test ve sample config hazırlanabilir. History rewrite gerekiyorsa dikkatli planlanmalıdır.

Legal Review

Legal review IP ve license uygunluğunu değerlendirir. Third-party code kullanım şartları kontrol edilmelidir. Contributor modelinin hukuki çerçevesi belirlenebilir. Proje adı ve trademark etkisi de düşünülebilir. Karar kayıt altında tutulmalıdır.

License

Uygun open source license projenin kullanım ve contribution modelini belirler. Seçim iş hedefiyle uyumlu olmalıdır. License dosyası repository root içinde bulunmalıdır. Dependency lisanslarıyla uyum kontrol edilmelidir. Contributor'lara lisans şartları açıkça gösterilmelidir.

Governance

Public proje karar süreci açık olmalıdır. Maintainer yetkileri ve contribution pathway tanımlanabilir. Büyük değişiklikler RFC ile tartışılabilir. Conflict resolution süreci bulunmalıdır. Governance proje büyüdükçe evrilebilir.

Maintainer

Maintainer issue, PR ve release sürecini sahiplenir. Tek kişinin tüm sorumluluğu taşıması bus factor yaratır. Yedek maintainer belirlenmelidir. Response beklentisi gerçek kapasiteyle uyumlu olmalıdır. Maintainer değişiklikleri community'ye açıkça duyurulmalıdır.

Community Launch

Community launch yalnızca repository'yi public yapmak değildir. README, CONTRIBUTING, Code of Conduct ve release planı hazır olmalıdır. İlk issue'lar newcomer-friendly olarak işaretlenebilir. Community feedback düzenli takip edilmelidir. Projenin güncel durumu şeffaf biçimde paylaşılmalıdır.

Diyarbakır Yazılım Topluluğu İçin Guideline Modeli

Diyarbakır Yazılım Topluluğu gibi topluluk odaklı yapılarda guideline modeli açık katılım ve sürdürülebilir katkı üzerine kurulabilir. Repository standardı, pull request süreci ve code review beklentileri yeni contributor'ların hızlı uyum sağlamasına yardımcı olur. Topluluğun yürüttüğü projeleri incelemek isteyenler https://www.diyarbakiryazilim.com.tr/projects adresini kullanabilir. Topluluk yapısı ve yaklaşımı hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresi de yararlı bir başlangıç noktasıdır. Bu model şirket guideline'larından farklı olarak daha açık contribution ve community governance yaklaşımına odaklanabilir.

Açık Kaynak Proje Guideline'ları

Topluluk projelerinde guideline contributor'ın ilk katkısını kolaylaştırmalıdır. Repository setup ve contribution süreci açıkça anlatılabilir. Gereksiz ağır onay mekanizması kullanılmamalıdır. Security ve license gibi temel kurallar korunmalıdır. Guideline'lar Git üzerinden community contribution'a açık tutulabilir.

Contributor Onboarding

Contributor onboarding kısa ve pratik olmalıdır. İlk issue seçimi, local setup ve ilk PR adımları açıklanabilir. Mentor veya maintainer desteği sağlanabilir. Starter task yeni katılımcının güven kazanmasını kolaylaştırır. Sık sorular belgeye eklenerek süreç sürekli iyileştirilebilir.

Repository Standardı

Topluluk repository'lerinde ortak README, LICENSE ve CONTRIBUTING yapısı kullanılabilir. Branch ve release kuralları standartlaştırılabilir. Template yeni proje açılışını kolaylaştırır. CODEOWNERS veya maintainer listesi görünür olmalıdır. Bu yapı contributor'ın farklı projeler arasında rahat geçmesini sağlar.

Pull Request Standardı

PR standardı değişikliğin amacını ve test bilgisini açıkça istemelidir. Template kısa tutulmalıdır. Contributor'a review süresi hakkında beklenti verilmelidir. Küçük ve anlaşılır PR'lar teşvik edilebilir. Review yorumları öğrenmeyi destekleyen dil kullanmalıdır.

Code Review Standardı

Review code correctness ve project consistency üzerine odaklanmalıdır. Kişisel stil tercihleri otomatik formatter'a bırakılabilir. Blocking comment açıkça işaretlenmelidir. Contributor'ın neden değişiklik istendiğini anlaması önemlidir. Review süreci topluluğun eğitim işlevine de katkı sağlar.

Community Code of Conduct

Code of Conduct güvenli ve saygılı katılım ortamını tanımlar. Moderation ve reporting süreci açık olmalıdır. Belge herkes için aynı şekilde uygulanmalıdır. Yeni contributor'lar erişim noktasında bu kuralları görebilmelidir. Community güveni tutarlı uygulamayla oluşur.

Release Guidelines

Release guideline version, changelog ve artifact üretimini açıklar. Maintainer sorumlulukları belirlenmelidir. Otomatik CI/CD süreci mümkün olduğunda kullanılabilir. Breaking change contributor ve kullanıcıya duyurulmalıdır. Stable release ve experimental sürüm ayrımı yapılabilir.

Maintainer Guidelines

Maintainer guideline review, issue triage ve release beklentilerini açıklar. Yeni maintainer seçimi ve yetki devri tanımlanmalıdır. Community ile iletişimde şeffaflık önemlidir. Burnout riskini azaltmak için sorumluluk dağıtılmalıdır. Maintainer değişiklikleri repository içinde kayıt altına alınabilir.

Topluluk ve Şirket Guideline'ları Birbirinden Ne Öğrenebilir?

Şirket ve open source toplulukları farklı yapılara sahip olsa da birbirinden önemli pratikler öğrenebilir. Açık tartışma, RFC ve şeffaf change history şirket içi governance'ı iyileştirebilir. Şirketlerin otomasyon ve risk bazlı kontrol deneyimi de topluluk projelerine katkı sağlayabilir. Dağıtık ownership her iki yapıda da sürdürülebilirliği artırır. Living documentation yaklaşımı ortak öğrenme kültürünü güçlendirir.

Açık Tartışma

Açık tartışma karar öncesinde farklı görüşlerin görünür olmasını sağlar. Şirket içinde bunun tamamen public olması gerekmez. Ancak ilgili ekiplerin erişebileceği forum kullanılabilir. Karar sonrası gerekçe saklanmalıdır. Bu yaklaşım “kim böyle karar verdi?” sorusunu azaltır.

RFC

RFC open source kültüründen kurumsal mühendisliğe başarıyla uyarlanabilir. Büyük değişiklikler async review alır. Proposal ve alternatives aynı yerde tutulur. Karar kayıt altında kalır. Ekipler farklı saatlerde katkı sağlayabilir.

Pull Request ile Dokümantasyon Review

Dokümantasyon review'u PR üzerinden yapmak değişiklik geçmişini görünür kılar. Contributor aynı araçları kullanır. CODEOWNERS uzman reviewer atayabilir. Otomatik link ve format kontrolü çalıştırılabilir. Bu yöntem şirket guideline'larında da etkili olabilir.

Şeffaf Change History

Change History insanların kuralın nasıl geliştiğini anlamasını sağlar. Eski kararlar tamamen silinmemelidir. Breaking değişiklikler açıkça işaretlenmelidir. Karar gerekçesi gelecekteki review'a veri sağlar. Şeffaflık guideline'a güveni artırır.

Contributor Feedback

Open source projeler doğal olarak contributor feedback ile gelişir. Şirketler de benzer loop oluşturabilir. Guideline sayfasında feedback bağlantısı bulunabilir. Pilot ve retrospective düzenli uygulanabilir. Geliştirici geri bildirimi gerçek veri olarak değerlendirilmelidir.

Dağıtık Ownership

Dağıtık ownership tek merkezi ekibin darboğaz olmasını önler. Guild ve domain owner modelleri kullanılabilir. Ancak responsibility sınırları açık olmalıdır. Global minimumlar merkezi kalabilir. Yerel ekipler kendi bağlamında iyileştirme yapabilir.

Living Documentation

Living Documentation sürekli kullanılan ve güncellenen belgeyi ifade eder. Kod ve süreç değiştiğinde ilgili guideline da değişmelidir. Version, owner ve review date bu kültürü destekler. Kullanıcı feedback'i doğrudan belgeye yansır. Böylece dokümantasyon arşiv değil çalışma aracı olur.

AI Coding Assistant'lar İçin Şirket İçi Guidelines

AI coding assistant kullanımı şirket içinde yeni veri, security ve code review soruları oluşturur. Hangi repository'lere erişebileceği, hassas verinin prompt içinde kullanılıp kullanılamayacağı ve üretilen kodun nasıl review edileceği açık olmalıdır. AI çıktısı insan review'unun yerini almamalıdır. Lisans ve güvenlik riskleri mevcut development policy ile birlikte değerlendirilmelidir. Kurallar anlaşılır olmalı ve kullanılan araçların gerçek özelliklerine göre düzenli review edilmelidir.

AI Aracı Hangi Kodlara Erişebilir?

AI tool'un erişebileceği repository scope açıkça tanımlanmalıdır. Public, internal ve highly sensitive repository'ler farklı policy kullanabilir. SSO ve access control mevcut şirket yetkileriyle uyumlu olmalıdır. Tool'un code retention davranışı değerlendirilmelidir. Yeni araç eklenmeden önce security review uygulanabilir.

Hassas Veriler

Hassas veri prompt veya context içine gereksiz şekilde eklenmemelidir. Production credential, kişisel veri ve müşteri sırrı açıkça yasaklanabilir. Data classification policy AI tool kullanımına bağlanmalıdır. Tool enterprise privacy control sağlıyorsa bu ayarlar merkezi yönetilmelidir. Geliştiriciye gerçek örnekler verilmelidir.

Prompt İçeriği

Prompt şirketin bilgi güvenliği kurallarına tabi olmalıdır. Secret ve confidential business information sınırları açıklanmalıdır. Geliştirici hangi bilgiyi paylaşabileceğini kolayca anlamalıdır. Tool log retention davranışı bilinmelidir. Policy yalnızca genel “dikkatli olun” ifadesiyle bırakılmamalıdır.

AI-Generated Code Review

AI tarafından üretilen kod insan tarafından review edilmelidir. Geliştirici çıktının correctness ve security sorumluluğunu taşır. Otomatik test ve scanner normal kodla aynı şekilde çalıştırılmalıdır. “Araç yazdı” hata için gerekçe olmamalıdır. Büyük değişikliklerde standart review süreci korunmalıdır.

Lisans Riski

AI-generated code kullanımında lisans ve provenance riski araç ve kullanım biçimine göre değerlendirilmelidir. Şirket approved tool listesi oluşturabilir. Belirsiz veya şüpheli snippet'ler review edilmelidir. Open source policy ile bağlantı kurulmalıdır. Legal guidance gerektiğinde erişilebilir olmalıdır.

Security Review

AI aracının enterprise security özellikleri değerlendirilmelidir. Data retention, model training ve access control ayarları önemlidir. Kullanım scope'u risk seviyesine göre sınırlandırılabilir. Tool update'leri policy review tetikleyebilir. Security review sadece ilk satın alma sırasında yapılmamalıdır.

Human Approval

AI çıktısında nihai sorumluluk insanda kalmalıdır. Pull request approval normal role sahip geliştirici tarafından verilmelidir. Kritik security veya architecture kararı AI önerisiyle otomatik kabul edilmemelidir. İnsan reviewer gerekçeyi anlamalıdır. Bu prensip accountability'nin korunmasını sağlar.

AI Agent'lara Guideline Nasıl Aktarılır?

AI agent'ların şirket standartlarına uygun çalışması için kurallar erişilebilir ve version-controlled biçimde sunulmalıdır. Repository instruction files ve merkezi rule set kullanılabilir. İnsan dokümanı ile AI talimatı farklılaşırsa rule drift oluşur. Bu nedenle mümkün olduğunda aynı canonical kaynaktan üretim yapılmalıdır. Repository-specific kurallar global minimumların üzerine eklenebilir.

Repository Instruction Files

Repository instruction files agent'a proje özelindeki çalışma kurallarını sağlar. Build, test ve code style bilgileri burada bulunabilir. Hassas veri veya tool kullanım sınırları da eklenebilir. Dosya version control içinde tutulmalıdır. Değişiklikler code review sürecinden geçmelidir.

AGENTS.md

AGENTS.md gibi instruction dosyaları agent'ın repository context'ini anlamasını kolaylaştırabilir. Hangi komutların çalıştırılacağı ve hangi dosyaların değiştirilmemesi gerektiği açıklanabilir. İnsanlar da aynı dosyayı okuyabilmelidir. Kurallar merkezi guideline ile çelişmemelidir. Güncellik owner tarafından takip edilmelidir.

AI Coding Rules

AI coding rules normal coding guideline'ın makineye daha açık ifade edilmiş versiyonu olabilir. Naming, test ve dependency sınırları belirtilebilir. Gereksiz uzun natural language talimatları yerine açık kurallar kullanılmalıdır. Tool'un desteklediği format dikkate alınmalıdır. Human review yine zorunlu kalabilir.

Merkezi Kurallar

Company-wide security ve compliance kuralları merkezi rule set olarak yönetilebilir. Agent hangi repository'de çalışırsa çalışsın bu minimumları görmelidir. Merkezi kaynak version-controlled olmalıdır. Değişiklikler ilgili governance review'dan geçmelidir. Repository local dosyası bu kuralları devre dışı bırakamamalıdır.

Repository-Specific Kurallar

Repository-specific rules proje bağlamını açıklar. Build command, test strategy veya architecture boundary buna örnek olabilir. Global kurallarla birlikte uygulanmalıdır. Precedence açıkça tanımlanmalıdır. Local owner bakım sorumluluğunu üstlenebilir.

İnsan Dokümanı ile AI Talimatının Ayrışmasını Önlemek

Aynı kural iki yerde manuel yazılırsa zamanla farklılaşabilir. Canonical source üzerinden hem developer docs hem agent instruction üretmek daha güvenlidir. CI drift kontrolü yapabilir. Değişiklik tek pull request içinde her çıktıyı güncelleyebilir. Böylece insan ve AI aynı standardı takip eder.

AI Çağında Guidelines-as-Code

AI destekli geliştirme, guidelines-as-code yaklaşımının önemini daha da artırır. İnsan ve AI aynı version-controlled kural kaynağından beslendiğinde tutarlılık güçlenir. Otomatik validation pull request aşamasında kurumsal standardı kontrol eder. AI tarafından üretilen kod da normal code review, test ve security sürecinden geçmelidir. Rule drift merkezi kaynak ve düzenli review ile önlenmelidir.

İnsan ve AI İçin Aynı Kaynak

Canonical guideline hem developer portal hem AI instruction için kaynak olabilir. Böylece iki farklı belge seti bakım ihtiyacı azalır. İnsan açıklaması daha detaylı, machine rule daha yapısal formatta üretilebilir. Kaynak değiştiğinde her iki çıktı güncellenir. Bu model tutarlılığı artırır.

Version-Controlled Rules

AI instruction dosyaları Git içinde version-controlled tutulmalıdır. Hangi kuralın hangi commit ile değiştiği görülebilir. Review ve rollback mümkün olur. Tool davranışı değiştiğinde kural güncellenebilir. Audit açısından da güçlü izlenebilirlik sağlanır.

Automated Validation

AI-generated change normal pipeline'dan geçmelidir. Lint, test ve security scan otomatik çalışır. Böylece üretim kaynağına göre farklı kalite standardı uygulanmaz. Hata mesajı gerekli fix'i gösterir. Validation human review'u tamamlar.

Pull Request Enforcement

PR enforcement AI ve insan tarafından üretilen değişikliklere aynı şekilde uygulanabilir. Required review ve CI check korunur. AI bot tarafından açılan PR'lar özel label alabilir. Human approval zorunlu tutulabilir. Böylece accountability açık kalır.

AI Tarafından Üretilen Kodda Kurumsal Standartlar

AI çıktısı coding, security ve testing guideline'larına uymalıdır. Prompt içinde bazı kurallar verilebilir ancak enforcement pipeline'da yapılmalıdır. Approved library listesi agent'a sağlanabilir. Repository pattern'leri örnek olarak kullanılabilir. Review sonunda sorumluluk insan geliştiricide kalır.

Rule Drift'i Önlemek

Rule drift aynı standardın farklı sistemlerde farklı sürümde kalmasıdır. Merkezi source ve otomatik generation bu riski azaltır. CI consistency check uygulanabilir. Deprecated rule'lar agent instruction'dan da kaldırılmalıdır. Version metadata hangi rule set'in aktif olduğunu göstermelidir.

Guideline Çakışmaları Nasıl Çözülmeli?

Farklı guideline'ların aynı durumda çelişmesi mümkündür. Global ve takım kuralları, security ve developer experience veya architecture ve delivery speed arasında denge gerekebilir. Bu durumda precedence rules ve escalation path açık olmalıdır. Üst seviye zorunlu security veya compliance kuralı yerel tercihle geçersiz kılınmamalıdır. Diğer konularda daha spesifik kural bağlama göre öncelik alabilir.

Global vs Team Guideline

Global guideline minimum şirket standardını tanımlar. Team guideline kendi domain'ine özel ek detay sağlayabilir. Yerel kural global MUST şartını kaldıramaz. Ancak global SHOULD maddesini daha spesifik hale getirebilir. Çelişki durumunda escalation yolu kullanılmalıdır.

Security vs Developer Experience

Security kontrolü gereksiz friction yaratıyorsa çözüm güvenliği kaldırmak değildir. Aynı riski daha kolay yöntemle azaltmak araştırılmalıdır. Self-service ve otomatik fix iyi seçeneklerdir. Security ve DX ekipleri birlikte tasarım yapmalıdır. Risk kabulü açık yetkiyle verilmelidir.

Architecture vs Delivery Speed

Architecture standardı uzun vadeli bakım değerini korurken delivery hızını etkileyebilir. Her küçük karar architecture board'a götürülmemelidir. Approved pattern ve golden path hızlı varsayılan sunabilir. Büyük deviation için RFC kullanılabilir. Bu model hız ve tutarlılığı dengeler.

Yeni vs Legacy Sistem

Yeni projeler güncel guideline'ı doğrudan uygulayabilir. Legacy sistemler aynı değişikliği hemen yapamayabilir. Gap analysis ve migration roadmap gerekir. Kritik kurallar önce ele alınmalıdır. Geçici grandfathering sınırsız olmamalıdır.

Precedence Rules

Precedence hierarchy company, business unit, platform, team ve repository gibi seviyelerle tanımlanabilir. Daha spesifik kural genellikle yerel bağlamı yönetir. Ancak üst seviye mandatory şartlar korunur. Bu istisna açıkça belgelenmelidir. Developer portal effective rule set'i hesaplayıp gösterebilir.

Escalation Path

Çelişki çözülemiyorsa hangi role gidileceği bilinmelidir. Guideline owner, guild veya standards council sıralı escalation sağlayabilir. Küçük anlaşmazlıkların yönetim seviyesine çıkması gerekmemelidir. Karar SLA'sı belirlenebilir. Sonuç kayıt altına alınmalıdır.

Global Guideline ile Proje Guideline'ı Arasındaki Öncelik

Global ve proje guideline'ı arasındaki ilişki açık tanımlanmazsa ekipler farklı kuralları uygulayabilir. Company-wide mandatory standartlar taban sınır oluşturmalıdır. Business unit, platform, team ve repository seviyeleri bu sınırın üzerine daha spesifik kurallar ekleyebilir. En spesifik kural bağlamı yönetirken üst seviye zorunlulukları ihlal etmemelidir. Precedence modeli merkezi katalogda görünür olmalıdır.

Company-Wide

Company-wide kurallar tüm engineering organizasyonu için minimum beklentiyi tanımlar. Security basics ve secrets buna örnek olabilir. Çok fazla company-wide rule ekip özerkliğini azaltabilir. Yalnızca yüksek değerli ortak maddeler bu seviyede tutulmalıdır. Owner merkezi governance veya platform olabilir.

Business Unit

Business Unit belirli iş alanının ek risklerini yönetebilir. Finans veya sağlık domain'i ek compliance kuralı uygulayabilir. Company-wide standard devam eder. Yerel owner ek requirement'ları yönetir. Cross-unit projelerde precedence açıkça belirlenmelidir.

Platform

Platform guideline kullanılan altyapının teknik sınırlarını tanımlar. Deployment, runtime veya observability standardı bu seviyede olabilir. Takımlar platformu kullandığında ilgili kurallar otomatik uygulanabilir. Platform dışı çözüm farklı RFC gerektirebilir. Rule set tooling ile birlikte versioned tutulmalıdır.

Team

Team guideline domain-specific çalışma biçimini açıklayabilir. Review veya release için ek şart eklenebilir. Global MUST kuralları değiştirilemez. Yerel kurallar kolay bulunmalıdır. Takım değişiklikleri guild ile paylaşılabilir.

Repository

Repository guideline en yerel bağlamı temsil eder. Build command, specific architecture decision veya maintenance kuralı burada bulunabilir. Global standardla çelişmemelidir. README veya instruction file üzerinden görünür olabilir. Owner repository metadata içinde belirtilmelidir.

En Spesifik Kuralın Uygulanması

Yerel bağlamı en iyi bilen kural çoğu durumda daha spesifiktir. Ancak bu prensip sınırsız değildir. Mandatory global kontrol her zaman korunmalıdır. Developer portal effective policy hesaplayabilir. Böylece kullanıcı precedence'i manuel yorumlamak zorunda kalmaz.

Üst Seviye Zorunlu Kuralların Ezilememesi

Security veya compliance gibi global MUST kurallar local file ile kapatılamamalıdır. Exception gerekiyorsa resmi süreç kullanılmalıdır. Bu kontrol policy engine ile uygulanabilir. Bypass kayıt altında tutulmalıdır. Böylece merkezi risk sınırı korunur.

Legacy Projelerde Yeni Guidelines Nasıl Uygulanmalı?

Legacy projeleri yeni guideline'a bir gecede geçirmek çoğu zaman gerçekçi değildir. Yeni projelerde kurallar hemen uygulanabilirken mevcut projeler için gap analysis yapılmalıdır. Critical Rules First yaklaşımı yüksek riski önce azaltır. Grandfathering yalnızca süreli ve gerekçeli kullanılmalıdır. Teknik borç backlog'u migration ilerlemesini görünür hale getirebilir.

Yeni Projelere Anında Uygulama

Yeni projeler geçmiş teknik borç taşımadığı için güncel guideline'ı başlangıçtan uygulamak daha kolaydır. Starter repository bu süreci otomatik hale getirir. Yeni template her minimum kuralı içerebilir. Exception yalnızca özel durumlarda gerekir. Bu model eski problemin tekrar oluşmasını önler.

Mevcut Projelerde Gap Analysis

Gap Analysis mevcut durum ile yeni standard arasındaki farkları listeler. Otomatik scan mümkünse kullanılmalıdır. Her gap severity ve effort ile değerlendirilebilir. Owner ve deadline atanır. Böylece migration somut backlog'a dönüşür.

Grandfathering

Grandfathering eski sistemin belirli süre mevcut davranışla devam etmesine izin verir. Kalıcı muafiyet olmamalıdır. Risk seviyesi ve migration maliyeti değerlendirilmelidir. Yeni değişiklikler güncel guideline'a tabi olabilir. Review tarihiyle karar tekrar gözden geçirilmelidir.

Migration Roadmap

Roadmap büyük migration'ı fazlara ayırır. En yüksek riskli repository'ler önce ele alınabilir. Platform tooling ve automation hazırlanır. Progress düzenli raporlanır. Roadmap iş planıyla uyumlu tutulmalıdır.

Critical Rules First

Her guideline maddesini aynı anda uygulamak yerine kritik riskler önceliklendirilmelidir. Secret management veya branch protection gibi kontroller önce gelebilir. Stil ve düşük riskli documentation maddeleri sonra taşınabilir. Bu yaklaşım risk azaltımını hızlandırır. Ekiplerin migration yükünü de yönetilebilir tutar.

Boy Scout Rule

Boy Scout Rule değiştirilen kodu geldiğinden biraz daha iyi bırakmayı teşvik eder. Büyük migration mümkün değilse touched area güncel guideline'a yaklaştırılabilir. Ancak critical security eksikleri bu yöntemle yıllarca bekletilmemelidir. Scope açık olmalıdır. Kademeli iyileştirme teknik borcu zamanla azaltır.

Teknik Borç Backlog'u

Guideline gap'leri teknik borç backlog'unda görünür tutulabilir. Severity, owner ve deadline eklenmelidir. Product planning içinde kapasite ayrılabilir. Çok eski gap'ler escalation gerektirebilir. Progress dashboard yönetim ve ekiplerin ortak görünümünü sağlar.

Guideline Migration Plan

Migration plan büyük guideline değişikliklerinin kontrollü uygulanmasını sağlar. Etkilenen repository, gap, risk, owner ve deadline açık biçimde listelenmelidir. Otomatik fix mümkün olan alanlarda önceliklendirilmelidir. Progress dashboard sayesinde tamamlanma durumu izlenebilir. Plan sadece doküman değil, gerçek execution aracı olmalıdır.

Etkilenen Repository'ler

Repository inventory migration scope'unu belirler. Active, archived ve critical sistemler ayrılmalıdır. Owner bilgisi güncel olmalıdır. Otomatik query manuel liste hatasını azaltır. Scope değişiklik boyunca güncel tutulmalıdır.

Gap

Her repository'nin yeni guideline'a göre eksikleri belirlenmelidir. Gap otomatik check veya manuel review ile bulunabilir. Severity eklenmelidir. Aynı gap çok sayıda projede görülüyorsa ortak migration tool geliştirilebilir. Sonuç backlog'a dönüştürülür.

Risk

Risk migration önceliğini belirler. Critical security gap yüksek öncelik almalıdır. Low-risk style farkı daha sonra çözülebilir. Risk ve effort birlikte değerlendirilir. Bu yaklaşım kaynakların doğru yere ayrılmasını sağlar.

Owner

Her migration item için owner belirlenmelidir. Merkezi platform ekibi ortak tooling'i sahiplenebilir. Repository owner uygulama sorumluluğu üstlenebilir. Sahipsiz item progress kaybına yol açar. Owner değişiklikleri dashboard'da güncellenmelidir.

Deadline

Deadline risk ve migration effort'a göre belirlenmelidir. Tüm projelere aynı tarih vermek gerçekçi olmayabilir. Fazlı takvim kullanılabilir. Yaklaşan tarihler için reminder gönderilebilir. Deadline sonrası enforcement seviyesi artırılabilir.

Otomatik Fix

Otomatik fix geniş migration'larda büyük zaman kazandırır. Bot PR, codemod veya config updater kullanılabilir. Fix küçük pilotla test edilmelidir. Riskli otomasyon insan review'undan geçmelidir. Developer yalnızca özel durumlara odaklanabilir.

Progress Dashboard

Dashboard migration'ın genel durumunu gösterir. Kaç repository tamamlandı ve kaç critical gap kaldı bilgisi sunulabilir. Team ve owner bazında filtre kullanılabilir. Amaç ekipleri yarıştırmak değil, darboğazları bulmaktır. Güncel veri otomatik sistemlerden alınmalıdır.

Kurumsal Guideline Kataloğu Nasıl Organize Edilmeli?

Kurumsal guideline kataloğu bilgi mimarisi açısından sade olmalıdır. Kullanıcı domain, teknoloji, lifecycle stage veya risk seviyesine göre arama yapabilmelidir. Search ve tagging temel özelliklerdir. Related Guidelines alanı benzer kurallar arasında geçişi kolaylaştırır. Katalog büyüdükçe taxonomy düzenli olarak review edilmelidir.

By Domain

Domain kategorisi security, architecture ve testing gibi alanlara göre düzenleme sağlar. Geliştirici ihtiyacını bildiğinde doğru bölüme hızlı ulaşır. Her guideline birden fazla tag alabilir. Tek hiyerarşiye zorlamak gereksiz olabilir. Search ile birlikte kullanılmalıdır.

By Technology

Technology görünümü Java, frontend veya cloud gibi stack-specific kuralları bulmayı kolaylaştırır. Merkezi prensipler ayrıca gösterilebilir. Deprecated teknoloji açık biçimde işaretlenmelidir. Technology owner görünür olmalıdır. Radar bilgisiyle bağlantı kurulabilir.

By Lifecycle Stage

Lifecycle view proje başlangıcı, development, review, release ve operations aşamalarına göre içerik sunar. Yeni çalışanlar için özellikle faydalıdır. Kullanıcı mevcut görevine göre doğru checklist ve guideline'ı bulabilir. Stage metadata otomatik eklenebilir. Aynı guideline birden fazla aşamada görünebilir.

By Risk Level

Risk Level görünümü projenin profilinde hangi kuralların mandatory olduğunu gösterir. Low-risk proje gereksiz high-risk dokümanları görmek zorunda kalmaz. Critical system için ek security ve compliance maddeleri öne çıkar. Repository metadata ile otomatik filtre uygulanabilir. Bu yaklaşım katalog gürültüsünü azaltır.

By Team

Team görünümü ekip özelindeki guideline'ları listeler. Global ve local kurallar birlikte gösterilebilir. Team owner değiştiğinde metadata güncellenmelidir. Cross-team repository için birden fazla takım görülebilir. Yerel kural global minimumla çelişmemelidir.

Search ve Tagging

Search sadece title eşleşmesine bağlı olmamalıdır. Keyword, tag ve synonym desteği kullanılabilir. Developer'ın yazdığı doğal arama terimleri analiz edilebilir. Sonuçlarda status ve scope görünür olmalıdır. Deprecated belgeler ayrı biçimde gösterilmelidir.

Related Guidelines

Related Guidelines alanı bağımlı kuralları birbirine bağlar. Security requirement ile ilgili CI enforcement aynı yerde gösterilebilir. Migration guide ve exception policy bağlantısı eklenebilir. Kullanıcı bağlamı kaybetmeden ilgili bilgiye ulaşır. Bağlantılar otomatik link checker ile doğrulanabilir.

Guideline Metadata

Metadata guideline'ın yönetilebilir olmasını sağlar. ID, title, status, owner, scope ve version gibi alanlar temel bilgidir. Effective date ve review tarihleri yaşam döngüsünü görünür kılar. Enforcement Method kuralın nasıl kontrol edildiğini gösterir. Bu alanlar merkezi katalog ve otomasyon tarafından makine okunabilir şekilde kullanılabilir.

ID

Her guideline benzersiz ID taşıyabilir. ID link ve automation entegrasyonunda kullanışlıdır. Başlık değişse bile referans sabit kalır. Kategori prefix'i kullanılabilir. Ancak ID formatı gereksiz uzun olmamalıdır.

Title

Title kuralın ne hakkında olduğunu kısa biçimde anlatmalıdır. Kullanıcının arayacağı terimleri içermesi faydalıdır. Aşırı genel başlıklardan kaçınılmalıdır. Status title içine yazılmak yerine metadata'da tutulabilir. Search sonuçlarında ID ile birlikte gösterilebilir.

Status

Status guideline'ın yaşam döngüsündeki durumunu gösterir. Draft, Proposed, Active veya Deprecated gibi değerler kullanılabilir. Kullanıcı aktif olmayan kuralı yanlışlıkla uygulamamalıdır. Status renk veya badge ile görünür olabilir. Geçiş kuralları workflow içinde tanımlanmalıdır.

Owner

Owner güncel sorumluyu gösterir. İsim yanında team de belirtilebilir. Sahip değişiklikleri otomatik directory ile senkronize edilebilir. Ownerless belge alert üretebilir. Support soruları bu role yönlendirilebilir.

Scope

Scope kuralın nerede geçerli olduğunu açıklar. Team, repository, technology ve risk level kullanılabilir. Makine okunabilir metadata policy engine için faydalıdır. Belirsiz “engineering” scope'u mümkünse daha spesifik hale getirilmelidir. Out-of-scope alanlar gerektiğinde belirtilir.

Severity

Severity kural ihlalinin risk seviyesini gösterir. Critical, high, medium ve low gibi sınıflar kullanılabilir. Severity enforcement ve remediation SLA'yı etkileyebilir. Her MUST kural critical olmak zorunda değildir. Risk kriterleri merkezi tanımlanmalıdır.

Version

Version aktif kural sürümünü belirtir. Breaking değişiklikler version artışıyla görünür olur. Repository hangi guideline version'a uyduğunu kaydedebilir. Otomatik portal history gösterebilir. Basit numbering modeli yeterlidir.

Effective Date

Effective Date kuralın ne zaman yürürlüğe girdiğini gösterir. Migration döneminde kritik bilgidir. Future-dated guideline önceden yayınlanabilir. Enforcement bu tarihe bağlı aktive edilebilir. Kullanıcı eski ve yeni sürüm arasındaki geçişi anlayabilir.

Last Review

Last Review guideline'ın en son ne zaman değerlendirildiğini gösterir. Eski tarih potansiyel guideline debt sinyali olabilir. Review içeriğin değişmesi anlamına gelmez. “No change required” sonucu da kaydedilebilir. Audit ve governance raporlarında kullanılabilir.

Next Review

Next Review bir sonraki planlı değerlendirme tarihidir. Owner'a otomatik reminder gönderilebilir. Risk seviyesine göre süre belirlenir. Event-driven review tarihi beklemeden devreye girebilir. Overdue review dashboard'da görünür olmalıdır.

Enforcement Method

Enforcement Method kuralın nasıl kontrol edildiğini belirtir. CI, lint, manual review veya no enforcement gibi değerler kullanılabilir. Kullanıcı violation'ın nerede görüleceğini bilir. Otomasyon bağlantısı doğrudan eklenebilir. Enforcement yoksa gerekçesi açık olmalıdır.

Guideline Status Modeli

Status modeli guideline'ın hangi yaşam döngüsü aşamasında olduğunu gösterir. Draft ile Active arasındaki fark kullanıcı için net olmalıdır. Pilot status kontrollü deneme sürecini görünür kılar. Deprecated ve Retired eski kuralların güvenli şekilde kullanım dışına alınmasını sağlar. Status geçişleri owner ve gerekli approval kurallarıyla yönetilebilir.

Draft

Draft henüz olgunlaşmamış çalışma belgesidir. Uygulama zorunluluğu yoktur. Yazar ve çalışma grubu değişiklik yapabilir. Feedback toplanabilir. Katalogda aktif kural gibi görünmemelidir.

Proposed

Proposed review'a açılmış taslağı ifade eder. Scope ve ana kural yeterince şekillenmiştir. Stakeholder feedback alınır. Approval henüz tamamlanmamıştır. Kullanıcı yeni davranış için hazırlık yapabilir ancak zorunluluk başlamaz.

Pilot

Pilot sınırlı ekiplerde gerçek kullanım aşamasıdır. Enforcement warning modunda olabilir. Friction ve impact ölçülür. Feedback toplanır. Sonuçlara göre kural revize veya iptal edilebilir.

Approved

Approved resmi onayı tamamlanmış ancak effective date'i henüz gelmemiş guideline olabilir. Migration communication bu aşamada yapılabilir. Tooling ve template hazırlanır. Takımlar geçiş planını başlatabilir. Effective date geldiğinde Active durumuna geçilir.

Active

Active şu anda geçerli kuralı ifade eder. Enforcement ve compliance ölçümü çalışır. Owner ve review date görünür olmalıdır. Exception süreci aktif kullanılabilir. Değişiklikler version management üzerinden yapılır.

Deprecated

Deprecated yeni kullanım için önerilmeyen ancak legacy sistemlerde hâlâ görülebilen kuraldır. Replacement bağlantısı gösterilmelidir. Migration window devam ediyor olabilir. New project template artık bu kuralı kullanmamalıdır. Removal date belirtilmelidir.

Retired

Retired artık uygulanmayan guideline'ı gösterir. Aktif katalogdan kaldırılmalıdır. Tarihsel referans için archive içinde tutulabilir. Enforcement devre dışı olmalıdır. Replacement varsa bağlantı korunmalıdır.

Guideline Review Takvimi

Her guideline aynı sıklıkta review edilmek zorunda değildir. Security ve teknoloji kuralları hızlı değiştiği için daha sık değerlendirilebilir. Process guideline daha uzun cycle kullanabilir. Incident, audit veya yeni regülasyon gibi olaylar takvim dışında review tetiklemelidir. Bu model gereksiz toplantıyı azaltırken güncelliği korur.

Security Guidelines

Security guideline threat ve tooling değişikliklerinden sık etkilenir. Altı aylık veya yıllık review kullanılabilir. Critical vulnerability event-driven review tetikleyebilir. Security owner değişiklikleri takip etmelidir. Otomatik dependency policy ayrıca daha sık güncellenebilir.

Technology Guidelines

Technology guideline framework ve platform değişimleri nedeniyle düzenli review ister. Technology radar ile aynı cycle kullanılabilir. Deprecated tool ve yeni approved option'lar güncellenir. Community ve maintenance durumu değerlendirilir. Legacy migration etkisi dikkate alınmalıdır.

Architecture Guidelines

Architecture guideline daha stabil olabilir ancak organizasyon büyüdükçe değişebilir. Yıllık review yeterli olabilir. Büyük platform değişikliği erken review tetikleyebilir. Architecture guild feedback sağlar. Çelişkili local pattern'ler incelenebilir.

Process Guidelines

Process guideline delivery ve team workflow değişikliklerinden etkilenir. Review sırasında friction metric özellikle incelenmelidir. Gereksiz approval adımları kaldırılabilir. New tooling süreci basitleştirebilir. Ekip feedback'i temel veri olmalıdır.

Event-Driven Review

Event-driven review belirli olay sonrası guideline'ın tekrar değerlendirilmesini sağlar. Takvim tarihini beklemek gerekmez. Incident, audit, regülasyon veya büyük teknoloji değişimi trigger olabilir. Owner otomatik ticket alabilir. Böylece hızlı öğrenme sağlanır.

Incident Sonrası

Incident root cause guideline eksikliğine bağlanıyorsa review yapılmalıdır. Mevcut kural anlaşılmamış veya uygulanmamış olabilir. Yeni rule yazmadan önce gerçek neden incelenmelidir. Tooling veya training eksikliği de çözüm olabilir. Postmortem action item guideline lifecycle'a bağlanabilir.

Audit Sonrası

Audit bulgusu tekrar eden control eksikliğini gösterebilir. Guideline scope ve enforcement incelenmelidir. Yalnızca doküman eklemek her zaman çözüm değildir. Otomatik evidence veya control geliştirmek daha etkili olabilir. Sonuç audit action planına işlenmelidir.

Yeni Regülasyon

Yeni regülasyon belirli guideline'ları hızla etkileyebilir. Gerçek legal requirement ilgili uzmanla netleştirilmelidir. Etkilenen sistem inventory üzerinden bulunur. Migration ve effective date planlanır. Communication açık ve somut olmalıdır.

Büyük Teknoloji Değişimi

Yeni platform veya framework mevcut guideline'ı geçersiz hale getirebilir. Technology ve architecture kuralları birlikte review edilmelidir. Starter template ve tooling güncellenir. Legacy sistemler için migration roadmap hazırlanır. Eski örnekler aktif belgelerden kaldırılır.

Guideline Retrospective

Guideline retrospective kuralların gerçekten işe yarayıp yaramadığını topluca değerlendiren periyodik çalışmadır. Sürekli ihlal edilen veya çok fazla exception üreten maddeler özellikle incelenmelidir. Developer friction ve business outcome birlikte değerlendirilir. Otomasyon fırsatları belirlenir. Gerekli olmayan kurallar cesur biçimde kaldırılmalıdır.

Hangi Kurallar İşe Yarıyor?

İşe yarayan kural hedeflenen problemi azaltmalıdır. Incident, defect veya support soruları düşmüş olabilir. Developer feedback olumlu olabilir. Bu kuralların hangi tasarım özelliklerinin başarılı olduğu analiz edilir. Öğrenilenler yeni guideline'lara aktarılır.

Hangi Kurallar Sürekli İhlal Ediliyor?

Sürekli violation yalnızca disiplin problemi olmayabilir. Kural anlaşılmıyor veya uygulanması zor olabilir. Enforcement eksik olabilir. Risk artık geçerli olmayabilir. Root cause bulunmadan daha güçlü gate eklenmemelidir.

Hangi Kurallar Çok Fazla Exception Üretiyor?

Yüksek exception rate yanlış scope veya aşırı zorunluluk gösterebilir. Gerekçeler kategorize edilmelidir. Aynı sebep tekrar ediyorsa guideline revize edilebilir. Platform desteği eksikse tooling yatırımı yapılabilir. Exception verisi iyileştirme için kullanılmalıdır.

Hangi Kurallar Gereksiz Maliyet Yaratıyor?

Approval süresi ve manual compliance time maliyeti gösterir. Risk azaltımı düşükse süreç sadeleştirilebilir. Otomasyon aynı kontrolü daha ucuz yapabilir. Ekip feedback'i bu konuda değerlidir. Gereksiz kontrol guideline'a güveni azaltır.

Hangileri Otomatikleştirilebilir?

Tekrarlanan ve net kurallar automation adaylarıdır. Lint, branch protection ve dependency scan örnek olabilir. Otomasyon önce pilot edilmelidir. Error message ve fix experience tasarlanmalıdır. İnsan review'u bağlam gerektiren konulara bırakılmalıdır.

Hangileri Kaldırılmalı?

Artık risk azaltmayan veya eski teknolojiye bağlı kurallar kaldırılmalıdır. Belgeyi sırf geçmişte yazıldığı için tutmak doğru değildir. Deprecation süreci uygulanabilir. Replacement yoksa kaldırma gerekçesi açıklanır. Katalog sade kaldıkça güven artar.

Guideline'ın Kendisi Teknik Borca Dönüşebilir mi?

Evet, guideline'ın kendisi de teknik borca dönüşebilir. Eski teknolojiye göre yazılmış, owner'ı bulunmayan ve çelişkili belgeler geliştiriciyi yanlış yönlendirir. Dead link ve güncel olmayan örnekler güveni hızla azaltır. Guideline Debt Backlog bu sorunları görünür hale getirebilir. Dokümantasyon da kod gibi bakım isteyen yaşayan bir sistemdir.

Eski Teknolojiye Göre Yazılmış Kurallar

Deprecated framework'e göre yazılmış guideline yeni projelerde yanlış karar üretir. Technology radar ile link kurulmalıdır. Eski içerik deprecated işaretlenebilir. Replacement açıkça gösterilmelidir. Review cycle bu riski azaltır.

Artık Geçerli Olmayan Security Varsayımları

Security threat modeli zaman içinde değişebilir. Eskiden güvenli kabul edilen yaklaşım artık riskli olabilir. Guideline yeni vulnerability ve platform değişikliklerine göre review edilmelidir. Security emergency update gerekebilir. Eski varsayımlar rationale bölümünde görünür olabilir.

Çelişkili Dokümanlar

Aynı konuda farklı kural yazan belgeler güven kaybı yaratır. Canonical source ve precedence model bu problemi azaltır. Duplicate sayfalar tespit edilmelidir. Eski belgeler redirect ile kapatılabilir. Search yalnızca aktif kaynağı öne çıkarmalıdır.

Dead Links

Dead link kullanıcıyı ihtiyaç anında yarı yolda bırakır. CI link checker otomatik kontrol yapabilir. Internal tool URL değişiklikleri düzenli taranmalıdır. Çok sayıda broken link guideline health metriği olabilir. Owner'a otomatik issue atanabilir.

Owner Eksikliği

Owner eksik belge bakım sorumluluğunu belirsizleştirir. Soru geldiğinde kimse cevap vermez. Review tarihleri kaçırılır. Organizational directory ile owner check otomatik yapılabilir. Sahipsiz guideline governance backlog'una alınmalıdır.

Guideline Debt Backlog

Guideline debt normal teknik borç gibi takip edilebilir. Overdue review, broken link ve missing owner item haline getirilebilir. Severity ve effort belirlenir. Sprint veya maintenance cycle içinde kapasite ayrılır. Böylece belge sağlığı sistematik biçimde korunur.

Şirket İçi Guideline Anti-Pattern'leri

Guideline sistemi yanlış tasarlandığında fayda yerine ek yük üretir. Çok uzun rehberler, her şeyi zorunlu yapmak ve owner belirlememek sık görülen anti-pattern'lerdir. İnsanlardan sürekli manuel compliance beklemek de sürdürülebilir değildir. Exception mekanizması bulunmayan sistemler gizli workaround üretir. Sağlıklı governance bu işaretleri düzenli olarak izlemelidir.

200 Sayfalık Okunmayan Rehber

Çok uzun tek belge bilgi bulmayı zorlaştırır. Kullanıcı ihtiyaç anında doğru maddeyi bulamaz. İçerik küçük, aranabilir guideline'lara bölünebilir. Search ve tagging eklenmelidir. Handbook sadece giriş ve yönlendirme rolü üstlenebilir.

Her Şeyi Zorunlu Hale Getirmek

Her maddeyi MUST yapmak risk ayrımını ortadan kaldırır. İnsanlar gerçekten kritik kuralları fark edemez. Exception sayısı hızla artar. Developer friction yükselir. MUST, SHOULD ve MAY dengeli kullanılmalıdır.

Nedeni Açıklanmayan Kurallar

Rationale bulunmayan kural ezberlenir ancak anlaşılmaz. Deneyimli geliştirici farklı bağlamda doğru karar veremez. Exception değerlendirmesi de zorlaşır. Her önemli madde nedenini açıklamalıdır. Bu bilgi gelecekteki review için de gereklidir.

Bir Kişinin Yazıp Herkese Dayatması

Tek kişinin perspektifi tüm ekiplerin ihtiyacını kapsamayabilir. Merkezi dayatma adoption sorununa yol açar. Peer review ve pilot kullanılmalıdır. Etkilenen ekiplerden feedback alınmalıdır. Ownership tek kişi olsa bile üretim collaborative olabilir.

Güncellenmeyen Wiki

Eski wiki sayfası yanlış bilgi kaynağıdır. Kullanıcı birkaç kez yanlış bilgi gördüğünde tüm dokümana güvenmeyi bırakır. Owner ve review date görünür olmalıdır. Overdue içerik dashboard'da gösterilebilir. Gereksiz sayfalar archived edilmelidir.

Owner Olmayan Guideline

Sahipsiz guideline zamanla stale hale gelir. Sorular cevapsız kalır. Değişiklik gerektiğinde kimse karar veremez. Named Owner zorunlu metadata olmalıdır. Owner ayrılırsa transfer süreci çalışmalıdır.

Exception Mekanizması Olmaması

İstisna yolu yoksa ekipler kuralı gizlice bypass edebilir. Bu durum riskin görünürlüğünü azaltır. Resmi exception süreci kontrollü esneklik sağlar. Expiry ve justification kayıt altına alınır. Çok fazla exception kural review'u tetikler.

Enforcement Olmadan Compliance Beklemek

Yüzlerce yazılı kuralı insanların sürekli hatırlamasını beklemek gerçekçi değildir. Otomasyona uygun alanlarda guardrail kullanılmalıdır. Error mesajı öğretici olmalıdır. İnsan review'u yüksek bağlamlı konulara ayrılır. Böylece compliance daha sürdürülebilir olur.

Her Şeyi Manuel Review Etmek

Formatting ve lint gibi mekanik kontroller insan zamanını tüketmemelidir. Tooling bu görevleri daha hızlı ve tutarlı yapar. Reviewer design ve correctness'e odaklanabilir. Manuel approval yalnızca risk gerektiriyorsa kullanılmalıdır. Bu yaklaşım review SLA'yı iyileştirir.

“Confluence'da Yazıyor” Anti-Pattern'i

Bir kuralın bir wiki sayfasında bulunması onun ekipler tarafından bilindiğini göstermez. Kullanıcı belgeyi bulamıyor, varlığından haberdar değil veya kod farklı davranışı teşvik ediyorsa dokümantasyon etkisiz kalır. Yeni çalışan eski kodu kopyalayabilir. AI aracı da repository'deki eski pattern'i tekrar üretebilir. Bu nedenle önemli guideline'lar aktif guardrail, template ve repository instruction ile desteklenmelidir.

Dokümanın Bulunamaması

Search kötü ise kullanıcı doğru sayfaya ulaşamaz. Uzun wiki hiyerarşisi ek maliyet yaratır. Tagging ve merkezi katalog kullanılmalıdır. Repository'den ilgili guideline'a link verilebilir. Bulunabilirlik düzenli kullanıcı testiyle ölçülebilir.

Developer'ın Varlığından Habersiz Olması

Yeni guideline yalnızca duyuru mesajıyla paylaşılırsa kısa sürede unutulabilir. Geliştirme akışında bağlamsal görünürlük gerekir. PR template veya CI error linki kullanılabilir. Onboarding içinde temel kataloğa yer verilebilir. Adoption ölçümü iletişim eksikliğini gösterebilir.

Kod ile Dokümanın Ayrışması

Repository eski pattern kullanırken guideline yeni yaklaşımı öneriyorsa geliştirici kodu takip edebilir. Starter template ve örnek repository güncel tutulmalıdır. Migration plan eski kodu kademeli düzeltmelidir. Documentation update tek başına yeterli değildir. Doğru davranış yaşayan kodda da görünür olmalıdır.

Yeni Çalışanın Eski Kodu Kopyalaması

İnsanlar çoğu zaman mevcut örneği resmi belgeden daha hızlı takip eder. Legacy pattern repository içinde yaygınsa yeni çalışan onu doğru kabul edebilir. Deprecated code pattern lint veya warning ile işaretlenebilir. Golden example sağlanmalıdır. Review sırasında rationale açıklanmalıdır.

AI Aracının Eski Pattern'i Kopyalaması

AI coding assistant repository'deki mevcut koddan pattern çıkarabilir. Eski yaklaşım ağırlıktaysa yeni guideline'a aykırı çıktı üretebilir. Repository instruction file güncel kuralı açıkça belirtmelidir. CI enforcement sonucu kontrol eder. Legacy code migration bu riski zamanla azaltır.

Dokümanı Aktif Guardrail'e Dönüştürmek

Otomatikleştirilebilir kural yalnızca wiki'de bırakılmamalıdır. Lint, CI veya repository policy kullanılabilir. İnsan açıklaması yine korunmalıdır. Error message canonical guideline'a link vermelidir. Böylece doküman gerçek geliştirme davranışına bağlanır.

Aşırı Standardizasyonun Riskleri

Standardizasyon faydalı olsa da aşırıya kaçtığında teslimat ve yenilik hızını düşürebilir. Gereksiz approval, shadow process ve workaround bu durumun işaretleridir. İnsanlar guideline'a güvenmeyi bırakırsa kritik kurallar da etkisini kaybeder. Bu nedenle risk bazlı yaklaşım kullanılmalıdır. Düşük riskli alanda ekip özerkliği korunmalıdır.

Innovation'ın Yavaşlaması

Yeni teknoloji denemek için aylar süren approval gerekiyorsa ekipler yeniliğe uzaklaşabilir. Assess ve Trial kategorileri kontrollü deney alanı sağlar. POC için daha hafif süreç kullanılabilir. Production adoption ise daha güçlü review gerektirebilir. Böylece deney ile risk yönetimi dengelenir.

Developer Friction

Her adımda manuel form ve onay developer friction'ı artırır. Bu maliyet ölçülmelidir. Self-service platform ve automation kullanılabilir. Gereksiz kontrol kaldırılmalıdır. Friction düşük olduğunda compliance daha doğal hale gelir.

Gereksiz Approval

Approval risk azaltmıyorsa yalnızca bekleme üretir. Her değişiklik için manager onayı gerekli olmayabilir. Decision threshold açıkça tanımlanmalıdır. Otomatik check daha hızlı olabilir. Approval cycle time düzenli olarak ölçülmelidir.

Shadow Process

Resmi süreç çok ağır olduğunda ekipler gayriresmi yollar üretir. Bu shadow process risk görünürlüğünü azaltır. Workaround analiz edilmelidir. Süreç neden kullanılmıyor sorusu sorulmalıdır. Daha kolay resmi yol tasarlanmalıdır.

Workaround

Workaround sürekli hale geldiyse guideline veya tooling problemi vardır. Ekipler gizli script veya manuel adım kullanabilir. Feedback loop bu davranışı görünür kılmalıdır. Riskli bypass engellenebilir. Daha iyi official path sunmak kalıcı çözüm olur.

Guideline'a Güvenin Kaybolması

Gereksiz veya eski kurallar guideline sistemine güveni azaltır. Kullanıcı kritik uyarıları da görmezden gelmeye başlayabilir. Katalog düzenli sadeleştirilmelidir. False positive guardrail azaltılmalıdır. Her kural gerçek değer üretmelidir.

Çok Az Standardizasyonun Riskleri

Aşırı standardizasyon kadar hiç standardın bulunmaması da sorun yaratır. Her takım farklı çalıştığında security ve architecture drift oluşabilir. Onboarding süresi uzar ve bakım maliyeti artar. Bilgi kişilerin hafızasında kalır. Minimum Viable Guidelines yaklaşımı iki uç arasında dengeli başlangıç sağlar.

Her Takımın Farklı Çalışması

Her takım farklı branch, release ve monitoring yöntemi kullanırsa ekip geçişi zorlaşır. Platform desteği parçalanır. Merkezi tooling geliştirmek güçleşir. Minimum ortak pattern fayda sağlar. Yerel farklılıklar yalnızca gerçek ihtiyaç varsa korunmalıdır.

Security Drift

Security standardı yoksa ekipler farklı access ve secret yöntemi kullanabilir. Bazı projeler eski yaklaşımda kalabilir. Central minimum ve automated scan bu drift'i azaltır. Riskli deviation exception olarak kayıt altına alınmalıdır. Security posture merkezi olarak görünür olmalıdır.

Architecture Drift

Ortak principle olmadığında benzer problem farklı pattern'lerle çözülür. Dependency ve integration maliyeti artar. Architecture guideline minimum boundary ve approved pattern sunabilir. Takımlar gerektiğinde RFC ile farklı çözüm seçebilir. Böylece çeşitlilik tamamen yasaklanmadan kontrol edilir.

Onboarding Zorluğu

Her ekip farklı çalıştığında yeni çalışan tekrar tekrar süreç öğrenir. Internal transfer bile onboarding gerektirir. Ortak repository ve review standardı bu maliyeti azaltır. Team-specific kurallar yalnızca ek bilgiyi içerir. Merkezi handbook temel yolu gösterir.

Yüksek Bakım Maliyeti

Çok sayıda farklı tool ve pattern support maliyetini artırır. Platform ekibi her kombinasyonu destekleyemez. Preferred technology ve golden path bakım maliyetini düşürür. Takım özel seçim yaptığında ek sahiplik gerekir. TCO bu kararda görünür olmalıdır.

Tribal Knowledge

Kurallar yalnızca deneyimli çalışanların hafızasında kalırsa bus factor yükselir. Yeni kişi sürekli soru sormak zorunda kalır. Kararlar farklı anlatılabilir. Living documentation bu bilgiyi görünür hale getirir. Owner ve version kurumsal hafızayı korur.

Minimum Viable Guidelines Yaklaşımı

İlk günden yüzlerce guideline yazmak yerine en kritik kurallarla başlamak daha etkilidir. Repository, code review, security basics ve ownership gibi alanlar güçlü başlangıç noktalarıdır. Pilot ve developer feedback sonrasında katalog kademeli genişletilebilir. Her yeni kural gerçek problemden üretilmelidir. Bu yaklaşım guideline programının hızlı değer göstermesini sağlar.

İlk Günden 100 Kural Yazmamak

Çok sayıda kural ekibi bunaltabilir. Hangisinin gerçekten önemli olduğu anlaşılmaz. İlk aşamada yüksek riskli ve tekrar eden sorunlara odaklanılmalıdır. Adoption ölçülmelidir. Sistem olgunlaştıkça yeni guideline eklenebilir.

En Kritik 10–20 Kural

İlk set temel engineering risklerini kapsamalıdır. Secret management, review ve CI gibi alanlar öncelikli olabilir. Sayı organizasyona göre değişebilir. Her kuralın owner'ı bulunmalıdır. Minimum set kısa ve uygulanabilir tutulmalıdır.

Pilot

İlk guideline seti birkaç ekipte pilot edilebilir. Friction ve missing rule geri bildirimi toplanır. Enforcement başlangıçta warning modunda tutulabilir. Sonuçlara göre içerik sadeleştirilir. Geniş rollout daha sonra yapılır.

Feedback

Feedback guideline programının erken aşamasında özellikle değerlidir. Ekipler hangi kuralın anlaşılmadığını söyleyebilir. Tooling eksikleri ortaya çıkar. Support soruları analiz edilir. Program gerçek kullanım üzerinden şekillenir.

Kademeli Genişleme

Guideline kataloğu ihtiyaç oluştukça büyütülmelidir. Yeni domain'ler eklenebilir. Her genişleme adoption kapasitesini dikkate almalıdır. Owner ve review yükü planlanmalıdır. Hızlı büyüyen ancak bakılamayan katalog oluşturulmamalıdır.

Kuralları Gerçek İhtiyaçtan Üretmek

Yeni rule gerçek problem veya riskten doğmalıdır. Incident, audit veya tekrar eden review tartışması kaynak olabilir. Kuralın hedefi measurable olmalıdır. “Best practice olduğu için” tek başına gerekçe sayılmamalıdır. Böylece katalog ihtiyaçla birlikte gelişir.

İlk Oluşturulması Gereken Guideline'lar

Yeni guideline programı başlatan şirketler ilk olarak günlük geliştirmeyi ve temel riskleri etkileyen alanlara odaklanabilir. Repository standardı, code review, security, testing ve secrets güçlü başlangıç başlıklarıdır. CI/CD, release, documentation ve ownership sonraki temel katmanı oluşturur. Bu alanlar çoğu ekipte tekrar eden kararlardır. İlk set kısa, ölçülebilir ve otomasyona açık olmalıdır.

Repository Standardı

Repository standardı yeni projelerin ortak başlangıç yapısını oluşturur. Naming, branch protection ve ownership temel maddelerdir. Template ile otomatik uygulanabilir. Yeni proje experience hızlanır. Bu nedenle ilk guideline'lar arasında güçlü adaydır.

Code Review

Code review standardı minimum reviewer ve comment davranışını açıklar. Aynı tartışmaların tekrarını azaltır. Review SLA eklenebilir. Automation mekanik kontrolleri devralır. İnsan review'u design ve correctness'e odaklanır.

Security Basics

Security basics herkesin bilmesi gereken minimum davranışları içerir. Secret, authentication ve dependency güvenliği temel alanlardır. Kısa ve örnekli metin kullanılmalıdır. Kritik maddeler hard gate olabilir. Bu set yeni çalışan onboarding'inde de yer almalıdır.

Testing

Testing guideline hangi değişiklikte hangi test beklendiğini açıklar. Bug fix için regression yaklaşımı tanımlanabilir. Coverage tek hedef yapılmaz. CI testleri otomatik çalıştırır. Ekip risk bazlı test stratejisi geliştirir.

Secrets

Secrets standardı credential'ların nerede tutulacağını netleştirir. Repository içine secret eklemek yasaklanabilir. Secret manager sağlanmalıdır. Scan otomatik çalıştırılmalıdır. Rotation ve incident yolu açıklanmalıdır.

CI/CD

CI/CD minimum build, test ve security adımlarını tanımlar. Merkezi template kullanılabilir. Deployment ve rollback akışı açıklanır. Audit trail otomatik üretilir. Risk seviyesine göre ek gate uygulanabilir.

Release

Release guideline readiness ve rollback beklentisini belirler. Version ve release notes politikası eklenebilir. Critical release monitoring gerektirir. Emergency flow ayrı tanımlanır. Customer communication gereken durumlar açıklanır.

Documentation

Documentation standardı README ve owner gibi minimumları belirler. Kritik servislerde runbook istenebilir. Code change ile doc update birlikte yapılır. Docs-as-code kullanılabilir. Gereksiz belge üretmekten kaçınılır.

Ownership

Her repository ve service için owner bulunmalıdır. Owner support ve lifecycle sorumluluğunu taşır. Organizational directory ile senkron tutulabilir. Sahipsiz sistem alert üretebilir. Ownership birçok diğer guideline'ın temelidir.

30 Günlük Guideline Hazırlama Planı

İlk 30 gün amaç yüzlerce kural yazmak değil, mevcut durumu anlamak ve küçük bir pilot başlatmaktır. Doküman envanteri, PR review analizi, incident incelemesi ve developer interview ile gerçek ihtiyaçlar çıkarılabilir. İkinci hafta ilk taslaklar hazırlanır. Üçüncü hafta workshop ve review yapılır. Dördüncü hafta birkaç ekipte pilot başlatılır.

İlk Hafta — Mevcut Durum

İlk hafta discovery dönemidir. Mevcut belge, tool ve workflow'lar incelenir. Aynı konuda birden fazla kural varsa kayıt altına alınır. Ekiplerden tekrar eden sorunlar toplanır. Hedef ilk guideline backlog'unu oluşturmaktır.

Doküman Envanteri

Mevcut wiki, README ve policy belgeleri listelenir. Owner ve last review bilgisi toplanır. Duplicate ve outdated belgeler işaretlenir. Canonical kaynak adayları belirlenir. Bu inventory merkezi katalog tasarımına temel olur.

PR Review Analizi

Son dönemdeki pull request yorumları örneklenebilir. Tekrar eden naming, test veya security tartışmaları kategorize edilir. Blocking yorumların nedeni incelenir. Review cycle time ölçülür. Sonuç yeni guideline önceliklerine veri sağlar.

Incident Analizi

Yakın dönem incident'ları root cause açısından incelenir. Tekrar eden failure mode'lar belirlenir. Guideline veya guardrail ile önlenebilecek davranışlar çıkarılır. Her incident otomatik kural üretmemelidir. Öncelik risk ve tekrar sıklığına göre verilir.

Developer Interview

Farklı takımlardan geliştiricilerle kısa görüşmeler yapılabilir. “En çok hangi konuda ortak standard eksik?” sorusu güçlü başlangıçtır. Approval ve documentation friction noktaları toplanır. Yeni çalışan deneyimi ayrıca sorulabilir. Nitel feedback sayısal veriyi tamamlar.

İkinci Hafta — İlk Taslaklar

İkinci hafta en kritik 10 ile 20 kural için taslak hazırlanabilir. Her taslak problem, scope, requirement level ve owner alanlarını içermelidir. Doğru ve yanlış örnekler eklenebilir. Otomatik enforcement fırsatları not edilir. Taslakların kısa ve review edilebilir olması önemlidir.

Üçüncü Hafta — Workshop ve Review

Üçüncü hafta etkilenen ekiplerle workshop yapılabilir. Gerçek case'ler üzerinden taslaklar değerlendirilir. Belirsiz maddeler düzeltilir. Security veya architecture uzmanlarından gerekli review alınır. Pilot için minimum olgun sürüm hazırlanır.

Dördüncü Hafta — Pilot

Dördüncü hafta seçilen ekiplerde pilot başlatılır. Baseline ve friction ölçümleri alınır. Otomatik kontroller mümkünse warning modunda çalıştırılır. Developer feedback günlük olarak toplanabilir. Ay sonunda ilk revision backlog'u hazırlanır.

31–60 Günlük Plan

İkinci ay pilot verilerini kullanarak guideline sistemini olgunlaştırma dönemidir. Taslaklar revize edilir ve owner'lar resmileştirilir. Approval sonrası merkezi katalog oluşturulur. En kolay otomatik kontroller devreye alınır. Amaç dokümanları artırmak değil, ilk kuralların gerçekten kullanılmasını sağlamaktır.

Pilot Sonuçlarının İncelenmesi

Pilot compliance, friction ve developer feedback birlikte incelenir. Sadece başarı oranına bakılmaz. Beklenmeyen workaround'lar tespit edilir. Gereksiz rule'lar kaldırılabilir. Sonuçlar kısa retrospective ile kayıt altına alınır.

Guideline Revizyonu

Pilot sonucu metin ve scope güncellenir. Requirement level değişebilir. Örnek ve exception bölümü geliştirilebilir. Tool error message iyileştirilebilir. Yeni sürüm review için hazırlanır.

Owner Ataması

Her guideline için named owner belirlenir. Yedek ekip veya rol de tanımlanabilir. Owner'ın sorumlulukları açıkça paylaşılır. Directory ve katalog güncellenir. Sahipsiz guideline aktif hale getirilmez.

Approval

Olgunlaşan taslaklar riskine uygun approval sürecinden geçer. Düşük riskli maddeler hafif review ile tamamlanabilir. Critical security kuralı daha geniş onay alabilir. Effective date belirlenir. Approval kaydı version history'de tutulur.

Merkezi Katalog

İlk aktif guideline'lar merkezi katalogda yayınlanır. Search ve tagging temel seviyede çalışmalıdır. Owner, scope ve status görünür olur. Deprecated eski belgeler ayrıştırılır. Repository'lerden canonical link verilmeye başlanır.

İlk Otomatik Kontroller

Formatting, branch protection ve secret scan gibi kolay kontroller seçilebilir. Yeni rule önce warning modunda çalıştırılabilir. False positive oranı izlenir. Developer fix experience test edilir. Olgun kontrol daha sonra gate'e dönüştürülebilir.

61–90 Günlük Plan

Üçüncü ay başarılı guideline modelini daha geniş organizasyona yayma dönemidir. Training, starter template ve CI enforcement aynı anda ilerleyebilir. Dashboard ile adoption ve compliance görünür hale getirilir. İlk guideline retrospective yapılarak programın kendisi değerlendirilir. Bu aşamada kurumsal proje yönetimi yönergesi ve süreç tasarımı danışmanlığı ihtiyacı bulunan şirketler, kendi ekip kapasitesine göre dış uzman desteğini de değerlendirebilir.

Şirket Geneline Rollout

Rollout tüm ekipleri tek günde değiştirmek zorunda değildir. Risk ve readiness durumuna göre fazlara ayrılabilir. Her dalgada support sağlanmalıdır. Etkilenen repository listesi otomatik üretilebilir. Adoption dashboard progress'i gösterir.

Developer Training

Training uzun sunumlardan çok gerçek kullanım senaryolarına odaklanmalıdır. İlk PR, security scan ve exception örneği gösterilebilir. Kayıt veya kısa video destek olabilir. Workshop soru cevap alanı sağlar. Training materyali canonical guideline'a yönlendirmelidir.

Starter Templates

Starter template yeni guideline'ları varsayılan hale getirir. Repository, CI ve documentation yapısı hazır gelir. Ekip manuel configuration yapmak zorunda kalmaz. Template versioned tutulmalıdır. Mevcut projeler için migration yolu ayrıca sunulur.

CI Enforcement

Pilot sonrası güvenilir kontroller CI içinde enforcement moduna geçirilebilir. High-risk violation merge'i engelleyebilir. Warning seviyesinde kalan maddeler ayrıca izlenebilir. Hata mesajı fix ve guideline linki verir. Exception path erişilebilir olmalıdır.

Dashboard

Dashboard adoption, compliance ve violation trendlerini gösterir. Metrikler team punishment için kullanılmamalıdır. Support ve automation önceliğini belirlemek amacıyla kullanılmalıdır. Risk seviyesi filtreleri eklenebilir. Data quality düzenli kontrol edilmelidir.

İlk Guideline Retrospective

İlk 90 gün sonunda programın genel durumu değerlendirilir. Hangi kurallar değer üretti ve hangileri friction oluşturdu sorulur. Owner ve review süreci kontrol edilir. Otomasyon backlog'u güncellenir. Sonraki çeyrek için sade bir roadmap hazırlanır.

Guideline Hazırlama Kontrol Listesi

Guideline hazırlama kontrol listesi taslağın temel kalite şartlarını hızlıca doğrular. Her maddenin gerçek probleme dayanması, owner ve scope taşıması önemlidir. Kural spesifik olmalı ve gerekçesi bulunmalıdır. Otomasyon ve exception olasılığı değerlendirilmelidir. Review tarihi olmadan aktif guideline yayınlanmaması iyi bir varsayılandır.

Gerçek Problem Tanımlandı mı?

Kuralın çözdüğü problem açıkça yazılmalıdır. Incident, defect veya tekrar eden tartışma örneği kullanılabilir. Problem yoksa guideline ihtiyacı sorgulanmalıdır. Ölçülebilir etki varsa baseline alınmalıdır. Bu cevap rationale bölümüne temel oluşturur.

Owner Var mı?

Aktif guideline sahipsiz olmamalıdır. Named person veya stable team belirlenebilir. Owner değişiklik, soru ve review sürecini koordine eder. Yedek sorumluluk düşünülebilir. Metadata içinde açıkça gösterilmelidir.

Scope Açık mı?

Hangi takım, repository veya risk seviyesinin etkilendiği belli olmalıdır. “Tüm engineering” yalnızca gerçekten gerekiyorsa kullanılmalıdır. Out-of-scope alanlar belirtilmelidir. Scope otomasyon tarafından okunabilir olabilir. Böylece yanlış enforcement azalır.

Zorunluluk Seviyesi Açık mı?

MUST, SHOULD veya MAY net biçimde seçilmelidir. Enforcement bu seviyeye uygun olmalıdır. Recommended ifade hard gate ile çelişmemelidir. Exception gereksinimi değerlendirilebilir. Kullanıcı neyin zorunlu olduğunu hemen anlayabilmelidir.

Kural Spesifik mi?

Kural ölçülebilir veya değerlendirilebilir davranış tanımlamalıdır. “Kaliteli olun” gibi belirsiz ifadeler yeterli değildir. Tek konuya odaklanmalıdır. Reviewer aynı sonucu verebilmelidir. Örnekler spesifikliği artırır.

Gerekçesi Var mı?

Her önemli kural nedenini açıklamalıdır. Risk veya fayda birkaç cümleyle yazılabilir. Gerekçe adoption'ı artırır. Exception kararını da kolaylaştırır. Gelecekte kuralın hâlâ gerekli olup olmadığını anlamaya yardımcı olur.

Örneği Var mı?

Örnek guideline'ı pratik davranışa çevirir. Doğru ve yanlış örnek birlikte verilebilir. Kod veya configuration gerçek kullanıma yakın olmalıdır. Eski örnekler review sırasında güncellenmelidir. Kısa açıklama öğrenmeyi destekler.

Otomatik Kontrol Edilebilir mi?

Net kural automation açısından değerlendirilmelidir. Lint, CI veya repository rule kullanılabilir. İnsan kararına ihtiyaç varsa bu açıkça belirtilmelidir. Otomasyon maliyeti faydayı aşmamalıdır. Error message developer experience açısından tasarlanmalıdır.

Exception Süreci Var mı?

Her mandatory rule gerçek istisna ihtimalini değerlendirmelidir. Process hafif ve kayıtlı olmalıdır. Approver ve expiry belirlenmelidir. Risk ve compensating control yazılabilir. Çok fazla exception guideline review'u tetiklemelidir.

Review Tarihi Var mı?

Next review aktif guideline için görünür olmalıdır. Risk seviyesine göre süre seçilir. Owner'a otomatik reminder gönderilebilir. Event-driven trigger ayrıca kullanılabilir. Overdue guideline health dashboard'da gösterilebilir.

Guideline Yayına Alma Kontrol Listesi

Yayın öncesinde guideline'ın yalnızca metin olarak değil, operasyonel olarak hazır olduğu doğrulanmalıdır. Stakeholder review ve pilot tamamlanmış olmalıdır. Owner, version ve effective date bulunmalıdır. Migration ve communication ihtiyacı değerlendirilmelidir. Enforcement hazır değilse kuralın nasıl uygulanacağı açıkça belirtilmelidir.

Stakeholder Review Tamamlandı mı?

Etkilenen temel ekiplerden feedback alınmış olmalıdır. Herkesin resmi onayı gerekmez. Critical uzman görüşleri tamamlanmalıdır. Açık concern'ler kayıt altına alınmalıdır. Son karar owner tarafından görünür hale getirilmelidir.

Pilot Yapıldı mı?

Geniş etkili guideline mümkünse pilot edilmelidir. Küçük editorial rule için pilot gerekmeyebilir. Pilot friction ve unintended consequence gösterir. Sonuçlar belgelenmelidir. Yüksek riskli hard gate pilot olmadan yaygınlaştırılmamalıdır.

Owner Onayladı mı?

Owner final sürümün hazır olduğunu doğrulamalıdır. Scope, rationale ve enforcement kontrol edilir. Açık review yorumları çözülmüş olmalıdır. Approval kaydı tutulmalıdır. Owner yayın sonrası support sorumluluğunu da bilmelidir.

Version Verildi mi?

Guideline sürümü açıkça belirtilmelidir. İlk active sürüm basit şekilde 1.0 olabilir. Değişiklik history ile uyumlu tutulmalıdır. Tooling version bilgisini okuyabilir. Repository compliance hangi sürüme göre ölçüldüğünü gösterebilir.

Effective Date Belirlendi mi?

Yürürlük tarihi açık olmalıdır. Migration gerekmiyorsa publication ile aynı gün olabilir. Büyük değişiklikte ileri tarih seçilebilir. Communication bu tarihe göre yapılmalıdır. Enforcement otomatik olarak aynı tarihte devreye girebilir.

Migration Gerekiyor mu?

Yeni guideline mevcut projeleri etkiliyorsa gap analysis yapılmalıdır. Migration effort ve risk değerlendirilir. Deadline ve owner atanır. Otomatik fix fırsatı belirlenir. New project ile legacy project farklı rollout kullanabilir.

İletişim Hazır mı?

Kimlerin etkilendiği ve ne yapması gerektiği açık mesajla anlatılmalıdır. Change Summary ve guideline linki hazırlanır. Migration guide varsa eklenir. Support kanalı belirtilir. Gereksiz geniş mailing yerine hedefli iletişim kullanılabilir.

Enforcement Hazır mı?

Kural otomatik kontrol edilecekse tool yayından önce test edilmelidir. False positive oranı değerlendirilmeli ve error message gözden geçirilmelidir. Exception path çalışmalıdır. İlk dönemde warning mode kullanılabilir. Enforcement kuralın effective date'iyle uyumlu olmalıdır.

Örnek Guideline Şablonu

Aşağıdaki alanlar şirket içi proje yönetimi guideline şablonu ve örnekleri oluşturmak isteyen ekipler için güçlü bir temel sunar. Şablonun amacı her kuralı aynı düşünme çerçevesinden geçirmektir. Gereksiz form alanları eklenmemelidir. Organizasyon büyüdükçe metadata alanları otomasyon için kullanılabilir. Şablon belirli aralıklarla kullanıcı feedback'i üzerinden sadeleştirilmelidir.

ID

Benzersiz guideline ID kullanın. ID başlık değişse bile sabit kalmalıdır. Otomasyon ve referans bağlantılarında kullanılabilir. Kısa kategori prefix'i eklenebilir. Örneğin SEC-001 veya ENG-014 benzeri yapı yeterlidir.

Başlık

Başlık kuralın konusunu birkaç kelimede anlatmalıdır. Kullanıcı aradığında kolay eşleşmelidir. Belirsiz “Genel Kurallar” gibi ifadelerden kaçınılmalıdır. Scope başlığa gereksiz yere eklenmeyebilir. Metadata ayrı alanlarda detay verir.

Amaç

Amaç kuralın hangi sonucu üretmek istediğini açıklar. Risk azaltma veya kalite artışı gibi hedef belirtilebilir. Mümkünse ölçülebilir sonuçla ilişki kurulmalıdır. Çok geniş amaçlardan kaçınılmalıdır. Birkaç kısa cümle yeterlidir.

Scope

Scope geçerli takım, repository ve risk seviyesini açıklar. Technology veya data class eklenebilir. Out-of-scope örnekleri gerekirse belirtilir. Makine okunabilir metadata faydalıdır. Böylece enforcement doğru hedefe uygulanır.

Status

Status Draft, Proposed, Pilot, Active veya Deprecated olabilir. Kullanıcı aktif olmayan kuralı yanlış yorumlamamalıdır. Workflow geçişleri tanımlanmalıdır. Status katalogda görünür olmalıdır. Retired belgeler archive'a taşınabilir.

Requirement Level

Requirement Level MUST, SHOULD veya MAY olarak yazılabilir. Kısa açıklama kullanıcıya anlamı hatırlatır. Enforcement ile tutarlı olmalıdır. Çok fazla MUST kullanımından kaçınılmalıdır. Risk değerlendirmesi seçimde temel olmalıdır.

Kural

Kural açık ve tek davranışa odaklı olmalıdır. Kim, ne zaman ve ne yapacak sorularına cevap verebilir. Belirsiz sıfatlardan kaçınılmalıdır. Test edilebilir şart tercih edilmelidir. Kısa tutmak okunabilirliği artırır.

Rationale

Rationale kuralın neden var olduğunu anlatır. Incident veya risk örneği eklenebilir. Kararın alternatifleri kısaca açıklanabilir. Gelecekte review sırasında bu bölüm önemli veri sağlar. Gerekçe bilinmeyen kurallar kolayca anlamsız hale gelir.

Compliant Example

Compliant Example doğru uygulamayı gösterir. Gerçek kod veya workflow kullanılabilir. Örnek mümkün olduğunca kısa tutulmalıdır. Neden uyumlu olduğu açıklanmalıdır. Gerekli tooling komutu eklenebilir.

Non-Compliant Example

Non-Compliant Example sık görülen hatayı gösterir. Neden sorun olduğu açıkça anlatılmalıdır. Kullanıcı yalnızca yasak değil alternatif de görmelidir. Riskli gerçek credential gibi içerik kullanılmamalıdır. Örnek düzenli güncellenmelidir.

Enforcement

Enforcement CI, lint, manual review veya başka yöntemle açıklanır. Tool adı ve kontrol noktası belirtilebilir. Error message ilgili guideline ID'yi göstermelidir. Otomasyon yoksa neden olmadığı yazılabilir. Gelecekte automation backlog'una eklenebilir.

Exception

Exception bölümü özel durumda izlenecek yolu açıklar. Request linki, approver ve expiry şartı belirtilir. Business ve technical justification istenebilir. Risk değerlendirmesi dahil edilir. Permanent exception varsayılan olmamalıdır.

Owner

Owner guideline yaşam döngüsünden sorumlu kişi veya ekip olmalıdır. Contact yolu görünür tutulabilir. Owner değişiklikleri version history'de izlenir. Yedek sorumluluk eklenebilir. Active belgede owner boş olmamalıdır.

Version

Version aktif kural sürümünü gösterir. Değişiklik türüne göre artış yapılabilir. Breaking değişiklik açıkça işaretlenir. History linki eklenebilir. Otomasyon version bilgisine göre davranabilir.

Effective Date

Effective Date kuralın ne zaman zorunlu hale geldiğini gösterir. Migration period varsa publication'dan farklı olabilir. Tarih açık formatta yazılmalıdır. Enforcement bu tarihe bağlı olabilir. Kullanıcı eski ve yeni sürümü karıştırmamalıdır.

Review Date

Review Date kuralın tekrar değerlendirileceği tarihi gösterir. Risk seviyesine göre süre belirlenir. Owner reminder alabilir. Event-driven review ayrıca tetiklenebilir. Overdue durum katalogda görünür olabilir.

Guideline KPI'ları

Guideline programı ölçülebilir göstergelerle yönetilmelidir. Adoption, compliance, exception ve violation trend başlangıç metrikleridir. Developer satisfaction ve onboarding time insan tarafını görünür hale getirir. Incident ve defect reduction gerçek iş sonucunu gösterir. KPI'lar ekipleri cezalandırmak yerine sistem iyileştirmek amacıyla kullanılmalıdır.

Adoption Rate

Adoption Rate kaç ekip veya repository'nin guideline'ı kullanmaya başladığını gösterir. Template usage ve active policy coverage kullanılabilir. Yüksek adoption düşük quality ile birlikte değerlendirilebilir. Trend rollout progress'ini gösterir. Düşük adoption root cause araştırmasını tetiklemelidir.

Compliance Rate

Compliance Rate aktif kurallara uyum seviyesini gösterir. Severity weighting kullanılabilir. Kritik tek violation toplam yüzdeden daha önemli olabilir. Coverage düşükse oran yanıltıcıdır. Repository ve team coverage ile birlikte gösterilmelidir.

Exception Rate

Exception Rate kuraldan sapma taleplerini ölçer. Çok yüksek oran guideline scope problemini gösterebilir. Gerekçe kategorileri analiz edilmelidir. Kısa dönem migration etkisi ayrı değerlendirilir. Trend retrospective için güçlü girdidir.

Violation Trend

Violation Trend ihlallerin zaman içinde artıp azaldığını gösterir. Yeni rule ilk günlerde yüksek violation üretebilir. Migration sonrası düşüş beklenir. Sürekli sabit kalan ihlaller tooling veya ownership sorunu olabilir. Severity bazlı grafik daha anlamlıdır.

Mean Time to Fix

Mean Time to Fix violation'ın çözülme süresini ölçer. High severity için daha kısa hedef belirlenebilir. Uzun süre fix'in zor olduğunu gösterebilir. Otomatik remediation etkisi bu metrikle görülebilir. Median ve percentile değerleri ortalamayı tamamlayabilir.

Developer Satisfaction

Developer Satisfaction guideline'ın günlük deneyime etkisini gösterir. Kısa periyodik survey kullanılabilir. “Kuralı bulmak kolay mı?” ve “uygulamak kolay mı?” gibi somut sorular tercih edilmelidir. Tek skor yerine yorumlar analiz edilmelidir. Sonuçlar DX backlog'una dönüşebilir.

Onboarding Time

Onboarding Time yeni geliştiricinin temel görevleri bağımsız yapma süresidir. İlk PR ve ilk deployment ölçülebilir. Guideline kataloğu ve golden path bu süreyi azaltabilir. Çok fazla doküman tam tersine olumsuz etki yaratabilir. New hire feedback ile veri desteklenmelidir.

Incident Reduction

Incident Reduction özellikle reliability ve security guideline için önemli outcome metriğidir. İlgili incident kategorisi izlenmelidir. Sistem sayısı veya trafik artışı sonucu etkileyebilir. Baseline ile normalize etmek gerekebilir. Guideline ile doğrudan nedensellik iddiası dikkatli kurulmalıdır.

Defect Reduction

Defect Reduction testing ve review guideline'ın etkisini gösterebilir. Production bug severity ile birlikte izlenmelidir. Release sayısı değişiyorsa oran kullanmak daha doğru olabilir. Rework ve customer report sayısı ek sinyal olabilir. Sonuçlar quality guild tarafından review edilebilir.

Guideline Olgunluk Modeli

Guideline olgunluk modeli organizasyonun mevcut durumunu anlamaya yardımcı olur. Tribal knowledge seviyesinden merkezi kataloğa, otomatik guardrail'lerden data-driven governance'a kadar gelişim yolu tanımlanabilir. Amaç her şirketi zorla en üst seviyeye taşımak değildir. İşletmenin risk ve büyüklüğüne uygun seviye seçilmelidir. Model roadmap oluşturmak için pratik referans sağlar.

Seviye 0 — Tribal Knowledge

Kurallar insanların hafızasında bulunur. Yeni çalışan sürekli soru sormak zorundadır. Code review kişiye göre değişebilir. Bus factor yüksektir. İlk hedef kritik bilgiyi yazılı hale getirmektir.

Seviye 1 — Dağınık Dokümanlar

Wiki ve README içinde çeşitli belgeler vardır. Ancak canonical source belli olmayabilir. Çelişkili ve eski içerik sık görülür. Owner bilgisi eksiktir. Merkezi inventory sonraki adım için temel olur.

Seviye 2 — Merkezi Guideline Kataloğu

Aktif guideline'lar tek katalogda bulunur. Search ve taxonomy vardır. Standart template kullanılır. Kullanıcı resmi kaynağı bilir. Ancak enforcement hâlâ büyük ölçüde manuel olabilir.

Seviye 3 — Owner ve Version Yönetimi

Her guideline owner, version ve review date taşır. RFC ve exception süreçleri oturmuştur. Change history görünürdür. Governance yaşam döngüsü yönetilir. Bu seviye sürdürülebilir dokümantasyon sağlar.

Seviye 4 — Otomatik Guardrail'ler

Net kurallar CI ve repository policy ile otomatik uygulanır. Scorecard compliance'ı görünür hale getirir. Starter template doğru davranışı varsayılan yapar. Developer portal self-service sağlar. İnsan review'u yüksek bağlamlı konulara odaklanır.

Seviye 5 — Data-Driven Continuous Governance

Guideline etkisi gerçek outcome metrikleriyle ölçülür. Continuous feedback ve retrospective çalışır. AI-aware rule management uygulanabilir. Gereksiz kurallar veriyle kaldırılır. Governance sürekli iyileştirilen ürün gibi yönetilir.

Seviye 0 — Tribal Knowledge

Seviye 0'da şirketin çalışma biçimi büyük ölçüde deneyimli çalışanların hafızasına dayanır. Bu yapı küçük ekipte bir süre çalışabilir. Ekip büyüdüğünde bilgi aktarımı ciddi darboğaz haline gelir. İlk hedef her şeyi belgelemek değil, kritik ve tekrar eden bilgiyi görünür hale getirmektir. Repository, review ve security gibi temel konular iyi başlangıç noktalarıdır.

Kurallar Senior'ların Kafasında

Karar bilgisinin birkaç senior geliştiricide kalması bus factor yaratır. Yeni çalışan aynı soruları tekrar tekrar sorar. Farklı senior'lar farklı cevap verebilir. En sık sorulan konular guideline adayıdır. Bilgi kısa belge ve örneklerle dışsallaştırılmalıdır.

Yeni Çalışanların Sürekli Soru Sorması

Soru sormak normal ve değerlidir. Ancak aynı temel sorular sürekli tekrar ediyorsa documentation eksikliği vardır. Soru kategorileri toplanabilir. Handbook ve FAQ geliştirilebilir. Amaç insan iletişimini azaltmak değil, tekrar eden bilgi ihtiyacını kolaylaştırmaktır.

Tutarsız Code Review

Standart yoksa reviewer kişisel tercihini zorunlu kural gibi sunabilir. Aynı kod farklı reviewer'dan farklı sonuç alabilir. Common review guideline bu tutarsızlığı azaltır. Formatting automation'a bırakılabilir. Blocking kriteri açıkça tanımlanmalıdır.

Yüksek Bus Factor

Tek kişinin ayrılması önemli bilginin kaybolmasına yol açabilir. Owner ve shared documentation bu riski azaltır. Pairing ve guild bilgi paylaşımını destekler. Kritik süreçler runbook'a dönüştürülebilir. Bus factor düzenli olarak service ownership kapsamında değerlendirilebilir.

Seviye 1 — Dağınık Dokümantasyon

Seviye 1'de bilgiler yazılıdır ancak farklı sistemlerde dağınık halde bulunur. Wiki, README ve eski sunumlar aynı konuda farklı kurallar içerebilir. Kullanıcı hangi belgenin güncel olduğunu bilmez. İlk iyileştirme merkezi inventory ve canonical source belirlemektir. Eski belgeler archived edilip yeni kaynağa yönlendirilmelidir.

Wiki

Wiki kolay içerik üretimini sağlar. Ancak governance yoksa hızla yüzlerce eski sayfa birikir. Owner ve review date eklenmelidir. Search kalite kontrolü önemlidir. Canonical guideline bölümü oluşturulabilir.

README

README proje özelinde değerli bilgi taşır. Ancak company-wide standardın kopyasını içinde tutmak drift yaratabilir. Merkezi guideline'a link verilmelidir. Repository-specific kurallar local kalabilir. README yalnızca ilgili bilgiyi içermelidir.

Eski Sunumlar

Sunumlar belirli toplantı anını yansıtır. Yıllar sonra resmi kural gibi kullanılmamalıdır. Kalıcı kararlar canonical guideline'a taşınmalıdır. Eski sunum reference olarak archive edilebilir. Search sonuçlarında aktif dokümandan daha önde görünmemelidir.

Farklı Takımlarda Çelişkili Kurallar

Takımlar zamanla farklı practice geliştirebilir. Bu her zaman problem değildir. Ancak global risk alanında çelişki varsa precedence gerekir. Ortak guild konuyu değerlendirebilir. Yerel farklılık gerekçeli şekilde korunabilir.

Seviye 2 — Merkezi Guideline Kataloğu

Seviye 2'de şirket aktif kuralları merkezi ve aranabilir katalogda toplar. Single Source of Truth yaklaşımı ile resmi kaynak netleşir. Taxonomy ve search bilgiye erişimi kolaylaştırır. Standart template her guideline'ın aynı temel alanları taşımasını sağlar. Bu seviye dokümantasyon düzeni açısından önemli sıçramadır.

Single Source of Truth

Her aktif guideline tek canonical kaynağa sahip olmalıdır. Duplicate kopyalar redirect ile kapatılabilir. Version yalnızca ana kaynakta yönetilir. Diğer sistemler link verir. Böylece kullanıcı güncel belgeyi kolayca bulur.

Taxonomy

Taxonomy guideline'ları domain, technology ve lifecycle gibi kategorilerle düzenler. Çok derin hiyerarşi aramayı zorlaştırabilir. Tag tabanlı model esnek olabilir. Kullanıcı davranışı üzerinden taxonomy iyileştirilebilir. Related Guidelines navigasyonu destekler.

Search

Search merkezi kataloğun en önemli özelliklerinden biridir. Title, tag ve content içinde arama yapılabilir. Deprecated belge açıkça işaretlenir. Search query analytics eksik keyword'leri gösterir. Sonuç kalitesi düzenli olarak test edilmelidir.

Standart Template

Template problem, scope, rule ve owner gibi alanları standardize eder. Kullanıcı her belgede bilgiyi aynı yerde bulur. Yazar önemli alanları unutmaz. Template gereksiz uzun olmamalıdır. Kullanım feedback'i üzerinden sadeleştirilmelidir.

Seviye 3 — Yönetilen Guidelines

Seviye 3 guideline'ların sadece yayınlanmadığı, yaşam döngüsüyle yönetildiği aşamadır. Owner, version, review date ve RFC gibi mekanizmalar devreye girer. Exception Management kayıtlı şekilde çalışır. Değişikliklerin neden ve ne zaman yapıldığı görülebilir. Bu aşama dokümantasyonu sürdürülebilir governance sistemine dönüştürür.

Owner

Her guideline named owner taşır. Sorular ve review bu role yönlendirilir. Owner ayrılırsa devir yapılır. Merkezi katalog ownerless belgeleri gösterebilir. Ownership aktif bakımın temelidir.

Version

Version değişiklik etkisini görünür kılar. Breaking update ile minor edit ayrılır. Effective date sürümle birlikte tutulur. Repository uyumu version bazında ölçülebilir. History geçmiş kararı korur.

Review Date

Review Date belgenin güncelliğini yönetir. Otomatik reminder owner'a gönderilir. Overdue guideline dashboard'da görünür olur. Event-driven review ayrıca çalışabilir. “No change” kararı bile kayıt altına alınabilir.

RFC

RFC büyük değişikliklerde şeffaf tartışma sağlar. Problem ve proposal açıkça yazılır. Stakeholder feedback toplanır. Karar ve rationale saklanır. Böylece standard değişiklikleri kişisel karardan ortak mühendislik sürecine dönüşür.

Exception Management

Exception resmi ve süreli süreç üzerinden yönetilir. Business ve technical justification kaydedilir. Approver risk seviyesine göre seçilir. Expiry otomatik takip edilir. Tekrarlanan exception guideline improvement için veri sağlar.

Seviye 4 — Automated Governance

Seviye 4'te guideline'ların önemli bölümü otomatik guardrail'lere dönüşür. CI Checks, repository policies ve scorecard sistemleri compliance'ı sürekli ölçer. Automated Fix geliştiricinin manuel iş yükünü azaltır. Developer Portal doğru rule set'i bağlamsal olarak gösterir. İnsan review'u makinenin yapamadığı yüksek bağlamlı kararlara odaklanır.

CI Checks

CI formatting, test ve security policy'lerini otomatik kontrol eder. Pull request aşamasında hızlı feedback verir. Error message ilgili guideline'a link verir. False positive düzenli izlenir. Risk bazlı gate seviyesi uygulanır.

Repository Policies

Repository Policy branch protection ve required review gibi şartları merkezi uygular. Yeni repository otomatik doğru profile bağlanır. Manual configuration drift azalır. Exception kayıtlı şekilde yönetilir. Policy version history tutulmalıdır.

Scorecards

Scorecard repository'nin guideline posture'unu özetler. Security, reliability ve documentation alanları ayrı gösterilir. Critical issue basit ortalama içinde kaybolmamalıdır. Ekip gerekli aksiyonu görebilmelidir. Score punishment aracı olarak kullanılmamalıdır.

Automated Fix

Automated Fix compliance maliyetini önemli ölçüde azaltır. Bot PR, formatter veya codemod kullanılabilir. Fix güvenli ve review edilebilir olmalıdır. Büyük migration'da batch rollout yapılabilir. Developer effort daha değerli işlere ayrılır.

Developer Portal

Developer Portal rule, owner ve score bilgisini bir araya getirir. Repository seçildiğinde yalnızca ilgili guideline'lar gösterilebilir. Self-service resource oluşturma sağlanabilir. Search ve documentation aynı yerde sunulur. Bu yapı governance'ı günlük workflow'a taşır.

Seviye 5 — Continuous Governance

Seviye 5'te guideline sistemi statik kurallardan sürekli öğrenen governance modeline dönüşür. Impact Metrics gerçek iş sonucunu ölçer. Continuous Feedback kural tasarımını düzenli olarak besler. Automated Enforcement ve AI-aware guideline'lar aynı canonical kaynağa bağlanır. Retrospective ile işe yaramayan kurallar kaldırılır veya sadeleştirilir.

Guideline Impact Metrics

Impact metric incident, defect, onboarding veya delivery sonucunu ölçer. Compliance yalnızca ara göstergedir. Baseline ile değişim karşılaştırılır. Sonuç guideline review'a veri sağlar. Değer üretmeyen kural kaldırılabilir.

Continuous Feedback

Developer feedback sürekli erişilebilir olmalıdır. Portal veya repository üzerinden kolay feedback verilebilir. Support ve exception verileri de sinyal sağlar. Owner düzenli analiz yapar. Değişiklik sonuçları kullanıcılara geri bildirilir.

Automated Enforcement

Olgun kurallar otomatik ve güvenilir şekilde uygulanır. Enforcement risk seviyesine göre değişir. Warning, soft gate ve hard gate birlikte kullanılabilir. False positive düşük tutulur. Exception self-service ancak kontrollü olabilir.

AI-Aware Guidelines

Guideline sistemi AI-assisted development davranışını da kapsar. Human ve AI aynı kurumsal standarda tabi olur. Repository instruction ve CI enforcement birlikte çalışır. Data security sınırları açıkça tanımlanır. Tool değişiklikleri review trigger olabilir.

Sürekli Guideline Retrospective

Retrospective yalnızca yıllık büyük toplantı olmak zorunda değildir. Kural bazında otomatik health sinyalleri kullanılabilir. Yüksek exception veya friction review tetikler. Owner gerekli değişikliği küçük iteration'larla yapar. Governance böylece yaşayan mühendislik ürününe dönüşür.

Sık Sorulan Sorular

Şirket İçi Proje Yönergelerinin (Guidelines) Hazırlanma Süreçleri hakkında en sık karşılaştığım sorular genellikle guideline ile policy arasındaki fark, kimlerin onay vermesi gerektiği ve uyumun nasıl ölçüleceği etrafında toplanır. Bunun nedeni şirketlerin çoğu zaman belge yazmayı süreç tasarımıyla aynı şey sanmasıdır. Oysa iyi guideline; problem, owner, scope, zorunluluk seviyesi, enforcement ve review döngüsünü birlikte ele alır. Aşağıdaki cevaplar hem teknik ekipler hem de proje yönetimi sorumluları için hızlı referans olarak kullanılabilir. Kurumsal proje yönetimi yönergesi ve süreç tasarımı danışmanlığı değerlendirirken de bu sorular temel kontrol noktaları olarak işe yarar.

Şirket içi proje yönergesi nedir?

Şirket içi proje yönergesi ekiplerin ortak çalışma ve mühendislik beklentilerini açıklar. Proje başlangıcı, review, testing, release ve ownership gibi alanları kapsayabilir. Her kural aynı zorunluluk seviyesinde olmak zorunda değildir. Scope ve exception süreci açık olmalıdır. En iyi guideline gerçek bir probleme dayanır.

Guideline ile policy arasındaki fark nedir?

Policy üst seviyede kurumun zorunlu prensibini tanımlar. Guideline ise bu prensibin uygulanmasına yardımcı olan daha pratik rehberdir. Policy çoğu zaman daha bağlayıcıdır. Guideline MUST, SHOULD ve MAY gibi farklı seviyeler içerebilir. İki belge türünün ilişkisi açıkça tanımlanmalıdır.

Guideline ile standard arasındaki fark nedir?

Standard minimum zorunlu teknik veya operasyonel şartı tanımlama eğilimindedir. Guideline ise tercih edilen yöntem ve örnekleri daha geniş açıklayabilir. Kurum kendi terminolojisini netleştirmelidir. Aynı kelimelerin ekiplerde farklı anlamda kullanılması önlenmelidir. Zorunluluk seviyesi belge üzerinde açıkça gösterilmelidir.

SOP ile guideline aynı şey midir?

Hayır, aynı şey değildir. SOP belirli işlemin adım adım nasıl yapılacağını açıklar. Guideline ise tercih edilen yaklaşımı ve kuralları tanımlar. Örneğin release guideline genel beklentiyi, emergency release SOP ise adımları açıklayabilir. İki belge birbirine bağlantı verebilir.

Yazılım geliştirme standartları nasıl hazırlanır?

Önce gerçek problemler ve riskler belirlenmelidir. Code review, incident ve developer feedback verileri kullanılabilir. Sonra scope, requirement level ve owner tanımlanır. Taslak pilot edilir ve feedback ile revize edilir. Otomasyona uygun maddeler CI veya repository policy ile uygulanır.

Coding guidelines nasıl oluşturulur?

Coding guideline naming, formatting, error handling ve dependency gibi alanları kapsayabilir. Mekanik kurallar formatter ve lint'e bırakılmalıdır. İnsan guideline'ı daha çok rationale ve önemli engineering choice'ları açıklamalıdır. Language-specific detaylar ayrı belgede tutulabilir. Kurallar gerçek kod örnekleriyle desteklenmelidir.

Guideline'ı kim yazmalıdır?

Guideline probleme en yakın uzmanlar tarafından ortaklaşa hazırlanmalıdır. Engineering Lead, Senior Developer veya ilgili domain uzmanı taslağa liderlik edebilir. Etkilenen ekipler review ve pilot sürecine dahil edilmelidir. Tek kişinin görüşü company-wide standarda dönüşmemelidir. Nihai owner ayrıca belirlenmelidir.

Guideline'ı kim onaylamalıdır?

Onay seviyesi kuralın riskine ve kapsamına göre değişmelidir. Düşük riskli coding guideline için ilgili owner yeterli olabilir. Security veya compliance etkisi bulunan kurallarda ilgili uzman onayı gerekebilir. Leadership approval yalnızca geniş organizasyonel etki olduğunda kullanılmalıdır. RACI matrisi sorumluluğu açık hale getirir.

Guideline'lar ne sıklıkla güncellenmelidir?

Tek bir sabit süre her guideline için doğru değildir. Security ve technology guideline daha sık review edilebilir. Process guideline daha uzun aralık kullanabilir. Incident, audit veya regülasyon değişikliği erken review tetikleyebilir. Her guideline metadata'sında Next Review alanı bulunmalıdır.

Guideline'lar Git ile yönetilebilir mi?

Evet, özellikle teknik guideline'lar Git ile oldukça etkili yönetilebilir. Markdown belgeler pull request üzerinden review edilebilir. Version history doğal olarak korunur. CODEOWNERS uygun uzmanları reviewer olarak atayabilir. Merge sonrası otomatik dokümantasyon yayını yapılabilir.

Docs-as-code nedir?

Docs-as-Code dokümantasyonu kod geliştirme yöntemleriyle yönetme yaklaşımıdır. Git, Markdown, pull request ve CI temel araçlardır. Link checking ve documentation test otomatik çalıştırılabilir. Değişiklik geçmişi güvenilir biçimde tutulur. Teknik ekiplerin katkı yapması kolaylaşır.

Guidelines-as-code nedir?

Guidelines-as-Code yazılı kuralların uygun bölümünü otomatik kontrole dönüştürür. CI, lint, repository policy ve policy engine kullanılabilir. İnsan dokümanı kuralın nedenini açıklamaya devam eder. Makine net şartı otomatik doğrular. İki taraf mümkün olduğunca aynı canonical kaynağa bağlı tutulmalıdır.

Her guideline zorunlu mudur?

Hayır, guideline içindeki her madde zorunlu olmak zorunda değildir. MUST zorunlu, SHOULD güçlü öneri ve MAY opsiyonel davranışı ifade edebilir. Risk düşükse tavsiye seviyesi yeterli olabilir. Her şeyi MUST yapmak gereksiz friction üretir. Zorunluluk seviyesi açıkça yazılmalıdır.

Guideline exception nasıl yönetilir?

Exception resmi talep üzerinden kayıt altına alınmalıdır. Business ve technical justification yazılmalıdır. Risk ve compensating control değerlendirilir. Approver ile expiry date belirlenir. Tekrarlanan exception'lar guideline review için sinyal olarak kullanılmalıdır.

Engineering guild nedir?

Engineering Guild farklı takımlardaki benzer uzmanların ortak çalışma grubudur. Architecture, security veya backend gibi alanlarda kurulabilir. Ortak guideline ve pattern geliştirebilir. Yönetim hiyerarşisinin yerine geçmez. Bilgi paylaşımı ve dağıtık ownership sağlar.

Yeni programlama dili şirket içinde nasıl onaylanmalıdır?

Yeni programlama dili iş ihtiyacı ve teknik kriterlerle değerlendirilmelidir. Team skill, security, maintenance ve TCO incelenir. Küçük pilot veya RFC kullanılabilir. Technology radar üzerinde Assess veya Trial statüsü verilebilir. Başarılı sonuç sonrası Approved veya Preferred hale getirilebilir.

Yazılımcı olmak için şirket standartlarını bilmek gerekli midir?

Profesyonel ekip çalışmasında şirket standartlarını bilmek önemlidir. Git, code review, testing ve security günlük geliştirme işinin parçasıdır. Ancak standardı ezberlemek tek başına yeterli değildir. Geliştirici nedenini anlamalı ve gerektiğinde iyileştirme önermelidir. Mühendislik yargısı her zaman önemini korur.

Açık kaynak projelerde contribution guidelines nedir?

Contribution Guidelines contributor'ın projeye nasıl katkı yapacağını açıklar. Setup, issue, pull request ve test beklentileri bulunabilir. Code of Conduct ve security policy ile birlikte çalışır. İlk katkı deneyimini kolaylaştırmalıdır. Open source projelerde şeffaf governance özellikle önemlidir.

AI coding assistant'lar için şirket yönergesi gerekli midir?

Evet, özellikle hassas veri ve source code erişimi nedeniyle açık kurallar faydalıdır. Hangi tool'ların approved olduğu belirtilmelidir. Prompt içinde hangi bilgilerin kullanılamayacağı açıklanmalıdır. AI-generated code normal review ve security sürecinden geçmelidir. Human approval nihai sorumluluğu korur.

Guideline uyumu nasıl ölçülür?

Compliance Rate, Repository Coverage ve Exception Rate temel göstergeler olabilir. Otomatik rule sonuçları merkezi dashboard'da toplanabilir. Ancak yalnızca yüzdeye bakmak yeterli değildir. Developer friction ve gerçek iş outcome'u da ölçülmelidir. Risk bazlı scorecard daha anlamlı görünüm sağlar.

Guideline'ın işe yaramadığı nasıl anlaşılır?

Kural yüksek friction yaratırken hedeflenen risk değişmiyorsa faydası sorgulanmalıdır. Incident veya defect oranı düşmeyebilir. Exception sayısı sürekli artabilir. Geliştiriciler workaround kullanabilir. Retrospective bu sinyalleri bir araya getirerek revizyon veya kaldırma kararı sağlar.

Şirket içi proje yönergeleri nasıl hazırlanır ve hangi bölümleri içermelidir?

Şirket içi proje yönergeleri gerçek problem tanımıyla başlamalıdır. Amaç, scope, requirement level, kural, rationale, örnek, enforcement, exception, owner ve review date temel bölümlerdir. Taslak ilgili ekiplerle review edilmeli ve mümkünse pilot edilmelidir. Kurallar gerçek davranışa bağlanmalı ve ölçülebilir olmalıdır. Şirket içi proje yönetimi yönergesi nasıl hazırlanır sorusunun en kısa cevabı, kural yazmadan önce problem ve sahiplik modelini netleştirmektir.

Proje yönetimi yönergelerinde rol, sorumluluk ve yetki matrisi nasıl tanımlanmalıdır?

Rol ve sorumluluk için RACI matrisi kullanılabilir. Responsible işi yapan, Accountable nihai sorumluluğu taşıyan, Consulted görüşü alınan ve Informed bilgilendirilen tarafı gösterir. Her süreçte tek Accountable bulunması karar belirsizliğini azaltır. Approval seviyeleri kuralın riskine göre farklılaştırılmalıdır. Proje yönergesinde görev yetki sorumluluk ve onay süreçleri nasıl belirlenir sorusuna en pratik cevap, lifecycle aşamalarının her biri için RACI tanımlamaktır.

Kurumsal proje yönergeleri hazırlanırken PMI, Agile ve şirket içi standartlar nasıl uyumlu hale getirilir?

Dış metodolojiler doğrudan kopyalanmak yerine kurumun gerçek çalışma biçimine uyarlanmalıdır. PMI daha yapılandırılmış governance ve sorumluluk çerçevesi sunarken Agile iteratif planlama ve hızlı feedback yaklaşımını destekleyebilir. Şirket içi standartlar security, release ve architecture gibi kuruma özel zorunlulukları ekler. Ortak noktalar tek guideline altında birleştirilebilir. Kullanılan çerçevenin adı değil, ekibin riskleri yönetirken değer üretmesini kolaylaştırması önemlidir.

Hazırlanan proje yönergelerinin ekipler tarafından uygulanması ve güncel tutulması nasıl sağlanır?

Yönergeler günlük geliştirme akışına bağlanmalıdır. Starter template, CI kontrolü, developer portal ve onboarding bu konuda güçlü araçlardır. Her guideline için owner, version ve next review date bulunmalıdır. Developer feedback ve exception verileri düzenli olarak incelenmelidir. Kullanılmayan veya eski kalan kurallar revize edilmeli ya da kaldırılmalıdır.

Şirket içi proje yönetimi yönergesi hazırlama danışmanlığı yakınımda nerede bulabilirim?

Proje yönetimi süreç ve prosedür danışmanlığı yakınımda şeklinde arama yaparken yalnızca doküman yazan bir hizmet yerine süreç analizi, ekip görüşmeleri, governance tasarımı ve otomasyon yaklaşımı sunan yapıları değerlendirmek daha sağlıklı olur. Danışmanlık öncesinde mevcut incident, review ve workflow verilerinin incelenmesi önemlidir. Hazırlanan guideline'ın kullanılabilir ve ölçülebilir olması hedeflenmelidir. Diyarbakır Yazılım Topluluğu'nun çalışmaları, projeleri ve topluluk yaklaşımı hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr adresini inceleyebilirsiniz. Kurumsal proje yönetimi yönergesi ve süreç tasarımı danışmanlığı değerlendirirken gerçek ihtiyacı, uygulanabilirliği ve uzun vadeli sahipliği birlikte ele almak en doğru sonucu verir.

Sonuç — İyi Guideline Yazılan Değil, Kullanılan ve Sürekli İyileştirilen Guideline'dır

Şirket İçi Proje Yönergelerinin (Guidelines) Hazırlanma Süreçleri, yalnızca iyi metin yazma işi değildir. Başarılı bir sistem gerçek problemleri tanımlar, ekipleri tasarım sürecine dahil eder, ownership oluşturur ve mümkün olan kontrolleri otomasyona bağlar. Guideline'lar canlı tutulmalı, version ve review tarihleri yönetilmeli, gereksiz hale gelen kurallar kaldırılmalıdır. En güçlü yaklaşım doğru davranışı geliştirici için en kolay yol haline getirmektir. Kendi ekiplerinizde guideline, açık kaynak contribution süreçleri veya sürdürülebilir yazılım topluluğu modelleri üzerine çalışmak istiyorsanız https://www.diyarbakiryazilim.com.tr üzerinden Diyarbakır Yazılım Topluluğu'na ulaşabilirsiniz.

Gerçek Bir Problemden Başlamalıdır

Her guideline gerçek bir ihtiyaca dayanmalıdır. Incident, review tartışması veya tekrar eden hata güçlü başlangıç noktalarıdır. Problem yoksa kural yazmak yerine mevcut süreç izlenebilir. Ölçülebilir baseline etkisini değerlendirmeyi kolaylaştırır. Böylece guideline teorik değil, gerçek soruna yönelik olur.

Ekiplerle Birlikte Hazırlanmalıdır

Etkilenen ekiplerin katkısı guideline kalitesini artırır. Workshop, RFC ve pilot kullanılabilir. Merkezi ekip gerçek kullanım detaylarını bu yolla öğrenir. Katılım adoption'ı güçlendirir. Son karar sahipliği yine açık role bağlı tutulabilir.

Owner ve Version Sahibi Olmalıdır

Her active guideline named owner taşımalıdır. Version değişiklik geçmişini görünür kılar. Owner review ve exception sürecini koordine eder. Ayrılma durumunda ownership transfer edilir. Bu iki alan sürdürülebilirliğin temelidir.

Zorunluluk Seviyesi Açık Olmalıdır

MUST, SHOULD ve MAY ayrımı kullanıcıya beklentiyi gösterir. Her şeyi zorunlu yapmak sağlıklı değildir. Risk seviyesi requirement level seçiminde kullanılmalıdır. Enforcement aynı seviyeye uygun olmalıdır. Böylece kritik ve tavsiye niteliğindeki kurallar karışmaz.

Uygulanması Kolay Olmalıdır

Doğru davranış geliştirici için mümkün olduğunca kolay hale getirilmelidir. Template, golden path ve self-service araçlar bu hedefi destekler. Manuel compliance süresi ölçülmelidir. Error message açık fix göstermelidir. Kolay uygulanan guideline daha yüksek adoption üretir.

Mümkün Olan Kurallar Otomatik Kontrole Dönüştürülmelidir

Formatting, lint ve branch protection gibi net kurallar otomatikleştirilebilir. Bu yaklaşım insan reviewer'ın zamanını korur. CI erken feedback verir. Otomatik fix eklenirse friction daha da düşer. İnsan kararı gereken alanlar ise zorla makine kuralına çevrilmemelidir.

Exception Mekanizması Bulunmalıdır

Gerçek dünyada istisnalar oluşabilir. Resmi exception süreci riskin görünür kalmasını sağlar. Gerekçe, approver ve expiry kaydedilmelidir. Tekrarlanan exception guideline review'u tetiklemelidir. Böylece esneklik kontrolsüz bypass'a dönüşmez.

Etkisi Ölçülmelidir

Guideline'ın başarısı yalnızca compliance yüzdesiyle değerlendirilmemelidir. Incident, defect, delivery ve developer friction gibi sonuçlar izlenmelidir. Baseline ile karşılaştırma yapılmalıdır. Değer üretmeyen kural revize edilmelidir. Ölçüm öğrenme ve iyileştirme amacıyla kullanılmalıdır.

Değişen Teknoloji ve Kurum İhtiyaçlarına Göre Sürekli Güncellenmelidir

Teknoloji, ekip yapısı ve iş gereksinimleri sürekli değişir. Guideline bu değişimlerden bağımsız kalamaz. Owner ve review schedule güncelliği korur. Incident ve büyük platform değişimi event-driven review başlatabilir. Yaşayan guideline kültürü, kurumsal mühendislik standartlarının uzun vadede gerçekten kullanılmasını sağlar.