Yazılım commit’ler arasında üretilir

 (zed.dev)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • DeltaDB, ajanlarla yapılan konuşmaları ve ajanların düzenlediği worktree’yi birlikte sürümleyen yeni bir sürüm kontrol sistemi
  • Git, tek tek commit’ler etrafında kuruludur; kod sürekli değişirken devam eden konuşmaları ve kod değişikliklerini birlikte ele almak üzere tasarlanmamıştır
  • DeltaDB, yalnızca commit’leri değil, çalışma sırasında oluşan tüm işlemleri ayrıntılı bir delta akışı olarak kaydeder ve her delta’ya kararlı bir kimlik verir
  • Mesajlar ve bu mesajların ürettiği düzenlemeler yan yana kaydedilir; birden fazla kişi ve ajan, farklı makinelerde aynı dosyayı eşzamanlı olarak düzenleyebilir
  • İşbirliği, commit ve push sonrasındaki inceleme sürecinden ziyade, kod üretilirken yapılan konuşma ve worktree içinde daha doğrudan gerçekleşebilir

Arka plan ve problem tanımı

  • Zed ekibi pull request yöntemine alışkın değildi; aynı worktree üzerinde birlikte çalışıp kod yazarken tartışarak güven ve ortak anlayış inşa ediyordu
  • GitHub, ancak commit edip push ettikten sonra kod hakkında konuşmaya izin veriyor; oysa Zed ekibinin önemli konuşmaları çoğu zaman o noktadan önce zaten bitmiş oluyordu
  • Zed, 2021’de commit’in kısıtlarını aşmak için başladı; önce dünyanın en iyi geliştiricilerine yakışan bir editör yapıp, ardından onun içinde daha iyi bir işbirliği yöntemi sunmayı hedefledi
  • İnsanlar arası işbirliği bağlamında uzun süredir düşünülen bu sorun, ajanlarla işbirliği yapılırken daha da önemli hale geldi
  • Kodu üreten konuşma, giderek yazılımın gerçek kaynağı haline geliyor ve bu konuşmanın, sürekli gelişen ve değişen kodla karşılıklı referanslı olması gerekiyor
  • Git, tekil commit’ler etrafında kurulduğu için bu tür sürekli konuşma ile kod değişimi arasındaki bağı destekleyecek şekilde tasarlanmamıştır

DeltaDB ve sonraki adım

  • Tüm commit’ler değil, tüm işlemler

    • DeltaDB, çalışmayı ayrıntılı bir delta akışına böler; Git’in her commit’te snapshot saklamasının aksine, commit’ler arasındaki tüm işlemleri kaydeder
    • Her delta kararlı bir kimliğe sahip olduğundan, kod değişmeye devam ederken bile evrimin belirli bir anına işaret edilebilir
    • Worktree, değişimin sonucu değil bizzat değişim süreci olarak sürümlenir ve bu değişimi yönlendiren konuşmayla birlikte ele alınır
    • Mesajlar ve bu mesajların ürettiği düzenlemeler yan yana kaydedilir; birbirinden kopuk değildir
    • DeltaDB, çakışmasız çoğaltılmış worktree’yi yerleşik olarak sunar; böylece birden fazla kişi ve ajan, farklı makinelerde aynı dosyayı aynı anda düzenleyebilir
    • Dosyalar gerçek dosyalardır; ajanlar terminal üzerinden dosyalarla çalışır ve kullanıcılar gerektiğinde tüm worktree’yi diske mount edip kendi araçlarını kullanabilir

  • Kaynak kod artık kaynak konuşma

    • Referanslar satır numaralarına değil delta’lara sabitlendiği için, kod aşağıya taşınsa bile referans korunur
    • Geçmiş konuşmalardaki herhangi bir satırdan, kodun mevcut haline ya da ajanın o sırada yazmış olduğu koda gidilebilir
    • Kodun herhangi bir satırından, o kodu üreten konuşma ile sonrasında o koda dokunan tüm konuşmalar bulunabilir
    • Ajanlar da bu bilgiyi kullanarak dokundukları kodun arka plan bağlamını getirebilir
    • Ajanlar, daha önce aynı kod üzerinde çalışmış başka bir ajanı çağırıp neden o şekilde yazıldığını sorabilir

  • İşbirliği için commit atmak gerekmemeli

    • Hedef, ajanlarla yapılan konuşmanın işbirliği için gereken tek konuşma haline gelmesidir
    • Ekip üyeleri iş henüz sürerken katılabilir, işi yapan ajanla konuşabilir ve süreç devam ederken yorum bırakabilir
    • Katılmak için önce commit ve push beklemeleri gerekmez
    • Pull request, review thread ve inline comment; kod ile tartışma farklı yerlerde olduğu için, tartışmayı sonradan koda yeniden bağlamak amacıyla kullanılan süreçlerdi
    • Kod ve tartışma aynı yerdeyse bu tür süreçler ortadan kalkar
    • Git ve CI, kontrolleri çalıştırmak ve dış dünyayla bağlantı kurmakla sınırlı kalır; işbirliğinin zorunlu olarak gerçekleştiği yer olmaz

  • Sonraki adım

    • Yazılım artık commit’lerde değil, konuşma içinde şekilleniyor
    • DeltaDB bunun için tasarlanmış sürüm kontrol sistemidir ve birkaç hafta içinde ilk kullanıcılara sunulacaktır
    • Önce denemek isterseniz bekleme listesine kaydolabilirsiniz

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News görüşleri

  • Commit'ler arasındaki çalışma ürünü dağınık bir çorba gibidir; içine bakmak kimseye fayda sağlamaz. git rebase ile geçmişi yeniden yazar, her commit'i küçük ve atomik hale getirir ve commit'lerden oluşan hikâyenin neden bugünkü haline geldiğini anlatırsınız
    Gerçekte hangi kronolojik sırayla ilerlediğinin bir önemi yok. Pull request incelemesinin fazla geç kaldığına katılıyorum, ancak sorun pull request'lerin tüm branch sonucunu tek seferde incelemek üzere tasarlanmış olması ve bu yüzden tek tek commit incelemesinin zor olması. Çözüm, tüm gürültüyü paylaşmak değil; özellik ya da düzeltme tamamlanmadan önce ilk çalışmanın incelenebilmesini sağlayacak küçük ve atomik commit'leri teşvik etmek olmalı

    • Buradaki yorumlara ve profesyonel çevreme bakınca insanlar genel olarak iki kampa ayrılıyor. Bir taraf Git'i kaba bir otomatik kayıt gibi kullanıp merge sırasında birleştiriyor, diğer taraf ise temizce düzenlenmiş, tamamen çalışan atomik commit'leri tercih ediyor
      Benim deneyimimde 1. yaklaşım daha yaygın; bunda GitHub'ın doğal olarak o yöntemi daha iyi desteklemesi ve birikimli commit'lerin 2. yaklaşımın bazı sorunlarını çözebilmesi etkili olabilir. Seçmem gerekirse 1. yaklaşım bana çok daha mantıklı geliyor
    • Bu Phabricator ya da Gerrit gibi araçların sorunu değil de sadece bir GitHub sorunu değil mi?
    • Dağınık bir çorba olsun ya da olmasın, disk ya da maliyet sorun değilse birinin—muhtemelen bir ajanın—benim ne yaptığımı görebilmesi başlı başına sorun değil
      Çok güçlü bir kanaatim yok ama ajanların, bazıları için gürültü olsa bile, ek bilgiyi tercih edeceğini düşünüyorum
    • Böyle tepkiler geleceğini tahmin etmiştim. Yazıyı okurken, sürüm kontrolü konuşuldukça aynı duyguların tekrarlandığını görüp hayal kırıklığı yaşadığımı hatırladım
      Çok fazla insan, kayıtları “daha temiz” göstermek uğruna onları fazla kolayca çöpe atıyor. Mantıksız ama şaşırtıcı derecede yaygın olan belirli bir programcı mantığına göre bu makul görünüyor
      Benim yöntemim günde onlarca kez sık sık commit atmaktır. Commit'ler olan bitenin kaydıdır ve bu kaydın mümkün olduğunca fazlasının kalmasını isterim. git bisect'in görünüşte sorunsuz tek satırlık küçük bir commit'i işaret edip çok daha sonra fark edilen ince bir bug'ı bulmama yardım ettiği birçok durum oldu
      Bana göre kaynak kontrolü tam da bunun içindir. Büyük bir commit'teki tüm satırları didik didik etmek zorunda kalsaydım bu tür sorunlar çok daha acı verici olurdu
      Bu yüzden insanların PR büyüklüğündeki commit'leri bilerek tek bir yerde toplayıp birleştirmesini ve sürüm kontrolünün faydalı olan yegâne kısmını çöpe atmasını gerçekten anlayamıyorum. Üstteki yorumdaki gibi düşünen çok kişi var; bu yüzden yazarın daha ayrıntılı kayıt planı kolay bir mücadele olmayacak gibi görünüyor
    • Commit'leri kullanma biçiminiz, benim iş yerinde stacked PR kullanma biçimime benziyor
      İyi commit disiplini takım düzeyinde zor uygulanıyor ama ilginç biçimde PR düzeyinde insanlar iyi açıklamalar yazmaya ve değişiklik gruplarını temiz tutmaya epey istekli oluyor

  • Bu, Git'e daha az güvenen sık otomatik commit yaklaşımı gibi geliyor. Git sık otomatik commit'leri gayet iyi kaldırabilir
    Sık otomatik commit'leri daha “temiz” üst seviye commit'lere sararken her anlık otomatik commit'in “konuşmasını” da korumak istiyorsanız, ara sıra git merge --no-ff kullanabilir ve “konuşma” commit'leri yerine üst seviye commit'lere odaklanmak için --first-parent gibi araçlardan yararlanabilirsiniz
    Git arka ucunda zaten Git pack ve başka araçlarda bolca delta DB optimizasyonu var; aslında biraz elden geçirilmesi gereken yer Git ön ucu—özellikle --first-parent—ve sayısız “metro haritası öncelikli/özel” Git arayüzü. Birçok insan bu haritaları çirkin, kafa karıştırıcı ve itici buluyor; bu yüzden --first-parent'a karşılık gelen drill-down UI'lardan daha fazla olmalı

    • Ben de öyle yapıyorum. Branch commit'lerine normalde bakmıyorum ama gerekirse oradalar. git blame de --first-parent kullanacak şekilde ayarlanabiliyor

  • “Yazılım commit'ler arasında yapılır” ifadesine katılıyorum ama “DeltaDB her commit arasındaki tüm çalışmayı yakalar” ifadesine katılmıyorum
    Öncelikle bu müdahaleci hissettiriyor. Çalışırken 7/24 çalışan bir ekran kayıt cihazı da istemem. Hatalarımın görünür olması başlı başına yanlış değil ama işimi düzgün yapıyorsam ürettiğim değer commit'lerde yer alır ve bu bana çok daha az müdahaleci gelir
    İkinci olarak, ben birden fazla araç kullanıyorum ve bunların hepsini tuhaf bir veritabanında birleştirmek istemiyorum. Bir noktada sonuç “harici bir süreç bir şey yaptı” seviyesinde kalacaksa her şeyi yakalamanın anlamı ne? Zed'in birçok şeyi entegre edebilmesi güzel ama bu, Zed'e entegre olan her şeyi kullanmak istediğim anlamına gelmiyor. En son baktığımda Zed'de ACP üzerinden Claude Code kullanırken önceki mesajları geri sarıp düzenlemek bile mümkün değildi
    Son olarak, kişisel olarak commit'in özünü zaten kaçırdığımızı düşünüyorum. Çoğu kişi keyfi ve sınırsız değişiklik demetleri oluşturup sonra git commit çalıştırıyor; ardından bu değişiklik demetleri devasa parçalar halinde inceleniyor ve commit'ler birleştiriliyor. Dünyanın sonu değil ama elde özenle şekillendirilmiş commit'ler gerçekten harikadır. Bu yaklaşımı zorunlu kılan bir projede git blame çalıştırırsanız ne demek istediğimi hemen anlarsınız
    DeltaDB gibi şeyler, commit'leri gelişigüzel yığma alışkanlığını daha da güçlendirip kalıcı hale getirmekten başka bir şey yapmaz. Ne olduğunu merak ederseniz artık kullanıcının LLM ile yaptığı konuşmayı röntgenci gibi yeniden oynatmanız gerekecek
    Son nokta ilginç ama aynı zamanda sinir bozucu. Ekip arkadaşlarına fayda sağlayan iyi bir mühendislik pratiği olduğu için insanları değişiklikleri ve gerekçelerini belgelemeye ikna edemedik ama herkes LLM'e bir şeyler açıklamaya gönüllü. Bunun büyük kısmı, iş yapabilmesi için LLM'in buna ihtiyaç duymasından kaynaklanıyor; ama insanların daha önce yapmadıkları şeyleri sırf LLM'i tatmin etmek için ne kadar fazla yaptığını görmek ilginç. Birdenbire tuhaf biçimde belgelenmemiş şeyler CLAUDE.md içine yazılmaya başlandı

  • Commitler arasında yazdığım kod, benim düşünme sürecimdir. Kodu yazıp silerek ve yeniden yazarak düşünüyorum
    Commit ile taşınan kod ise başkasının anlayabilmesi için yazılmış olandır ve düşünmek için yazılan sürecin bir çıktısıdır. Düşüncelerimin serileştirilip sürüm kontrolüne alınmasını ve herkese açık şekilde erişilebilir olmasını istemiyorum
    https://www.nature.com/articles/s44222-025-00323-4

    • JJ konusunda da aynı sorun vardı. Commitler arasındaki her şeyin sürüm kontrolünde olmasını istemiyorum
      Commitler arasındaki tüm ara durumların gerçekten ilgili ya da faydalı olduğundan da emin değilim. Ama sanırım azınlıktayım
    • Bu yüzden PR öncesinde rebase kullanıyorum ve squash'tan hoşlanmıyorum. İki yıl sonra o kodu neden öyle yazdığınızı hatırlamayacaksınız; bir bug'ı anlamak ve Chesterton'ın çiti durumunu tespit etmek için elinizde sadece delta ve commit geçmişi kalacak
      Squash yapınca geriye tek bağlam olarak “bir kerede” yazdığınız 400 satırlık kod ve o kodun atandığı özellik isteği kalıyor. Hiç yardımcı olmuyor
      En kötüsü, yeni bir modül yazarken bir ölçüde çalışır hale gelene kadar hiçbir şeyi check-in etmeyen insanlardı. Sanırım bu, kendi kodundaki bug'ları önce söylemeyip gizlice düzeltmeye çalışan kırılgan egolarıyla da bağlantılıydı. Kernighan yasasını görünür kılan anlaşılmaz kodlar yazardı ve böyle şeyler yapmak için 10 yıl daha fazla deneyimi vardı. Kendi kodunun “güçlü” olduğunu övünerek söylerdi; bu bir övgü değil, bir alametti. İlk commit kodlarında defalarca bug buldum. Ne olur bir şeyler bırakın
      Sorunu bulana kadar rastgele şeyler denediğinizi itiraf etmeniz gerekmiyor. B noktasına ulaşılabildiğini öğrendikten sonra, A'dan B'ye giden istediğiniz hikâyeyi kurabilirsiniz. Commitleri, en baştan tam olarak ne yapmanız gerektiğini biliyor olsaydınız nasıl yazardıysanız o şekilde yeniden düzenleyebilirsiniz. Yazıp hemen sildiğiniz kodun %90'ını ya da o anlatıyı desteklemeyen her şeyi atabilirsiniz
      Kolluk kuvvetlerinde paralel yapılandırma diye bir şey vardır. Mahkemede kabul edilemeyecek bilgiler üzerinden bir şüphelinin suçlu olduğunu bilebilirsiniz, ama aynı olguları usule uygun şekilde yeniden keşfetmeniz gerekir. Çöp toplama gününde çöpleri ele geçirmek, komşularla görüşmek, arama izni almaya yetecek kadar dolaylı kanıt toplamak ve sonra o kanıtı yeniden bulmak gibi
    • Bunun daha çok AI agent'lar düşünülerek yazıldığını sanıyorum. Daha önce gördüğüm ilginç bir fikir ve herkesin AI için bir şeyleri yeniden icat etmeye çalışıyor olması eğlenceli
      Ama bana göre sadece bir metin dosyası oluşturup içine commit referansları koymak yeterli olmaz mı? Fossil kullanmamak için de bir neden göremiyorum. SQLite veritabanı olduğu için istediğiniz her şeyi zaten bir araya getirebilir ve commitlere referans verebilen türlü özellikler de zaten içinde var
    • İş birliği kısmına şüpheyle yaklaşıyorum ama kurumsal müşterilere yönelik bir özellik gibi duruyor, dolayısıyla niyeti anlıyorum
    • Kesinlikle katılıyorum. Gözetim hissi aşırı rahatsız edici. Özellikle de “DeltaDB işi ayrıntılı delta akışlarına böler. Git her commit'in anlık görüntüsünü yakalarken DeltaDB aradaki tüm çalışmayı yakalar ve her birine kalıcı bir tanımlayıcı verir” kısmı
      Zed'e emacs keymap geldiğini duyunca bir deneyeyim mi diye düşünmüştüm ama artık hayır. Bu, korkunç derecede istilacı bir özellik ve inceleme için yayımladığım commit'e gelene kadar olan tüm ara düzenlemelerin ekip arkadaşlarım tarafından tuş vuruşu düzeyinde incelenmesini hiç istemiyorum
      Bazen PR açmadan önce magit'te commit geçmişini biraz düzelterek daha doğrusal ve sindirmesi kolay hale getiriyorum. Açıklamaları düzeltmek ya da bitişik commitleri birleştirmek gibi. Ama bu özellik, o işin bir yönünü tamamen çöpe atıp “meslektaşım, al bu delta itfaiye hortumunu içine çek ve keyfini çıkar” demek gibi
      “Gerçekte istediğimiz şey basit: agent ile yaptığınız konuşmanın, ihtiyacınız olan tek konuşma haline gelmesi.” cümlesi ne anlama geliyor ki? Hayır, yanlış

  • Anthropic veya OpenAI'nin Zed'i satın alması kaçınılmazmış gibi geliyor ve bu beni kötü hissettiriyor. Fikir fazla iyi, yazılım da fazla iyi

    • Zed'in coding harness'i Claude Code'dan çok daha iyi ama Claude API'yi doğrudan kullandığı için çok daha pahalı. Aynı ürün ailesinin içine girerse ürün kategorisini tanımlayan seviyede olabilir
    • Neden Zed'de dursunlar ki? AI şirketlerinin topladığı 1 trilyon dolarlık yatırım, kâğıt üzerinde veri merkezleri içindi ama maliyetler artıp tamamlanma takvimleri normal iş planı ufkunun ötesine geçince, o parayı başka yerlere harcamak daha verimli olabilir. 1 trilyon dolarla istediğiniz her şeyi satın alabilirsiniz
    • Anthropic veya OpenAI'nin gitmek istediği yerde artık editör var gibi görünmüyor. Ben şahsen daha iyi salt okunur kod araçları ya da belki UML'nin geri dönüşünü isterim

  • Şu anda bu alanda yarışan gerçekten çok sayıda erken aşama startup var. Son birkaç haftada mülakat yaparken en az iki tanesiyle konuştum
    Bu araçların büyük ölçekte başarılı olabilecek kadar yer edinmesi için rekabetin çok sert olması gerekecek. Yine de bütün bunların, beni aşırı rahatsız eden düzeyde geliştirici gözetimini mümkün kıldığını düşünmeden edemiyorum

    • Eğer bir yönetici, altındaki tüm geliştiricilerin bütün tuş vuruşlarını izlemeye zaman harcıyorsa, demek ki gerçekten yapacak işi ya da dikkat etmesi gereken iş sorunları yoktur

  • Commitler, önceden ayıklanıp düzenlendikleri için faydalıdır. Aradaki deneme-yanılma ise bir şeyler denediğiniz ve çıkmaz sokakları sildiğiniz yerdir; bunların çoğu atılmalıdır
    Tüm değişiklikleri ve agent mesajlarını saklarsanız, o çöp sadece kalmaya devam eder

  • Google bunu citc ile muhtemelen yaklaşık 10 yıl önce yapıyordu. Gemini'nin bunu fiilen ne zaman kullanacağını bilmiyorum ama Google en az 10 yıldır neredeyse tüm geliştiricilerin geçmişini Ctrl-S düzeyinde fiilen eksiksiz şekilde elinde tutuyor
    Gemini şu anda aptal görünüyorsa, bunun tek nedeni hesaplama kaynağı tahsisinden kısmalarıdır
    0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)

  • Buradaki değer önerisinin ne olduğunu anlamıyorum. Çeşitli şirketlerin kabaca bu tür özellikler önerdiğini gördüm, ama bu teknolojinin var olması için ikna edici bir gerekçe sunan hiçbirine rastlamadım

    • Deneyiminizin ve iş akışınızın benimkinden bu kadar farklı olması ilginç. Bu, benim her gün yaşadığım gerçek bir sorunu çözdüğünü iddia eden bir özellik.
      Şirketimiz tamamen uzaktan çalışıyor ve ekip arkadaşlarımın çoğu bana yakın yaşamıyor. Günde birkaç kez görüntülü konuşuyoruz ama esas olarak Slack üzerinden iletişim kuruyoruz.
      İyi kod yazmak için LLM ajanlarını devreye alma eğrisinde de epey ilerideyiz. İyi modeller ve belirli bir kodlama altyapısındaki çok iyi güvenlik önlemleri sayesinde bugünlerde kodumuzun çoğunu LLM yazıyor.
      Genelde bir gün, bir ticket alıp onu LLM'e yönelterek birlikte problemi çözmeye başlamakla geçiyor. Mimari kararlar alıyor, bir plan yapıyor ve uyguluyoruz. En son deploy ettiğim özelliğin token maliyeti 19 dolardı ve en yoğun anında LLM, benden hiçbir girdi almadan yaklaşık 30 dakika çalışmaya devam etti.
      Hangi yönün daha iyi olduğundan emin olmadığımda ekip sohbetine bir soru atıp iş arkadaşlarımın görüşünü isteyebiliyorum. Ama birçok ticket tamamen otonom şekilde tamamlanıyor.
      Sonra bir PR açıp inceleme istemek için Slack'e PR bağlantısını bırakıyorum; ekip arkadaşlarım da implementasyonu ilk kez o anda görüyor. Bazen sorular soruyorlar. Hızlı gerçek zamanlı konuşmalar için GitHub yorumları pek uygun olmadığından, soruları PR yorumları yerine çoğu zaman Slack dizisinde soruyorlar.
      Bu soruların yanıtları dizüstü bilgisayarımdaki LLM ile yaptığım sohbet günlüğünde var, ama bunları ekip arkadaşlarıma kolayca göstermenin bir yolu yok. Bu yüzden ekip arkadaşlarının sorularını Slack'ten LLM sohbetine kopyalayıp yanıtları geri yapıştırdığım bir kulaktan kulağa oyunu yaşanıyor.
      Ekip arkadaşlarımın, LLM'in ve benim aynı konuşmaya daha kolay katılabilmesi fikri çok çekici.
      Bu, Zed ekibinin doğru yönde olduğu anlamına gelmiyor; ekibimiz farklı bir çalışma biçimiyle daha iyi olabilir. Ama mevcut yaklaşım o kadar “başarılı” ki, bunu organizasyonel olarak değiştirmek için fazla baskı yok

  • Yazılım ekiplerinin işi, belirli bir alanda etkili şekilde çalışan modelleri işbirliği içinde öğrenmektir. Sonra bu modeli ve edinilen bilgileri kod, testler ve ilgili dokümantasyonla ifade ederiz.
    Bu yüzden bir yandan pull request'lerin ve code review sürecinin bu süreci ölümcül biçimde bozduğu fikrine tamamen katılıyorum, ama hemen ardından bizi oyalayacak başka ikincil süreçler ve çıktılar üretme düşüncesi beni irkiltiyor. Bunların hepsi kod tabanında görünür olmalı.
    Ayrı bir şey olmamalı. Ne commit mesajları yığını ne de bir ADR koleksiyonu. Eğer kod tabanı hem insanlara hem de yapay zekaya neyin ne olduğunu ve nedenini kendi başına eksiksiz açıklayamıyorsa, o zaman başarısız olmuştur; ve bu başarısızlığı yönetmek için ömür boyu daha fazla süreç üretmek zorunda kalırız.

    • Özellikler ve deneyler için ucuz branch'leme, belirli commit'leri hızla geri alabilme yeteneği ve tek bir satır kodun en son ne zaman değiştiğine dair commit mesajını okuyabilmek son derece önemlidir ve bunlar dağıtık sürüm kontrol sistemlerinin mümkün kıldığı şeylerdir.
      Kodun yalnızca mevcut durumu, modern yazılım geliştirme için yeterli değildir