Kıdemli Front-End Geliştiriciler Nasıl Düşünür: 4 Kritik Yaklaşım

Kariyerinin ilk yıllarında bir front-end geliştiricisinin odak noktası genellikle araçları ve teknolojileri öğrenmek olur:

• JavaScript nasıl yazılır?
• React, Vue ya da Angular nasıl kullanılır?
• API’lar nasıl tüketilir?
• Yeniden kullanılabilir bileşenler nasıl oluşturulur?
• Uygulama durumu nasıl yönetilir?
• Cevaplayıcı (responsive) düzenler nasıl oluşturulur?

Bu soruların tümü son derece önemlidir. Her front-end geliştiricisinin sahip olması gereken teknik temeli oluştururlar.

Ancak profesyonel deneyimin birkaç yıl sonrasında geliştiriciler genellikle yazılım geliştirmenin en zor kısmının kod yazmak olmadığını keşfederler.

Zor olan aslında:

• Belirli bir proje için doğru teknik kararı vermek.
• Doğru karmaşıklık düzeyini seçmek.
• Teslim hızını kod kalitesi ile dengelemek.
• Mühendislik takımındaki anlaşmazlıkları yönetmek.
• Bir sistemin ne zaman yeniden yapılandırılması (refactor) gerektiğini bilmek.
• Mevcut kodun ne zaman olduğu gibi bırakılması gerektiğini anlamak.
• Teknik borcu ciddi bir sorun haline gelmeden yönetmek.
• Projelerin gereğinden fazla karmaşık hale gelmesini engellemek.
• Takımı yavaşlatmak yerine iyileştiren kod incelemeleri yapmak.

Kıdemli bir front-end geliştiricisini jünyondan ayıran şey, kıdemlinin daha fazla kütüphane bilmesi ya da daha karmaşık kod yazabilmesi değildir.

Kıdemli geliştirici, kusurlu koşullarda makul kararlar alabilme yeteneğine sahiptir.

Gerçek dünya yazılım geliştirme nadiren ideal projelerde gerçekleşir.

Sıkıntı:

• Sıkı teslim tarihleri.
• Kısıtlı bütçeler.
• Farklı deneyim düzeylerine sahip geliştiriciler.
• Sık değişen gereksinimler.
• Eski (legacy) kod.
• Yönetim ya da müşteri baskısı.
• Üretimdeki sorunların hızla çözülmesi gerekliliği.
• Her hatanın doğrudan etkilenen gerçek kullanıcılar.

Bu makale, kıdemli bir front-end mühendisinin dört kritik alanına odaklanıyor:

• Teknik kararların nasıl alınacağı.
• Gereğinden fazla karmaşıklık (overengineering) nasıl önleneceği.
• Etkili kod incelemelerinin nasıl yapılacağı.
• Teknik borcun nasıl yönetileceği.

Kıdemli Geliştiriciler Teknik Kararlarını Nasıl Verir?

Teknik kararlar en "iyi" teknolojiyi seçme yarışması değildir

Yazılım geliştirmedeki yaygın hatalardan biri, teknik kararları en iyi teknolojiyi seçme yarışması olarak görmektir.

Ekipler genellikle şu soruları sorar:

En iyi durum yönetimi kütüphanesi hangisi? En iyi front-end çatısı hangisi? Mikro-frontend’ler kullanmalı mıyız? Kendi tasarım sistemimizi mi inşa etmeliyiz?

Sorun, bu soruların genellikle eksik olmasıdır.

Hiçbir teknoloji her durumda objektif olarak en iyisi değildir.

Daha iyi soru şu olmalıdır:

Bu proje, bu takım, bu aşama ve bu kısıtlar için en uygun teknoloji hangisi?

Redux bir projede mükemmel bir seçim olabilirken, başka bir projede gereksiz bir yük haline gelebilir.

Next.js, arama motoru optimizasyonuna (SEO) ve sunucu tarafı oluşturma (SSR) gereksinimi yüksek platformlar için güçlü bir seçim olabilir, ancak özel bir dahili panel için gereksiz karmaşıklık getirebilir.

Mikro-frontend’ler onlarca bağımsız mühendislik takımı olan organizasyonlar için akla yatkın olabilirken, üç geliştiriciden oluşan bir takım için felaket bir karar olabilir.

İç tasarım sistemi inşa etmek büyük bir platform için uzun vadeli bir yatırım olabilir, ancak dört hafta içinde lansman yapması gereken bir MVP için zaman kaybı olabilir.

Teknik bir karar, teknolojinin ne kadar modern ya da etkileyici göründüğüyle değil, gerçek problemi ne kadar etkili şekilde çözdüğüyle değerlendirilmelidir.

Aracı değil, problemi başlangıç noktası yapın

Deneyimsiz bir geliştirici genellikle bir teknolojiyle başlar:

Zustand kullanmak istiyorum. GraphQL denemek istiyorum. Projeyi mikro-frontend’lerle inşa etmek istiyorum. Clean Architecture’ı her yere uygulamak istiyorum.

Daha deneyimli bir geliştiriciyse problemi başlangıç noktası olarak alır:

• Hangi problemi çözmeye çalışıyoruz?
• Problemi kim yaşıyor?
• İşletme üzerindeki etkisi nedir?
• Bu mevcut bir problem mi yoksa gelecekteki varsayımsal bir problem mi?
• Problemin varlığına dair kanıtımız var mı?
• Bunu şimdi çözmemiz gerekiyor mu?
• Problemi çözebilecek en basit çözüm nedir?
• Bu çözüm takım için ne kadara mal olacak?

Herhangi bir teknoloji önerisi sunmadan önce problemi net bir şekilde tanımlayın.

Örneğin:

Redux’a ihtiyacımız var.

demek yerine:

Mevcut kullanıcı, izinler, alışveriş sepeti ve filtreler birkaç bileşen düzeyinden geçirilerek iletiliyor ve bunların props aracılığıyla yönetilmesi giderek zorlaşıyor.

diyebilirsiniz.

Artık problem netleşmiştir ve takım birkaç olası çözümü karşılaştırabilir:

• React Context.
• Zustand.
• Redux Toolkit.
• Bileşen yeniden yapılandırma.
• Sunucu durumunu React Query’e taşımak.
• Filtreleri URL’e taşımak.
• Bazı verileri yerel olarak tutmak.

Takım, asıl problemin durum yönetimi kütüphanesi eksikliği olmadığını keşfedebilir.

Gerçek problem, farklı durum kategorilerinin birbirine karıştırılması olabilir.

Front-end geliştirmedeki teknik karar türleri

Kıdemli bir front-end geliştiricisi birkaç düzeyde teknik kararlar alır.

1. Teknoloji seçim kararları

Örnekler şunlardır:

• React, Vue ya da Angular mı?
• TypeScript mi yoksa JavaScript mi?
• Next.js mi yoksa istemci tarafı React uygulaması mı?
• REST mi yoksa GraphQL mi?
• Redux, Zustand ya da Context mi?
• Tailwind CSS, CSS Modülleri ya da CSS-in-JS mi?
• Mevcut bir UI kütüphanesi mi yoksa iç tasarım sistemi mi?

2. Mimari kararlar

Örnekler şunlardır:

• Proje nasıl yapılandırılmalı?
• Dosyalar teknik tipe mi yoksa özelliklere göre mi organize edilmeli?
• İş mantığı nereye yerleştirilmeli?
• API katmanı nasıl tasarlanmalı?
• Hatalar nasıl ele alınmalı?
• Kimlik doğrulama nasıl uygulanmalı?
• Yetkilendirme ve izinler nasıl temsil edilmeli?

Hatırlayın: en modern ya da etkileyici teknoloji değil, gerçek problemi en etkili şekilde çözen teknoloji seçilmelidir.

Sonuç: İyi Kararlar, Sağlam Temeller

Kıdemli front-end geliştiriciler, ideal olmayan koşullarda bile akıllıca kararlar alabilme yetenekleriyle öne çıkarlar. Onların başarısı, sadece kullandıkları araçlarda değil, bu araçları ne zaman ve nasıl kullanacaklarını bilmekte yatar.

İyi bir front-end mühendisi, projenin gereksinimlerini teknik yetenekleriyle dengeleyebilir. Gereksiz karmaşıklık tuzağına düşmeden, hem bugünkü hem de gelecekteki ihtiyaçları karşılayacak çözümler üretebilir.

Unutmayın: teknoloji bir araçtır. Asıl hedef, kullanıcıların gerçek sorunlarını çözmektir. İyi kod yazmak önemli, ancak doğru kararları vermek daha da önemlidir.