# Nasıl mühendislik yapıyoruz > Tignex'in ne geliştireceğine, neyi geliştirmeyi reddedeceğine ve neyi açıkça yazacağına karar veren dört taahhüt. - Güncelleme: 2026-09-15 - Kaynak: https://tignex.com/tr/muhendislik/ - Dil: tr-TR - Yazar: Muhammet Şafak --- Tignex tek bir ürüne, dile ya da teknolojiye bağlı değil. Onu bir arada tutan şey kısa bir taahhüt listesi — aşağıdakiler. İster bir CLI aracı, ister bir spesifikasyon, ister sunucu altyapısı olsun, organizasyon altındaki her projenin bunlara uyması bekleniyor. ## Kontrol sizde kalır Her proje açık kaynak ve asıl önemli anlamda açık: okuyabilir, fork edebilir ve kendi makinenizde çalıştırabilirsiniz. Yayımladığımız hiçbir şey bizim işlettiğimiz bir servisin istemcisi değil — çünkü kaldıramayacağınız bir bağımlılığa giden en kısa yol budur. - Self-hosting birinci sınıf yol, ücretli bir katman değil. - Veri zaten sizin kontrolünüzdeki sistemlerde kalır. - Ayrılmak desteklenen bir işlem — lock-in'den önce export. ```bash git clone https://github.com/CommitBrief/commitbrief cd commitbrief go test ./... ``` ## Tasarımı gereği birlikte çalışabilir Açık formatları ve dokümante edilmiş protokolleri, kullanışlı özel olanlara tercih ediyoruz — özel olanı daha erken çıkacak olsa bile. Yalnız tek bir implementasyonun anladığı bir format, o implementasyonun öldüğü gün sona eren bir vaattir. > Başka bir ekip yalnızca spesifikasyona bakarak ikinci bir implementasyon > yazamıyorsa, spesifikasyon bitmemiştir. Buradaki projelerin kendi adlarını ve evlerini korumasının sebebi de bu. Ancak bütün kataloğumuzu benimseyerek benimsenebilen bir standart, standart değildir — fazladan adımı olan bir markadır. ## Üretim odaklı Hedef, zaten çalışan sistemlerle temasa dayanan yazılım: gerçek veri, gerçek yük, gerçek migration ve tasarım sırasında odada bulunmamış bir operatör. Yalnızca demoda ayakta duran özellikler yayımlanmaz. :::note{title="Pratikte"} Özellikten önce bir yükseltme yolu, yapılandırma yolundan önce gözlemleme yolu ve kılavuzu hiç okumayan biri için güvenli varsayılanlar. ::: ## Varsayılan olarak şeffaf Kararlar, ödünleşmeler ve sınırlar tartışılabilecekleri yere yazılır: depoya, spesifikasyona ve [mühendislik notlarına](/tr/notlar/). Buna gurur verici olmayan kısımlar da dahil — bir projenin neyi kötü yaptığı, neyi henüz çözmediği ve neyi yapmamaya karar verdiğimiz. ## Bunun dışarıda bıraktıkları Ciddiye alındığında bu taahhütler seçenekleri ortadan kaldırır. Bize doğrultulmasını istemeyeceğimiz hiçbir telemetri yok. Bir protokolün ortasında `open-core` özellik duvarı yok. Yalnızca bizim çalıştırabileceğimiz altyapıya bağlı release yok. Liste bilinçli olarak kısa: her projeyi ona uydurmak mümkün olmalı.