İstem yazma, hızlı yineleme ve refaktörün vibe kodlama iş akışında ağır tasarım dokümanlarının yerini nasıl alabileceğini—netlik, uyum veya kalite kaybetmeden—öğrenin.
“Vibe kodlama”, niyet ve örneklerle başlayıp uygulamanın hızlı istem, çalıştırma ve ayarlama döngüleriyle gelişmesine izin verdiğiniz bir yazılım geliştirme yaklaşımıdır. Büyük bir plan yazmak yerine erken çalışan bir şey elde eder, gördüklerinizden öğrenir ve kodu istediğiniz sonuca doğru yönlendirirsiniz.
Bir vibe kodlama iş akışı şu şekildedir:
“Vibe” kısmı rastgele tahmin değildir—hızlı geri bildirimdir. Öğrenme ve yinelemeyi spekülasyonun yerine koyuyorsunuz.
AI, çaba harcamayı ayrıntılı dokümantasyon yazmaktan, açık ve çalıştırılabilir yön vermeye kaydırır:
Bu yaklaşım ürün yinelemesi, dahili araçlar, erken aşama özellikler ve hızlı öğrenmenin en hızlı yol olduğu refaktörler için en uygundur.
Resmî onaylar, sıkı uyumluluk, uzun süreli ekipler arası taahhütler veya geri alınamaz mimari kararlar gerektiğinde iyi bir uyum değildir. Bu durumlarda yine yazılı bir karar kaydına ihtiyaç vardır—ama daha küçük, daha sıkı ve daha açık olmalıdır.
İstemleri hafif spesifikasyonlar olarak nasıl ele alacağınızı, yinelemeyi plan aracı olarak nasıl kullanacağınızı ve netliği korumak için refaktör ve testlere nasıl güveneceğinizi öğreneceksiniz—ağır tasarım dokümanlarına başvurmadan.
Geleneksel tasarım dokümanları değişikliklerden önce netlik yaratmak için vardır. Hızlı yapılarda genellikle tam tersini üretirler: öğrenmeyle başa çıkamayan ağır, kırılgan bir eser.
Tasarım dokümanları çok çabuk eskimeye eğilimlidir. Uygulama başladığında ekip kenar durumları, kütüphane tuhaflıkları, performans kısıtları ve entegrasyon gerçekleri keşfeder—bunlar ilk gün basit görünmeyebilir. Dokümanı sürekli düzenleyecek biri olmadıkça (nadir), tarihsel bir kayıt haline gelir, rehber değil.
Ayrıca yazması da yavaş, okunması da yavaştır. Hız önemliyse ekipler gönderime öncelik verir: doküman “iyi olur” haline gelir, hızlıca gözden geçirilir ve sonra sessizce unutulur. Çaba yine harcanmıştır—sadece karşılığı alınmamıştır.
Büyük ön doküman sizi yanlış bir ilerleme hissine sokabilir: sertifikalandırılmış gibi hissedersiniz ama zor kısımlarla yüzleşmeden önce işin tasarımını tamamladığınızı düşünürsünüz.
Oysa gerçek kısıtlar genellikle deneyerek keşfedilir:
Eğer doküman bu deneyleri geciktiriyorsa, ekip neyin mümkün olduğunu öğrenmeyi geciktirir.
Hızlı yapılar hareketli hedeflerle şekillenir: geri bildirim günlük gelir, öncelikler değişir ve prototipi gördüğünüzde en iyi çözüm değişir. Geleneksel dokümanlar geleceği yeterince ayrıntılı tahmin edebileceğinizi varsayar. Bu uyumsuzluk israf yaratır—ya dokümanları yeniden yazmak ya da işi eskimiş plana uydurmak zorunda kalırsınız.
Hedef evrak işi değil; paylaşılan anlayıştır: ne inşa ediyoruz, neden önemli, “tamamlandı” ne demek ve hangi risklere bakıyoruz. Geri kalan sadece bir araçtır—ve hızlı yapılarda ağır doküman genellikle yanlış araçtır.
Geleneksel bir tasarım dokümanı geleceği tahmin etmeye çalışır: ne inşa edeceksiniz, nasıl çalışacak ve bir şey değişirse ne yapacaksınız. Çalıştırılabilir bir istem bunun tersini yapar. O çalıştırılabilir bir spesifikasyondur: yürütüp gözlemleyip düzeltebileceğiniz canlı bir belge.
Başka bir deyişle: “doküman” statik bir PDF değildir—bir sonraki doğru arttırmayı güvenilir biçimde üreten talimatlar kümesidir.
Amaç niyeti belirsiz bırakmamak ve test edilebilir kılmaktır. İyi bir çalıştırılabilir istem şunları içerir:
Paragraflar yerine işi doğrudan kod, test veya kontrol listesi üretebilecek şekilde tanımlıyorsunuz.
Çoğu sürpriz yeniden işleme, varsayımların örtük kalmasından kaynaklanır. İstemde bunları açık hâle getirin:
Bu erken hizalanmayı zorlar ve ağır bir dokümanın yükü olmadan görünür bir karar kaydı oluşturur.
Bir tasarım dokümanının en faydalı kısmı genellikle sonudur: neyin tamam sayıldığı. Bunu doğrudan çalıştırılabilir isteme koyun ki işin yanına taşınsın.
Örnek olarak, istem birim testlerinin geçmesini, güncellenmiş hata işlemlerini, erişilebilirlik kontrollerini ve kısa bir değişiklik özetini zorunlu kılabilir. İstem spesifikasyon olduğunda, “tamam” tartışma olmaktan çıkar ve her yinelemede yeniden çalıştırılabilen doğrulanabilir çıktılara dönüşür.
Bu iş akışı, istem yazma, çalıştırma, gözden geçirme ve geri alma işlemlerinin sıkı bağlantılı olduğu durumlarda en iyi çalışır. Vibe-kodlama platformları örneğin Koder.ai, bu döngü etrafında tasarlanmıştır: sohbet üzerinden web/sunucu/mobil dilimleri üretip yineleyebilirsiniz, bir planlama modu ile kod değişikliklerinden önce mikro-plan alabilir ve bir yineleme ters giderse anlık görüntüler ve geri alma ile güvenli geri dönüş yapabilirsiniz. Pratik etkisi daha az “istem tiyatrosu” ve daha çok gerçek, test edilebilir artıştır.
Geleneksel tasarım dokümanları belirsizliği kağıt üzerinde “çözmeye” çalışır. Ancak yapının en riskli kısımları genellikle temizce mantık yürüterek çözülemeyenlerdir: kenar durumları, performans darboğazları, kafa karıştırıcı UX akışları, üçüncü taraf tuhaflıkları ve gerçek kullanıcıların ifadeyi nasıl yorumladığı.
Vibe kodlama iş akışı belirsizliği sıkı döngülerle yakar. Tartışmak yerine kanıt üretebilen en küçük versiyonu inşa eder, sonra ayarlarsınız.
Gerçek sınırları olan en küçük işe yarar dilimi seçin: UI → API → veri → arka. Bu, entegre olmayan “mükemmel” modüllerden kaçınmanızı sağlar.
Örneğin, “kaydedilmiş aramalar” inşa ediyorsanız, her filtre seçeneğini tasarlamak yerine bir filtre, bir kaydetme ve bir alma ile başlayın. Dilim doğru hissettirirse genişletin.
Döngüleri kısa ve açık tutun:
30–90 dakikalık bir zaman kutusu netlik zorlar. Amaç özelliği bitirmek değil—bir sonraki en büyük bilinmeyeni ortadan kaldırmaktır. Bir sonraki adımı bir ya da iki cümlede tanımlayamıyorsanız, adım çok büyük demektir.
Uygulanabilirlik veya UX konusunda emin değilseniz, hızlı bir prototip yapın. Prototipler dürüstçe etiketlenip beklentiler konulduğunda atıl “oyuncak kod” değildir: bir soruyu cevaplar.
İyi prototip sorularına örnekler:
Gerçek geri bildirim iç tartışmalardan üstündür. Bir bayrağın arkasına gönderin, bir paydaşla demo yapın veya test verileriyle akışı kendiniz çalıştırın. Her döngü somut bir çıktı üretmelidir: geçen bir test, çalışan bir ekran, ölçülen bir sorgu zamanı veya açık bir “bu kafa karıştırıcı” bulgusu.
Büyük tasarım dokümanları kararları öne yüklemeye çalışır. Vibe kodlama iş akışı bunun tersini yapar: işi istem yazarken parçalayarak kod tabanının absorbe edebileceği ve gözden geçirenlerin doğrulayabileceği mikro-planlar üretirsiniz.
“Bir faturalama sistemi kur” demek yerine tek bir çıktı ve etrafındaki kısıtları adlandıran bir istem yazın. Amaç, geniş istemleri kod tabanının kaldıramayacağı kadar büyük olmaktan çıkarıp, bir mimari icat edilmeden uygulanabilecek görevlere dönüştürmektir.
Yararlı bir yapı:
Planlamayı zorunlu bir adım yapın: AI’dan kod üretmeden önce adım adım bir plan isteyin. Mükemmel tahmin aramayın—sadece gözden geçirilebilir bir yol arıyorsunuz.
Sonra o planı somut bir kontrol listesine çevirin:
Eğer plan bunları adlandıramıyorsa hâlâ çok belirsizdir.
Mikro-planlar en iyi her değişiklik hızlıca gözden geçirilebilecek kadar küçük olduğunda çalışır. Her istemi bir PR büyüklüğünde dilim olarak düşünün: ya bir şema düzelmesi ya bir endpoint ya da bir UI durum geçişi—sonra yineleyin.
Pratik bir kural: gözden geçirenin değişikliği anlamak için toplantıya ihtiyacı varsa, tekrar bölün.
Ekip tutarlılığı için tekrarlanabilir istem şablonlarını kısa bir iç sayfada saklayın (ör. /playbook/prompts) ki parçalama alışkanlık haline gelsin, kişisel bir stile dönüşmesin.
Refaktör, “öğrendiklerimiz”in “ne demek istediğimiz”e dönüştüğü noktadır. Vibe kodlama iş akışında erken istemler ve yinelemeler kasıtlı olarak keşfedicidir: ince bir dilim gönderirsiniz, nerede kırıldığını görürsünüz ve gerçek kısıtları keşfedersiniz. Refaktör, tasarımın açıkça ortaya çıktığı ve gelecekteki takım arkadaşlarının okuyup güvenebileceği yapıya, isimlere, sınırlandırmalara ve testlere dönüştürme aşamasıdır.
Temiz bir kod tabanı kendi kendini açıklar. handleThing() gibi belirsiz bir fonksiyonu calculateTrialEndDate() olarak yeniden adlandırıp BillingRules modülüne taşıdığınızda, yürütülebilir bir tasarım dokümanı yazmış olursunuz.
İyi refaktörler genellikle şu görünür:
Mimari diyagramlar hızla eskir. Testlerle desteklenen temiz arayüzler daha iyi yaşlanır.
Bir “Hizmetler” kutu-ok diyagramı yerine tercih edin:
Birisi “bu nasıl çalışıyor?” diye sorduğunda cevap artık bir slayt destesinden ziyade koddaki sınırlar ve onları zorlayan testler olur.
Refaktörleri yeterince kanıt topladığınızda zamanlayın: aynı alanda tekrar eden değişiklikler, kafa karıştırıcı sahiplik veya belirsiz sınırlar yüzünden ortaya çıkan hatalar. İstem yazma ve yineleme hızlı öğrenmenizi sağlar; refaktör öğrendiklerinizi kilitleyerek bir sonraki geliştirmeye netlik sağlar, tahmine değil.
Uzun tasarım dokümanlarını bırakmak, hafıza olmadan çalışmak anlamına gelmez. Amaç, gelecekteki siz veya takım arkadaşlarınızın kodun neden böyle göründüğünü anlayabileceği kadar yazılı bağlamı korumaktır—ilerlemeyi dondurmadan.
Önemli istemlerin ve bunların sonucu olarak nelerin değiştiğinin basit bir günlükünü tutun. Bu bir depo içindeki markdown dosyası (ör. /docs/prompt-log.md) veya issue takip sisteminizde bir thread olabilir.
Yakalayın:
Bu, “AI’ye bir sürü şey sorduk”u denetlenebilir bir iz haline getirir ve gözden geçirmeleri ve sonraki refaktörleri destekler.
Her proje veya özellik alanı için yarım sayfa kadar bir “neden” dokümanı hedefleyin. Bir spes değil—daha çok:
Birisi “neden bunu yapmadık?” diye sorduğunda, cevabı iki dakikada bulunabilmeli.
Hafif bir issue şablonu birçok doküman bölümünün yerini alabilir. Kapsam, riskler ve net kabul kriterleri (“tamam demek…” ) alanları ekleyin. Bu aynı zamanda AI destekli çalışmada işe yarar: isteme issue’yu yapıştırdığınızda çıktılar hedeflenen sınırlara uyar.
İlgili olduğunda, iç sayfalara bağlantı verin; aynı içeriği tekrarlamayın. Bağlantıları göreli tutun (ör., /pricing) ve yalnızca gerçekten bir karar vermeye yardımcı olduklarında ekleyin.
Hızlı yineleme sadece insanların aynı hedefler etrafında yönlendirilmiş olması halinde işe yarar. Hile, “herkesin unuttuğu tek bir büyük doküman”ı birkaç küçük ritüel ve eserle değiştirmektir—özellikle AI kod üretimine yardım ederken insanlar kontrolü elinde tutmalıdır.
Vibe kodlama iş akışı rolleri ortadan kaldırmaz; aksine onları netleştirir.
Yazılım için istem oluştururken bu sahipleri görünür kılın. Örneğin: “Product kapsam değişikliklerini onaylar,” “Design etkileşim değişikliklerini onaylar,” “Engineering mimari değişiklikleri onaylar.” Bu, AI kaynaklı itişin kararları sessizce yeniden yazmasını engeller.
Herkesten 10 sayfalık bir dokümanı okumasını istemek yerine, ana noktalarda 15–25 dakikalık hizalanma oturumları yapın:
Çıktı küçük, çalıştırılabilir kararlar olmalı: şimdi ne gönderiyoruz, ne göndermiyoruz ve neyi tekrar ele alacağız. Sürekliliğe ihtiyaç varsa, bunu uzun bir anlatıya değil depo içindeki kısa bir notta (ör. /docs/decisions.md) yakalayın.
İsteme ve PR açıklamalarına kolayca kopyalanabilecek canlı bir “kısıtlar listesi” tutun:
İterasyon baskısı arttığında bu kısıtlar iş akışının sapmasını engelleyen hafif dokümantasyon demirbaşınız olur.
Kimin neyi onaylayabileceğini ve ne zaman yükseltme gerektiğini tanımlayın. Basit bir politika: “kapsam/UX/güvenlik değişiklikleri açık onay gerektirir” küçük AI destekli düzenlemelerin izinsiz yeniden tasarıma dönüşmesini engeller.
Eğer bir kural isterseniz: doküman ne kadar küçükse, onaylar o kadar sıkı olsun. Hızlı kalıp hizayı kaybetmemek için bu kuralı uygulayın.
Hız yalnızca gönderdiğiniz şeye güvenebiliyorsanız işe yarar. Vibe kodlama iş akışında kalite kapıları her değişiklikte uzun “onay” dokümanlarının yerine geçen kontrollerle yer değiştirir.
İstemleri yazmadan önce, küçük bir kabul kriterleri setini düz dille tanımlayın: kullanıcı ne yapabilmeli, “tamam” nasıl görünür ve asla ne olmamalı. Kontrol edilebilir ve kısa tutun ki bir gözden geçiren dakikalar içinde doğrulayabilsin.
Sonra kriterleri çalıştırılabilir hâle getirin. Yararlı bir desen, her kriteri en az bir otomatik kontrole dönüştürmektir.
Özelliğin “çalışmasını” beklemeyin; yolu uçtan uca çalıştırabilir hale gelir gelmez test ekleyin:
Kabul kriterlerini AI’dan doğrudan test vakaları üretmesini isteyin, sonra gerçekçilik için düzenleyin. Amaç niyetin kapsanmasıdır, devasa bir test paketine sahip olmak değil.
Kod incelemesini tasarım ve güvenlik kontrolü olarak ele alın:
İnceleyenler AI’dan “ne kötü gidebilir” senaryoları önermesini isteyebilir, ama nihai yargı takımınındır.
Fonksiyonel olmayan gereksinimler tasarım dokümanları olmadan kaybolabilir, bu yüzden bunları kapıya dahil edin:
Bunları PR açıklamasına veya kısa bir kontrol listesine ekleyin ki doğrulansın, varsayılmasın.
Vibe kodlama iş akışları çok hızlı olabilir—ama hız kod tabanı zorlanmaya başlayana kadar bazı hataları gizleyebilir. İyi haber: çoğu basit alışkanlıkla önlenebilir.
Eğer mükemmel istemler yazmak için harcadığınız zaman, artış göndermeye harcadığınız zamandan daha fazlaysa, yeni formatta bir tasarım dokümanı felci yaratmışsınız demektir.
Pratik çözüm: istemleri zaman kutusuna alın: "yeterince iyi" bir istem yazın, en küçük dilimi inşa edin ve ancak sonra iyileştirin. İstemleri çalıştırılabilir tutun: girdiler, çıktılar ve hızlı bir kabul kontrolü içersin ki hemen doğrulayabilesiniz.
Hızlı yinelemeler genellikle hangi yaklaşımın seçildiğini, nelerin reddedildiğini ve hangi kısıtların etkili olduğunu gömerken saklar. Sonradan ekip aynı kararları tekrar tartışır veya varsayımları bilmeden bozar.
Bunu önlemek için kararları ilerledikçe kaydedin:
/docs/decisions.md içinde bir madde tutun.Hızla gönderme, sürdürülebilir gönderme demek değildir. Her yineleme kısayollar ekliyorsa, iş akışı değişiklikler riskli hale geldiğinde yavaşlar.
Refaktörü tamamlanma tanımının bir parçası yapın: bir özellik çalıştıktan sonra bir geçiş daha yapıp isimleri sadeleştirin, fonksiyonlar çıkarın ve ölü yolları silin. Eğer refaktör güvenli değilse, bu testlere veya daha net sınırlandırmalara ihtiyaç duyduğunuzun işaretidir.
Koruyucu kurallar olmadan her yineleme kodu farklı bir yöne çekebilir—yeni desenler, tutarsız isimlendirme, karışık klasör konvansiyonları.
Sapmayı önlemek için sistemi sabitleyin:
Bu alışkanlıklar iş akışını hızlı tutarken açıklığı, tutarlılığı ve sürdürülebilirliği korur.
Bunu yaymak, bir butonla tüm şirketi çevirmek yerine kontrollü bir deney olarak yapmak en iyisidir. Etkisini ölçüp hızlıca ayarlayabileceğiniz küçük bir iş dilimi seçin.
Bir özellik alanı (veya bir servis) seçin ve önümüzdeki sprint veya iki için izleyebileceğiniz tek bir başarı metriği tanımlayın—örnekler: biletten merge’e geçen süre, inceleme döngüsü sayısı, kaçan hatalar veya on-call aksaklıkları.
Başlamadan önce “tamam”ın ne demek olduğunu bir cümle ile yazın. Bu deneyi dürüst tutar.
İstemler karşılaştırılabilir ve tekrar kullanılabilir olsun diye paylaşılan bir istem şablonu tanıtın. Basit tutun:
İstemleri depoya (ör., /docs/prompt-log.md) veya bilet sistemine koyun, ama kolay bulunur olsun.
Uzun tasarım dokümanları yerine, her değişiklik için üç hafif eser zorunlu kılın:
Bu, teslimatı yavaşlatmadan niyet izini sağlar.
Kısa bir retro yapın ve çıktılara odaklanın: Metriği hareket ettirdik mi? İncelemeler nerede tıkandı? Hangi istemler kafa karışıklığı yarattı? Şablonu güncelleyin, asgari gereksinimleri ayarlayın ve başka bir alanı genişletip genişletmeme kararını verin.
Ağır dokümanları değiştirmeyi ciddi olarak düşünüyorsanız, yinelemeyi güvenli kılan araçlar kullanmak yardımcı olur: hızlı dağıtımlar, kolay ortam sıfırlamaları ve deney başarısız olduğunda geri alma kabiliyeti.
Örneğin, Koder.ai bu vibe-kodlama iş akışı için inşa edilmiştir: sohbetle mikro-plan ve uygulama kısmını yürütebilir, React tabanlı web uygulamaları, Go + PostgreSQL backend’leri ve Flutter mobil uygulamaları üretebilir ve keşiften daha geleneksel bir repo iş akışına geçmek istediğinizde kaynak kodunu dışa aktarabilirsiniz. Anlık görüntüler ve geri alma, agresif yineleme yaparken “dene”yi düşük riskli kılar.
Tasarım dokümanları vibe kodlama iş akışında yok olmaz—küçülür, daha spesifik olur ve işe daha yakın hale gelir. Önceden yazılmış tek bir “büyük doküman” yerine, güvenilir olan dokümantasyon sürekli üretilir: niyeti belirten istemler, gerçeği ortaya çıkaran yinelemeler ve sonucu anlaşılır ve dayanıklı kılan refaktör.
İstem niyeti belirler. İyi bir istem çalıştırılabilir bir tasarım spesifikasyonu gibi davranır: kısıtlar, kabul kriterleri ve “kırılmaması gereken” kurallar düz dille belirtilir.
Yineleme gerçeği bulur. Küçük döngüler (üret → çalıştır → incele → düzelt) spekülasyonu geri bildirimle değiştirir. Bir şey belirsizse, tartışmazsınız—denersiniz, ölçersiniz ve istemi ya da kodu güncellersiniz.
Refaktör bunu kilitler. Çözüm çalıştığında tasarımı okunabilir kılmak için refaktör yapın: isimlendirme, sınırlar, testler ve nedenini açıklayan yorumlar. Bu, bir eskimiş PDF’den daha güvenilir bir uzun vadeli referans olur.
Hafif, yüksek işaretli birkaç eser tutun:
Tutarlı bir istem/PR şablonu benimseyin, hızlanmadan önce testleri sıkılaştırın ve değişiklikleri dakikalar içinde gözden geçirilebilecek kadar küçük tutun—günler değil. Somut bir yaygınlaştırma sırası istiyorsanız, bkz. /blog/a-practical-rollout-plan-for-your-team.
Bir vibe kodlama iş akışı, niyeti doğal dilde belirleyip küçük bir artışı (çoğunlukla AI ile) üretip çalıştırdığınız, sonucu gözlemleyip düzeltme yaptığınız yinelemeli bir geliştirme döngüsüdür.
Uzun önden planlamayı hızlı geri bildirim ile değiştirir: istem → uygula → test et → düzelt.
Gerçek uygulama kısıtlarını (API tuhaflıkları, kenar durumlar, performans limitleri, entegrasyon detayları) ortaya çıkardıkça çabuk demode olma eğilimindedirler.
Hızlı işlerde ekipler genellikle uzun dokümanları gözden geçirir ya da görmezden gelir; böylece harcanan çaba tutarlı bir fayda sağlamaz.
Dört şey içermelidir:
Birinin hızlıca kod üretebilmesi ve doğrulayabilmesi için yazın.
Açıkça sormak:
Sonra hangi varsayımların kısıt haline geleceğine, hangilerinin teste dönüşeceğine ve hangilerinin ürün/tasarım girdisi gerektirdiğine karar verin.
Gerçek sınırları geçen en küçük uçtan uca yolu seçin (UI → API → veri → arka).
Örnek: “kaydedilmiş aramalar” için her filtre seçeneğini tasarlamak yerine, bir filtre, bir kayıt ve bir geri alma yoluyla başlayın; dilim doğruysa genişletin.
Her döngüyü 30–90 dakikaya zaman kutusuna alın ve somut bir çıktı isteyin (geçen bir test, çalışan bir ekran, ölçülen bir sorgu süresi veya net bir UX bulgusu).
Eğer bir sonraki adımı 1–2 cümlede tarif edemiyorsanız, işi tekrar bölün.
Önce plan isteyin, sonra bunu mikro-kontrol listesine çevirin:
Her istemi bir PR büyüklüğünde bir dilim olarak ele alın ki gözden geçirmek için toplantıya gerek kalmasın.
Yinelemelerden öğrendikten sonra: aynı alanda tekrarlanan değişiklikler, karışık sınırlar veya belirsiz yapılar varsa refaktör zamanı gelmiştir.
Refaktörle niyeti açık hale getirin: anlamlı isimler, domaine uygun modüller ve davranışı kilitleyen testler oluşturun.
Küçük, yüksek sinyalli eserleri saklayın:
Aynı bağlamı tekrar yazmak yerine içe bağlantı verin.
Her yinelemede çalışan kalite kapıları kullanın:
Ayrıca performans, erişilebilirlik, gizlilik/güvenlik gibi fonksiyonel olmayan ihtiyaçları PR kontrol listesine ekleyin.