Frontend'de Memory Leak Analizi ve Performans İyileştirme

Frontend projeleri küçükken mimari kararların etkisi çoğu zaman görünmez. Birkaç component, birkaç API çağrısı ve sınırlı state yönetimiyle proje rahat ilerler. Fakat ürün büyüdükçe aynı modalın beş farklı sürümü, benzer validasyonların farklı klasörlerde tekrarlanması ve feature'ların birbirine doğrudan bağımlı hale gelmesi geliştirme hızını düşürmeye başlar. Frontend Projelerinde Yeniden Kullanılabilir Mimari Tasarımı bu noktada yalnızca kod tekrarını azaltmak için değil, değişikliklerin güvenli ve öngörülebilir biçimde yapılabilmesi için önem kazanır. Bu rehberde component tasarımından Feature-Sliced Design yaklaşımına, monorepo yapısından design system governance modeline kadar yeniden kullanılabilir frontend mimarisini uygulamalı bir bakışla ele alacağız.

Yeniden Kullanılabilir Frontend Mimarisi Nedir?

Yeniden kullanılabilir frontend mimarisi, uygulama parçalarının ihtiyaç duyulan bağlamlarda tekrar kullanılabilmesini sağlarken bağımlılıkların kontrol altında tutulduğu bir tasarım yaklaşımıdır. Buradaki amaç bütün kodu ortak klasörlere taşımak değildir. Aksine hangi kodun local kalması, hangi parçanın domain seviyesinde bulunması ve hangi component'ın gerçekten shared olması gerektiği açık biçimde belirlenir. İyi mimari component sınırlarını, API sözleşmelerini, state yönetimini ve dependency flow'u birlikte düşünür. Bu sayede proje büyürken geliştirme hızı tamamen yeni katmanlar ve istisnalar üretmek zorunda kalmaz.

Frontend Architecture Neyi Kapsar?

Frontend architecture yalnızca klasör isimlerinden oluşmaz. Component sınırları, state yönetimi, API katmanı, dependency yönü ve build süreci mimarinin bir parçasıdır. Tasarım sistemi, test stratejisi ve deployment modeli de aynı bütüne dahildir. Bir projede klasör yapısı düzenli görünürken component'lar birbirine yoğun biçimde bağlıysa mimari yine sorunlu olabilir. Bu nedenle frontend architecture, kodun nasıl organize edildiği kadar değişikliklerin sistem içinde nasıl yayıldığını da kapsar.

Reusability Nedir?

Reusability bir kod parçasının başka bir kullanım alanında büyük değişiklik gerektirmeden kullanılabilmesidir. Yeniden kullanılabilir component yalnızca iki yerde import edilmiş component değildir. API'si anlaşılır, bağımlılıkları sınırlı ve davranışı öngörülebilir olmalıdır. Bunun yanında tekrar kullanımın gerçek bir ihtiyaca dayanması gerekir. Tek bir feature için yazılmış kodu gelecekte belki kullanılır düşüncesiyle generic hale getirmek çoğu zaman gereksiz maliyet üretir.

Reusable Kod ile Generic Kod Aynı Şey midir?

Reusable kod ile generic kod aynı anlamı taşımaz. Generic tasarım birçok farklı senaryoyu parametrelerle desteklemeye çalışabilir. Reusable kod ise belirli bir problemi tutarlı biçimde birden fazla yerde çözebilir. Çok generic bir component yirmi farklı prop nedeniyle anlaşılması zor hale gelebilir. Bu nedenle iyi yeniden kullanılabilirlik çoğu zaman sınırsız esneklikten değil doğru seçilmiş sınırlar ve küçük, anlaşılır API'lerden doğar.

İyi Frontend Mimarisinin Temel Hedefleri

İyi frontend mimarisi yalnızca bugünkü geliştirme hızını değil gelecekteki değişiklik maliyetini de düşünür. Maintainability, scalability ve testability temel hedefler arasında yer alır. Reusability ortak çözümlerin tekrar kullanılmasını sağlarken Developer Experience ekiplerin bu çözümleri rahatça kullanabilmesini destekler. Bu hedeflerden biri diğerlerini tamamen ezmemelidir. Örneğin aşırı generic bir component yeniden kullanılabilir görünürken bakım ve test maliyetini yükseltebilir.

Maintainability

Maintainability kodun zaman içinde anlaşılabilir ve değiştirilebilir kalmasını ifade eder. Component sorumlulukları açık olduğunda değişikliklerin etkisi daha kolay tahmin edilir. Benzer işlevlerin farklı klasörlerde farklı biçimde çözülmesi bakım maliyetini artırır. Ortak naming ve dependency kuralları bu yükü azaltır. Amaç yalnızca az dosya değil, değiştirildiğinde beklenmeyen yan etkiler üretmeyen bir sistem oluşturmaktır.

Scalability

Frontend scalability yalnızca kullanıcı trafiğiyle ilgili değildir. Ekip ve kod tabanı büyüdüğünde mimarinin aynı düzeni koruyabilmesi de ölçeklenebilirliğin parçasıdır. Beş kişilik ekipte işe yarayan devasa components klasörü elli kişilik organizasyonda ciddi sorun yaratabilir. Feature sınırları ve public API bu büyümeyi daha kontrollü hale getirir. İyi ölçeklenebilir mimari yeni feature eklerken bütün sistemi yeniden organize etmeyi gerektirmez.

Testability

Testability kod parçalarının bağımsız biçimde doğrulanabilmesini ifade eder. Business logic component render sürecine gömülü olduğunda test yazmak zorlaşır. Hook, service veya use case gibi sınırlar davranışın daha kolay test edilmesini sağlayabilir. Public contract açık olduğunda consumer testleri de daha anlamlı hale gelir. Test edilebilirlik mimari kalitenin güçlü göstergelerinden biridir.

Reusability

Reusability aynı çözümün tekrar tekrar yazılmasını azaltır. Fakat her tekrar shared abstraction gerektirmez. Benzer görünen iki component zaman içinde farklı yönlere gelişebilir. Gerçek kullanım ihtiyacı ortaya çıktığında ortaklaştırma daha güvenli sonuç verir. Bu nedenle önce local, sonra shared yaklaşımı frontend mimarisinde güçlü bir başlangıç prensibidir.

Developer Experience

Developer Experience iyi mimarinin günlük kullanım tarafını gösterir. Yeni feature oluşturmak için onlarca dosyayı manuel bağlamak gerekiyorsa mimari teorik olarak düzenli olsa bile ekip verimsiz çalışabilir. Starter template, iyi isimlendirme ve açık dokümantasyon karar süresini azaltır. Lint ve CI kuralları mimari hataları erken gösterir. Developer Experience yüksek olduğunda doğru yolu seçmek ekstra çaba gerektirmez.

Frontend Projelerinde Yeniden Kullanılabilir Mimari Neden Gereklidir?

Frontend projelerinde tekrar eden ihtiyaçlar ürün büyüdükçe daha görünür hale gelir. Aynı form alanının, tarih seçicinin veya API hata işleme mekanizmasının birçok ekip tarafından ayrı ayrı geliştirilmesi doğrudan zaman kaybı oluşturur. Buna rağmen çözüm her şeyi tek shared klasörde toplamak değildir. Yeniden kullanılabilir mimari tekrar kullanım için doğru sınırlar ve contracts oluşturur. Bu yaklaşım yeni feature süresini kısaltırken refactoring ve onboarding risklerini de azaltabilir.

Kod Tekrarını Azaltmak

Kod tekrarının tamamı kötü değildir. Bazen benzer iki kod parçasını bir süre ayrı tutmak gelecekteki ihtiyaçları daha iyi anlamayı sağlar. Fakat aynı doğrulama veya UI davranışı sürekli kopyalanıyorsa bakım yükü büyür. Bir hata düzeltildiğinde bütün kopyaların bulunması gerekir. Gerçek ortak davranış netleştiğinde shared abstraction oluşturmak tekrarın maliyetini azaltır.

Yeni Feature Geliştirme Süresini Kısaltmak

Yeni feature geliştirme süresi yalnızca business logic yazma süresinden oluşmaz. Form, API client, loading durumu ve error handling gibi ortak ihtiyaçlar tekrar tekrar zaman tüketebilir. Reusable component ve ortak infrastructure hazır olduğunda ekip doğrudan feature değerine odaklanır. Yeni geliştirici de hangi yaklaşımın kullanılacağını yeniden araştırmak zorunda kalmaz. Bu nedenle reusable architecture bir hızlandırıcı olarak değerlendirilebilir.

Tasarım Tutarlılığını Sağlamak

Aynı ürün içinde üç farklı button davranışı kullanıcı deneyimini zayıflatır. Shared UI component'lar tasarım kararlarını kod seviyesinde tekrar kullanılabilir hale getirir. Design token kullanımı renk, spacing ve typography tutarlılığını artırır. Farklı ekipler yeni ekran geliştirirken aynı temel component'ları kullanabilir. Tutarlılık yalnızca görsel değil accessibility ve interaction davranışlarını da kapsamalıdır.

Refactoring Riskini Azaltmak

İyi sınırlar refactoring sırasında değişikliğin etkisini azaltır. Public API üzerinden kullanılan bir modülün iç yapısı consumer'ları etkilemeden değiştirilebilir. Deep import kullanımı ise internal detayları dışarı açarak bu esnekliği azaltır. Shared component contract'ı stabil tutulduğunda implementation yeniden yazılabilir. Bu nedenle reusable architecture yalnızca kod paylaşımı değil güvenli değişiklik kapasitesi sağlar.

Yeni Geliştiricilerin Projeye Adaptasyonunu Kolaylaştırmak

Yeni geliştiriciler projeye ilk katıldığında en fazla zaman hangi dosyanın nerede bulunacağını anlamaya harcayabilir. Feature-based yapı ve ortak naming kuralları bu süreci kısaltır. Design system ve shared library kullanımı tekrar eden soruların sayısını azaltır. Dokümantasyon ile Storybook component kullanımını görünür hale getirir. Tutarlı architecture onboarding süresini doğrudan etkiler.

Birden Fazla Ürün Arasında Ortak Kod Kullanmak

Bir organizasyon web, admin ve customer portal gibi birden fazla frontend uygulamasına sahip olabilir. Design token, UI component ve API client gibi parçalar bu projeler arasında paylaşılabilir. Monorepo veya package yaklaşımı ortak kodun dağıtımını kolaylaştırır. Ancak business domain kodunu gereksiz biçimde bütün ürünlere taşımak coupling yaratabilir. Paylaşım altyapı ve gerçekten ortak davranış seviyesinde planlanmalıdır.

Frontend'de Neler Yeniden Kullanılabilir?

Frontend'de yeniden kullanılabilirlik yalnızca Button veya Input component'larıyla sınırlı değildir. Hook, API client, validation schema ve test utility gibi birçok teknik parça ortaklaştırılabilir. Bununla birlikte her katmanın paylaşım kriteri farklıdır. Domain içeren kodun başka feature'lara taşınması dikkatli değerlendirilmelidir. Shared katman mümkün olduğunca feature detaylarından bağımsız kalmalıdır.

UI Components

Button, Modal ve FormField gibi temel UI component'ları doğal reuse adaylarıdır. Görsel ve interaction davranışlarının ortak olması yüksek değer sağlar. Component API küçük tutulmalıdır. Domain metinleri veya business rule doğrudan primitive component içine eklenmemelidir. UI component ne kadar bağımsızsa farklı feature'larda kullanımı o kadar kolay olur.

Custom Hooks

Custom hook tekrar eden state veya lifecycle davranışını paylaşmak için kullanılabilir. Hook yalnızca kod satırı azaltmak amacıyla oluşturulmamalıdır. Anlamlı bir davranışı veya integration sınırını temsil etmesi daha değerlidir. Domain-specific hook ilgili feature içinde kalabilir. Shared hook ise feature detaylarını bilmeden çalışmalıdır.

Business Logic

Business logic yeniden kullanılabilir olabilir fakat UI component içine gömülmemelidir. Fiyat hesaplama veya izin kontrolü gibi kurallar domain service veya use case içinde tutulabilir. Böylece farklı ekranlar aynı davranışı tekrar kullanabilir. Test yazmak kolaylaşır. Business logic'in UI framework'üne bağımlılığı da azalır.

API Clients

API client authentication, base URL ve error normalization gibi ortak ihtiyaçları merkezi hale getirebilir. Transport katmanı generic tutulabilir. Domain endpoint'leri ilgili feature veya entity seviyesinde tanımlanabilir. Tek bir devasa API dosyası zamanla bakım sorunu yaratır. Reuse infrastructure seviyesinde yapılmalı, domain sorumluluğu dağıtılmalıdır.

Validation Schemas

Aynı domain verisi birden fazla formda kullanılıyorsa validation schema paylaşılabilir. Bununla birlikte her formun business amacı aynı olmayabilir. Ortak domain kuralı ile ekran özelinde gereken validation ayrılmalıdır. Schema'nın doğrudan UI component'a bağlı olmaması faydalıdır. Böylece API, form ve test senaryolarında tekrar kullanılabilir.

TypeScript Types

TypeScript types contract'ların görünür hale gelmesini sağlar. Shared type'lar gerçekten birden fazla modül tarafından kullanılan stable contract'ları temsil etmelidir. Her interface'i global types klasörüne taşımak düzen sağlamaz. Feature'a özel type ilgili feature içinde tutulabilir. Public type ile internal implementation type arasında ayrım yapılmalıdır.

Utility Functions

Utility function küçük ve bağımsız davranışları tekrar kullanmak için faydalıdır. Fakat utils klasörü zamanla ilgisiz fonksiyonların toplandığı bir alana dönüşebilir. Domain'e ait utility ilgili domain yanında tutulmalıdır. Shared utility framework ve feature bilgisinden bağımsız olmalıdır. İsimler davranışı net biçimde anlatmalıdır.

Configuration

Lint, TypeScript ve build configuration birden fazla projede ortaklaştırılabilir. Monorepo içinde shared config package oluşturmak tekrar eden ayarları azaltır. Değişiklik bütün uygulamalara kontrollü biçimde yayılabilir. Proje özelinde gerekli override'lara izin verilmelidir. Configuration reuse geliştirici deneyimini doğrudan iyileştirir.

Authentication

Authentication infrastructure çoğu uygulamada ortak davranış içerir. Token yönetimi, refresh ve session kontrolü tekrar kullanılabilir. Bunun yanında authorization gibi business kuralları domain'e göre değişebilir. Teknik authentication ile feature bazlı izin logic'i ayrılmalıdır. Böylece security davranışı merkezi kalırken domain esnekliği korunur.

Design Tokens

Design token renk, spacing ve typography gibi temel tasarım kararlarını kod seviyesinde tanımlar. Birden fazla ürün aynı tasarım dilini kullanabilir. Token değişikliği component'ların tamamına kontrollü biçimde yansır. Hard-coded değerler azalır. Tasarım ve development ekipleri ortak sözlük kullanabilir.

Test Utilities

Test setup ve render helper gibi araçlar ortaklaştırılabilir. Router veya provider hazırlığı her testte tekrar edilmemelidir. Shared utility testleri sadeleştirir. Bununla birlikte helper çok fazla gizli davranış oluşturmamalıdır. Testin gerçekten ne kurduğunu geliştirici anlayabilmelidir.

Her Tekrarlanan Kod Shared Olmalı mı?

Her tekrarlanan kod shared yapılmamalıdır. İki component'ın bugün benzer görünmesi gelecekte aynı yönde değişeceği anlamına gelmez. Çok erken oluşturulan ortak abstraction iki feature'ı gereksiz biçimde birbirine bağlayabilir. Local First ve Rule of Three gibi yaklaşımlar gerçek reuse ihtiyacının ortaya çıkmasını beklemeyi teşvik eder. Ortaklaştırma kararının tekrar satır sayısından çok değişim yönüne dayanması daha sağlıklıdır.

Local First Yaklaşımı

Local First yaklaşımı yeni component veya helper'ın ilk olarak kullanıldığı feature yanında tutulmasını önerir. Kod daha sonra gerçek bir reuse ihtiyacı gösterirse shared alana taşınır. Bu yaklaşım erken abstraction riskini azaltır. Feature'ın ihtiyaçları netleşmeden generic API tasarlamak zorunda kalınmaz. Shared katman daha kontrollü büyür.

Rule of Three

Rule of Three benzer çözüm üçüncü kez ortaya çıktığında abstraction ihtiyacının daha ciddi değerlendirilmesini önerir. Bu katı bir matematik kuralı değildir. Amaç yeterli örnek görmeden ortak API tasarlamamaktır. Üç kullanım senaryosu gerçek ortak noktayı daha iyi ortaya çıkarabilir. Böylece component API varsayıma değil gözleme dayanır.

Gerçek Reuse ile Tesadüfi Benzerlik

İki ekran aynı kart yapısını kullanıyor olabilir fakat business anlamları tamamen farklı olabilir. İlk bakışta aynı component'a taşımak kolay görünür. Ancak biri ödeme durumuna, diğeri üyelik sürecine göre gelişirse ortak component hızla prop yığınına dönüşebilir. Gerçek reuse aynı davranışın birlikte değişmesini gerektirir. Tesadüfi benzerlik ise yalnızca bugünkü görünümün benzer olmasıdır.

Component Ne Zaman Shared Katmanına Taşınmalı?

Component'ın shared katmana taşınması için birden fazla kullanım alanı ve stabil bir API sinyali bulunmalıdır. Domain bağımlılığı karar üzerinde belirleyicidir. Feature'a özel business bilgi taşıyan component'ın global shared olması çoğu zaman doğru değildir. Domain-independent primitive'ler daha doğal adaylardır. Component'ın gelecekteki değişim yönü de değerlendirilmelidir.

Tek feature kullanıyorsa

Tek feature tarafından kullanılan component varsayılan olarak local tutulabilir. Shared klasöre taşımak gelecekte kullanılacağı garantisini oluşturmaz. Local yapı ownership'i daha net gösterir. Feature kaldırıldığında component'ın da silinmesi kolay olur. Gerçek reuse ortaya çıkarsa refactoring yapılabilir.

Birden fazla feature kullanıyorsa

Birden fazla feature aynı component'ı kullanıyorsa shared adaylığı güçlenir. Yine de kullanım senaryolarının gerçekten aynı davranışı beklediği kontrol edilmelidir. Component'ın public API'si stabil olmalıdır. Domain bağımlılıkları kaldırılabilir. Shared taşıma sonrası ownership ve test sorumluluğu belirlenmelidir.

Domain bilgisi taşıyorsa

Domain bilgisi taşıyan component her zaman global shared katmana uygun değildir. OrderStatus veya InvoiceSummary gibi component'lar entity veya feature seviyesinde daha anlamlı olabilir. Domain isimlerinin shared UI içine girmesi bağımlılık yönünü bozabilir. Aynı domain içinde reuse mümkündür. Ancak bu reuse global shared ile karıştırılmamalıdır.

Tamamen domain-independent ise

Domain-independent component shared katman için güçlü adaydır. Button, Input ve generic Modal buna örnek olabilir. API'si business kavramlarını bilmeden çalışmalıdır. Styling ve accessibility davranışı merkezi tutulabilir. Bu component'lar design system içinde de paketlenebilir.

Premature Abstraction Nedir?

Premature Abstraction ihtiyaç yeterince anlaşılmadan ortak ve generic çözüm tasarlamaktır. Frontend projelerinde bu hata genellikle çok sayıda prop alan base component'lar olarak görülür. Geliştirici gelecekteki bütün kullanım senaryolarını tahmin etmeye çalışır. Sonuç component'ın anlaşılması ve değiştirilmesi zor hale gelir. Bir miktar duplication çoğu zaman yanlış abstraction'dan daha ucuz olabilir.

Çok Erken Generic Component Oluşturmak

İlk kullanım senaryosunda generic component tasarlamak gerçek ihtiyaçları tahmin etmeyi gerektirir. Henüz ikinci ekranın nasıl davranacağı bilinmez. Geliştirici gelecekte lazım olabilir düşüncesiyle çok sayıda opsiyon ekler. Bu opsiyonların çoğu hiç kullanılmayabilir. Önce concrete kullanım, sonra ortak desen görmek daha güvenilir API üretir.

20+ Prop Alan Component Problemi

Çok sayıda prop genellikle component'ın birden fazla sorumluluğu taşıdığını gösterir. Boolean kombinasyonları davranışı tahmin etmeyi zorlaştırır. Test senaryosu sayısı hızla artar. Composition veya daha küçük component'lara ayırma seçenekleri değerlendirilmelidir. API'nin kullanım kolaylığı prop sayısından daha önemli bir kalite metriğidir.

Her Şeyi Çözmeye Çalışan Base Component'lar

Base component bütün projedeki olası kullanım senaryolarını desteklemeye çalıştığında esnekliği kontrol etmek zorlaşır. Her yeni feature yeni bir prop veya callback ekler. Zamanla component'ın hangi kombinasyonlarının geçerli olduğu belirsiz hale gelir. Primitive ve domain-specific component ayrımı daha sağlıklı olabilir. Composition çoğu zaman devasa base component'tan daha iyi ölçeklenir.

Abstraction Ne Zaman Yapılmalı?

Abstraction tekrar eden davranış ve değişim yönü yeterince görünür olduğunda yapılmalıdır. En az birkaç gerçek kullanım örneği API tasarımına veri sağlar. Hangi parçaların sabit, hangilerinin değişken olduğu anlaşılır. Testler yeni abstraction'ın davranışını güvence altına alır. Karar gelecekteki varsayıma değil mevcut probleme dayanmalıdır.

Duplication ile Abstraction Maliyeti Arasındaki Denge

Duplication kısa vadede bakım yükü oluşturabilir. Yanlış abstraction ise farklı feature'ları uzun süre birbirine bağlayabilir. Küçük tekrar bazen daha güvenli seçimdir. Tekrarın gerçekten aynı nedenle değişip değişmediği incelenmelidir. Frontend architecture için önemli becerilerden biri bu iki maliyet arasında doğru zamanı bulmaktır.

Component Tasarımında Composition Over Inheritance

Composition Over Inheritance frontend component tasarımında esnekliğin temel araçlarından biridir. Component'ları karmaşık miras zincirleriyle genişletmek yerine küçük parçaları bir araya getirmek tercih edilir. React, Vue ve modern UI framework'leri composition yaklaşımını doğal biçimde destekler. Children, slots ve compound component gibi pattern'ler farklı içerikleri aynı davranış etrafında birleştirebilir. Bu yaklaşım generic component ihtiyacını azaltırken API'nin daha anlaşılır kalmasını sağlar.

Component Composition Nedir?

Component composition küçük ve odaklı parçaların birlikte kullanılarak daha büyük UI davranışı oluşturmasıdır. Bir Card component başlık, body ve action alanlarını dışarıdan alabilir. Component her olası içeriği prop olarak tanımlamak zorunda kalmaz. Kullanıcı ihtiyacına göre içerik birleştirir. Bu esneklik base component'ın sürekli büyümesini önler.

Children Pattern

Children pattern wrapper component'ın içeriğini dışarıdan almasını sağlar. Modal veya Card gibi yapılar bunun için uygundur. Component layout ve behavior sağlar, içerik consumer tarafından belirlenir. Böylece content-specific prop sayısı azalır. API daha doğal ve HTML composition mantığına yakın hale gelir.

Compound Components

Compound Components ilişkili UI parçalarını ortak context veya state üzerinden birlikte çalıştırır. Consumer component'ları istediği sırada compose edebilir. Tabs, Select ve Modal gibi yapılarda güçlü bir modeldir. API declarative kalır. Bununla birlikte context ve accessibility davranışı library tarafından iyi yönetilmelidir.

Modal

Modal compound yapıda Trigger, Content, Header ve Footer gibi parçalara ayrılabilir. Consumer yalnızca ihtiyacı olan alanları kullanır. Açılma state'i merkezi yönetilebilir. Focus management ve keyboard behavior ortak component tarafından çözülür. Farklı modal türleri aynı temel davranıştan yararlanır.

Tabs

Tabs yapısı List, Trigger ve Content parçalarına ayrılabilir. Active state parent veya context seviyesinde tutulur. Consumer yeni tab eklerken tek bir devasa config object kullanmak zorunda kalmaz. Keyboard navigation component sistemi tarafından çözülür. UI ve accessibility davranışı tekrar kullanılabilir hale gelir.

Select

Select Trigger, Content ve Item parçalarına ayrılabilir. Bu yapı farklı item render senaryolarına izin verir. Search veya group gibi özellikler eklenebilir. State contract kontrollü tutulmalıdır. Primitive davranış ile domain seçenekleri birbirinden ayrılır.

Table

Table component çok generic prop yapısına kolayca dönüşebilir. Compound yaklaşım Header, Row ve Cell seviyesinde composition sağlayabilir. Ancak büyük veri tablolarında headless table engine daha uygun olabilir. Sorting ve pagination davranışları UI'dan ayrılmalıdır. Kullanım alanına göre pattern seçilmelidir.

Slot Pattern

Slot pattern component'ın belirli bölgelerine dışarıdan içerik yerleştirmeyi sağlar. Header action veya prefix icon gibi alanlar slot olabilir. Bu yaklaşım çok sayıda özel prop oluşturmadan genişletilebilirlik sunar. Vue slots ve React composition benzer hedefe hizmet eder. Slot sayısı arttıkça component contract'ın anlaşılır kalmasına dikkat edilmelidir.

Render Props

Render Props davranışı consumer'ın render kararından ayırmak için kullanılabilir. Component state veya callback sağlar, kullanıcı UI'ı belirler. Modern hook yaklaşımı bazı kullanım alanlarını azaltmıştır. Yine de library seviyesinde esnek API gerektiğinde faydalı olabilir. Pattern kullanım kolaylığı açısından diğer seçeneklerle karşılaştırılmalıdır.

Headless Component Yaklaşımı

Headless component behavior ve accessibility sağlar fakat görsel tasarımı dayatmaz. Design system farklı markalarda kullanılacaksa güçlü bir temel oluşturabilir. Consumer stil ve markup üzerinde daha fazla kontrol sahibi olur. Bu esneklik ek kullanım yükü de yaratabilir. Primitive component ve headless yaklaşım proje ihtiyacına göre dengelenmelidir.

Hangi Pattern Ne Zaman Kullanılmalı?

Basit wrapper için children yeterli olabilir. Birbiriyle ilişkili birçok alt component varsa compound component daha okunaklı API sunabilir. Davranış ile görünümü tamamen ayırmak gerekiyorsa headless yaklaşım değerlendirilebilir. Çok özel render ihtiyacında render props işe yarayabilir. Pattern seçimi kullanım senaryosunun karmaşıklığına göre yapılmalı ve gereksiz katman eklenmemelidir.

Reusable Component API Nasıl Tasarlanır?

Reusable component'ın başarısı büyük ölçüde public API'sinin kalitesine bağlıdır. Prop sayısı arttıkça component daha esnek görünür fakat kullanım ve test maliyeti de yükselir. Variant-based API ve sensible defaults consumer tarafındaki karar yükünü azaltır. Controlled ve uncontrolled kullanım gerektiğinde açık sözleşmeler tanımlanmalıdır. Backward compatibility özellikle birçok uygulamanın kullandığı component library'lerde önemlidir.

Minimum Prop Surface

Component yalnızca gerçekten dışarıdan kontrol edilmesi gereken alanları prop olarak sunmalıdır. Internal implementation detayı public API'ye taşınmamalıdır. Her yeni prop uzun vadeli support yüküdür. Kullanım örnekleri API'nin gereksiz alanlarını ortaya çıkarabilir. Küçük API component'ın anlaşılmasını ve refactoring yapılmasını kolaylaştırır.

Variant-Based API

Variant-based API görsel ve davranış seçeneklerini açık isimlerle gruplar. Çok sayıda boolean yerine sınırlı variant değerleri kullanılır. Bu yaklaşım geçersiz kombinasyonları azaltır. TypeScript ile variant değerleri type-safe hale getirilebilir. Design system component'larında özellikle kullanışlıdır.

variant

Variant component'ın temel görsel veya semantic türünü ifade edebilir. Button için primary, secondary veya danger değerleri kullanılabilir. İsimler tasarım sistemiyle uyumlu olmalıdır. Business-specific variant eklemekten kaçınılmalıdır. Variant listesi gereksiz biçimde büyürse component sınırı yeniden değerlendirilmelidir.

size

Size belirli ve desteklenen ölçü setini ifade eder. Consumer arbitrary pixel değeri vermek yerine tasarım token'larına bağlı seçenek kullanabilir. Bu yaklaşım tutarlılığı artırır. Small, medium ve large gibi değerler yeterli olabilir. Çok fazla size seçeneği tasarım sistemini anlamsız hale getirebilir.

state

State loading, disabled veya error gibi davranışları kontrol edebilir. Ancak bütün state'leri tek prop içinde toplamak her zaman gerekli değildir. Native HTML davranışı mümkün olduğunda korunmalıdır. State'in owner'ı açık olmalıdır. Geçersiz kombinasyonlar type sistemiyle sınırlandırılabilir.

Boolean Prop Explosion'dan Kaçınmak

isPrimary, isSecondary, isDanger ve isGhost gibi boolean prop'lar aynı anda true olabilir. Bu durum geçersiz kombinasyon üretir. Tek variant prop daha anlaşılır contract sağlar. Boolean'lar gerçekten bağımsız durumlar için kullanılabilir. API tasarımı consumer'ın yanlış kombinasyon oluşturmasını zorlaştırmalıdır.

Controlled ve Uncontrolled Components

Controlled component state'i tamamen consumer üzerinden alır. Uncontrolled component internal state kullanabilir. Form input ve dialog gibi yapılarda her iki kullanım modeli faydalı olabilir. API bu iki davranışı açık biçimde ayırmalıdır. Aynı anda controlled ve uncontrolled prop kullanıldığında beklenen davranış belirsiz olmamalıdır.

Sensible Defaults

Sensible defaults en yaygın kullanımın en az configuration ile çalışmasını sağlar. Button için default size veya modal için standard focus davranışı buna örnektir. Consumer sadece farklı ihtiyaç olduğunda override yapar. Bu yaklaşım design system adoption'ını artırır. Default değerler product genelindeki en yaygın davranışı temsil etmelidir.

Escape Hatch Ne Zaman Sağlanmalı?

Her component sınırlı API'ye sahip olmalı fakat bazı ileri kullanım durumları için kontrollü escape hatch gerekebilir. className veya slot bunun örneği olabilir. Escape hatch temel contract'ı tamamen bypass edecek kadar geniş olmamalıdır. Çok sık kullanılıyorsa component API ihtiyacı karşılamıyor olabilir. Kullanım oranı yeni variant ihtiyacını gösterebilir.

Backward Compatibility

Shared component değişikliği birçok consumer'ı etkileyebilir. Public prop silmek major breaking change olarak değerlendirilmelidir. Deprecation süresi geçişi kolaylaştırır. Codemod veya migration guide büyük değişikliklerde yardımcı olabilir. Component library versioning politikası kullanıcılara öngörülebilirlik sağlar.

Frontend Klasör Yapısı Nasıl Tasarlanmalı?

Frontend klasör yapısı proje büyüklüğü ve domain yapısına göre seçilmelidir. Tek bir evrensel doğru klasör düzeni yoktur. Küçük projelerde layer-based yapı yeterli olabilirken büyük uygulamalarda feature-based yaklaşım ownership ve dependency sınırlarını daha iyi gösterebilir. Önemli olan klasör isimlerinin mimari bağımlılıklarla uyumlu olmasıdır. Sadece dosyaları taşıyarak iyi architecture oluşturulamaz.

Layer-Based Architecture

Layer-based yaklaşım dosyaları teknik türlerine göre gruplar. Components, hooks, services ve utils gibi klasörler kullanılır. Küçük uygulamalarda oldukça anlaşılır olabilir. Proje büyüdükçe tek bir klasörde yüzlerce dosya oluşabilir. Domain ownership görünürlüğü zamanla azalabilir.

components

Components klasörü UI component'ları içerir. Küçük uygulamada kullanımı kolaydır. Büyük projede domain-specific ve shared component'lar aynı yerde karışabilir. İsim çakışmaları artabilir. Belirli ölçekten sonra feature bazlı ayrım değerlendirilebilir.

hooks

Hooks klasörü custom hook'ları teknik türüne göre toplar. Başlangıçta düzenli görünür. Ancak useCheckout ve useInvoice gibi domain hook'ları birbirinden bağımsız alanlarda aynı klasöre düşebilir. Ownership zorlaşır. Shared ve feature hook ayrımı daha anlamlı olabilir.

services

Services klasörü API ve business service dosyalarını içerebilir. Bütün servisleri tek yerde toplamak domain sınırlarını zayıflatır. Büyük projede devasa bir servis katmanı oluşabilir. Feature-specific service ilgili feature yanında tutulabilir. Yalnızca gerçek infrastructure davranışı shared service olarak ayrılmalıdır.

utils

Utils klasörü en hızlı büyüyen alanlardan biridir. Farklı domain'lere ait helper'lar aynı yerde birikir. Arama ve ownership zorlaşır. Generic utility ile business helper ayrılmalıdır. Bir utility yalnızca feature içinde kullanılıyorsa local kalması daha anlamlıdır.

Layer-Based Yapının Ölçeklenme Sorunları

Layer-based yapı ekipler büyüdüğünde yatay bağımlılığı artırabilir. Tek feature değişikliği için components, hooks ve services klasörlerinin tamamında gezmek gerekebilir. Domain sınırı dosya sistemi üzerinden görünmez. Bir feature kaldırılırken hangi dosyaların ona ait olduğunu bulmak zorlaşır. Bu nedenle orta ve büyük projelerde feature-based yaklaşım çoğu zaman daha iyi ownership sağlar.

Feature-Based Architecture

Feature-based architecture dosyaları business özelliğine göre gruplar. Checkout veya profile gibi feature'lar kendi component, hook ve API dosyalarına sahip olabilir. Değişikliklerin çoğu aynı klasör içinde kalır. Ownership daha belirgin hale gelir. Shared katman yalnızca gerçekten ortak parçaları barındırır.

Feature'a özgü components

Feature'a özgü component ilgili business davranışına yakın tutulur. CheckoutSummary gibi component'ın global components klasörüne taşınması gerekmez. Feature kaldırıldığında dosyalar birlikte silinebilir. Domain context daha kolay anlaşılır. Gerçek reuse ortaya çıkarsa component daha üst seviyeye taşınabilir.

Feature hooks

Feature hook ilgili kullanım senaryosunun state veya effect davranışını toplar. useCheckout veya useAddressForm gibi isimler domain bağlamını açıklar. Shared hook'larla karışmaz. API dependency feature içinde kalır. Test ve refactoring daha sınırlı alanda yapılır.

Feature API

Feature API ilgili endpoint'leri ve request mapping davranışını kapsayabilir. Generic transport shared infrastructure içinde kalır. Checkout endpoint'leri checkout feature yanında bulunur. Bu yapı devasa merkezi api.ts dosyasını önler. Dependency ve ownership daha kolay anlaşılır.

Feature types

Feature types sadece ilgili domain tarafından kullanılan contract'ları içerir. Global types klasöründe gereksiz isim birikimi oluşmaz. Public type gerekirse feature public API üzerinden export edilir. Internal type dışarı sızdırılmaz. Bu yaklaşım module boundary'yi güçlendirir.

Feature-Based vs Layer-Based Karşılaştırması

Layer-based yapı küçük projelerde basitlik avantajı sunar. Feature-based yapı proje ve ekip büyüdükçe domain ownership'i daha iyi gösterir. Her iki yaklaşım da doğru sınırlarla kullanılabilir. Teknik layer'lar feature içinde de bulunabilir. Seçim proje ölçeği ve değişikliklerin hangi eksende gerçekleştiğine göre yapılmalıdır.

Feature-Sliced Design (FSD) Nedir?

Feature-Sliced Design frontend uygulamalarını belirli katman ve slice yapılarıyla organize eden mimari yaklaşımdır. App, Pages, Widgets, Features, Entities ve Shared gibi katmanlar farklı sorumluluklar taşır. En önemli fikirlerden biri bağımlılık yönünün yukarıdan aşağıya kontrollü ilerlemesidir. FSD büyük projelerde domain sınırlarını ve import kurallarını görünür hale getirebilir. Küçük projelerde ise bütün katmanları zorla kullanmak gereksiz yapı oluşturabilir.

App Layer

App layer uygulamanın global initialization ve provider yapılarını içerebilir. Routing setup, global styles ve application provider'ları burada bulunabilir. Business feature kodu bu katmanda birikmemelidir. App uygulamanın composition root'u gibi düşünülebilir. Alt katmanları bir araya getirir.

Pages Layer

Pages layer route seviyesindeki ekranları temsil eder. Bir page birden fazla widget ve feature'ı compose edebilir. Business logic mümkün olduğunca daha alt katmanlarda tutulmalıdır. Page routing bağlamını bilir. Aynı feature farklı page'lerde tekrar kullanılabilir.

Widgets Layer

Widgets daha büyük ve anlamlı UI bloklarını temsil eder. Header veya ProductRecommendations buna örnek olabilir. Birden fazla feature ve entity'yi compose edebilir. Her projede Widget layer gerekli değildir. Kullanım gerçek büyük UI bölümleri ortaya çıktığında anlam kazanır.

Features Layer

Features kullanıcıya veya business sürecine değer sağlayan davranışları temsil eder. AddToCart veya ChangePassword gibi aksiyonlar burada bulunabilir. Feature kendi UI, model ve API parçalarına sahip olabilir. Başka feature'a doğrudan bağımlılık sınırlanmalıdır. Composition daha üst katmanda yapılmalıdır.

Entities Layer

Entities domain'deki temel kavramları temsil eder. User, Product veya Order buna örnek olabilir. Entity model, type ve temel UI gösterimini içerebilir. Use case davranışı feature seviyesinde kalabilir. Böylece domain nesnesi ile kullanıcı aksiyonu birbirinden ayrılır.

Shared Layer

Shared layer domain-independent infrastructure ve UI parçalarını içerir. Button, generic API client veya date utility burada bulunabilir. Feature veya entity bilgisini bilmemelidir. Bu bağımlılık kuralı shared katmanın çöplüğe dönüşmesini önlemeye yardımcı olur. Shared büyüdükçe alt segmentlere ayrılabilir.

FSD Dependency Rule

FSD dependency rule üst katmanların alt katmanları kullanabilmesini, alt katmanların üst katmanları bilmemesini hedefler. Bu yön dependency graph üzerinde netlik sağlar. Feature'ın Page import etmesi mimari ihlal olabilir. ESLint boundary rule ile kontrol otomatikleştirilebilir. Kurallar dokümandan CI sürecine taşınmalıdır.

FSD Hangi Projelerde Mantıklıdır?

FSD domain sayısı ve ekip büyüklüğü arttığında daha fazla değer sağlar. Çok feature içeren uzun ömürlü ürünlerde ownership kolaylaşır. Dependency kontrolü refactoring güvenini artırabilir. Yeni geliştiriciler aynı pattern'i farklı alanlarda görebilir. Bununla birlikte eğitim ve tooling yatırımı gerektirir.

FSD Ne Zaman Overengineering Olur?

Tek ekranlı küçük uygulamada bütün FSD layer'larını kurmak gereksiz olabilir. Dosya sayısı işlevden daha hızlı büyüyebilir. Geliştirici basit değişiklik için fazla klasör arasında dolaşır. Mimari problem henüz oluşmadan çözüm uygulanmış olur. Küçük projede feature-based basit yapı daha uygun olabilir.

Atomic Design Nedir?

Atomic Design UI component'larını görsel ve yapısal ölçeğe göre sınıflandıran tasarım yaklaşımıdır. Atoms, Molecules, Organisms, Templates ve Pages seviyeleri component sistemini düşünmek için ortak dil sağlar. Özellikle design system oluştururken faydalıdır. Ancak business domain sınırlarını tek başına çözmez. Bu nedenle büyük uygulamalarda feature veya domain architecture ile birlikte kullanılabilir.

Atoms

Atoms en temel UI yapı taşlarını temsil eder. Button, Input ve Icon gibi component'lar bu gruba girebilir. Tek başlarına sınırlı iş davranışı taşırlar. Tasarım token'larıyla güçlü biçimde ilişkilidir. Design system'ın en alt seviyesini oluşturabilirler.

Button

Button temel interaction primitive'idir. Variant, size ve disabled davranışı standardize edilebilir. Keyboard ve accessibility özellikleri component seviyesinde çözülür. Domain-specific metin veya business rule içermez. Birçok uygulama aynı Button contract'ını kullanabilir.

Input

Input form girişinin temel parçasıdır. Label ve error davranışı ayrı primitive veya composite ile birleştirilebilir. Native HTML davranışı mümkün olduğunca korunmalıdır. Accessibility attributes doğru uygulanmalıdır. Validation business kuralı Input içine gömülmemelidir.

Icon

Icon görsel sembolleri ortak API altında sunabilir. Size ve color token kullanımı standardize edilir. Decorative ve semantic icon farkı accessibility açısından önemlidir. Bütün SVG'leri tek component içinde koşullu render etmek gereksiz olabilir. Build ve tree shaking davranışı da değerlendirilmelidir.

Molecules

Molecules birkaç atomun birlikte anlamlı küçük UI davranışı oluşturmasıdır. SearchField veya FormField buna örnek olabilir. Bileşen belirli bir interaction pattern'i temsil eder. Domain bilgisinin minimumda tutulması tekrar kullanımı artırır. Çok fazla katman oluşturmamak önemlidir.

Organisms

Organisms daha büyük UI bloklarını temsil eder. Header veya FilterPanel buna örnek olabilir. Birden fazla molecule ve atom bir araya gelir. Domain bağımlılığı bu seviyede artabilir. Her organism'ın design system içinde olması gerekmez.

Templates

Templates sayfanın içerik yerleşimini tanımlar. Gerçek veri veya domain içeriği yerine layout yapısına odaklanabilir. AdminLayout veya TwoColumnPage buna örnek olabilir. Farklı page'ler aynı template'i kullanabilir. Responsive davranış merkezi hale getirilebilir.

Pages

Pages gerçek içerik ve business verisini template ile birleştirir. Route seviyesinde bulunabilir. Atomic Design burada UI hiyerarşisini tamamlar. Ancak state ve API dependency sınırlarını tek başına tanımlamaz. Bu ihtiyaç için feature architecture ile birlikte düşünülmelidir.

Atomic Design'ın Avantajları

Atomic Design tasarım ve geliştirme ekipleri arasında ortak component dili oluşturur. Primitive reuse'u kolaylaştırır. Design system dokümantasyonu daha düzenli hale gelir. Görsel tutarlılık artar. Component'ın UI ölçeği hakkında hızlı fikir sağlar.

Atomic Design'ın Sınırlamaları

Atomic Design business domain bağımlılıklarını açıklamaz. Bir component'ın molecule mı organism mı olduğu zaman zaman tartışmalı olabilir. Büyük projede kategori tartışması gereksiz zaman tüketebilir. Feature ownership sorununu çözmez. Bu nedenle mimarinin tamamı yerine UI organization aracı olarak değerlendirmek daha sağlıklıdır.

Atomic Design ve Feature-Sliced Design Birlikte Kullanılabilir mi?

Atomic Design ile Feature-Sliced Design farklı problemleri çözdüğü için birlikte kullanılabilir. Atomic Design UI component'larının yapısal seviyesini düşünmeye yardımcı olur. FSD ise business ve dependency sınırlarını düzenler. Shared UI içinde atomic yaklaşım kullanılırken feature component'ları kendi domain alanında kalabilir. Böylece görsel reuse ile business architecture birbirine karıştırılmaz.

Atomic Design ile UI Sınırlarını Belirlemek

Atomic yaklaşım primitive ve composite UI seviyelerini ayırabilir. Button ve Input gibi düşük seviye component'lar ortaklaştırılır. Daha büyük yapılar ihtiyaç oldukça compose edilir. Design system bu sınıflandırmadan yararlanabilir. Domain davranışı atomic seviyelere zorla taşınmamalıdır.

FSD ile Business Domain Sınırlarını Belirlemek

FSD feature ve entity seviyeleriyle domain bağımlılıklarını görünür kılar. Checkout veya Profile gibi kullanım alanları ayrı slice olabilir. Shared UI business kavramlarını bilmez. Page ve Widget daha alt seviyeleri compose eder. Bu yapı business change'in etki alanını sınırlar.

Shared UI İçinde Atomic Structure

Shared UI component library içinde atoms ve molecules sınıflandırması kullanılabilir. Primitive component sayısı büyüdükçe dokümantasyon kolaylaşır. Ancak klasör isimlerinin pratik fayda sağlaması gerekir. Çok küçük library'de ekstra seviye gereksiz olabilir. Yapı ekip tarafından kolay anlaşılmalıdır.

Feature İçinde Local Components

Feature component'ları Atomic Design zorunluluğuyla shared alana taşınmamalıdır. CheckoutSummary sadece checkout içinde kullanılabilir. Component local kaldığında domain ownership net olur. Gerekirse feature içinde küçük component hiyerarşisi kurulabilir. Gerçek reuse ortaya çıktığında uygun üst seviyeye taşınır.

Örnek Hibrit Klasör Yapısı

Hibrit yapıda shared/ui altında primitive ve composite component'lar bulunabilir. features altında her business özelliği kendi component ve model dosyalarını taşır. entities temel domain kavramlarını barındırır. pages bu parçaları compose eder. Bu düzen hem tasarım sistemi hem domain mimarisi için anlaşılır sınırlar oluşturabilir.

Shared Layer Nasıl Tasarlanmalıdır?

Shared layer mimarinin en dikkatli yönetilmesi gereken alanlarından biridir. Çünkü başlangıçta yararlı görünen ortak klasör zamanla her yere konulamayan dosyaların bırakıldığı alana dönüşebilir. Shared UI, lib, config, types ve API infrastructure gibi alt alanlar sorumluluğu daha açık hale getirir. Temel kural shared katmanın feature veya business kullanım senaryosunu bilmemesidir. Bu sınır dependency inversion ve reuse kalitesini güçlendirir.

Shared UI

Shared UI domain-independent component'ları içerir. Button, Modal ve generic FormField burada bulunabilir. Component API business terimlerinden uzak tutulmalıdır. Design token ve accessibility standardı merkezi uygulanabilir. Feature-specific component shared UI içine taşınmamalıdır.

Shared Lib

Shared Lib tarih formatlama veya generic parsing gibi bağımsız yardımcıları içerebilir. Fonksiyonların domain kavramlarına bağlı olmaması gerekir. Utils klasörüne göre daha anlamlı alt domain isimleri tercih edilebilir. Her helper'ın global olması gerekmemelidir. Kullanım alanı azsa local tutulabilir.

Shared Config

Shared Config runtime veya build configuration yardımcılarını içerebilir. Environment variable parsing buna örnektir. Application-specific değerler yine App seviyesinde tutulabilir. Config contract type-safe hale getirilebilir. Secret veya environment mantığı UI component içine taşınmamalıdır.

Shared Types

Shared Types yalnızca gerçekten global contract'ları içermelidir. Her feature interface'ini bu klasöre taşımak dependency belirsizliği yaratır. Utility generic type'lar burada bulunabilir. Public domain type ise entity seviyesinde daha anlamlı olabilir. Type ownership kod ownership ile uyumlu olmalıdır.

Shared API Infrastructure

HTTP transport, auth header ve error normalization shared infrastructure içinde tutulabilir. Endpoint tanımları feature veya entity seviyesinde bulunmalıdır. Böylece transport davranışı tekrar kullanılırken domain ownership kaybolmaz. Test mock'ları da aynı contract üzerinden üretilebilir. API client değişikliği daha kontrollü yapılır.

Shared Klasörünün Çöplüğe Dönüşmesini Önlemek

Shared'e taşıma kriteri dokümante edilmelidir. Dosya en az iki bağımsız domain tarafından kullanılmıyorsa local kalabilir. Feature kavramı taşıyan isimler uyarı sinyali olabilir. Pull request review sırasında ownership sorgulanmalıdır. Mimari lint kuralları bazı yanlış import'ları otomatik engelleyebilir.

Shared Katmanının Feature Bilmemesi Kuralı

Shared layer üst seviye feature'ları import etmemelidir. Aksi durumda dependency yönü tersine döner. Generic component business use case'e bağlanır. Reuse azalır ve circular dependency riski yükselir. Bu kural lint ve module boundary ile otomatik kontrol edilmelidir.

Public API ile Modül Sınırları Nasıl Korunur?

Public API modülün dış dünyaya hangi parçaları sunduğunu açık biçimde tanımlar. Consumer internal dosya yollarına bağımlı olmadığında modül iç yapısı daha rahat değiştirilebilir. Barrel export veya package exports bu contract'ı teknik olarak destekleyebilir. Deep import ise internal implementasyonu istemeden public hale getirir. Stabil modül sınırları büyük frontend projelerinde refactoring güvenini önemli ölçüde artırır.

Public API Nedir?

Public API bir feature veya package'ın dışarıdan kullanılmasına izin verdiği export listesidir. Internal component ve helper'lar dışarı açılmaz. Consumer yalnızca belirlenmiş contract üzerinden çalışır. Bu yaklaşım implementation değişikliğini kolaylaştırır. Public API küçüldükçe modül bağımsızlığı güçlenir.

index.ts / Barrel Export

index.ts dosyası belirli modülün public export'larını tek noktada toplayabilir. Consumer internal path yerine modül kökünden import yapar. Çok büyük global barrel dosyaları circular dependency riskini artırabilir. Barrel modül sınırı seviyesinde kullanılmalıdır. Build tool'un tree shaking davranışı ayrıca kontrol edilmelidir.

Deep Import Neden Risklidir?

Deep import consumer'ı internal klasör yapısına bağlar. Dosya taşındığında birçok proje kırılabilir. Internal component yanlışlıkla public contract'a dönüşür. Package versioning yönetimi zorlaşır. Lint rule deep import kullanımını engelleyebilir.

Internal Component'ları Gizlemek

Bir package içindeki her component dışarı export edilmemelidir. Bazı parçalar yalnızca ana component'ın implementation detayı olabilir. Dışarı açılmadığında refactoring özgürlüğü korunur. Consumer kullanım yolu daha net olur. Public API review versioning sürecinin parçası haline getirilebilir.

Stable Contract Oluşturmak

Stable contract consumer'ın güvenebileceği davranışı tanımlar. Prop ve type isimleri sık değişmemelidir. Internal implementation gerektiğinde tamamen değişebilir. Backward compatibility kararı public contract üzerinden yönetilir. Contract testleri büyük package'larda faydalı olabilir.

Package Exports Kullanımı

Package exports hangi dosya yollarının dışarı erişilebilir olduğunu tanımlamaya yardımcı olur. Public entry point'ler açık biçimde listelenebilir. Deep import teknik olarak sınırlandırılabilir. ESM ve CJS build stratejisiyle uyum kontrol edilmelidir. Monorepo package sınırları daha net hale gelir.

Dependency Management Frontend Mimarisini Nasıl Etkiler?

Frontend mimarisinin kalitesi dependency graph üzerinden oldukça net görülebilir. Feature'ların birbirini rastgele import ettiği sistemlerde klasör yapısı ne kadar düzenli görünürse görünsün coupling yüksektir. Tek yönlü dependency flow değişiklik etkisini sınırlar. Circular dependency ve deep import otomatik kontrollerle erken yakalanabilir. Dependency graph mimari dokümantasyonun yanında gerçek kod yapısını gösteren önemli bir araçtır.

Tek Yönlü Dependency Flow

Tek yönlü bağımlılık daha düşük seviyelerin üst seviyeleri bilmemesini sağlar. Shared feature import etmez, feature page import etmez. Bu yaklaşım circular dependency riskini azaltır. Modüller daha bağımsız test edilebilir. Dependency yönü architecture guide içinde açık biçimde tanımlanmalıdır.

Circular Dependency

Circular dependency iki veya daha fazla modülün birbirine döngüsel biçimde bağlı olmasıdır. Runtime initialization sorunları oluşturabilir. Daha önemlisi domain sınırlarının bozulduğunu gösterir. Dependency Cruiser veya lint araçlarıyla tespit edilebilir. Çözüm çoğu zaman shared abstraction veya composition sınırını yeniden düşünmeyi gerektirir.

Feature-to-Feature Import Problemi

Feature A doğrudan Feature B'nin internal dosyasını import ettiğinde iki business alanı birbirine bağlanır. B değiştiğinde A da etkilenebilir. Ortak davranış entity veya shared seviyesine taşınabilir. Alternatif olarak daha üst composition layer kullanılabilir. Feature independence büyük ekiplerde özellikle değerlidir.

Dependency Inversion

Dependency Inversion üst seviye business logic'in düşük seviye implementation detaylarına doğrudan bağlanmasını azaltır. Interface veya callback üzerinden abstraction kurulabilir. Frontend'de API veya storage integration bu şekilde ayrılabilir. Her yerde interface üretmek gerekli değildir. Yüksek değişim ihtiyacı bulunan dependency'lerde faydalıdır.

Dependency Graph Nasıl Görselleştirilir?

Monorepo araçları package dependency graph oluşturabilir. Nx graph buna örnektir. Multi-repo sistemlerde static analysis veya custom tooling kullanılabilir. Görsel graph beklenmeyen cross-feature import'ları ortaya çıkarır. Architecture review sırasında gerçek bağımlılık yapısı üzerinden konuşmayı kolaylaştırır.

Architecture Rule'ları Nasıl Otomatik Kontrol Edilir?

Mimari kural yalnızca dokümanda kalırsa zamanla ihlal edilir. ESLint, Nx ve Dependency Cruiser gibi araçlar import sınırlarını otomatik kontrol edebilir. CI bu kontrolleri merge öncesinde çalıştırır. Developer hatayı kod review'dan önce görür. Otomasyon mimari standardı günlük geliştirme sürecine taşır.

ESLint boundaries

ESLint boundary plugin'leri klasör veya modül tipleri arasında import kuralları tanımlayabilir. Shared'in feature import etmesi engellenebilir. Hata editor içinde erken görünür. Kurallar proje yapısıyla uyumlu tutulmalıdır. Çok katı kurallar gereksiz friction yaratabilir.

Nx module boundaries

Nx monorepo içinde tag ve module boundary kuralları sağlayabilir. Package'lar domain veya layer etiketleriyle sınıflandırılabilir. Import yönü otomatik kontrol edilir. Graph ile ihlaller görünür hale gelir. Büyük monorepo'larda güçlü yönetişim aracı olabilir.

Dependency Cruiser

Dependency Cruiser JavaScript ve TypeScript dependency graph'ını analiz edebilir. Circular dependency ve yasak import pattern'leri tanımlanabilir. CI pipeline'a kolayca eklenebilir. Rapor çıktısı architecture review için kullanılabilir. Kurallar kod tabanına göre aşamalı uygulanmalıdır.

CI checks

CI checks mimari kuralı merge öncesinde zorunlu hale getirir. Developer local ortamda atlamış olsa bile repository standardı korunur. Check hızlı çalışmalıdır. Çok uzun architecture scan developer feedback süresini olumsuz etkileyebilir. Kritik kurallar önceliklendirilmelidir.

Domain-Driven Frontend Architecture

Domain-Driven Frontend Architecture UI dosyalarını yalnızca teknik türlerine göre değil business kavramlarına göre organize etmeyi önerir. Entity ve feature sınırları bu yaklaşımda önemlidir. Business rule'ların component içinde dağılması önlenir. Domain types ve service'ler ortak sözlük oluşturur. Böylece frontend yalnızca API response gösteren bir katman olmaktan çıkıp iş alanını açık biçimde modelleyebilir.

Frontend'de Domain Nedir?

Domain uygulamanın çözmeye çalıştığı iş alanını ifade eder. Sipariş, kullanıcı veya ödeme gibi kavramlar domain'in parçasıdır. Frontend bu kavramları yalnızca API type'ları olarak görmek zorunda değildir. Kullanıcı interaction'ları da business davranışı temsil edebilir. Domain'in açık isimlendirilmesi codebase okunabilirliğini artırır.

Entity ile UI Component Arasındaki Fark

Entity business kavramını temsil eder. UI component ise bu kavramı belirli biçimde gösterebilir. Product entity ile ProductCard aynı şey değildir. Entity type ve domain behavior UI'dan bağımsız tutulabilir. Bu ayrım aynı entity'nin farklı ekranlarda farklı component'larla kullanılmasını sağlar.

Business Rule'ları Component'tan Ayırmak

Business rule render function içine gömüldüğünde tekrar kullanım ve test zorlaşır. Rule domain service veya pure function içinde tutulabilir. Component yalnızca sonucu gösterir. Aynı rule farklı UI'da tekrar kullanılabilir. Framework değişikliği business logic'i daha az etkiler.

Domain Types

Domain types business kavramlarını açık isimlerle modelleyebilir. API response type ile birebir aynı olmak zorunda değildir. Mapping layer backend contract'ını domain modele dönüştürebilir. Bu yaklaşım API değişikliklerinin UI'a yayılmasını azaltabilir. Her küçük type için ayrı domain katmanı oluşturmak yine gerekli değildir.

Domain Services

Domain service component'a ait olmayan business davranışını kapsayabilir. Fiyat hesaplama veya permission kontrolü buna örnek olabilir. Service mümkün olduğunca framework-independent tutulabilir. Test yazmak kolaylaşır. Çok büyük service dosyaları oluşursa use case bazlı ayrım yapılabilir.

Domain-Based Naming

İsimlendirme technical jargon yerine business anlamı yansıtmalıdır. handleClick yerine submitOrder gibi isim davranışı daha iyi açıklar. Feature klasörleri domain vocabulary kullanabilir. Bu yaklaşım product ve engineering arasında ortak dil oluşturur. Kodun amacı yalnızca implementation okuyarak daha kolay anlaşılır.

Business Logic UI'dan Nasıl Ayrılır?

Business logic'in UI'dan ayrılması reusable frontend architecture için temel prensiplerden biridir. Component mümkün olduğunca render ve interaction koordinasyonuna odaklanır. Hook, service veya use case katmanı business davranışı taşır. Bu ayrım test ve framework bağımsızlığını artırabilir. Bununla birlikte her küçük koşulu ayrı service'e taşımak gereksiz katman oluşturabileceği için sınır dikkatli seçilmelidir.

Smart ve Presentational Components

Smart component data ve state orchestration yaparken presentational component daha çok render davranışına odaklanır. Bu ayrım özellikle büyük UI bloklarında faydalı olabilir. Modern hook yapısıyla sınırlar daha esnek hale gelmiştir. Her component'ı zorla ikiye bölmek gerekmez. Ama data fetching ile saf UI arasındaki ayrım hâlâ güçlü bir tasarım aracıdır.

Custom Hook

Custom hook UI ile React state ve side effect davranışı arasında abstraction sağlar. useCheckout gibi hook business interaction'ını component'tan çıkarabilir. Hook yine framework'e bağlıdır. Pure business rule ayrıca service veya function içinde tutulabilir. Hook orchestration için iyi bir orta katmandır.

Service Layer

Service layer dış sistem veya domain davranışını UI'dan ayırabilir. API client veya permission service buna örnektir. Component doğrudan HTTP detayını bilmek zorunda kalmaz. Service'in amacı bütün logic'i merkezi dev dosyada toplamak değildir. Domain sınırına göre küçük ve odaklı servisler tercih edilmelidir.

Use Case Layer

Use Case Layer belirli kullanıcı veya business aksiyonunu temsil edebilir. PlaceOrder veya UpdateProfile buna örnektir. Birden fazla service çağrısını koordine edebilir. UI yalnızca use case'i tetikleyebilir. Çok basit CRUD ekranlarında bu katman gereksiz olabilir.

Business Logic'i Component İçine Gömmemenin Avantajları

Component içindeki business logic UI ile birlikte değişmek zorunda kalır. Ayrı logic farklı component'larda tekrar kullanılabilir. Unit test daha hızlı yazılır. API veya framework değişikliği domain davranışını daha az etkiler. Kod review sırasında business kuralı daha görünür hale gelir.

API Katmanı Yeniden Kullanılabilir Nasıl Tasarlanır?

API katmanı sadece endpoint çağrılarının toplandığı tek bir dosya olmamalıdır. Transport ve domain API sorumlulukları ayrıldığında reuse daha sağlıklı hale gelir. Base URL, authentication ve error normalization ortak infrastructure seviyesinde çözülebilir. Endpoint ve response mapping ise ilgili feature veya entity alanında tutulabilir. Type generation gibi otomasyonlar contract hatalarını azaltabilir.

Transport Layer

Transport layer HTTP client ve request altyapısını kapsar. Header, timeout ve serialization burada yönetilebilir. Domain endpoint isimlerini bilmesine gerek yoktur. Testte mock veya farklı implementation ile değiştirilebilir. Ortak davranışın tek yerde tutulmasını sağlar.

Domain API Layer

Domain API ilgili business endpoint'lerini tanımlar. Orders API veya Profile API buna örnektir. Transport client'ı kullanır fakat HTTP configuration detayını tekrar etmez. Response mapping domain type'a yakın yerde yapılabilir. Ownership feature veya entity ekibinde kalır.

Base URL ve Header Yönetimi

Base URL ve common header her endpoint'te tekrar yazılmamalıdır. Environment configuration merkezi yönetilebilir. Request-specific header override desteklenebilir. Secret değerler frontend bundle içine yanlışlıkla eklenmemelidir. Runtime environment strategy deployment modeliyle birlikte değerlendirilmelidir.

Authentication

Authentication token ekleme ve refresh davranışı transport seviyesinde çözülebilir. Component token detayını bilmemelidir. Session expiration merkezi event veya callback üretebilir. Authorization yine domain seviyesinde değerlendirilmelidir. Authentication logic'in UI içinde dağılması security riskini artırabilir.

Error Normalization

Backend farklı error shape döndürebilir. API katmanı bunları ortak application error modeline dönüştürebilir. UI status code veya raw response detayına bağımlı kalmaz. Error type business veya technical seviyede ayrılabilir. Observability için original error bilgisi güvenli biçimde korunabilir.

Retry

Retry her hata için otomatik uygulanmamalıdır. Idempotent request ve network failure gibi senaryolar değerlendirilebilir. Mutation retry business etkisi yaratabilir. Exponential backoff kullanılabilir. Retry policy server state library ile birlikte planlanmalıdır.

Response Types

API response type backend contract'ını ifade eder. Domain type ile aynı olmak zorunda değildir. Mapping bu iki model arasında sınır oluşturabilir. TypeScript compile-time güvenlik sağlar. Runtime validation kritik dış veri için ayrıca düşünülebilir.

OpenAPI ile Type Generation

OpenAPI type generation backend contract'ından TypeScript type ve client üretmeye yardımcı olabilir. Manuel type tekrarını azaltır. Contract değişikliği build sırasında görünür hale gelir. Generated kod doğrudan domain model olarak kullanılmak zorunda değildir. Wrapper veya mapper ile application contract korunabilir.

State Management Mimariye Nasıl Dahil Edilmeli?

State management seçimi frontend mimarisinin önemli parçasıdır fakat her state aynı araçta tutulmamalıdır. Local, URL, server ve global client state farklı yaşam döngülerine sahiptir. Server state için cache ve synchronization araçları daha uygun olabilir. UI local state'i global store'a taşımak gereksiz coupling yaratır. İlk soru hangi library kullanılmalı değil, state'in gerçek sahibi kim olmalı şeklinde sorulmalıdır.

Local State

Local state yalnızca component veya küçük component ağacını ilgilendirir. Modal open durumu veya input value buna örnek olabilir. Global store'a taşınması gereksiz dependency oluşturabilir. State mümkün olduğunca kullanıldığı yere yakın tutulmalıdır. Reuse ihtiyacı çıktığında yukarı taşınabilir.

URL State

Filter, pagination ve selected tab gibi durumlar URL'de tutulmaya uygun olabilir. Kullanıcı sayfayı paylaşabilir veya refresh sonrası aynı duruma dönebilir. Browser history doğal olarak çalışır. Global store ile duplicate source oluşturulmamalıdır. URL application state'in önemli bir parçası olarak görülmelidir.

Server State

Server state backend'in sahibi olduğu veridir. Cache, stale time ve refetch davranışı gerektirir. Geleneksel global store içinde manuel yönetmek gereksiz kod üretebilir. TanStack Query gibi araçlar bu problem için tasarlanmıştır. Server state ile client state ayrımı architecture kararını sadeleştirir.

Global Client State

Global client state birden fazla uzak component tarafından paylaşılan ve server'a ait olmayan durumdur. Theme veya geçici workflow state buna örnek olabilir. Gereksiz global kullanım coupling'i artırır. Store slice'ları domain bazında ayrılabilir. State owner ve reset davranışı açık olmalıdır.

Context API

Context düşük sıklıkta değişen shared değerler için yeterli olabilir. Theme veya dependency injection benzeri ihtiyaçlarda kullanılabilir. Çok sık değişen büyük state'i Context üzerinden dağıtmak re-render sorunlarına yol açabilir. Context boundary dikkatli seçilmelidir. Her global state problemi Context gerektirmez.

Zustand

Zustand hafif client state yönetimi sağlar. Store oluşturma ve selector kullanımı basittir. Küçük ve orta ölçekli global state için uygun olabilir. Architecture library'nin basitliğine rağmen domain sınırlarını yine açık tanımlamalıdır. Tek dev store oluşturmaktan kaçınılmalıdır.

Redux Toolkit

Redux Toolkit daha yapılandırılmış state ve tooling sunar. Büyük ekiplerde predictable state transition avantaj sağlayabilir. Slice ve middleware yapısı karmaşık workflow'larda değerlidir. Her proje için zorunlu değildir. Boilerplate geçmişe göre azalsa da kullanım ihtiyaca dayanmalıdır.

TanStack Query

TanStack Query server state caching ve synchronization problemini hedefler. Loading, error ve refetch davranışını merkezi hale getirir. API client ile birlikte kullanılabilir. Query key tasarımı domain sınırlarıyla uyumlu olmalıdır. Server state'i global store'a kopyalama ihtiyacını önemli ölçüde azaltabilir.

Her State'i Global Yapmanın Sakıncaları

Global state component bağımsızlığını azaltır. Değişikliğin hangi ekranları etkilediğini anlamak zorlaşır. Test setup büyür. State reset ve lifecycle davranışı belirsiz hale gelir. Local First yaklaşımı state management için de güçlü bir prensiptir.

TypeScript Yeniden Kullanılabilir Mimariyi Nasıl Güçlendirir?

TypeScript component ve modül contract'larını compile-time seviyesinde görünür hale getirir. Shared library kullanan consumer hangi prop ve type'ların desteklendiğini daha kolay anlayabilir. Generic types ve discriminated unions güçlü API tasarımı sağlayabilir. Bununla birlikte aşırı generic type sistemi okunabilirliği azaltabilir. Type safety tasarımın yerini almamalı, tasarım sınırlarını desteklemelidir.

Component Contract'ları

Props type component public API'sini açık biçimde tanımlar. Required ve optional davranışlar görünür olur. Consumer yanlış kullanımda erken feedback alır. Public type versioning açısından önemli contract haline gelir. Internal type'lar gereksiz yere export edilmemelidir.

Generic Types

Generic type farklı veri şekillerinde çalışan component veya utility için faydalıdır. Table veya Select buna örnek olabilir. Generic sayısı arttıkça API kullanımı zorlaşabilir. Consumer sürekli explicit type yazmak zorunda kalıyorsa design yeniden değerlendirilebilir. Type inference mümkün olduğunca kullanılmalıdır.

Discriminated Unions

Discriminated union geçerli prop kombinasyonlarını type seviyesinde tanımlayabilir. Loading ve success state farklı alanlara sahip olabilir. Boolean prop explosion azaltılabilir. Switch yapılarında exhaustive check yapılabilir. Reusable component API daha güvenli hale gelir.

Domain Types

Domain type business kavramını kod içinde netleştirir. UserId veya Money gibi type'lar yanlış kullanım riskini azaltabilir. Her primitive için branded type oluşturmak gereksiz olabilir. Kritik domain boundary'lerde değerlidir. Type ile business sözlüğü arasında tutarlılık sağlanmalıdır.

Public Types

Public type package consumer'larının kullanacağı contract'tır. Stable tutulması versioning açısından önemlidir. Internal implementation type public export'a eklenmemelidir. Package exports ile giriş noktaları kontrol edilebilir. Breaking type değişikliği migration planı gerektirebilir.

Type-Safe Variant Tasarımı

Variant değerleri union type ile sınırlandırılabilir. Consumer desteklenmeyen string kullanamaz. Variant ve size kombinasyonları gerektiğinde discriminated union ile modellenebilir. Design token isimleri de type-safe hale getirilebilir. Bu yaklaşım design system contract'ını güçlendirir.

Generic Type'ların Aşırı Kullanılması

Çok gelişmiş conditional ve mapped type yapıları ekip için okunması zor olabilir. Type error mesajları anlaşılmaz hale gelir. Runtime davranışı basitken type sistemi gereksiz maliyet oluşturabilir. Önce kullanıcı deneyimi ve API basitliği düşünülmelidir. Type güvenliği okunabilirlikle dengelenmelidir.

Design System ile Reusable Frontend Mimarisi

Design System yalnızca component koleksiyonu değildir. Tasarım prensipleri, token'lar, component'lar ve kullanım pattern'leri birlikte düşünülür. Reusable frontend architecture için görsel ve interaction standardını merkezi hale getirir. Birden fazla ürün aynı temel dil üzerinden gelişebilir. Governance ve versioning olmadan design system kısa sürede farklı uygulamalarda farklı sürümlere ayrılabilir.

Design System Nedir?

Design System tasarım kararlarını tekrar kullanılabilir kurallar ve component'lar halinde sunar. Token, primitive ve pattern seviyeleri bulunabilir. Designer ile developer aynı component sözlüğünü kullanır. Accessibility standart davranışa dahil edilir. Sistem ürün geliştirme hızını artırırken tutarlılığı korumayı amaçlar.

Design Tokens

Design token tasarım kararının isimlendirilmiş değişken halidir. Renk, typography ve spacing bu şekilde tanımlanabilir. Token brand değişimini kolaylaştırır. Component hard-coded değer kullanmaz. Tasarım değişiklikleri daha kontrollü yayılır.

Colors

Color token semantic isimlerle tanımlanabilir. Blue500 yerine surfacePrimary gibi anlamlı token kullanılabilir. Tema değişikliği daha kolay olur. Contrast standardı merkezi kontrol edilir. Raw renk değerine doğrudan erişim sınırlanabilir.

Typography

Typography token font size, weight ve line height kombinasyonunu tanımlar. Heading ve body seviyeleri ortaklaştırılır. Her component rastgele font değeri kullanmaz. Responsive typography gerektiğinde token sistemiyle yönetilebilir. Tasarım tutarlılığı güçlenir.

Spacing

Spacing token layout boşluklarını sınırlı bir scale üzerinde tutar. 13px veya 27px gibi rastgele değerler azalır. Designer ve developer aynı ölçüleri kullanır. Component API size variant ile bu token'lara bağlanabilir. Görsel ritim daha tutarlı hale gelir.

Radius

Radius token border radius kararlarını merkezi hale getirir. Button ve Card aynı tasarım dilini kullanabilir. Brand değişikliği tek token setinden yönetilebilir. Aşırı token sayısı anlam kaybı yaratabilir. İsimler kullanım amacını yansıtmalıdır.

Primitive Components

Primitive component Button, Input ve Dialog gibi temel yapı taşlarıdır. Design token'ları kullanır. Accessibility davranışı burada çözülür. Domain bilgisinden bağımsızdır. Diğer composite component'lar bu primitive'leri compose edebilir.

Composite Components

Composite component birden fazla primitive'i ortak interaction pattern içinde birleştirir. FormField veya SearchBox buna örnek olabilir. Business logic minimumda tutulmalıdır. Çok spesifik product behavior feature içinde kalabilir. Composite katman design system'ın kullanım hızını artırır.

Patterns

Pattern belirli kullanıcı deneyiminin nasıl çözüleceğini açıklar. Confirmation flow veya form validation feedback buna örnek olabilir. Her pattern tek bir component olmak zorunda değildir. Dokümantasyon ve örnekler birlikte sunulabilir. Ekipler benzer problemi tutarlı biçimde çözer.

Page Templates

Page template sık kullanılan layout düzenlerini tekrar kullanılabilir hale getirir. Dashboard veya Settings layout buna örnek olabilir. Domain content dışarıdan sağlanır. Responsive davranış merkezi tutulabilir. Her page'i aynı template'e zorlamak gerekli değildir.

UI Kit ile Design System Arasındaki Fark

UI Kit, Component Library ve Design System benzer görünse de kapsamları farklıdır. UI Kit genellikle görsel component veya asset koleksiyonudur. Component Library çalışan kod paketini ifade eder. Design System ise bunun yanında prensip, token, dokümantasyon ve governance içerir. Proje ölçeğine göre bütün katmanlara aynı anda yatırım yapmak gerekmeyebilir.

UI Kit

UI Kit görsel tasarım öğelerini ortaklaştırır. Figma component set'i buna örnek olabilir. Kod implementation içermek zorunda değildir. Küçük ürünlerde tasarım tutarlılığı için yeterli başlangıç olabilir. Development tarafıyla senkronizasyon ayrıca yönetilmelidir.

Component Library

Component Library reusable UI component'larını kod olarak sunar. npm package veya monorepo package şeklinde dağıtılabilir. Versioning ve test gerektirir. Design token kullanabilir. Governance bulunmadığında yalnızca teknik kütüphane seviyesinde kalabilir.

Design System

Design System component ve token'ların yanında kullanım prensiplerini de içerir. Tasarım ve geliştirme ekipleri ortak ownership paylaşır. Contribution ve deprecation süreçleri bulunur. Accessibility ve content pattern gibi alanlar kapsanabilir. Büyük organizasyonda product tutarlılığı için güçlü temel sağlar.

Hangi Ölçekte Hangisi Gereklidir?

Tek küçük uygulama için tam design system programı gereksiz olabilir. Basit UI Kit ve birkaç reusable component yeterli kalabilir. Birden fazla uygulama ve ekip olduğunda component library değeri artar. Büyük ürün ailesinde governance ve token stratejisi design system ihtiyacını güçlendirir. Yatırım organizasyon ölçeğiyle uyumlu olmalıdır.

Storybook ile Component-Driven Development

Storybook component'ları application ekranından bağımsız biçimde geliştirmeyi ve dokümante etmeyi kolaylaştırır. Reusable component'ın farklı state'leri görünür hale gelir. Designer ve developer aynı örnek üzerinden konuşabilir. Interaction ve visual regression testleri component seviyesinde çalıştırılabilir. Storybook design system'ın yaşayan dokümantasyon katmanı haline gelebilir.

Component'ları İzole Geliştirmek

İzole geliştirme component'ın gerçek bağımlılıklarını ortaya çıkarır. Çok fazla global provider gerekiyorsa reusability sorgulanabilir. Component farklı state'lerde hızlı test edilebilir. Feature tamamlanmadan UI geliştirmek mümkün olur. Isolation API kalitesini iyileştirebilir.

Component Documentation

Storybook prop ve kullanım örneklerini gösterebilir. Consumer README aramak zorunda kalmaz. Doğru ve yanlış kullanım örnekleri eklenebilir. Component owner bilgisi bulunabilir. Dokümantasyon kod değişikliğiyle birlikte güncellenmelidir.

Component States

Reusable component yalnızca ideal success state'te değerlendirilmemelidir. Loading, error, disabled ve empty davranışları da tasarlanmalıdır. Story her durumu ayrı gösterir. Designer edge case'leri görebilir. Test kapsamı daha anlamlı hale gelir.

Default

Default state component'ın en yaygın kullanımını gösterir. Sensible default'lar burada doğrulanabilir. Consumer minimum prop ile davranışı görebilir. Tasarım standardı için referans oluşturur. Değişiklik visual regression ile izlenebilir.

Loading

Loading state veri beklerken kullanıcıya doğru feedback vermelidir. Button loading sırasında tekrar tıklamayı engelleyebilir. Skeleton veya spinner pattern'i tutarlı kullanılmalıdır. Accessibility için live region gerekebilir. State design system içinde ortaklaştırılabilir.

Error

Error state kullanıcıya problem ve sonraki adım hakkında bilgi verir. Form ve data component'larında davranış farklı olabilir. Görsel standardın yanında semantic markup önemlidir. Story error senaryosunu görünür tutar. Edge case production'a kalmaz.

Disabled

Disabled state yalnızca renk değişikliği değildir. Keyboard ve pointer interaction doğru davranmalıdır. Disabled kullanımının neden gerektiği ürün açısından sorgulanabilir. Accessibility semantics uygulanmalıdır. Story tasarım kontrastını kontrol etmeyi kolaylaştırır.

Empty

Empty state veri bulunmadığında kullanıcıya rehberlik eder. Generic NoData component her senaryoyu karşılamayabilir. Domain mesajı feature seviyesinde sağlanabilir. Design system layout pattern sunabilir. Story farklı empty content senaryolarını gösterebilir.

Interaction Testing

Interaction test component davranışını kullanıcı aksiyonlarıyla doğrular. Click, keyboard ve form interaction senaryoları yazılabilir. Story üzerinden çalışan test dokümantasyon ile kaliteyi birleştirir. Critical component'lar için faydalıdır. Unit testin yerini tamamen almak zorunda değildir.

Visual Regression Testing

Visual regression beklenmeyen görsel değişiklikleri tespit eder. Design system component'larında özellikle değerlidir. Screenshot diff otomatik review üretir. Dynamic content stabilize edilmelidir. Her küçük pixel farkını bloklamak yerine anlamlı threshold kullanılabilir.

Accessibility Reusable Component Seviyesinde Nasıl Çözülür?

Accessibility reusable component seviyesinde çözüldüğünde bütün ürünlere ölçeklenebilir. Button, Modal ve FormField gibi temel component'lar semantic HTML ve keyboard davranışını doğru uygular. Ekip her feature'da aynı accessibility problemini yeniden çözmek zorunda kalmaz. Design system bu nedenle yalnızca görsel değil erişilebilirlik standardı da olmalıdır. Otomatik testler insan testinin yanında destekleyici rol oynayabilir.

Semantic HTML

Semantic HTML accessibility için ilk tercihtir. Button davranışı div üzerine click eklemek yerine gerçek button elementiyle uygulanmalıdır. Native element keyboard ve screen reader desteği sağlar. Gereksiz ARIA kullanımını azaltır. Reusable primitive semantic yapıyı varsayılan hale getirir.

Keyboard Navigation

Interactive component keyboard ile tamamen kullanılabilir olmalıdır. Tab sırası ve arrow key davranışı component türüne göre belirlenir. Focus trap gerekli yapılarda dikkatli uygulanır. Keyboard test Storybook interaction içine eklenebilir. Bu davranış bütün consumer'lara otomatik taşınır.

Focus Management

Modal açıldığında focus uygun alana taşınmalıdır. Kapatıldığında tetikleyici elemana geri dönmesi beklenir. Route değişikliklerinde de focus deneyimi önemlidir. Shared primitive bu davranışı merkezi çözebilir. Hatalı focus kullanıcı için ciddi erişim problemi oluşturabilir.

ARIA

ARIA native semantic yeterli olmadığında kullanılmalıdır. Yanlış ARIA kullanımı erişilebilirliği iyileştirmek yerine bozabilir. Component library doğru role ve attribute'ları encapsulate edebilir. Consumer'ın düşük seviyeli detayları sürekli hatırlaması gerekmez. Dynamic state değişiklikleri gerektiğinde screen reader'a duyurulabilir.

Accessible Modal

Accessible Modal keyboard focus, escape davranışı ve aria-labelledby gibi detayları doğru yönetmelidir. Background interaction engellenmelidir. Focus kapanış sonrası geri dönmelidir. Bu davranış her product ekibinin yeniden yazmaması gereken güçlü reuse alanıdır. Headless accessibility primitive tercih edilebilir.

Accessible Form Components

Form component label ile input ilişkisini doğru kurmalıdır. Error message programatik olarak input ile bağlanabilir. Required ve invalid state doğru semantic kullanmalıdır. Shared FormField bu davranışı standartlaştırabilir. Business validation yine feature seviyesinde kalabilir.

Accessibility'yi Bir Kez Çözüp Tüm Projelere Aktarmak

Design system accessibility yatırımının en büyük avantajlarından biri tekrar kullanımdır. Bir Modal'daki focus hatası düzeltildiğinde bütün consumer'lar yeni sürümden faydalanabilir. Bunun için versioning ve upgrade disiplini gerekir. Consumer'ların eski sürümde yıllarca kalması faydayı azaltır. Merkezi kalite ile dağıtım süreci birlikte düşünülmelidir.

Reusable Component'lar Nasıl Test Edilmelidir?

Reusable component daha fazla consumer tarafından kullanıldığı için test yatırımı daha yüksek değer üretir. Unit, interaction ve accessibility testleri farklı hata sınıflarını yakalar. Visual regression tasarım değişikliklerini görünür hale getirir. Contract ve consumer testleri package sınırını güvence altına alabilir. Test stratejisi component'ın risk ve kullanım alanına göre belirlenmelidir.

Unit Tests

Unit test pure logic ve küçük component davranışını hızlı doğrular. Variant mapping veya utility function test edilebilir. Implementation detayına aşırı bağımlı test kırılgan olur. Kullanıcı davranışına yakın assertion tercih edilmelidir. Test bakım maliyeti de göz önünde bulundurulmalıdır.

Component Tests

Component test render ve interaction davranışını birlikte doğrulayabilir. Gerçek DOM ortamına yakın çalışmak faydalıdır. Prop contract farklı senaryolarda test edilir. Provider dependency minimumda tutulmalıdır. Reusable component için gerçek consumer davranışına odaklanmak önemlidir.

Interaction Tests

Interaction test kullanıcı aksiyonlarını simüle eder. Click, keyboard ve input senaryoları çalıştırılır. Controlled ve uncontrolled davranış doğrulanabilir. Accessibility keyboard akışı aynı testte kontrol edilebilir. Storybook ile birlikte kullanıldığında dokümantasyon da güçlenir.

Accessibility Tests

Otomatik accessibility test yaygın semantic hataları yakalayabilir. Contrast gibi bazı konular görsel test gerektirir. Screen reader deneyimi tamamen otomatik doğrulanamaz. Critical component'lar manuel accessibility review'dan geçebilir. Shared component düzeyindeki yatırım bütün uygulamalara fayda sağlar.

Visual Regression

Visual regression component'ın görünümünü snapshot olarak izler. Token veya CSS değişikliği beklenmeyen etkiler oluşturduğunda fark edilir. Bütün story state'leri taranabilir. Review süreci designer katkısına açılabilir. Gürültüyü azaltmak için stabil rendering gerekir.

Contract Tests

Contract test public API'nin beklenen davranışı koruduğunu doğrular. Package consumer'ları belirli prop veya export'lara bağımlı olabilir. Breaking change erken fark edilir. Type check contract'ın bir bölümünü kapsar. Runtime davranış için ek test gerekebilir.

Consumer Testleri

Consumer test shared component'ın gerçek uygulamada nasıl kullanıldığını doğrulayabilir. Library upgrade sırasında kritik uygulamalar CI içinde test edilebilir. Monorepo bunu kolaylaştırır. Multi-repo ortamında integration pipeline kurulabilir. Büyük design system değişikliklerinde güven sağlar.

Birden Fazla Frontend Projesinde Kod Nasıl Paylaşılır?

Birden fazla frontend uygulaması olduğunda ortak kod paylaşımı için farklı yöntemler vardır. Copy-paste en basit yöntemdir fakat değişiklik senkronizasyonu zordur. Package ve monorepo yaklaşımları daha kontrollü versioning sağlar. Her organizasyonun release ve ownership modeli farklıdır. En ağır tooling'i seçmek yerine paylaşım sıklığı ve ekip yapısına uygun çözüm kullanılmalıdır.

Copy-Paste

Copy-paste küçük ve nadiren değişen kod için bazen kabul edilebilir. Her ortaklık için package oluşturmak daha pahalı olabilir. Ancak bug fix bütün kopyalarda manuel yapılır. Kod zamanla farklılaşır. Tekrar sıklığı arttığında gerçek shared çözüm değerlendirilmelidir.

Git Package

Git repository doğrudan dependency olarak kullanılabilir. Küçük internal package için hızlı başlangıç sağlar. Semantic versioning ve registry deneyimi sınırlı olabilir. Build ve authentication süreci yönetilmelidir. Uzun vadede private registry daha düzenli seçenek olabilir.

npm Package

npm package açık veya private registry üzerinden dağıtılabilir. Semantic versioning kullanımı kolaylaşır. Consumer uygulamalar bağımsız release yapabilir. Breaking change kontrollü yayınlanır. Package maintenance ve publish pipeline gerekir.

Private Registry

Private registry şirket içi package'ları kontrollü biçimde dağıtır. Access ve audit yönetilebilir. Shared UI ve config package'ları için uygundur. Developer authentication mümkün olduğunca kolay olmalıdır. Package lifecycle ve deprecation politikası tanımlanmalıdır.

Monorepo

Monorepo birden fazla uygulama ve package'ı tek repository içinde yönetir. Shared code değişikliği consumer'larla aynı pull request içinde test edilebilir. Tooling dependency graph ve affected build optimizasyonu sağlayabilir. Repository governance yatırım ister. Her organizasyon için otomatik doğru seçim değildir.

Hangi Yaklaşım Ne Zaman Kullanılmalı?

Tek iki küçük proje için package ihtiyacı sınırlı olabilir. Bağımsız release yapan ekiplerde private registry mantıklı olabilir. Yoğun paylaşım ve ortak tooling varsa monorepo güçlü seçenek haline gelir. Çok bağımsız organizasyonlarda multi-repo daha rahat olabilir. Seçim coordination ve ownership ihtiyacına göre yapılmalıdır.

Monorepo Frontend Mimarisi

Monorepo frontend uygulamaları ile shared package'ları tek repository altında toplar. apps ve packages ayrımı kullanım alanlarını görünür hale getirir. Shared UI, types ve config ortaklaştırılabilir. Nx, Turborepo veya pnpm Workspaces gibi araçlar build ve dependency yönetimini destekler. Monorepo'nun değeri repository sayısını azaltmaktan çok değişiklikleri birlikte yönetme yeteneğidir.

Monorepo Nedir?

Monorepo birden fazla proje veya package'ın aynı version control repository'sinde tutulmasıdır. Bütün codebase tek application olmak zorunda değildir. Bağımsız package boundary korunabilir. Tooling sadece değişen projeleri build edebilir. Ortak standardı uygulamak kolaylaşır.

apps ve packages Ayrımı

apps deploy edilen uygulamaları temsil eder. packages tekrar kullanılabilir library ve config'leri içerir. Bu ayrım dependency yönünü görünür hale getirir. App başka app'in internal dosyasını import etmemelidir. Ortak ihtiyaç package'a taşınabilir.

Shared UI Package

Shared UI package design system veya component library'yi içerebilir. Birden fazla app aynı version veya workspace dependency kullanır. Storybook ayrı package içinde çalışabilir. Public API kontrollü tutulmalıdır. Breaking change affected app'lerde aynı PR içinde test edilebilir.

Shared Types Package

Shared types package gerçekten ortak contract'lar için kullanılabilir. Her domain type burada toplanmamalıdır. API generated types ayrı package olabilir. Package dependency graph'a dikkat edilmelidir. Type-only package bile circular business dependency yaratabilir.

Shared Config Package

ESLint ve TypeScript config package'ları monorepo standardını kolaylaştırır. Yeni app aynı ayarlarla başlayabilir. Override ihtiyacı kontrollü tutulur. Configuration versioned hale gelir. Tooling upgrade merkezi yapılabilir.

Shared API Package

Shared API package transport infrastructure veya generated client içerebilir. Domain API sınırlarına dikkat edilmelidir. Tek dev package bütün business endpoint'leri birleştirebilir. Modüler export yapısı daha sağlıklıdır. Consumer yalnızca ihtiyaç duyduğu contract'ı kullanmalıdır.

Nx

Nx monorepo task orchestration ve dependency graph özellikleri sunar. Module boundary kuralları architecture enforcement için kullanılabilir. Affected command CI süresini azaltabilir. Plugin ekosistemi kapsamlıdır. Tooling öğrenme maliyeti proje ölçeğiyle dengelenmelidir.

Turborepo

Turborepo task caching ve pipeline orchestration için hafif yaklaşım sunar. Workspace yönetimini package manager ile birlikte kullanır. Basit monorepo'larda hızlı başlangıç sağlayabilir. Architecture boundary için ek araç gerekebilir. İhtiyaca göre Nx veya diğer çözümlerle karşılaştırılmalıdır.

pnpm Workspaces

pnpm Workspaces package dependency yönetimini monorepo içinde kolaylaştırır. Disk kullanımı ve install performansı avantajlı olabilir. Workspace protocol internal package kullanımını netleştirir. Task orchestration için ek araç kullanılabilir. Küçük monorepo'larda tek başına yeterli olabilir.

Monorepo İçin Örnek Package Yapısı

Monorepo package yapısı deploy edilen uygulamalar ile ortak altyapı paketlerini net biçimde ayırmalıdır. apps/web, apps/admin ve apps/customer-portal farklı ürün yüzeylerini temsil edebilir. packages/ui ve packages/design-tokens ortak tasarım sistemini taşır. API, types ve configuration paketleri yalnızca gerçekten shared ihtiyaçlar için oluşturulmalıdır. Package sayısını artırmak mimari kaliteyi otomatik yükseltmez.

apps/web

apps/web ana web uygulamasını barındırabilir. Route ve application composition burada bulunur. Shared package'lardan dependency alır. Başka app'in internal kodunu import etmemelidir. App-level business feature'lar kendi sınırlarını korumalıdır.

apps/admin

apps/admin yönetim panelini temsil edebilir. Ana web ile UI ve types paylaşabilir. Business workflow farklı olduğu için feature kodu doğrudan paylaşılmamalıdır. Aynı API client kullanılabilir. Design system iki uygulama arasında tutarlılık sağlar.

apps/customer-portal

Customer portal farklı kullanıcı segmentine hizmet edebilir. Shared authentication ve UI package kullanabilir. Domain ihtiyaçları bağımsız kalabilir. Release cycle diğer app'lerden farklı olabilir. Monorepo bunu aynı repository içinde yönetmeye izin verir.

packages/ui

UI package reusable primitive ve composite component'ları içerir. Storybook ve component testleri burada bulunabilir. Public API package exports ile tanımlanır. Domain code import edilmemelidir. Design system ownership bu package üzerinde olabilir.

packages/design-tokens

Design token package renk, spacing ve typography değerlerini taşır. Web ve mobil farklı output format üretebilir. Figma token workflow ile entegre edilebilir. Versioning design system release sürecine bağlanır. Token değişiklikleri visual regression ile doğrulanabilir.

packages/api-client

API client package transport ve generated contract'ları içerebilir. Authentication hook'ları dikkatli ayrılmalıdır. Browser-specific ve server-side kullanım gereksinimleri değerlendirilmelidir. Domain wrapper'ları app veya feature seviyesinde kalabilir. Package'ın public export yüzeyi küçük tutulmalıdır.

packages/types

Types package ortak ve stable contract'ları barındırabilir. Her local interface buraya taşınmamalıdır. API contract ve design system types ayrı tutulabilir. Dependency yönü izlenmelidir. Type package'ın çok fazla domain'e bağlanması coupling yaratabilir.

packages/eslint-config

ESLint config package ortak coding ve architecture rule'larını sağlar. Import boundary kuralları burada tanımlanabilir. App'ler gerektiğinde küçük override yapabilir. Update merkezi yayımlanır. CI ile aynı config kullanılmalıdır.

packages/tsconfig

Shared tsconfig compiler seçeneklerini standardize eder. Base config üzerine app ve library config'leri extend edebilir. Strict mode kurumsal kaliteyi artırabilir. Farklı runtime hedefleri için ayrı preset oluşturulabilir. Config package'ı gereksiz option çoğalmasını azaltır.

Monorepo Ne Zaman Kullanılmamalı?

Monorepo birçok avantaj sunsa da her frontend projesi için gerekli değildir. Tek küçük uygulamada ek task runner ve package boundary yatırımı gereksiz olabilir. Paylaşılan kod yoksa repository birleşimi değer üretmeyebilir. Çok bağımsız ownership modelinde permission ve CI süreçleri zorlaşabilir. Tooling maliyeti gerçek collaboration ihtiyacıyla karşılaştırılmalıdır.

Tek Küçük Uygulama

Tek küçük uygulama ayrı package yapısına ihtiyaç duymayabilir. Basit feature-based klasörleme yeterlidir. Monorepo tool'u öğrenmek ek maliyet oluşturur. Build caching faydası sınırlı kalabilir. Mimari proje ihtiyacından büyük olmamalıdır.

Paylaşılan Kod Olmaması

Uygulamalar tamamen bağımsızsa aynı repository zorunlu avantaj sağlamaz. Ortak CI veya config bile bulunmayabilir. Ekiplerin release süreçleri farklı olabilir. Multi-repo autonomy daha uygun olabilir. Monorepo yalnızca trend olduğu için seçilmemelidir.

CI Karmaşıklığı

Büyük monorepo doğru caching olmadan CI süresini artırabilir. Her değişiklik bütün projeleri build ediyorsa avantaj kaybolur. Affected graph ve remote cache gerekebilir. Tooling operasyonu bakım ister. Küçük ekip bu maliyeti taşımak istemeyebilir.

Ownership Problemleri

Tek repository herkesin her dosyaya dokunması anlamına gelmemelidir. CODEOWNERS ve boundary gerekir. Çok bağımsız ekiplerde merge policy çatışabilir. Release sorumluluğu karışabilir. Organizasyonel yapı repository modeline uyumlu olmalıdır.

Gereksiz Tooling Maliyeti

Monorepo task orchestration ve cache altyapısı gerektirebilir. Plugin ve configuration upgrade yükü oluşur. Problem basitse bu yatırımın karşılığı olmayabilir. Önce collaboration problemi ölçülmelidir. Tooling gerçek ihtiyaca cevap vermelidir.

Micro-Frontend Yeniden Kullanılabilir Mimari midir?

Micro-frontend doğrudan yeniden kullanılabilirlik çözümü değildir. Temel amacı büyük frontend organizasyonunu bağımsız ekip ve deployment sınırlarına ayırmaktır. Shared dependency ve design system kullanımı ayrı olarak tasarlanmalıdır. Yanlış kullanıldığında bundle tekrarı ve kullanıcı deneyimi tutarsızlığı oluşturabilir. Bu nedenle micro-frontend ancak organizasyonel bağımsızlık ihtiyacı yeterince yüksek olduğunda değerlendirilmelidir.

Micro-Frontend Nedir?

Micro-frontend büyük frontend uygulamasını bağımsız ekiplerin yönettiği parçalara ayırır. Her parça ayrı release edilebilir. Teknik olarak farklı framework kullanımı mümkün olabilir. Ancak bu esneklik operasyon ve kullanıcı deneyimi maliyeti yaratır. Domain sınırlarının iyi tanımlanması gerekir.

Module Federation

Module Federation runtime sırasında farklı build'lerin modül paylaşmasına izin verebilir. Remote component ve application parçaları dinamik yüklenebilir. Shared dependency versioning dikkatli yönetilmelidir. Runtime failure senaryosu düşünülmelidir. Her micro-frontend için zorunlu teknoloji değildir.

Independent Deployment

Independent deployment micro-frontend'in önemli organizasyonel faydasıdır. Bir ekip bütün frontend release'ini beklemeden kendi domain'ini yayınlayabilir. CI ve rollback ayrı yönetilir. Contract değişiklikleri dikkatli koordine edilmelidir. Küçük ekip yapısında bu bağımsızlık gereksiz olabilir.

Shared Dependencies

React veya design system gibi dependency'ler micro-frontend'ler arasında paylaşılabilir. Version uyumsuzluğu runtime sorun oluşturabilir. Ortak dependency fazla centralize edilirse ekip bağımsızlığı azalabilir. Her dependency gerçekten shared olmak zorunda değildir. Contract seviyesinde paylaşım daha güvenli olabilir.

Design System Tutarlılığı

Bağımsız ekipler aynı kullanıcı deneyimini korumak için design system'a ihtiyaç duyabilir. UI package versioning önemli hale gelir. Farklı sürümlerin uzun süre birlikte yaşaması görsel fark yaratabilir. Merkezi guideline ve contribution modeli faydalıdır. Micro-frontend teknik bağımsızlık sağlarken görsel bütünlük ayrıca yönetilmelidir.

Micro-Frontend Ne Zaman Gereksizdir?

Tek ekip veya küçük application için micro-frontend çoğu zaman gereksizdir. Build ve runtime architecture daha zor hale gelir. Local development ve debugging yükü artar. Independent deployment ihtiyacı yoksa fayda sınırlı kalır. Önce modüler monolith frontend yaklaşımı denenebilir.

Frontend Architecture İçin En İyi Programlama Dili Hangisidir?

Frontend architecture için tek bir en iyi programlama dili veya framework yoktur. JavaScript temel çalışma ortamını sağlarken TypeScript type safety ve contract görünürlüğü ekler. React, Vue ve Angular ise framework veya library seviyesinde farklı geliştirme modelleri sunar. Yeniden kullanılabilir mimarinin kalitesini esas olarak component sınırları, dependency yönü ve test yaklaşımı belirler. Teknoloji tercihi bu prensipleri desteklemelidir.

JavaScript

JavaScript frontend ekosisteminin temel dilidir. Browser desteği ve geniş ekosistem güçlü avantaj sağlar. Büyük projelerde runtime type hataları daha geç fark edilebilir. Kod standardı ve test bu riski azaltabilir. TypeScript kullanılsa bile JavaScript temelleri anlaşılmalıdır.

TypeScript

TypeScript public contract ve domain type'larını daha görünür hale getirir. Büyük ekiplerde refactoring güvenini artırabilir. Shared package consumer'ları compile-time feedback alır. Type sistemi yanlış architecture'ı tek başına çözmez. Basit ve anlaşılır type tasarımı tercih edilmelidir.

React

React composition ve hook yaklaşımıyla reusable component tasarımına esnek temel sağlar. State ve architecture kararlarının önemli kısmını ekibe bırakır. Bu özgürlük standardizasyon ihtiyacını artırabilir. Büyük ekosistem farklı çözüm seçenekleri sunar. Proje içinde ortak prensipler belirlemek önemlidir.

Vue

Vue template ve Composition API yaklaşımıyla component geliştirmeyi kolaylaştırır. Composable yapıları logic reuse sağlar. Slots esnek composition sunar. Framework daha yönlendirilmiş geliştirme deneyimi sağlar. Architecture yine domain ve dependency sınırlarına göre tasarlanmalıdır.

Angular

Angular component, service ve dependency injection gibi yapıları framework içinde sunar. Daha opinionated yapı büyük ekiplerde tutarlılık sağlayabilir. Module ve standalone component yaklaşımları farklı organizasyon seçenekleri sunar. Framework kendi başına iyi domain sınırı oluşturmaz. Dependency ve feature ownership yine planlanmalıdır.

Framework ile Programlama Dilini Ayırmak

React programlama dili değil UI library'sidir. Vue ve Angular da framework seviyesinde araçlardır. TypeScript veya JavaScript bunların üzerinde kullanılan dillerdir. Bu ayrım teknoloji değerlendirmesinde önemlidir. Mimari prensipler framework değişse bile büyük ölçüde geçerliliğini koruyabilir.

Yeniden Kullanılabilir Mimari İçin Neden Type Safety Önemlidir?

Shared component birden fazla consumer tarafından kullanıldığı için contract hatasının etkisi büyür. Type safety yanlış prop ve data shape kullanımını erken yakalar. Refactoring sırasında kırılan consumer'lar compile aşamasında görünür. Public API daha iyi dokümante edilir. Runtime validation gereken dış veri için yine ek kontrol kullanılmalıdır.

Teknoloji Yerine Mimari Prensipleri Önceliklendirmek

Framework birkaç yıl içinde değişebilir. Composition, modularity ve dependency control daha uzun ömürlü prensiplerdir. Ekip yalnızca framework pattern'i öğrenirse yeni teknolojiye geçiş zorlaşır. Mimari düşünce farklı araçlara taşınabilir. Frontend Projelerinde Yeniden Kullanılabilir Mimari Tasarımı bu nedenle teknoloji listesinden çok sınır tasarımına odaklanmalıdır.

React, Vue ve Angular'da Reusable Architecture

React, Vue ve Angular farklı API'ler kullansa da reusable architecture hedefleri benzerdir. Component responsibility küçük tutulmalı, business logic mümkün olduğunca UI'dan ayrılmalı ve dependency yönü kontrol edilmelidir. Her framework composition için farklı araç sunar. React Hooks, Vue Composables ve Angular Services tekrar kullanım için farklı seviyelerde kullanılabilir. Seçim ekip deneyimi ve ürün ihtiyacına dayanmalıdır.

React

React küçük component ve composition üzerine esnek model sunar. Hook'lar stateful behavior'ı tekrar kullanılabilir hale getirir. Context belirli shared dependency'ler için kullanılabilir. Architecture framework tarafından zorlanmadığı için ekip guideline'ı önemlidir. Feature-based yapı React projelerinde sık tercih edilir.

Composition

React composition children ve component prop üzerinden güçlü esneklik sunar. Büyük boolean API yerine küçük component'lar birleştirilebilir. Compound component pattern yaygın kullanılır. Component sorumluluğu net tutulmalıdır. Composition generic base component ihtiyacını azaltabilir.

Hooks

Hooks state ve side effect davranışını component dışına çıkarabilir. Custom hook API ve orchestration logic'i tekrar kullanılabilir hale getirir. Hook her zaman shared olmak zorunda değildir. Feature hook local tutulabilir. Pure business logic hook'tan ayrı function olarak test edilebilir.

Context

Context component ağacında dependency paylaşmayı sağlar. Theme veya form context için uygundur. Çok sık güncellenen state büyük provider altında performans sorunları yaratabilir. Provider sayısı da cognitive load oluşturabilir. Context scope ihtiyaca göre dar tutulmalıdır.

Vue

Vue component ve template yaklaşımını güçlü reactive modelle birleştirir. Composition API logic reuse'u kolaylaştırır. Slots flexible component API sağlar. Feature-based structure Vue projelerinde de uygulanabilir. Framework seçimi architecture prensiplerini değiştirmez.

Composition API

Composition API related logic'i setup içinde organize etmeyi sağlar. Büyük component'lardaki dağınık options yapısını azaltabilir. Composable extraction daha doğal hale gelir. Reusability için yalnızca syntax değil doğru sorumluluk sınırı gerekir. Domain logic composable içinde gereksiz framework bağımlılığına dönüşmemelidir.

Composables

Composable Vue tarafında custom hook benzeri behavior reuse sunar. useAuth veya usePagination örnek olabilir. Shared composable domain-independent olmalıdır. Feature-specific composable local tutulabilir. API'nin state ownership davranışı açık olmalıdır.

Slots

Slots component composition için güçlü araçtır. Component layout sağlar, içerik consumer tarafından belirlenir. Named slot belirli bölgeleri özelleştirebilir. Aşırı slot kullanımı API'yi zorlaştırabilir. Dokümantasyon gerçek kullanım örnekleri göstermelidir.

Angular

Angular daha bütünleşik framework yapısı sunar. Components ve Services net teknik araçlar sağlar. Dependency Injection test ve abstraction için değerlidir. Büyük enterprise ekiplerde opinionated yapı tutarlılık sağlayabilir. Domain boundaries yine ayrıca tasarlanmalıdır.

Components

Angular component input ve output üzerinden contract oluşturur. Standalone component yapısı reuse'u kolaylaştırabilir. Presentational component'lar domain logic'ten ayrılabilir. Template ve TypeScript contract birlikte yönetilir. Design system Angular package olarak dağıtılabilir.

Services

Service API ve business orchestration için kullanılabilir. Dependency Injection test doubles kullanmayı kolaylaştırır. Her logic'i service'e taşımak yine doğru değildir. Domain seviyesinde sorumluluk ayrımı yapılmalıdır. Shared singleton state dikkatli yönetilmelidir.

Dependency Injection

Dependency Injection implementation detaylarını contract arkasına alabilir. Testte farklı provider kullanılabilir. API ve storage abstraction için faydalıdır. Gereksiz abstraction class sayısını artırabilir. Değişim ihtiyacı bulunan dependency'lerde kullanılmalıdır.

Hangi Framework Hangi Projeye Daha Uygun?

Framework seçimi ekip deneyimi, ürün yapısı ve organizasyon standardına göre yapılmalıdır. React daha esnek ekosistem sunarken Angular daha yönlendirilmiş yapı sağlar. Vue öğrenme ve geliştirme deneyimi açısından güçlü bir orta yol olabilir. Tek bir performans benchmark'ı kararı belirlememelidir. Uzun vadeli bakım ve işe alım da değerlendirilmelidir.

Reusable Architecture'da Versioning ve Breaking Change Yönetimi

Shared component veya package birçok consumer'a ulaştığında değişiklik yönetimi mimarinin temel parçası haline gelir. Semantic Versioning breaking ve backward-compatible değişiklikleri ayırmak için ortak dil sağlar. Deprecation consumer'lara geçiş süresi verir. Migration guide ve codemod büyük güncellemelerin maliyetini azaltabilir. Changelog ve Changesets release sürecini daha şeffaf hale getirir.

Semantic Versioning

Semantic Versioning major, minor ve patch numaraları üzerinden değişiklik türünü ifade eder. Public API contract'ı versioning için temel alınır. Her internal refactor major release gerektirmez. Breaking değişiklik açık biçimde tanımlanmalıdır. Package consumer'ları update riskini daha kolay değerlendirebilir.

Patch, Minor ve Major

Patch backward-compatible bug fix için kullanılabilir. Minor yeni fakat uyumlu özellik ekler. Major breaking API değişikliğini ifade eder. Bu ayrım release kararını standardize eder. Otomatik tooling yanlış version seçimini azaltabilir.

Deprecation

Deprecation eski API'nin gelecekte kaldırılacağını bildirir. Consumer hemen kırılmaz. Warning ve dokümantasyon yeni kullanım yolunu gösterir. Belirli major sürümde kaldırma planlanabilir. Çok uzun deprecation süresi library bakımını zorlaştırabilir.

Migration Guide

Migration guide eski ve yeni API arasındaki değişikliği açıklar. Before ve after örnekleri faydalıdır. Breaking change'in nedeni belirtilmelidir. Büyük migration için checklist hazırlanabilir. Consumer ekipler update süresini daha iyi planlar.

Codemod

Codemod mekanik kod değişikliklerini otomatikleştirebilir. Prop rename veya import path değişimi buna örnektir. Büyük component library migration'larında ciddi zaman kazandırır. Tool güvenli dry-run sunmalıdır. Manuel review yine yapılmalıdır.

Changelog

Changelog kullanıcıya her release'te ne değiştiğini anlatır. Teknik commit listesi yerine consumer etkisi yazılmalıdır. Breaking ve deprecation açık işaretlenir. Upgrade kararını kolaylaştırır. Otomatik release pipeline ile güncel tutulabilir.

Changesets

Changesets monorepo package versioning ve changelog üretimini yönetmeye yardımcı olabilir. Pull request sırasında değişiklik türü kaydedilir. Release sırasında ilgili package sürümleri hesaplanır. Shared library ekibi için şeffaf süreç oluşturur. Tool kullanım politikası ekip tarafından anlaşılmalıdır.

Design System Governance Nasıl Yapılır?

Design System büyüdükçe component ekleme ve değiştirme süreci yönetişim gerektirir. Ownership belirsiz olduğunda component sayısı hızla artar. RFC ve Design Review benzer ihtiyacın mevcut component ile çözülüp çözülemeyeceğini değerlendirir. Deprecation ve release süreçleri consumer'lara öngörülebilirlik sağlar. Governance'ın amacı katkıyı engellemek değil kalite ve tutarlılığı korumaktır.

Component Ownership

Her kritik component'ın owner veya maintainer'ı bulunmalıdır. Owner bug ve API kararlarını takip eder. Tek kişiye bağımlılık azaltılmalıdır. Contribution diğer ekiplere açık olabilir. Ownership sorumluluk demektir, kod üzerinde kapalı kontrol anlamına gelmemelidir.

Component Request Süreci

Yeni component talebi önce gerçek kullanım senaryosunu açıklamalıdır. Mevcut primitive'lerle çözüm mümkün mü değerlendirilir. En az birkaç kullanım örneği istenebilir. Tasarım ve development birlikte review yapar. Bu süreç duplicate component oluşmasını azaltır.

RFC

Büyük component veya API değişiklikleri RFC ile tartışılabilir. Alternatifler ve trade-off yazılır. Consumer ekiplerden geri bildirim alınır. Karar kayıt altında kalır. Küçük düzeltmeler için RFC zorunlu olmamalıdır.

Design Review

Design Review component'ın görsel ve interaction tutarlılığını değerlendirir. Design token kullanımı kontrol edilir. Accessibility durumu gözden geçirilir. Yeni pattern'ın gerçekten sistem seviyesinde olup olmadığı sorgulanır. Designer ve developer ortak karar verir.

Code Review

Code Review API, test ve implementation kalitesini kontrol eder. Public export değişiklikleri özellikle incelenmelidir. Bundle size etkisi değerlendirilebilir. Backward compatibility korunur. Review guideline contribution sürecini hızlandırır.

Deprecation Policy

Eski component'ın nasıl kaldırılacağı önceden tanımlanmalıdır. Yeni alternatif hazır olmadan deprecation yapılmamalıdır. Warning süresi verilir. Migration guide yayınlanır. Kullanım telemetry veya code search ile takip edilebilir.

Release Süreci

Release otomatik test ve changelog aşamalarını içermelidir. Semantic versioning uygulanır. Storybook yeni sürümle yayınlanabilir. Package registry release güvenli yetkilerle yapılmalıdır. Consumer'lara önemli değişiklikler duyurulmalıdır.

Frontend Platform Team Ne İşe Yarar?

Frontend Platform Team ortak frontend altyapısını ürün olarak geliştirir. Shared infrastructure, design system, scaffolding ve coding standards ekiplerin tekrar eden işleri azaltmasını sağlar. Platform ekibi application feature geliştirmek yerine geliştirici enablement'a odaklanır. Büyük organizasyonda ortak tooling ve architecture enforcement ihtiyacı arttığında değer üretir. Küçük ekipte ayrı platform organizasyonu kurmak gereksiz olabilir.

Shared Infrastructure

Shared infrastructure build, test ve deployment setup'ını ortaklaştırabilir. App ekipleri temel config'i tekrar yazmaz. Security ve observability standardı merkezi sağlanır. Platform update bütün projelere kontrollü taşınır. Ownership net tutulmalıdır.

Design System Ownership

Platform team design system'ın teknik ownership'ini taşıyabilir. Design ekibiyle yakın çalışır. Release ve compatibility süreçlerini yönetir. Contribution diğer product ekiplerine açık tutulabilir. Component request verisi roadmap'e yön verebilir.

Scaffolding

Scaffolding yeni app veya feature için başlangıç kodu oluşturur. Architecture rule ve test setup hazır gelir. Developer kurulum süresinden tasarruf eder. Generator aşırı karmaşık olmamalıdır. Template kullanım oranı izlenebilir.

Coding Standards

Coding standards lint ve formatter üzerinden otomatik uygulanabilir. Mimari import rule'ları da aynı sistemde yer alabilir. Style tartışması code review'dan çıkar. Standart ekip katkısıyla güncellenmelidir. Gereksiz kural developer frustration yaratabilir.

Developer Documentation

Platform docs common workflow'ları açıklar. Yeni app oluşturma ve package yayınlama adımları örnektir. Doküman kod ve template ile uyumlu olmalıdır. Arama ve version bilgisi önemlidir. Outdated docs platform güvenini azaltır.

Developer Enablement

Developer Enablement yalnızca tool sağlamak değildir. Workshop ve pairing ile ekiplerin doğru kullanımını destekler. Feedback toplanır. Sık sorulan problem automation fırsatına dönüşebilir. Platform kullanıcının işini kolaylaştırdığı ölçüde başarılıdır.

Platform Team Ne Zaman Gereklidir?

Birden fazla frontend ekip aynı infrastructure problemini tekrar çözüyorsa platform ihtiyacı artar. Design system ve monorepo maintenance ortak ownership gerektirebilir. Küçük tek ekipte ayrı platform team maliyeti yüksek olabilir. Platform sorumlulukları mevcut ekip içinde başlayabilir. Organizasyon büyüdükçe özel ekip oluşturulabilir.

Yeniden Kullanılabilir Mimarinin Performans Maliyeti Olabilir mi?

Reusability yanlış uygulandığında performans maliyeti oluşturabilir. Gereksiz wrapper component, fazla context provider ve büyük UI library runtime ile bundle maliyetini artırabilir. Shared package bütün component'ları tek entry point'ten export ediyorsa tree shaking beklenenden kötü çalışabilir. Lazy loading ve doğru package structure bu etkileri azaltır. Performans ile abstraction arasında ölçüme dayalı denge kurulmalıdır.

Gereksiz Wrapper Components

Her küçük layout için wrapper component oluşturmak component tree'yi gereksiz büyütebilir. React'te asıl sorun DOM node ve render davranışına bağlıdır. Wrapper anlamlı abstraction sağlamıyorsa kaldırılabilir. Semantic HTML doğrudan kullanılabilir. Component oluşturmak her zaman reuse anlamına gelmez.

Fazla Context Provider

Birçok nested provider component tree'yi anlamayı zorlaştırır. Context value değişikliği geniş re-render oluşturabilir. Provider scope daraltılmalıdır. Bazı dependency'ler prop veya local state ile çözülebilir. Performance profiling gerçek sorunu göstermelidir.

Re-render Problemleri

Shared component sık render edildiğinde gereksiz computation maliyeti oluşabilir. Memoization her component'a otomatik eklenmemelidir. State ownership ve prop stability önce incelenmelidir. React profiler kullanılabilir. Optimizasyon gerçek ölçüme dayanmalıdır.

Büyük UI Library

Bütün UI library'nin application bundle'a girmesi initial load süresini artırabilir. Tree shaking ve modular import önemlidir. CSS bundle da değerlendirilmelidir. Kullanılmayan component'lar production build'e dahil olmamalıdır. Bundle analyzer gerçek etkiyi gösterir.

Bundle Size

Bundle size kullanıcı yükleme süresini doğrudan etkileyebilir. Shared dependency duplicate build'e girebilir. Monorepo otomatik olarak küçük bundle sağlamaz. Route ve feature bazlı code splitting uygulanabilir. Performance budget CI içinde kontrol edilebilir.

Tree Shaking

Tree shaking kullanılmayan export'ların production bundle'dan çıkarılmasını sağlar. Package sideEffects ayarı önemlidir. Barrel export bazı toolchain'lerde beklenmeyen sonuç oluşturabilir. ESM build tercih edilebilir. Gerçek bundle analiz edilmelidir.

Lazy Loading

Lazy loading component veya route kodunu ihtiyaç anında yükler. Büyük feature'lar initial bundle'dan ayrılabilir. Her küçük component'ı lazy yapmak network overhead oluşturabilir. Kullanıcı akışı ve chunk boyutu değerlendirilmelidir. Loading UI tasarlanmalıdır.

AI Destekli Frontend Geliştirmede Mimari Nasıl Korunur?

AI destekli geliştirme component ve boilerplate üretimini hızlandırabilir. Fakat architecture rule'ları verilmediğinde benzer işlev için yeni component veya farklı state yaklaşımı üretilebilir. Repository guideline ve public API kuralları AI context'i içinde tutulmalıdır. Üretilen kod normal code review, accessibility, test ve security süreçlerinden geçmelidir. Hız artarken mimari dağınıklığın da aynı hızda artmaması için guardrail gereklidir.

AI'ya Architecture Rules Vermek

AI tool proje klasör yapısı ve import rule'larını bilmiyorsa generic çözüm üretebilir. Repository seviyesinde kısa architecture guide sağlanabilir. Shared ve feature sınırları açıkça açıklanır. Örnek doğru import yolları verilebilir. Çıktı yine developer tarafından doğrulanmalıdır.

AI ile Component Oluşturmak

AI basit component skeleton üretiminde yardımcı olabilir. Existing design system component'larını kullanması istenmelidir. Yeni primitive oluşturmadan önce repository search yapılmalıdır. Prop API review edilmelidir. Otomatik üretim code ownership'i ortadan kaldırmaz.

Duplicate Component Oluşmasını Önlemek

AI aynı ihtiyacı farklı isimle yeniden oluşturabilir. Component catalog context'e eklenebilir. Developer önce existing UI package'ı aramalıdır. Lint duplicate davranışı her zaman bulamaz. Code review reusable asset bilgisini korumak için önemlidir.

AI Generated Code Review

AI generated code normal kalite standardıyla değerlendirilmelidir. Kaynak bağımsız olsa da production sorumluluğu ekiptedir. Dependency, accessibility, test ve security kontrol edilir. Karmaşık type veya abstraction gereksizse sadeleştirilir. Hız uğruna architecture rule atlanmamalıdır.

Dependency kontrolü

AI gereksiz yeni package önerebilir. Existing dependency ile çözüm mümkün mü kontrol edilmelidir. Package lisans ve güvenlik durumu incelenir. Bundle size etkisi değerlendirilir. Dependency eklemek uzun vadeli support kararıdır.

Accessibility

Generated component semantic HTML kullanmayabilir. Keyboard ve focus davranışı test edilmelidir. Existing accessible primitive'ler tercih edilmelidir. ARIA doğru uygulanmalıdır. Otomatik accessibility scan pipeline'da çalışmalıdır.

Test

AI test üretebilir fakat test doğru davranışı ölçmeyebilir. Implementation detayına bağımlı assertion temizlenmelidir. Edge case'ler developer tarafından eklenir. Component interaction testleri gerçek kullanıcı davranışına odaklanmalıdır. Test varlığı kalite garantisi değildir.

Security

Generated kod XSS veya unsafe HTML gibi riskler içerebilir. Input ve output handling kontrol edilmelidir. Secret değer frontend koduna eklenmemelidir. Dependency güvenliği taranmalıdır. Kritik code path security review gerektirebilir.

Architecture Documentation'ı AI Context'i Olarak Kullanmak

Architecture docs yalnızca insanlar için değil coding assistant context'i için de kullanılabilir. Import rule ve package public API açıklanır. Örnek feature yapısı verilir. Güncel olmayan doküman AI çıktısını da yanlış yönlendirir. Docs-as-Code bu nedenle daha da değerli hale gelir.

Legacy Frontend'i Modüler Mimariye Nasıl Taşırız?

Legacy frontend'i tamamen yeniden yazmak çoğu durumda yüksek risk taşır. Incremental migration mevcut ürün değerini korurken architecture sınırlarını aşamalı geliştirir. Shared component ve API katmanı ayrılarak başlangıç yapılabilir. Feature boundary ve public API yeni geliştirmelerde uygulanır. Feature flag ve rollback planı migration riskini azaltır.

Big-Bang Rewrite'dan Kaçınmak

Big-Bang rewrite yıllarca geliştirilmiş business edge case'lerini kaybetme riski taşır. Yeni sistem tamamlanana kadar eski ürün değişmeye devam eder. İki codebase arasındaki fark büyür. Incremental migration küçük değer üretir. Tam rewrite yalnızca güçlü gerekçelerle değerlendirilmelidir.

Strangler Pattern

Strangler Pattern eski sistemi parça parça yeni modüler yapı ile değiştirmeyi hedefler. Yeni feature modern architecture içinde geliştirilebilir. Eski route veya component aşamalı taşınır. Kullanıcıya kesintisiz geçiş sağlanır. Migration ilerlemesi ölçülebilir hale gelir.

Önce Shared Component'ları Belirlemek

Legacy projede gerçekten tekrar kullanılan UI parçaları tespit edilebilir. Button ve form primitive'leri yeni design system'a taşınabilir. Fakat bütün eski component'ı doğrudan shared yapmak doğru değildir. Kullanım örnekleri incelenmelidir. Yeni API modern ihtiyaçlara göre sadeleştirilebilir.

Feature Boundary Oluşturmak

Yeni geliştirmeler feature-based klasör içinde başlatılabilir. Eski dosyalar hemen taşınmak zorunda değildir. Zamanla ilgili legacy kod feature içine alınır. Dependency rule yeni alanlarda uygulanır. Böylece migration aşamalı ilerler.

API Katmanını Ayırmak

Legacy component doğrudan fetch çağrısı yapıyorsa ilk iyileştirme API katmanı oluşturmak olabilir. Transport ve domain API ayrılır. Yeni component'lar bu contract'ı kullanır. Eski kod zamanla adapte edilir. Backend değişikliklerinin yayılımı azalır.

Incremental Migration

Migration küçük teslimat parçalarına ayrılmalıdır. Her adım production'a çıkabilir. Ölçülebilir feature veya route taşınır. Regression test güven sağlar. Takım uzun süre sadece migration işi yapmak zorunda kalmaz.

Feature Flags

Feature flag yeni ve eski implementation arasında kontrollü geçiş sağlar. Belirli kullanıcı grubunda yeni yapı denenebilir. Problemde hızlı geri dönüş yapılır. Flag cleanup planı olmalıdır. Kalıcı flag birikimi yeni teknik borç yaratabilir.

Rollback Planı

Her migration adımı geri dönüş yoluna sahip olmalıdır. Database veya API contract değişikliği compatibility gerektirebilir. Rollback yalnızca deployment revert olarak düşünülmemelidir. User state etkisi değerlendirilmelidir. Plan production riski azaltır.

Reusable Frontend Architecture'da Yapılan Yaygın Hatalar

Reusable architecture hedefi yanlış yorumlandığında proje daha düzenli olmak yerine daha zor hale gelebilir. En yaygın hata her şeyi shared yapmaktır. Premature generic component, devasa utils klasörü ve deep import diğer sık sorunlardır. State, micro-frontend ve design system seçimleri gerçek ihtiyaçtan büyük olduğunda tooling yükü artar. Architecture rule'larının otomatik kontrol edilmemesi de zamanla sınırların bozulmasına neden olur.

Her Şeyi Shared Yapmak

Shared olmak kalite işareti değildir. Local component ownership'i daha açık olabilir. Her dosya shared olduğunda feature sınırları kaybolur. Değişiklik etkisi genişler. Gerçek reuse kanıtlanmadan shared taşıma yapılmamalıdır.

Component'ları Çok Erken Generic Hale Getirmek

İlk kullanımda gelecekteki bütün senaryolar tahmin edilemez. Generic API gereksiz prop üretir. İki feature farklılaşmaya başladığında abstraction zorlanır. Önce local implementation daha güvenlidir. Tekrar pattern'i görünür olduğunda refactor yapılabilir.

Devasa Components Klasörü

Yüzlerce component'ın tek klasörde bulunması ownership'i belirsizleştirir. Domain-specific ve shared component karışır. Yeni geliştirici doğru component'ı bulmakta zorlanır. Feature-based organization daha iyi discovery sağlayabilir. Shared UI ayrı tutulmalıdır.

Devasa Utils Klasörü

Utils klasörü her yere konulamayan fonksiyonların toplandığı alana dönüşebilir. Domain helper'lar bağlamını kaybeder. İsim çakışmaları oluşur. Local utility feature yanında tutulmalıdır. Shared lib yalnızca generic davranış içermelidir.

Feature'ların Birbirini Doğrudan Import Etmesi

Direct feature import coupling oluşturur. Bir feature değişikliği diğerini etkiler. Ortak behavior daha düşük katmana taşınabilir. Composition page veya widget seviyesinde yapılabilir. Boundary lint ihlali otomatik yakalayabilir.

Deep Import Kullanımı

Deep import internal dosyayı public contract haline getirir. Refactoring sırasında consumer kırılır. Public API üzerinden import yapılmalıdır. Package exports deep import'u engelleyebilir. Lint rule ekip standardını destekler.

Circular Dependency

Circular dependency architecture sınırının bozulduğunu gösterir. Runtime sorunları da oluşturabilir. Dependency graph ile erken bulunmalıdır. Ortak abstraction veya ownership yeniden değerlendirilir. CI yeni döngü oluşmasını engelleyebilir.

UI İçinde Business Logic

Business logic render ile karıştığında test ve reuse zorlaşır. Component çok uzun hale gelir. API ve domain değişikliği UI'a yayılır. Hook veya service sınırı kullanılabilir. Gereksiz katman oluşturulmadan anlamlı davranış ayrılmalıdır.

Gereksiz Global State

Local interaction'ı global store'a taşımak dependency alanını büyütür. Test ve reset davranışı zorlaşır. Server state ayrı çözüm gerektirir. URL state browser tarafından yönetilebilir. State mümkün olduğunca gerçek owner'ına yakın tutulmalıdır.

Mikro-Frontend'i Çok Erken Kullanmak

Micro-frontend büyük organizasyon problemini çözmek için uygundur. Küçük ekipte build ve runtime yükü gereksiz olur. Shared dependency ve UX tutarlılığı ek sorun yaratır. Modüler monolith frontend önce değerlendirilmelidir. Organizasyonel bağımsızlık gerçek gereksinim olmalıdır.

Dokümantasyonsuz Design System

Component library tek başına kullanım standardı oluşturmaz. Consumer hangi variant'ın ne zaman kullanılacağını bilmeyebilir. Storybook ve guideline gereklidir. Deprecation ve owner bilgisi görünür olmalıdır. Dokümantasyon adoption'ın temel parçasıdır.

Architecture Rule'larını Otomatik Kontrol Etmemek

İnsanlar bütün import kurallarını sürekli hatırlayamaz. Code review geç aşamada feedback verir. ESLint ve CI rule hatayı erken yakalar. Dokümantasyon ile automation birlikte kullanılmalıdır. Yeni ekip üyesi standardı editor içinde öğrenebilir.

Open Source ve Frontend Mimarisinde İşbirliği

Açık kaynak component library geliştirmek yeniden kullanılabilir mimari prensiplerini gerçek collaboration ortamında sınamayı sağlar. Repository yapısı, contribution guideline ve review süreçleri açık olmak zorundadır. RFC ve semantic release gibi yöntemler değişiklikleri daha öngörülebilir hale getirir. Governance farklı katkıların aynı kalite standardında birleşmesini sağlar. Topluluk çalışmaları frontend architecture bilgisinin yalnızca tek ekip içinde kalmasını önler.

Açık Kaynak Component Library Oluşturmak

Open source library net problem alanıyla başlamalıdır. Her component'ı içeren devasa kit oluşturmaya gerek yoktur. Public API ve compatibility politikası açık olmalıdır. Test ve Storybook katkıyı kolaylaştırır. Maintenance kapasitesi proje kapsamıyla uyumlu olmalıdır.

Repository Yapısı

Repository contributor'ın hızlı anlayacağı yapıda olmalıdır. packages ve examples ayrımı kullanılabilir. Build ve test komutları README içinde açıklanır. Tooling gereksiz derecede özel olmamalıdır. Yeni katkı birkaç adımda local çalıştırılabilmelidir.

CONTRIBUTING.md

CONTRIBUTING.md development setup ve contribution beklentilerini açıklar. Branch ve commit kuralları belirtilebilir. Test gereksinimleri yazılır. Yeni contributor doğru yolu tahmin etmek zorunda kalmaz. Belge güncel tutulmalıdır.

Issue Templates

Issue template bug ve feature taleplerinde gerekli bilgiyi toplar. Reproduction veya kullanım senaryosu istenebilir. Component request'leri ortak formatta değerlendirilir. Maintainer'ın tekrar soru sorma ihtiyacı azalır. Template çok uzun olmamalıdır.

Pull Request Süreci

Pull request değişikliğin kapsamını ve nedenini açıklamalıdır. Test ve Storybook güncellemesi beklenebilir. Breaking change açık belirtilir. CI otomatik kalite kontrolü sağlar. Review contributor için öğrenme alanı olmalıdır.

Code Review

Code review yalnızca syntax kontrolü değildir. API ve architecture etkisi değerlendirilir. Accessibility ve test kapsamı incelenir. Geri bildirim net ve uygulanabilir olmalıdır. Maintainer standardı tutarlı uygulamalıdır.

RFC Süreci

Büyük API değişikliği veya yeni pattern RFC ile tartışılabilir. Community erken feedback verebilir. Alternatifler görünür olur. Karar geçmişi korunur. Küçük bug fix için RFC gerektirilmemelidir.

Semantic Release

Semantic release commit veya changeset bilgisinden version üretimini otomatikleştirebilir. Changelog güncel kalır. Breaking change görünür olur. Publish süreci insan hatasını azaltır. Release yetkileri güvenli biçimde yönetilmelidir.

Open Source Governance

Governance maintainer ve contributor rollerini açıklar. Karar süreci şeffaf olmalıdır. Security issue için ayrı kanal bulunabilir. Proje büyüdükçe yeni maintainer ekleme yolu tanımlanmalıdır. Governance katkıyı zorlaştırmak yerine sürdürülebilir bakım sağlar.

Diyarbakır Yazılım Topluluğu ile Reusable Frontend Projesi Geliştirmek

Topluluk temelli reusable frontend projesi gerçek code review, contribution ve design system deneyimi sağlar. Ortak bir UI Kit veya açık kaynak component library bu çalışma için uygun başlangıç olabilir. Contributor rollerinin belirlenmesi proje sürdürülebilirliğini artırır. Workshop ve pair programming yeni katılımcıların proje standartlarını öğrenmesini kolaylaştırır. Diyarbakır Yazılım Topluluğu çalışmaları hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr adresi üzerinden topluluk içeriklerine ulaşabilirsiniz.

Ortak Bir Açık Kaynak Proje Belirlemek

Proje gerçek ve sınırlı problem seçmelidir. Her şeyi kapsayan frontend framework geliştirmek iyi başlangıç değildir. Yerel ihtiyaç veya eğitim amacı kullanılabilir. Repository ve roadmap açık paylaşılır. Katkı yapacak kişilerin hızlı başlayabileceği issue'lar hazırlanır.

Diyarbakır İçin Ortak UI Kit Geliştirmek

Ortak UI Kit component design ve accessibility pratiği için güçlü alan sağlar. Button, Input ve Modal gibi primitive'lerle başlanabilir. Design token yaklaşımı birlikte öğrenilir. Dokümantasyon Storybook üzerinden sunulabilir. Proje zamanla gerçek açık kaynak contribution modeline dönüşebilir.

GitHub Organization Yapısı

Organization repository ve contributor yönetimini kolaylaştırır. Team ve permission yapısı tanımlanabilir. Main branch protection uygulanır. Issue ve project board ortak roadmap sağlar. Güvenlik yetkileri minimum seviyede tutulmalıdır.

Contributor Rollerini Belirlemek

Rol tanımı projedeki sorumlulukları açık hale getirir. Maintainer release ve yönetişim sorumluluğu alabilir. Contributor issue ve pull request üzerinden katkı verir. Reviewer kalite ve architecture değerlendirmesine destek olur. Designer component davranışının görsel ve kullanım tarafına katkı sağlar.

Maintainer

Maintainer proje yönünü ve release sürecini takip eder. Pull request merge sorumluluğu taşıyabilir. Security ve versioning kararlarını yönetir. Tek maintainer bağımlılığı oluşturulmamalıdır. Yeni maintainer yetiştirme süreci açık olmalıdır.

Contributor

Contributor issue veya feature üzerinde çalışır. Contribution guide kurallarını takip eder. Test ve dokümantasyon güncelleyebilir. Küçük katkıyla başlamak teşvik edilmelidir. Düzenli katkı reviewer veya maintainer rolüne ilerleyebilir.

Reviewer

Reviewer architecture ve kalite açısından değişikliği değerlendirir. Yalnızca hata bulmak değil geliştiriciye açıklayıcı feedback vermek önemlidir. Accessibility ve test standardı kontrol edilir. Merge yetkisi maintainer modeline göre değişebilir. Birden fazla reviewer bilgi paylaşımını artırır.

Designer

Designer component visual ve interaction davranışını tanımlar. Design token ve accessibility kararına katkı verir. Figma component ile kod component uyumu takip edilir. Design review pull request sürecine bağlanabilir. Tasarım tek seferlik teslim değil sürekli collaboration haline gelir.

Issue ve Roadmap Yönetimi

Issue backlog açık önceliklerle yönetilmelidir. Good first issue yeni contributor'lar için belirlenebilir. Roadmap gerçek bakım kapasitesine göre hazırlanmalıdır. Her feature aynı anda planlanmamalıdır. Community feedback roadmap girdisi olabilir.

Code Review Kültürü

Code review öğrenme ve kalite süreci olmalıdır. Kişisel tercih ile standard ayrılmalıdır. Feedback gerekçesi açıklanmalıdır. Contributor'ın soru sorması teşvik edilir. Aynı pattern zamanla dokümantasyona dönüştürülebilir.

Workshop ve Pair Programming

Workshop component design ve testing konularında ortak öğrenme sağlar. Pair programming yeni contributor'ın codebase'i daha hızlı anlamasına yardımcı olur. Gerçek issue üzerinde çalışmak teorik eğitimden daha etkili olabilir. Sonuç repository'ye katkı olarak döner. Topluluk bilgisi kalıcı hale gelir.

Üniversite–Topluluk–Şirket İşbirliği

Üniversite öğrencileri açık kaynak proje üzerinden gerçek geliştirme deneyimi kazanabilir. Topluluk mentoring ve collaboration alanı oluşturur. Şirket mühendisleri code review ve workshop desteği verebilir. Bu model frontend architecture bilgisini bölgesel ekosisteme yayar. Proje üretim ve öğrenme hedefini birlikte destekleyebilir.

Diyarbakır'daki En İyi Yazılımcılar Frontend Mimarisinde Hangi Yetkinliklere Sahip Olmalı?

Frontend mimarisinde güçlü geliştirici yalnızca framework API'sini bilen kişi değildir. JavaScript ve TypeScript temellerinin yanında component design, testing, accessibility ve performance bilgisi gerekir. API design ve code review ekip çalışmasının önemli parçalarıdır. Open source contribution iletişim ve collaboration becerisini geliştirebilir. Teknik kararları gerekçelendirme yeteneği kıdem arttıkça daha önemli hale gelir.

JavaScript ve TypeScript

JavaScript runtime ve language behavior iyi anlaşılmalıdır. Async, closure ve module sistemi temel konulardır. TypeScript yalnızca type annotation yazmak değildir. Generic ve union yapıları API tasarımında bilinçli kullanılmalıdır. Dil bilgisi framework kullanımından bağımsız temel oluşturur.

Component Design

Component design responsibility ve API sınırı kurmayı gerektirir. Reusability ile premature abstraction farkı anlaşılmalıdır. Composition pattern'leri bilinmelidir. Accessibility component tasarımının doğal parçası olmalıdır. Consumer deneyimi API kararında düşünülmelidir.

Software Design Principles

Separation of concerns ve dependency direction frontend için de önemlidir. SOLID prensipleri birebir class tasarımına indirgenmemelidir. Modül sınırları ve change impact düşünülmelidir. Abstraction maliyeti değerlendirilmelidir. Architecture kararları product ihtiyacıyla ilişkilendirilmelidir.

Testing

Unit, component ve integration test farkları bilinmelidir. Test kullanıcı davranışına yakın yazılmalıdır. Accessibility ve visual regression testleri gerektiğinde kullanılabilir. Her satırı test etmek hedef değildir. Kritik contract ve business davranışı önceliklendirilmelidir.

Git ve Code Review

Git ekip geliştirmesinin temelidir. Commit ve branch yönetimi bilinmelidir. Code review açık teknik iletişim gerektirir. Büyük PR yerine küçük ve anlaşılır değişiklikler tercih edilmelidir. Review feedback'i architecture bilgisinin yayılmasını sağlar.

Performance

Frontend developer bundle ve runtime performansını anlayabilmelidir. Network ve rendering darboğazlarını ayırmalıdır. Profiler ve bundle analyzer kullanabilmelidir. Optimization ölçüme dayanmalıdır. Gereksiz memoization veya premature optimization'dan kaçınılmalıdır.

Accessibility

Semantic HTML ve keyboard behavior temel bilgi olmalıdır. ARIA gerektiğinde doğru kullanılmalıdır. Accessibility yalnızca design system ekibinin sorumluluğu değildir. Shared primitive sayesinde kalite ölçeklenebilir. Manuel test deneyimi de önemlidir.

API Design

Frontend developer backend contract'ını yalnızca tüketmez. Error ve loading behavior'ı tasarlar. Type ve mapping sınırı kurabilir. API client abstraction ihtiyacını değerlendirebilir. Contract değişikliğinin UI üzerindeki etkisini yönetebilir.

Open Source Katkıları

Open source katkısı zorunlu kriter değildir fakat collaboration becerisini geliştirebilir. Contribution guide ve review süreci gerçek ekip deneyimi sunar. Dokümantasyon katkısı da değerlidir. Maintainer feedback'i teknik gelişimi hızlandırır. Topluluk çalışması iletişim becerisini güçlendirir.

Ekip İçinde Mimari Karar Alabilme

Mimari karar yalnızca en kıdemli kişinin görevi değildir. Geliştirici alternatifleri ve trade-off'ları açıklayabilmelidir. Karar veriye dayanmalıdır. ADR kısa biçimde gerekçeyi kaydedebilir. Ekip içinde fikir ayrılığı sağlıklı teknik tartışmayla çözülmelidir.

Yazılımcı Olmak İçin Ne Yapmalı? Frontend Architecture Öğrenme Yol Haritası

Frontend architecture öğrenmek için doğrudan micro-frontend veya monorepo ile başlamak gerekmez. HTML, CSS ve JavaScript temelleri ilk aşamadır. TypeScript ve bir framework ile gerçek uygulama geliştirildikten sonra composition, state ve API sınırları daha anlamlı hale gelir. Testing ve design system bilgisi component kalitesini artırır. Son aşamada feature-based architecture, monorepo ve açık kaynak contribution deneyimi daha büyük sistemleri anlamayı kolaylaştırır.

HTML ve CSS

Semantic HTML frontend'in temelidir. Layout ve responsive design CSS ile öğrenilmelidir. Framework utility'leri temel bilgiyi değiştirmez. Accessibility için doğru element seçimi önemlidir. Tasarım sistemi bilgisi CSS temelleri üzerine kurulur.

JavaScript

JavaScript dil ve browser davranışı iyi öğrenilmelidir. DOM, event ve async programlama temel konulardır. Framework abstraction arkasındaki davranışı anlamayı sağlar. Module sistemi reusable code için önemlidir. Küçük projelerle pratik yapılmalıdır.

TypeScript

TypeScript basic type ve interface ile başlanabilir. Union ve generic yapıları ihtiyaç oldukça öğrenilmelidir. Public API type tasarımı pratiği yapılabilir. Aşırı type-level programming gerekli değildir. Compiler feedback refactoring disiplinini geliştirir.

React, Vue veya Angular

Bir framework seçip gerçek uygulama geliştirmek yeterlidir. Aynı anda üçünü öğrenmek gerekmez. Component lifecycle ve state yaklaşımı anlaşılmalıdır. Routing ve API integration yapılmalıdır. Sonrasında diğer framework'lerin benzer prensipleri daha kolay öğrenilir.

Component Composition

Composition reusable component tasarımının temel becerisidir. Children, slots veya content projection kullanılabilir. Devasa prop API yerine küçük parçalar birleştirilir. Compound component pattern pratiği yapılabilir. Pattern gerçek ihtiyaçla birlikte öğrenilmelidir.

State Management

Önce local state ve URL state öğrenilmelidir. Server state'in farklı problem olduğu anlaşılmalıdır. Global store gereksiz kullanılmamalıdır. Küçük uygulamada Context veya basit store denenebilir. Büyük sistemde domain state sınırı önem kazanır.

API Entegrasyonu

HTTP client ve error handling temel seviyede öğrenilmelidir. Daha sonra transport ve domain API ayrımı uygulanabilir. Loading ve retry davranışları tasarlanmalıdır. Type generation denenebilir. API contract frontend architecture'ın önemli parçasıdır.

Testing

Unit ve component test yazılmalıdır. User interaction üzerinden assertion yapma alışkanlığı geliştirilmelidir. Accessibility test araçları denenebilir. Testlerin refactoring'e destek olması önemlidir. Coverage tek hedef olmamalıdır.

Design System

Küçük UI kit oluşturarak design token ve component API pratiği yapılabilir. Storybook kullanılabilir. Accessibility primitive seviyesinde çözülür. Semantic versioning denenebilir. Gerçek consumer kullanımı API hatalarını gösterir.

Feature-Based Architecture

Orta ölçekli projede feature bazlı klasörleme uygulanabilir. Shared ve local ayrımı gözlemlenir. Public API ve dependency rule denenebilir. FSD daha sonra değerlendirilebilir. Architecture problemden doğmalıdır.

Monorepo

Birden fazla app veya package olduğunda monorepo pratiği yapılabilir. Workspace dependency ve shared config öğrenilir. CI caching incelenebilir. Package boundary uygulanır. Tek küçük proje için monorepo kurmak öğrenme amacı dışında gerekli değildir.

Open Source Bir Projeye Katkı

Açık kaynak contribution gerçek review deneyimi sağlar. Küçük issue veya docs ile başlanabilir. Repository architecture incelenir. Maintainer feedback alınır. Düzenli katkı teknik ve iletişim becerisini birlikte geliştirir.

Production-Ready Reusable Frontend Architecture Kontrol Listesi

Production-ready reusable architecture için yalnızca klasör yapısının düzenli görünmesi yeterli değildir. Feature sınırları, dependency yönü ve public API'ler açık olmalıdır. Design system, accessibility ve test yaklaşımı ortak kalite standardını desteklemelidir. Versioning ve CI rule'ları değişikliklerin kontrollü yayılmasını sağlar. Developer documentation güncel değilse doğru architecture kullanımı zamanla azalabilir.

Feature sınırları açık mı?

Her feature'ın hangi business sorumluluğunu taşıdığı anlaşılmalıdır. Internal dosyalar başka feature'lar tarafından rastgele import edilmemelidir. Ownership net olmalıdır. Feature kaldırıldığında etkilediği alan belirlenebilmelidir. Boundary architecture tool ile desteklenebilir.

Shared layer gerçekten shared kod mu içeriyor?

Shared klasörde yalnızca bir feature tarafından kullanılan dosya bulunmamalıdır. Domain-specific component local tutulmalıdır. Generic utility gerçekten bağımsız olmalıdır. Shared büyümesi düzenli review edilmelidir. Yeni taşıma için net kriter kullanılmalıdır.

Dependency yönü tanımlı mı?

Hangi layer'ın hangisini import edebileceği açık olmalıdır. Shared üst seviyeyi bilmemelidir. Feature'lar arası direct dependency sınırlanmalıdır. Dokümantasyon tek başına yeterli değildir. Lint ve CI ile kontrol edilmelidir.

Circular dependency kontrol ediliyor mu?

Circular dependency build veya runtime problemi yaratabilir. Daha önemlisi modül sınırının bozulduğunu gösterir. Otomatik dependency scan kullanılmalıdır. Yeni döngü merge öncesinde bloklanabilir. Mevcut döngüler migration backlog'una alınabilir.

Public API'ler tanımlı mı?

Modül dışından hangi export'ların kullanılabileceği belli olmalıdır. Internal path'e deep import yapılmamalıdır. Package exports veya index entry kullanılabilir. Public type ve component stabil tutulmalıdır. Breaking change versioning ile yönetilmelidir.

Component API'leri minimal mi?

Component gereksiz prop taşıyor mu kontrol edilmelidir. Boolean explosion uyarı sinyalidir. Composition alternatif olarak değerlendirilir. Sensible default kullanımı consumer yükünü azaltır. Escape hatch kullanım oranı izlenebilir.

Design system var mı?

Her proje tam design system gerektirmez. Fakat ortak UI ve token stratejisi varsa tutarlılık artar. Birden fazla product için component library değerli olabilir. Governance ve versioning unutulmamalıdır. Kullanım ihtiyaçtan doğmalıdır.

Accessibility component seviyesinde çözülmüş mü?

Primitive component semantic HTML kullanmalıdır. Keyboard ve focus behavior doğrulanmalıdır. Shared Modal veya FormField accessibility standardını taşımalıdır. Otomatik test kullanılabilir. Manual review kritik component'larda sürdürülmelidir.

Test kapsamı yeterli mi?

Test kapsamı yalnızca yüzde olarak değerlendirilmemelidir. Public contract ve business behavior doğrulanmalıdır. Shared component edge state'leri test edilmelidir. Interaction ve accessibility testleri eklenebilir. Consumer impact büyükse integration test kullanılmalıdır.

Versioning politikası var mı?

Shared package değişikliklerinin nasıl yayınlanacağı belli olmalıdır. Semantic versioning kullanılabilir. Deprecation ve migration guide süreci tanımlanmalıdır. Changelog güncel tutulmalıdır. Consumer ekip release riskini anlayabilmelidir.

Architecture rule'ları CI'da kontrol ediliyor mu?

Import boundary ve circular dependency otomatik kontrol edilmelidir. Manual review tek başına yeterli değildir. Hata developer'a erken gösterilmelidir. CI check hızlı olmalıdır. Kurallar proje büyüdükçe güncellenmelidir.

Developer documentation güncel mi?

Yeni feature ve shared component oluşturma yolu açıklanmalıdır. Architecture kararlarının nedeni yazılmalıdır. Storybook component kullanımını göstermelidir. Outdated docs silinmeli veya güncellenmelidir. Dokümantasyon ownership'i açık olmalıdır.

Proje Ölçeğine Göre Önerilen Frontend Mimari Yapıları

Frontend architecture proje ölçeğine göre büyümelidir. Küçük projede minimal feature-based yapı yeterli olabilir. Orta ölçekli SaaS için shared UI ve TypeScript güçlü temel sağlar. Birden fazla uygulamada monorepo ve shared packages anlam kazanabilir. Çok büyük organizasyonda platform team ve architecture enforcement ihtiyacı artarken micro-frontend yalnızca gerçek bağımsızlık gereksiniminde değerlendirilmelidir.

Küçük Proje

Küçük projede basitlik en önemli hedeftir. Birkaç feature ve ortak primitive yeterli olabilir. Ağır monorepo veya FSD katmanı gerekmez. Local First yaklaşımı shared klasörün büyümesini önler. Proje büyüdükçe yapı evrimleşebilir.

Feature-based klasörleme

Feature-based klasörleme küçük projede bile domain ownership sağlar. Her feature kendi component ve logic'ini tutar. Shared sadece ortak primitive'leri içerir. Dosya bulmak kolaylaşır. Gelecekte ölçeklenmeye uygun temel oluşur.

Local components

Component ilk olarak feature yanında tutulur. Reuse ihtiyacı kanıtlanmadan shared'e taşınmaz. Ownership net kalır. Feature silindiğinde cleanup kolaydır. Premature abstraction riski azalır.

Minimal shared layer

Shared layer yalnızca Button, API client veya generic utility gibi gerçek ortak parçaları içerir. Dosya sayısını büyütmek hedef değildir. Domain dependency bulunmaz. Kullanım alanı düzenli review edilir. Minimal yapı cognitive load'u azaltır.

Orta Ölçekli SaaS

Orta ölçekli SaaS birden fazla feature ve ekip içerebilir. Feature-based architecture domain ownership için güçlü temel sağlar. Shared UI ve design system tutarlılığı artırabilir. TypeScript public contract'ları güvenli hale getirir. Dependency rule otomatik kontrol edilmeye başlanabilir.

Feature-based architecture

Feature'lar kendi UI ve state davranışını taşır. Cross-feature import sınırlanır. Page composition daha üst seviyede yapılır. API endpoint ownership netleşir. Codebase büyüdükçe navigation kolaylaşır.

Shared UI

Shared UI common primitive'leri merkezi sunar. Accessibility ve design token davranışı ortaklaşır. Duplicate component sayısı azalır. Storybook dokümantasyon sağlar. Business-specific UI feature içinde kalır.

Design system

SaaS büyüdükçe birden fazla ekran ve ekip tasarım tutarlılığı ihtiyacı oluşturur. Design token ve component library faydalıdır. Governance hafif başlayabilir. Component request süreci gerçek tekrar kullanım ihtiyacını kontrol eder. Adoption ölçülebilir.

TypeScript

TypeScript refactoring ve package contract'larında güçlü avantaj sağlar. API response type ve domain type ayrılabilir. Shared component props güvenli olur. Strict mode code quality'yi destekler. Type sistemi sade tutulmalıdır.

Birden Fazla Frontend Uygulaması

Birden fazla frontend app aynı organization içinde ortak altyapı ihtiyacını artırır. Monorepo coordination maliyetini azaltabilir. Shared package ve central design system tekrar kullanımı güçlendirir. Her app business feature'larını bağımsız tutmalıdır. Release ihtiyaçları package boundary ile yönetilebilir.

Monorepo

Monorepo app ve package'ları tek repository içinde birleştirir. Cross-project değişiklik aynı pull request'te yapılabilir. CI affected build kullanabilir. Module boundary architecture'ı korur. Ownership CODEOWNERS ile desteklenebilir.

Shared packages

UI, config ve API infrastructure package olarak paylaşılabilir. Business domain package'ları dikkatli değerlendirilmelidir. Public API stable tutulur. Versioning veya workspace dependency kullanılır. Package sayısı gerçek reuse ihtiyacına dayanmalıdır.

Central design system

Central design system bütün uygulamalarda görsel ve interaction tutarlılığı sağlar. Token ve primitive component'lar ortaklaşır. Release ve deprecation süreci önemlidir. Consumer feedback roadmap'e yön verir. Tasarım ekipleriyle ortak ownership kurulmalıdır.

Çok Büyük Kurumsal Organizasyon

Çok büyük organizasyonda architecture yalnızca code structure problemi değildir. Ekip ownership ve independent delivery önemli hale gelir. Monorepo veya kontrollü multi-repo modelleri kullanılabilir. Frontend platform team ortak tooling ve design system sağlar. Micro-frontend yalnızca organizasyonel bağımsızlık başka yollarla çözülemiyorsa değerlendirilmelidir.

Monorepo veya kontrollü multi-repo

Monorepo yüksek paylaşım ve central tooling için avantaj sağlar. Multi-repo bağımsız ekiplerde release autonomy sunabilir. Ortak package registry iki modeli bağlayabilir. Tek doğru yapı bulunmaz. Organizasyon sınırı repository seçimini etkiler.

Frontend platform team

Platform team shared infrastructure ve Developer Experience'a odaklanır. Product ekiplerin tekrar eden işlerini azaltır. Design system ve scaffolding sağlar. Adoption ve satisfaction ölçer. Merkezi bottleneck olmamaya dikkat eder.

Architecture enforcement

Büyük ekip sayısında manuel architecture review ölçeklenmez. Boundary rule ve policy automation gerekir. Public API ve package dependency CI'da kontrol edilir. Exception mekanizması bulunmalıdır. Kurallar ekiplerin işini kolaylaştıracak kadar anlaşılır olmalıdır.

Gerekliyse micro-frontends

Micro-frontend independent deployment ve ownership için kullanılabilir. Domain sınırları net olmalıdır. Shared dependency ve design system yönetimi ayrıca planlanır. Runtime integration operational cost yaratır. Alternatif modüler monolith çözümü önce değerlendirilmelidir.

Sık Sorulan Sorular

Reusable frontend architecture konusunda en sık sorulan sorular klasör yapısı, shared component ve teknoloji seçimi etrafında toplanır. Tek bir evrensel architecture şablonu yoktur. Proje büyüklüğü ve domain sınırları karar üzerinde belirleyicidir. En iyi yaklaşım basit başlayıp gerçek ihtiyaç ortaya çıktıkça sınırları geliştirmektir. Aşağıdaki cevaplar pratik karar verirken kullanılabilecek temel çerçeveyi özetler.

Frontend mimarisi nedir?

Frontend mimarisi component, state, API ve dependency yapısının birlikte tasarlanmasıdır. Klasör düzeni bunun yalnızca görünen parçasıdır. Test, build ve design system kararları da mimariye dahildir. İyi architecture change impact'i sınırlar. Ekip büyüdüğünde codebase'in anlaşılır kalmasını sağlar.

Yeniden kullanılabilir component nedir?

Reusable component birden fazla kullanım alanında stabil bir API ile çalışabilir. Domain bağımlılığı düşük olabilir. Her generic component reusable değildir. Component'ın gerçek consumer ihtiyacı bulunmalıdır. Test ve dokümantasyon kullanımı kolaylaştırır.

Component ne zaman shared yapılmalı?

Birden fazla bağımsız feature aynı davranışı kullanıyorsa shared adaylığı oluşur. API yeterince stabil olmalıdır. Domain-specific bilgi minimumda tutulmalıdır. Tek kullanım varsa local kalması daha güvenlidir. Rule of Three pratik değerlendirme aracı olabilir.

Feature-based architecture nedir?

Feature-based architecture dosyaları teknik tür yerine business özelliğine göre gruplar. Feature kendi component, hook ve API dosyalarını taşıyabilir. Ownership daha açık olur. Değişikliklerin çoğu aynı klasörde kalır. Büyük projects için layer-based yapıya göre daha iyi ölçeklenebilir.

Feature-Sliced Design nedir?

FSD frontend uygulamasını App, Pages, Widgets, Features, Entities ve Shared katmanlarına ayırabilir. Dependency yönü ana prensiplerden biridir. Domain sınırlarını görünür hale getirir. Büyük projelerde faydalı olabilir. Küçük projede bütün katmanları kullanmak gerekli değildir.

Atomic Design nedir?

Atomic Design UI component'larını Atoms, Molecules, Organisms, Templates ve Pages seviyelerine ayırır. Design system için ortak sözlük sağlar. Görsel component hiyerarşisine odaklanır. Business dependency sınırlarını tek başına çözmez. Feature architecture ile birlikte kullanılabilir.

Atomic Design ve FSD birlikte kullanılabilir mi?

Evet, çünkü farklı problemlere odaklanırlar. Atomic Design shared UI içindeki component seviyesini düzenleyebilir. FSD business ve dependency sınırlarını yönetebilir. Feature-local component'lar zorla shared yapılmamalıdır. Hibrit yaklaşım proje ihtiyacına göre sade tutulmalıdır.

React projelerinde en iyi klasör yapısı nedir?

Tek bir en iyi klasör yapısı yoktur. Küçük projede basit feature-based yapı çoğu zaman yeterlidir. Büyük projede FSD benzeri daha belirgin layer'lar kullanılabilir. Dependency yönü klasör isminden daha önemlidir. Yapı gerçek değişiklik pattern'lerine göre seçilmelidir.

Frontend için en iyi programlama dili hangisidir?

Browser tarafında temel dil JavaScript'tir. Büyük ve uzun ömürlü projelerde TypeScript güçlü avantaj sağlar. React, Vue ve Angular programlama dili değil framework veya library'dir. Teknoloji seçimi ekip ve ürün bağlamına göre yapılmalıdır. Mimari prensipler araçtan daha uzun ömürlüdür.

TypeScript reusable architecture için gerekli midir?

Zorunlu değildir fakat büyük projelerde contract güvenliğini artırır. Shared component ve package API'leri type-safe hale gelir. Refactoring sırasında consumer kırıkları daha erken görülür. TypeScript yanlış architecture'ı otomatik düzeltmez. Basit ve anlaşılır type tasarımı önemlidir.

Monorepo ne zaman kullanılmalı?

Birden fazla app ve shared package varsa monorepo değer üretebilir. Cross-project değişikliklerin birlikte yapılması gerekiyorsa avantajlıdır. Ortak tooling ve CI standardı kolaylaşır. Tek küçük app için gereksiz olabilir. Tooling maliyeti collaboration faydasıyla karşılaştırılmalıdır.

Micro-frontend ne zaman kullanılmalıdır?

Çok büyük organizasyonda independent deployment ve ownership ihtiyacı varsa değerlendirilebilir. Küçük ekipte çoğu zaman gereksizdir. Runtime integration ve shared dependency sorunları yaratır. Modüler frontend önce denenebilir. Organizasyonel problem açık olmadan kullanılmamalıdır.

Design system ile component library arasındaki fark nedir?

Component library reusable kod paketidir. Design system bunun yanında token, prensip, dokümantasyon ve governance içerir. UI Kit ise daha çok görsel asset set'i olabilir. Organizasyon büyüdükçe design system ihtiyacı artar. Küçük projede basit component library yeterli olabilir.

Shared klasörüne hangi dosyalar konulmalıdır?

Birden fazla domain tarafından kullanılan ve feature bilgisi taşımayan kod shared olabilir. UI primitive, generic utility ve API infrastructure buna örnektir. Feature-specific hook local kalmalıdır. Shared klasör düzenli review edilmelidir. Kullanım kanıtı olmadan dosya taşınmamalıdır.

Circular dependency nasıl engellenir?

Dependency yönü açık kurallarla tanımlanmalıdır. Feature-to-feature direct import sınırlandırılabilir. ESLint veya Dependency Cruiser otomatik kontrol sağlayabilir. CI yeni döngüyü merge öncesinde engeller. Mevcut döngü architecture sınırını yeniden tasarlamayı gerektirebilir.

Frontend mimarisi nasıl test edilir?

Architecture yalnızca unit test ile doğrulanmaz. Import boundary ve circular dependency static analysis ile kontrol edilebilir. Component public API contract testleri yazılabilir. Integration test gerçek feature davranışını doğrular. CI architecture rule'larını otomatik çalıştırmalıdır.

Sonuç: Yeniden Kullanılabilirlikten Çok Doğru Sınırlar Tasarlayın

Frontend Projelerinde Yeniden Kullanılabilir Mimari Tasarımı yalnızca daha fazla shared component üretmek anlamına gelmez. Kalıcı değer, hangi kodun local kalacağını, hangi domain sınırının korunacağını ve hangi contract'ın gerçekten ortak olduğunu doğru belirlemekten gelir. Composition, feature-based organization ve dependency rule'ları component sayısından daha etkili mimari araçlardır. Design system, testing ve tooling bu sınırların günlük geliştirme sırasında korunmasını sağlar. Sağlam frontend architecture, bugün az kod yazmaktan çok yarın yapılacak değişikliğin nereleri etkileyeceğini kontrol edebilmekle ilgilidir.

Önce Local, Sonra Shared

Yeni component veya hook ilk olarak kullanıldığı feature yanında tutulabilir. Gerçek reuse ortaya çıktığında shared'e taşımak daha güvenlidir. Bu yaklaşım premature abstraction riskini azaltır. Shared layer yalnızca doğrulanmış ortak davranış içerir. Refactoring doğal architecture gelişiminin parçası olur.

Composition'ı Generic Component'lardan Önce Düşünün

Çok sayıda prop eklemek yerine küçük component'ları compose etmek çoğu zaman daha anlaşılır API oluşturur. Children, slot ve compound component pattern'leri esneklik sağlar. Consumer ihtiyaç duyduğu yapıyı birleştirir. Base component sürekli büyümez. Reusability sınırsız configuration yerine doğru building block'lar üzerinden sağlanır.

Feature ve Domain Sınırlarını Koruyun

Business davranışları feature ve domain alanında tutulmalıdır. Shared katman domain detaylarını bilmemelidir. Feature'ların birbirini doğrudan import etmesi sınırlandırılmalıdır. Public API bu contract'ı teknik olarak korur. Böylece change impact daha öngörülebilir hale gelir.

Dependency Graph'i Mimari Tasarımın Merkezi Haline Getirin

Klasör yapısı düzenli görünse bile dependency graph gerçeği gösterir. Circular dependency ve deep import otomatik analiz edilebilir. Mimari yöneticilerin hafızasına bağlı kalmamalıdır. CI boundary rule'ları yeni ihlalleri erken yakalar. Graph düzenli architecture review için somut veri sağlar.

Design System, Tooling ve İşbirliği ile Mimarinin Sürdürülebilirliğini Sağlayın

Design system ortak UI ve accessibility davranışını bütün ürünlere taşır. Storybook ve testler component contract'ını görünür hale getirir. Tooling import ve architecture kurallarını otomatik uygular. Açık kaynak ve topluluk çalışmaları mimari bilginin ekipler arasında yayılmasını destekler. Reusable frontend projeleri ve yazılım topluluğu çalışmalarını takip etmek için https://www.diyarbakiryazilim.com.tr adresinden Diyarbakır Yazılım Topluluğu'na ulaşabilirsiniz.