Arda Akgür
Bu metin kusursuz sistemlerin nasıl kurulacağını anlatmıyor. Zaten kusursuz sistem diye bir şey olduğuna da inanmıyorum.
Bunlar yıllar içinde sistem kurarken, kod yazarken, öğrencilere ders verirken ve çalışan sistemlerin neden bozulduğunu görürken edindiğim bazı prensiplerdir.
Sistem mühendisliği benim için teknoloji seçmekten önce problem çözme işidir.
1. Bir sistemde en önemli şey istikrardır
Bir sistemi hangi temel mantıkla kurduysan, çalışmaya başladıktan sonra o mantığı sürekli değiştirme.
Parametreler değişebilir. Küçük iyileştirmeler yapılabilir. Hatalar düzeltilir. Fakat sistemin ana kurallarını yolun ortasında sürekli değiştirmeye başlarsan bir süre sonra elinde ne ilk tasarımın ne de yeni tasarımın kalır.
Major bir değişiklik gerekiyorsa bazen yapılabilecek en doğru şey mevcut sistemi zorlamak yerine yeni bir versiyon başlatmaktır.
Oyunun ortasında oyunun kurallarını değiştirme.
2. En basit çalışan sistemi kur
Daha ilk günden milyonlarca kullanıcıyı, beş yıl sonraki ölçeği ve henüz ortaya çıkmamış problemleri düşünerek devasa bir mimari kurmaya çalışma.
Bunu yapmak çoğu zaman mühendislik değil, YouTube mimarlığıdır.
Bugünkü problemi mümkün olan en kısa sürede çözen, anlaşılabilir ve çalışan sistemi kur.
Bir gün gerçekten scale problemi yaşarsan bu güzel bir problemdir. Demek ki sistem o noktaya kadar yaşamayı başarmıştır.
V2 gerektiğinde V2'yi farklı kurabilirsin.
3. Statükodan uzak dur
Herkesin bir teknolojiyi veya mimariyi kullanması onun senin problemin için doğru olduğu anlamına gelmez.
"Industry standard böyle" tek başına teknik gerekçe değildir.
Önce problemi tanımla. Sonra o problemi en iyi neyin çözdüğüne bak.
Cevap herkesin kullandığı yöntemse onu kullan. Değilse farklı bir şey yapmaktan korkma.
Araçlara değil, probleme sadık ol.
4. Açken ve yorgunken önemli karar alma
Bir mimarın en önemli aracı bilgisayarı değil, kendi zihnidir.
Açlık ve ciddi yorgunluk karar verme kalitesini bozabilir. Normalde kabul etmeyeceğin bir çözüm o anda yeterince iyi görünebilir. Gereksiz risk alabilir, kolay sinirlenebilir veya yalnızca işi bitirmek için yanlış bir kararı kabul edebilirsin.
Bazen bu durum intoxicating bile olabilir. Kendini karar verebilecek durumda sanırsın ama muhakeme kaliten çoktan düşmüştür.
Böyle zamanlarda rutin iş yapabilirsin. Kod yazabilirsin, test çalıştırabilirsin, log inceleyebilirsin. Fakat geri dönüşü pahalı olacak önemli mimari kararları mümkünse verme.
Karar sabaha kadar bekleyebiliyorsa ve sen tükenmiş durumdaysan bırak sabaha kadar beklesin.
Açlık ve yorgunluk senin düşmanındır.
Sistemi tasarlamadan önce mimarın kendisi çalışır durumda olmalıdır.
5. Kod değişiyorsa dokümantasyon da değişmeli
Her anlamlı code update ile birlikte dokümantasyonu da güncelle.
Dokümantasyonu iş bittikten sonra yapılacak ayrı bir görev olarak görme. Kod ile dokümantasyon aynı değişikliğin iki parçasıdır.
Modern AI araçları bu işi geçmişe göre çok kolaylaştırdı. Her önemli değişiklikten sonra AI'a yapılan değişikliği ve ilgili kodu incelet. Sistemin güncel durumunu anlatan Markdown dokümantasyonunu oluştur veya mevcut dokümantasyonu güncelle.
Dokümantasyonu mümkün olduğunca repository içinde `.md` formatında tut. Markdown basittir, version control ile rahat takip edilir ve GitHub üzerinde doğrudan düzgün biçimde görüntülenebilir.
Backend'de yapılan ve frontend'i ilgilendiren bir değişiklik varsa ilgili Markdown dokümanını frontend ekibiyle paylaş.
Frontend geliştiricisi endpoint'in nasıl çalıştığını, request ve response yapısını, değişen davranışı ve dikkat edilmesi gereken noktaları kodu kazmak zorunda kalmadan anlayabilmeli.
Aynı prensip diğer ekipler ve servisler arasındaki değişiklikler için de geçerlidir.
AI dokümantasyonu hızlandırır ama doğruluğunun sorumluluğu yine değişikliği yapan mühendistedir. AI'ın yazdığı dokümanı kontrol etmeden doğru kabul etme.
Kod güncellenip dokümantasyon güncellenmediyse iş tamamen bitmiş değildir.
Dokümantasyon sistemin hafızasıdır.
6. Sistemin bitmiş halini önce kafanda gör
Kod yazmaya başlamadan önce sistemin bitmiş halini kafanda görebilmelisin.
Göremiyorsan kalem ve kağıt al ve çiz.
ER diagram olmak zorunda değil. UML olmak zorunda değil. Kimsenin belirlediği bir standarda uymak zorunda değil.
Kutular çiz, oklar çiz, yanlarına notlar yaz. Kafana nasıl yatıyorsa öyle çiz.
Önemli olan çizimin güzel olması değil. Sistemin tamamını senin görebiliyor olman.
Kafanda olmayan sistemi kod yazarak keşfetmeye çalışırsan tasarım ile implementasyonu aynı anda yapmaya başlarsın.
Önce gör. Sonra yap.
7. Sistemi kimin için yaptığını unutma
Teknik olmayan yöneticilerin ve kullanıcıların fikirlerini küçümseme.
Bazen sana teknik açıdan garip gelen bir fikir, probleme senin hiç bakmadığın bir açıdan bakıyordur.
Onların görevi senin gibi düşünmek değildir.
Senin görevin ne istediklerini anlamak ve mümkünse bunu çalışan bir sisteme dönüştürmektir.
Hayallerini dinle ve gerçekleştirmeye çalış. Bazen sonuç seni gerçekten şaşırtabilir.
Sistemi kendin için değil, onu kullanacak insan için kur.
8. Mimar kontrolü kaybetmemeli
Her ciddi sistemin fail-safe mekanizmaları olmalı.
Gerektiğinde sistemi tek bir environment variable ile durdurabilmelisin. Gerekiyorsa kontrollü bir yönetim endpoint'in olsun. Kritik parçaları devre dışı bırakabileceğin yollar düşün.
Bunlar güvenliği delen gizli arka kapılar olmamalı. Yetkilendirilmiş, güvenli ve mümkünse loglanan mekanizmalar olmalı.
Sistem ne kadar otonom olursa olsun mimar kendi sisteminin seyircisine dönüşmemeli.
Son kontrol mimarda kalmalı.
9. Önce kendi hatandan şüphe et
Sistem yavaşladığında hemen hardware'i suçlama.
Belki göremediğin bir deadlock vardır. Belki yanlış bir query yazmışsındır. Belki gereksiz bir network çağrısı vardır. Belki de mimaride yaptığın bir hata sistemi kilitliyordur.
Tabii ki hardware gerçekten yetersiz olabilir.
Ama önce ölç.
Bir mühendis hata yapabileceğini kabul edebilmelidir. Bundan utanılacak hiçbir şey yoktur.
Yanıldığını kabul edemeyen insan hatasını da düzeltemez.
10. Öğrenci yetiştir
Sistemin yalnızca senin kafanda yaşamasına izin verme.
Öğrencilerine sistemi öğret.
Sen yarın orada olmazsan sistem devam edebilmeli. Bir başkasının sistemi anlayıp geliştirebilmesi senin otoriteni azaltmaz. Tam tersine iyi bir mimar olduğunun göstergesidir.
Tek kişinin anlayabildiği sistem güçlü değil, kırılgandır.
Bilgiyi aktar.
11. Küçük ve uyumlu bir ekiple çalış
Tek başına mimar olma. Ama gereksiz büyük ekip de kurma.
Öğrenmeye açık, seni dinleyen, soru soran ve öğrenci ruhunu kaybetmemiş insanlarla çalış.
Eleştiri değerlidir. Bir junior senin göremediğin hatayı görebilir. Onu dinle.
Fakat sürekli muhalefet etmeyi çalışma biçimi haline getiren insan sistem kurarken tehlikelidir. Her kararın tekrar tekrar tartışılması mimarı sürekli yön değiştirmeye zorlar ve sonunda sistemin istikrarını bozar.
Karar verilene kadar tartış.
Karar verildikten sonra ekip olarak uygula.
Sürekli muhalefet ederek ekibin ilerlemesini bozan biriyle uzun süre çalışmak zorunda değilsin.
12. Yaratıcı ol ama basit kal
İyi bir sistemi gören deneyimli bir mühendis "vay be" diyebilmeli.
Ama aynı sisteme giren iyi bir junior da yaklaşık bir hafta içinde ne olup bittiğini anlayabilmeli.
Bu ikisi birbirine zıt değildir.
Gerçek ustalık yüz tane servis kullanmakta veya kimsenin anlamadığı abstraction'lar yaratmakta değildir.
Karmaşık bir problemi beklenmedik derecede basit bir sistemle çözebilmektir.
Karmaşıklık marifet değildir.
13. Her yeniliği eski sisteme doldurma
Yeni bir fikir geldiğinde ilk refleksin mevcut sisteme eklemek olmasın.
Bazen yeni bir servis gerekir. Bazen yeni bir uygulama gerekir. Bazen de gerçekten V2 gerekir.
Eski sistemi sonsuza kadar genişletmeye çalışırsan bir süre sonra başlangıçtaki basit sistemin üzerine yılların kararlarını ve istisnalarını yığarsın.
Bazen sıfırdan başlamak daha ucuz, daha temiz ve daha doğrudur.
Değişim her zaman mevcut sistemi büyütmek anlamına gelmez.
14. Yapay zekayı araç olarak kullan
AI sistemini ciddi biçimde güçlendirebilir.
Özellikle modern reasoning motorları hem sistemi geliştirirken hem de runtime sırasında çok güçlü araçlardır.
Kod inceleyebilir, edge case bulabilir, karar desteği verebilir, doğal dili anlayabilir ve klasik algoritmaların zorlandığı belirsiz problemleri çözebilir.
Ama her şeyi AI'a yükleme.
Basit bir deterministik çözüm yeterliyse onu kullan. Reasoning gerçekten değer katıyorsa AI kullan. İkisinin birlikte çalışması daha doğruysa hibrit sistem kur.
AI'a iş ver ama sistem üzerindeki otoriteyi verme.
15. AI'dan mucize bekleme
AI'ın zekası onu kullanan kişinin zekası kadardır.
Problemi yanlış tarif edersen çok güçlü bir model sana yanlış çözümü çok hızlı biçimde üretebilir.
Ne istediğini bilmen gerekir. Verdiği cevabı değerlendirebilecek kadar problemi anlaman gerekir. Yanlış yaptığında bunu fark edebilmen gerekir.
AI senin yerine mühendis olmak zorunda değildir.
İyi kullanıldığında senin mühendislik kapasiteni büyütür.
Mucize bekleme.
16. Huydur çeker, boktur kokar
It is what it is.
Her şeyde derin bir anlam arama.
Bazen bug sadece bug'dır. Kötü kod kötü koddur. Çalışmayan fikir çalışmıyordur. Yanlış karar yanlış karardır.
Basit bir açıklama yeterliyse problemi gereksiz teorilerle süsleme.
Önce önündeki gerçeğe bak.
17. Ustayı taklit etmekten korkma
Öğrenciyken her şeyi icat etmek zorunda değilsin.
Ben öğrenci olduğum dönemde öğrenmek için ArrayList gibi mevcut yapıları sıfırdan yazdım. Amaç yeni bir veri yapısı icat etmek değildi.
Amaç ustaların yaptığı şeyi kendim yapmak, nasıl çalıştığını anlamak, kendi çözümümle karşılaştırmak ve kendimi geliştirmekti.
Taklit ederek öğrenmek kopyacılık değildir.
Önce ustanın yaptığını yapabilecek seviyeye gel. Neden öyle yaptığını anlamaya çalış. Sonra sorgula. Sonra kendi yöntemini geliştir.
Bilmediğin şeyi sırf farklı olmak için reddetmek yaratıcılık değildir.
Önce öğren. Sonra boz.
Son söz
İyi sistem mühendisliği mümkün olan en fazla teknolojiyi kullanma sanatı değildir.
Problemi anlamak, çözümü kafanda görebilmek, mümkün olduğunca basit kurmak, çalışan yapının istikrarını korumak ve gerektiğinde kendi hatanı kabul edebilmektir.
İyi mimar önce kendi zihninin durumunu bilir. Açken, yorgunken veya sağlıklı düşünemeyecek durumdayken büyük kararlar vermemeyi de mühendisliğin bir parçası kabul eder.
Kod kadar sistemin hafızasını da korur. Yaptığı değişikliği dokümante eder ve bu bilgiyi sistemi geliştiren diğer insanlarla paylaşır.
Sistemini kontrol eder ama ona tapmaz.
Ekibini yönetir ama öğrencilerini susturmaz.
Yapay zekayı kullanır ama düşünme görevini ona bırakmaz.
Geçmişte yapılanlardan öğrenir ama statükoya teslim olmaz.
Ve en önemlisi, sistem çalışıyorsa neden çalıştığını, çalışmıyorsa neden çalışmadığını anlamaya çalışır.
Gerisi araçtır.
Arda Akgür
ARC Sistem Prensipleri
v0.1 Final