Her front-end geliştirici bu hissi bilir. npm install dört dakika sürer. Production bundle sessizce bir megabaytı geçer. Tek satırlık bir CSS düzeltmesi, iki paket arasında üç dosyaya dokunmayı gerektirir. Yeni bir işe alım, ilk haftasının tamamını sadece dev sunucusunu başlatmaya harcar.
InfoWorld'ün front-end karmaşıklığının gizli maliyeti analizi, çoğu ekibin sezdiği ancak nadiren ölçtüğü bir şeyi adlandırıyor: modern front-end işinin pahalı kısmı nadiren özellik kodunun kendisidir. Asıl maliyet, onun etrafına sarılmış iskele, build pipeline'ı, bağımlılık grafiği, tasarım sistemi, lint kuralları, CI matrisi ve tüm bunları hareket halinde tutmak için gereken örtülü bilgidir.
Bu iskelenin bir sahibi, sprint kartı veya demosu yoktur. Hiçbir şey göndermez. Sadece çıkarır; hızdan, işe alım hızından, Cuma günü saat 16:00'da bir hatayı anlama yeteneğinizden.
Bu rehber, maliyeti ölçülebilir parçalara ayırıyor, kendi yığınınızı yaklaşık 30 dakikada nasıl denetleyeceğinizi gösteriyor ve tek bir sprint içinde karşılığını veren azaltma stratejilerini adım adım anlatıyor.
Karmaşıklık bir eğim değil, bir mandaldır
İçselleştirilmesi gereken ilk şey, front-end karmaşıklığının bir mandal gibi davrandığıdır. Sadece tek yöne döner.
Bir özellik, yeni bir bağımlılıkla birlikte gönderilir. Daha sonra özellik kullanımdan kaldırılır, ancak bağımlılık kalır; onu kaldırmak, başka bir şeyin onu içe aktarıp aktarmadığını kontrol etmek anlamına gelir ve kimsenin o bir saati yoktur. Bir CSS-in-JS tuhaflığını düzeltmek için bir build eklentisi eklenir; altı ay sonra temel kütüphane değiştirilir, eklenti kalır ve her build'i sessizce 8 saniye yavaşlatır. İki yıl önce yine tek seferlik bir !important tarafından oluşturulan bir özgüllük savaşını kazanmak için tek seferlik bir !important eklenir.
Her bir ekleme savunulabilirdi. Ancak toplam, buton dolgusunu değiştirmenin 40 dakikalık bir araştırma gerektirdiği bir kod tabanı ortaya çıkarır.
Front-end karmaşıklığının dört maliyet merkezi
Ekipler bir "karmaşıklığı azaltma" sprint'ini haklı çıkarmaya çalıştıklarında, argüman genellikle hislere dayanır. Oysa böyle olmak zorunda değil. Front-end karmaşıklığı size dört takip edilebilir para birimi üzerinden fatura keser.
1. Çalışma zamanı ve bundle maliyeti
Her kilobayt JavaScript, genellikle yoğun bir ağdaki 150 dolarlık bir Android telefon olan bir cihazda ayrıştırılır, derlenir ve yürütülür. Çalışma zamanı maliyeti en görünür faturalardır çünkü Core Web Vitals ve Lighthouse puanlarında kendini gösterir. Çoğu kuruluşta aynı zamanda en küçük faturalardan biridir, çünkü hızlı dizüstü bilgisayarları ve iyi Wi-Fi'si olan kullanıcılar bunu fark etmez, bu nedenle asla önceliklendirilmez.
2. Geri bildirim döngüsü maliyeti
Bu beklemenin maliyetidir. Yavaş HMR, 90 saniyelik bir CI build'i, her push'ta çalışması 22 dakika süren bir Playwright paketi. Build'iniz 90 saniye sürüyorsa ve bir geliştirici bunu günde 40 kez çalıştırıyorsa, bu, sekme değiştirmenin bağlam değiştirme cezasını saymazsak, geliştirici başına günde bir saat saf bekleme anlamına gelir.
3. Koordinasyon maliyeti
Takım topolojisiyle eşleşmeyen her soyutlama sınırı bir toplantı ekler. Sahibi olmayan her paylaşılan bileşen bir pazarlığa dönüşür. Her "eski uygulamaya dokunamayız" sınırı, yavaş yavaş ayrışan iki kod tabanında mantığı çoğaltır.
4. Bilişsel ve işe alım maliyeti
En pahalı ve en az ölçülen maliyettir. Yeni bir geliştiricinin bir bileşeni güvenle değiştirebilmesi ve etki alanını tahmin edebilmesi ne kadar sürer? İyi yapılandırılmış bir kod tabanında günler. Dört stil sistemi, özel bir form soyutlaması ve kimsenin tam olarak anlamadığı bir build yapılandırması olan bir kod tabanında aylar sürebilir.
Bugün çalıştırabileceğiniz 30 dakikalık bir karmaşıklık denetimi
Ölçmediğiniz bir şeyi azaltamazsınız. Herhangi bir düzeltme önermeden önce sayıları alın. Bu komutlar size maliyetinizin nerede yoğunlaştığına dair kabaca bir harita verir.
# 1. How many direct dependencies do you actually declare?
npm ls --depth=0 --json | jq '.dependencies | length'
# 2. How many transitive dependencies do you actually install?
find node_modules -maxdepth 3 -name package.json | wc -l
# 3. What is the install footprint?
du -sh node_modules
# 4. What is actually shipping to users?
npx source-map-explorer 'dist/assets/*.js'
# 5. What is declared but never imported?
npx knip
knip sonucu genellikle tüm denetimdeki en göz açıcı sayıdır. Üç yıllık bir front-end kod tabanının %20-30 oranında kullanılmayan bağımlılık, ölü dışa aktarım ve sahipsiz CSS dosyası taşıması alışılmadık bir durum değildir.
Ardından, ekibinizin her gün hissettiği maliyet olduğu için geri bildirim döngüsünü ölçün:
// scripts/measure-build.mjs
import { performance } from 'node:perf_hooks';
import { execSync } from 'node:child_process';
const runs = [];
for (let i = 0; i < 5; i++) {
const t0 = performance.now();
execSync('npm run build', { stdio: 'ignore' });
runs.push(performance.now() - t0);
}
runs.sort((a, b) => a - b);
console.log(`median build: ${(runs[2] / 1000).toFixed(1)}s`);
Medyan build süresini ekip büyüklüğünüzle ve günlük build çağrılarının dürüst bir tahminiyle çarpın. Bu, mühendis-saat cinsinden aylık geri bildirim döngüsü faturanızdır. Neredeyse her zaman en büyük tek kalemdir ve neredeyse her zaman düzeltilebilir.
Framework değişimi: kimsenin bütçe ayırmadığı yükseltme koşu bandı
Front-end, yığındaki herhangi bir katmandan daha kısa bir yarı ömre sahiptir. UI kütüphaneleri, state yöneticileri, stil çözümleri, bundler'lar ve meta-framework'lerin tümü yaklaşık 24-36 aylık bir döngüde yenilenir. Hevesle yükseltme yapan bir ekip, kapasitesinin kalıcı bir kısmını göçe ayırır. Tembelce yükseltme yapan bir ekip ise, sonunda bir yeniden yazmayı zorunlu kılan birikimli bir güvenlik ve uyumluluk açığı biriktirir.
Her iki yol da pahalıdır. Aradaki fark, bunlardan yalnızca birinin planlı olmasıdır.
Pratik çözüm, yükseltmeleri kahramanca olaylar olarak görmeyi bırakıp onları ölçülü bir boru hattı olarak ele almaya başlamaktır:
- **Ana sürümü sabitleyin, alt sürümleri otomatikleştirin.**Haftalık periyotta yama ve alt sürümler için Dependabot veya Renovate kullanmak, asla 40 sürümlük bir sıçrama ile karşı karşıya kalmamanızı sağlar. -Çeyrek başına bir göç için açıkça bütçe ayırın."Bir gün" değil. Tarihi olan adlandırılmış bir hedef. -Yükseltme sırasında yükseltme notları yazın, sonradan değil. O koda daha sonra dokunacak mühendis, eksik dokümantasyonun bedelini ödeyen kişidir.
Tasarım sistemi kayması: sessiz çarpan
Beş yıllık bir kod tabanını temiz olandan ayıran desen budur.
Bir tasarım sistemi token'larla birlikte gelir: boşluk skalası, yazı tipi skalası, renk paleti. Ardından bir ürün ekibinin, standart karttan neredeyse farksız, 16 piksel yerine 12 piksel dolgulu bir karta ihtiyacı olur. Token'ı değiştirmek yerine, onu yerel olarak geçersiz kılarlar. Ardından başka bir ekip bu geçersiz kılmayı geçersiz kılar. Bir yıl içinde uygulama genelinde 47 farklı dolgu değeriniz ve kimsenin gerçekte oluşturmadığı bir UI'ı tanımlayan bir tasarım sisteminiz olur.
Bu kayma, belirli ve birikimli bir şekilde pahalıdır: gelecekteki her tasarım değişikliğini bir token düzenlemesi yerine bir ara-bul-yok et görevine dönüştürür.
/* Before: three competing sources of truth */
.card { padding: 16px; }
.panel { padding: 1rem; }
.widget { padding: var(--space-4, 16px) !important; }
/* After: one token, one scale, one place to change */
:root { --space-4: 1rem; }
.card, .panel, .widget { padding: var(--space-4); }
Gerçek dünya temel çizgisini ölçmek
En hafife alınan karmaşıklık azaltma tekniklerinden biri hiçbir şeye mal olmaz: diğer ekiplerin aynı sorunu nasıl çözdüğüne bakın ve bunun en küçük versiyonunu kopyalayın.
Bir fiyatlandırma tablosu, bir gezinme menüsü veya bir kahraman bölümü yeniden oluşturmanız gerektiğinde, zihinsel olarak en ucuz hamle genellikle sıfırdan yeni bir bileşen oluşturmak ve kendi !important geçersiz kılmalarını biriktirmesine izin vermektir. Toplamda daha ucuz olan hamle ise, iyi inşa edilmiş bir sitenin bu öğeyi nasıl uyguladığını incelemek, hesaplanan değerleri çıkarmak ve bilinen iyi bir temelden başlamaktır.
// Paste in DevTools on the live site you're studying
const el = document.querySelector('.pricing-card');
const cs = getComputedStyle(el);
console.log({
font: cs.font,
padding: cs.padding,
gap: cs.gap,
radius: cs.borderRadius,
shadow: cs.boxShadow,
transition: cs.transition,
});
```DivMagic tam olarak bu iş akışı için geliştirildi. `getComputedStyle` çıktısını alan alan elle kopyalamak ya da daha kötüsü, bir düzeni göz kararıyla yeniden oluşturup 6px kaymış bir sürümü yayına almak yerine, uzantıyı canlı herhangi bir sayfadaki herhangi bir öğeye yönlendirir ve ortaya çıkan HTML ile CSS'i doğrudan projenize aktarırsınız. Sonuç, "yeni" bir bileşenin bir yaklaşıklıktan değil, referans bir uygulamadan başlamasıdır; bu da daha az geçersiz kılma katmanı, daha az tasarım incelemesi gidiş-dönüşü ve yukarıda anlatılan kaymadan daha azı anlamına gelir.
## Gerçekten işe yarayan beş azaltma stratejisi
### Kural 1: Paket boyutunu, para bütçeler gibi bütçeleyin
Ana paket açık bir onay olmadan %5'ten fazla büyüdüğünde derlemeyi başarısız kılan bir boyut kontrolünü CI'ya ekleyin. `size-limit` bunu yaklaşık on satırda yapar:
```json
{
"size-limit": [
{ "name": "main", "path": "dist/assets/main-*.js", "limit": "180 kB" },
{ "name": "vendor", "path": "dist/assets/vendor-*.js", "limit": "90 kB" }
]
}
Bir bütçe, paket büyümesini görünmez bir kaymadan görünür ve tartışmaya açık bir karara dönüştürür. Bütün mesele de bu.
Kural 2: Eklediğiniz her bağımlılık için bir bağımlılık silin
Katı bir politika benimseyin: her yeni çalışma zamanı bağımlılığı, mevcut bir bağımlılığın kaldırılmasını ya da yazılı bir gerekçeyi gerektirir. Bu, kütüphane karşıtı olmakla ilgili değil; tam yaşam döngüsü maliyetini kararın içine zorla dahil etmekle ilgilidir. Tek bir 3 KB'lık tarih kütüphanesi sorun değildir. Yirmi tanesi 60 KB artı yirmi yükseltme yolu artı yirmi tedarik zinciri yüzeyi demektir.
Kural 3: Araç yüzeyini daraltın
Projenizde hem Webpack hem Vite yapılandırması varsa, ya da hem Babel hem SWC, ya da hem ESLint hem Biome varsa, birinin yeterli olacağı yerde iki sisteminiz var demektir ve artık her geliştirici hangisinin geçerli olduğunu bilmek zorundadır. Birleştirme projeleri sıkıcıdır, gösterişsizdir ve genellikle haftalar içinde kendini amorti eder.
Kural 4: Tasarım sistemini stil konusundaki tek doğruluk kaynağı haline getirin
Tek bir token dosyası. Tek bir boşluk ölçeği. Bileşen CSS'inde sabit kodlanmış px değerlerini işaretleyen lint kuralları. Her geçersiz kılmada "bu bir token olmalı mı?" diye soran inceleme disiplini. Amaç sıfır geçersiz kılma değil; her geçersiz kılmanın varsayılan yol olmak yerine bilinçli ve görünür bir istisna olmasıdır.
Kural 5: Geri bildirim döngüsünü ölçümleyin
Medyan derleme süresini ve CI süresini bir panoda birinci sınıf metrikler olarak izleyin. Bir derleme eşiğinizi aştığı anda, tipik olarak yerelde 30 saniye, CI'da 5 dakika, bu bir hata olarak ele alınır. Geri bildirim döngüsü gerilemeleri, gözden kaçırılması en kolay tek maliyettir; çünkü buna neden olan kişi bunu neredeyse fark etmez ve bedelini herkes öder.
| Approach | Up-front Cost | Ongoing Cost | Onboarding Drag |
|---|---|---|---|
| Add abstraction per feature | Low | High | High |
| Framework rewrite | Very high | Low | Medium |
| Incremental budget + ratchet rules | Medium | Low | Low |
| Do nothing | Zero | Compounding | Very high |
Asıl soru "nasıl daha hızlı yayına alırız?" değil. Asıl soru "kod tabanımızın ne kadarı özellikleri desteklemek için var, özelliklerin kendisi olmak yerine?"
30 günlük karmaşıklık azaltma planı
Azaltma, tek bir kahramanca yeniden düzenlemeden ziyade bir dizi küçük ve doğrulanabilir kesinti olarak en iyi şekilde işler.
**1. Hafta, Ölçün.**Denetimi çalıştırın. Üç sayı üretin: kurulum boyutu, derleme süresi ve kullanılmayan bağımlılıkların sayısı. Bunları bir panoya koyun. Kimse kendi depolarından sizin ürettiğinizi izlediği bir sayıyla tartışmaz. **2. Hafta, Silin.**Ölü bağımlılıkları, öksüz CSS'i ve kullanılmayan dışa aktarımları kaldırın. Ana sürümleri sabitleyin. Bu, tüm plandaki en yüksek değer/risk oranıdır ve neredeyse her zaman yalnızca inceleme gerektiren bir değişikliktir. **3. Hafta, Bütçeleyin.**CI'ya paket boyutu sınırları, bir derleme süresi eşiği ve bir bağımlılık politikası ekleyin. Bunlar, cırcırın geri dönmesini engelleyen korkuluklardır. 4. Hafta, Birleştirin. En kötü tekrarlamayı seçin — iki HTTP istemcisi, iki stil sistemi, iki tarih kütüphanesi — ve onu tek bir çözüme indirin. Önce/sonra sayılarını ekibe duyurun. İvme teknik bir varlıktır.
Bu neden şimdi önemli
Ön uç ekosistemi, yetenek eklemenin marjinal maliyetinin çarpıcı biçimde düştüğü bir döneme giriyor; kod üretimi, yapay zekâ destekli iskelet oluşturma ve bileşen üreticileri, daha fazla kod üretmeyi son derece kolaylaştırıyor. Bu da yetenek sürdürmenin marjinal maliyetini baskın değişken haline getiriyor. Haftada 500 bileşen üretebilen ama bir tanesini bile silemeyen bir ekip, elle yirmi bileşen yazan bir ekipten daha kötü durumdadır.
Ön uç karmaşıklığının gizli maliyeti bir teknoloji sorunu değildir. Bir disiplin sorunudur: ölçme disiplini, silme disiplini ve korkulukları ürünün bir kesintisi değil, ürünün bir parçası olarak ele alma disiplini.
Karmaşıklık ölçeğin bedeli değildir. Neyin kaldırılacağına hiç karar vermemiş olmanın bedelidir.
Sıkça sorulan sorular
**Ön ucumun gerçekten çok karmaşık olup olmadığını nasıl anlarım?**Üç sinyal kullanın. Birincisi, yeni bir işe alınan kişinin ilk anlamlı commit'e ulaşma süresi; gün cinsinden ölçülür. İkincisi, tipik bir PR'da değişen dosya sayısına göre derleme süresinin oranı. Üçüncüsü, tek bir geliştiricinin stil sistemini kafasında tutup tutamaması; tutamıyorsa kayma zaten başlamıştır. Büyük bir uygulamada bazı karmaşıklıklar kaçınılmaz değil mi?
Evet. Amaç asla sıfır karmaşıklık değildir; amaç, geri verilebilen kiralanmış karmaşıklıktır. İyi ayrıştırılmış bir soyutlama, sizin seçtiğiniz ve kaldırabileceğiniz karmaşıklıktır. Geçersiz kılmalar ve geçişli bağımlılıklardan oluşan bir yumak ise birikmiş ve kimsenin güvenle silemeyeceği karmaşıklıktır.
**En hızlı tek kazanım nedir?**Kullanılmayan bağımlılıkları ve ölü dışa aktarımları denetleyin. Bu genellikle aynı gün yapılan bir değişikliktir, neredeyse sıfır ürün riski taşır, kurulum ve derleme süresini hemen azaltır ve daha büyük değişiklikler istemeden önce paydaşlara gösterebileceğiniz inandırıcı bir sayı verir. Bir referans sitesinden UI kopyalamak, azaltma stratejisine nasıl uyar?
En büyük kayma kaynaklarından birini ortadan kaldırır: bir şeyi görsel yaklaşıklıktan yeniden oluşturup ardından farkları geçersiz kılmalarla örtmek. DivMagic gibi bir araçla çıkarılmış gerçek ve çalışan bir uygulamadan başlamak, doğru boşluk, yazı tipi ölçeği ve gölge değerlerinde başladığınız ve daha sonra sürdürecek çok daha az şeyiniz olduğu anlamına gelir.
