Atladığınız plan, daha sonra ayıklamak zorunda kalacağınız kesintidir
Yazılım mühendisliğindeki her yaklaşım size hızlı hareket etmenizi, erken yayınlamanızı, üretimde iterasyon yapmanızı söyler. Yapay zeka ile üretilen web siteleri için bu tam tersidir. Buradaki builder, kodu doğrudan isteminizden akıtmayı reddeder — durur, bir plan yazar ve incelemenizi bekler — ve bu ret, bu hattaki her şeyin üzerine kurulduğu tek karardır. Başta daha yavaş, sonrasında her yerde daha ucuz. Ben bu değiş tokuşu her zaman kabul ederim, ve bunun tersini savunan çoğu kişinin yanlış bir tahminin sonrasında neye mal olduğunu gerçekten görmediğini düşünüyorum.
İşte planın önlemek için var olduğu başarısızlık senaryosu. "Stüdyom için bir rezervasyon sitesi" yazıp gönder'e basıyorsunuz. Sistem "rezervasyon"un ne anlama geldiğini tahmin etmek zorunda — bir takvim widget'ı mı, üçüncü taraf bir gömülü sistem mi, çakışma kontrolü olan gerçek bir rezervasyon sistemi mi — ve bunu henüz hiçbir şey yazmadan önce tahmin etmek zorunda, çünkü başka bir sıralama yok. Bir plan içinde yanlış tahmin ederseniz düzeltmesi tek bir cümle, beş saniye, tamamdır. Üretilmiş kod içinde yanlış tahmin ederseniz artık bir cümleyi düzenlemiyorsunuz, zaten yanlış varsayıma dayanan on dosyayı geri sarıyorsunuz. Her iki versiyonu da gördüm. Plan aşamasındaki düzeltme tek bir alışveriş. Aynı belirsizlik üzerine üretim sonrası dönüş ise atıp yeniden inşa etmektir.
Plan sadece bir yapılacaklar listesi de değil, ve insanların kaçırdığı kısım burası. Bir sözleşmedir ve sistem kendini buna bağlı tutar: bir uygunluk kontrolü doğrulayıcısı, bir build'in yayınlanmadan önce onay vermesi gereken agent'lardan biri, tamamlanmış siteyi onayladığınız planla karşılaştırır. Planlanan her sayfa yapıldı mı? Özellik listesi yayınlananla eşleşiyor mu? "Tamam" burada bir his değil — yazılı bir söze göre değerlendirilir, satır satır kontrol edilebilir. Bu, "kod çalışıyor"dan daha güçlü bir garantidir ve bunu yalnızca karşılaştıracak bir belge olduğu için elde edersiniz. Planı kaldırırsanız ölçütü de kaldırmış olursunuz.
Bunun gerçekte nerede işe yaradığı
Build'i yönlendiren kişi olarak elinizdeki güç, kullansanız da kullanmasanız da başa yüklenmiştir. Bilgi mimarisini, sayfa yapısını, hangi özelliklerin v1'de mi v2'de mi olacağını önemsiyorsanız — bu titizlik, plan incelemesinde ilk üretim geçişinden sonrakine göre on kat daha değerlidir. Bir planı yeniden okumak için harcanan dört ek dakika, zaten yanlış giden bir build'i düzeltmek için gidip gelmekten daha iyidir.
En net örnek ürün tipidir — düz statik site, kurulabilir uygulama, framework build, gerçek kalıcılığa sahip sunucu tabanlı uygulama. Bir açılır menü gibi görünür. Değildir. Tüm sürecin en yapısal seçimidir, çünkü sitenin görünüşüyle hiçbir ilgisi olmayan bir düzine şeyi sessizce belirler.
| Ürün tipi | Önizleme | Yayınla | Hesaplar / veritabanı |
|---|---|---|---|
| Düz statik site | Anında, çünkü sadece statik dosyalar | Statik çıktı sorunsuzca kopyalanır | Mümkün değil — giriş istemek, bu tipin yapısal olarak yapamayacağı bir şeyi istemektir |
| Framework build | Önce derlenir; bozuk bir build "bozuk sayfa" değil "önizleme yok" olarak görünür | Derlendikten sonra aynı temiz statik kopyalama yolu | Mümkün değil |
| Sunucu tabanlı uygulama | — | Gerçekten bir sürecin çalışacağı bir yere ihtiyaç duyar, bu da farklı şekilde başarısız olur — eksik bir dosya değil, çökmüş bir süreç | Hesapların ve veritabanlarının hiç var olduğu tek tip |
Ve türü daha sonra öylece yükseltemezsiniz. Düz bir siteden sunucu destekli bir uygulamaya geçmek bir ayar değiştirmek değildir — neredeyse ikinci bir derlemedir, çünkü planın varsayımlarının yarısı (sayfaların nasıl yüklendiği, verinin nerede tutulduğu, "yayınlamanın" ne anlama geldiği) eski türe göre yapılmıştır. O yüzden plan aşamasında söyleyin, yarı emin olsanız bile: "hesaplara ihtiyaç duyma ihtimalim var." Sunucu destekli bir uygulama için planlayıp yalnızca statik kısımları kullanmak size hiçbir şeye mal olmaz. Sonradan buna ihtiyacınız olduğunu keşfetmek ise yeniden bir derlemeye mal olur.
Eleştirmenlerin haklı olduğu noktalar
Bunların hiçbiri bedava değil ve öyleymiş gibi davranmayacağım. Çalışma başına izole çalışma alanları, bilgi dosyalarınızın her seferinde yeniden kopyalandığı, hiçbir şeyin bilgisayarınıza geri ulaşmadığı anlamına gelir — derleme sırasında dizüstü bilgisayarınız çökerse sizin için iyi, gecikme açısından kötü, çünkü bir çalışma alanı hazırlamak ve framework derlemeleri için bir konteyner sınırı içinde gerçek bir bağımlılık kurulumu çalıştırmak gerçek zaman alır. Bu konteyner sınırı var çünkü bir framework derlemesi `npm install` ve keyfi derleme betikleri çalıştırır — sizin yazmadığınız, derleme zamanı yetkileriyle çalışan kod — ve bunu izolasyonsuz paylaşımlı bir sunucuda yapmak, bir bağımlılık karışıklığı saldırısıyla başka bir kiracının verisine dokunmaktan bir adım uzaktadır. Hızlı-ama-güvensiz seçeneği vardı. Sadece yapmaya değer bir takas değildi.
Doğrulama konusunda da aynı hikaye. Tamamlanmış bir derleme, üretim durduğunda değil; bir dizi bağımsız doğrulayıcı engellenmeye değer bir şey bulmayı bıraktığında ardışık düzenden çıkar:
- Kod incelemesi
- Güvenlik
- Bağlantılar ve SEO
- Erişilebilirlik
- Uygunluk
- Gerçek bir tarayıcı içi çalıştırma
Bu tek geçişli bir işlem değil, işaretle-düzelt-yeniden kontrol et döngüsüdür; kimsenin söyleyecek bir şeyi kalmayana kadar döner, çünkü tek bir linter geçişi kendi düzeltmesinin yol açtığı bir gerilemeyi kaçırabilir. Aynı sayfada bozuk bir bağlantıyı düzeltip yanlışlıkla başlık hiyerarşisini bozmak, tam olarak tek seferlik bir kontrolün kaçırdığı ve bir yeniden kontrolün yakaladığı türden bir şeydir. Bu döngünün dürüst maliyeti, bazen sonunda görünür bir neden olmadan bir dakika daha uzun süren bir derlemedir. İnsanlar o dakikayı fark eder. Az önce sitelerini tartışmayı bitiren altı ajanı fark etmezler. Bu, deneyim hakkında adil bir şikayettir — sadece bu tartışmanın hiç yaşanmadan yayına çıkmak için iyi bir argüman olduğunu düşünmüyorum.
