Tam Yığın Geliştirme

Nov 25 2022
Full-stack geliştirici terimi son zamanlarda giderek daha sık kullanılmaktadır. Özellikle ekip yapısı, işe alma gereklilikleri veya bir bireyin saf mükemmelliği hakkında çıkarım yapmakla ilgili tartışmalarda.

Full-stack geliştirici terimi son zamanlarda giderek daha sık kullanılmaktadır. Özellikle ekip yapısı, işe alma gereklilikleri veya bir bireyin saf mükemmelliği hakkında çıkarım yapmakla ilgili tartışmalarda.

Unsplash'ta Mike Marrah'ın fotoğrafı

Bir özgeçmişte bu tür bir ifade gördüğümde veya birinin kendisini tam yığın olarak tanımladığını duyduğumda aklıma bir dizi soru geliyor:

  • Tam yığın geliştirme ile ne demek istiyorsunuz?
  • Hangi yığının üzerinde ustalık iddia ediyorsun?
  • Elementlerin her biri için bilginiz ne kadar kapsamlı? Ne kadar dolu olması gerekiyor?
  • Tam yığın geliştirici gerçek bir şey mi? Gerçekten varlar mı?
  • Varsa neden faydalıdırlar?
  • Tam yığın, her işin ustası, hiçbirinin ustası demenin başka bir yolu mu?

Arka fon

Ayrıntılara girmeden önce, neyi geliştirmeyi ve sunmayı amaçladığımızı tanımlamaya değer.

Dizüstü bilgisayarınızda çalışan bir PoC için eksiksiz bir geliştirici olduğunuzu iddia etmek, bu çözümün her parçasını geliştiren tek kişi olduğunuz için muhtemelen adil bir açıklamadır. Ölçek çok küçüktür ve kötü tasarım veya geliştirmenin etkisi çok sınırlıdır. Temel olarak, CIO'ya bir saatlik demo için çalışabildiği sürece, bir hizmet sunmayan bir konsepti kanıtlıyorsunuz, sorun yok.

Çözümü, canlı müşteri verilerini işleyen ve içgörüler / iş değeri oluşturulmasını sağlayan veriler üreten bir üretim sistemi olarak tanımlarsak, durum farklıdır ve kodlama hatalarının veya kötü uygulamaların etkisi çok daha yüksektir.

Bu yazının amaçları doğrultusunda, büyük miktarlarda (günde 10 GB) gerçek müşteri verilerini (PII dahil) işleyen ve en az 2 9 saniye kullanılabilirlik ile temel iş hizmetleri sağlayan bir sistemi ele alacağız.

Full-stack geliştiriciler neden değerlidir?

Bu tür insanların varlığı bir yana bırakıldığında sağladıkları faydalar apaçık ortadadır. Herhangi bir dış destek olmaksızın bir çözüm tasarlayabilir, inşa edebilir ve çalıştırabilirler; bu, zaman alıcı ve hataya açık tasarım atölyelerinin, bileşen entegrasyonlarının, test döngülerinin ve operasyon devir teslimlerinin büyük ölçüde ortadan kaldırıldığı anlamına gelir. Çözümü tasarlayabildiğiniz, oluşturabildiğiniz ve çalıştırabildiğiniz için güvenlik, platform, DB, operasyonlar, ... KOBİ'ler arasında bir toplantı veya daha kötüsü bir dizi toplantı planlamanıza gerek yoktur. Bu tanrı (küçük g) benzeri geliştiricilerin az bir kısmı, büyük bir işlevler arası ekibin işini teslim edebilir ve devretme ek yükünü ortadan kaldırdığı için teslimat da çok daha hızlıdır ve hataya daha az eğilimlidir.

Öyleyse, bu açık faydalara dayanarak neden tüm BT organizasyonlarında bu insanlardan oluşan daha fazla ekip yok? Şirketler neden bu ninja ekiplerini oluşturmak için aktif olarak işe alım ve eğitim yapmıyor? Batman veya Tony Stark'ın geliştirme eşdeğerlerinin gerçekten var olmadığı için mi?

Bu soruları cevaplamak için (çok) basitleştirilmiş bir yığının nasıl göründüğüne bakmamız gerekiyor.

Basitleştirilmiş Yığın

Sadeleştirme amacıyla platform altyapısını dışarıda bırakıyorum.

Yukarıdaki unsurlara bakıldığında, her katmanda uzman olmanın zor olacağı açıktır. Ancak, her katmanda HER ŞEYİ bilmem gerekmediğini varsayarsak, gereken bilgiyi azaltabilir ve yine de tam yığın olarak kabul edilebilir miyim? Ön Uç Uygulamasını örnek bir etki alanı olarak alırsak, Android ve iOS'u kolayca kaldırabilir ve yalnızca bir web kanalına odaklanabilir ve belki daha da geliştirebilir ve React ile sınırlı olduğunu söyleyebiliriz, bu nasıl yardımcı olur?

Kısıtlanmış kapsamımıza göre, React web uygulamaları hakkında neleri bilmem gerekiyor?

Öncelikle, tek sayfa uygulamalarının nasıl çalıştığını, özellikle bir web uygulamasını oluşturmak, hatalarını ayıklamak ve çalıştırmak için gereken temel ilkeleri ve npm, webpack, içerik yönetimi, tepki devtools, UX yönergeleri gibi ilgili araçları anlamanız gerekecek.

Ayrıca, üçüncü şahıslar tarafından sağlanan işlevlere, örneğin malzeme kullanıcı arabirimi, redux, önyükleme, … ve npm gibi bir paket yönetimi çözümüne (güvenlik açıklarının yönetilmesi dahil - tipik olarak bir DevOps değerlendirmesidir, sonraki notlara bakın) çok aşina olmanız gerekir.

Peki ya performans, örneğin ilk içerikli boyama zamanı, etkileşim zamanı, blokaj zamanı, ... Yardımcı olması için ilerici bir web uygulaması mimarisini ve/veya hizmet çalışanlarını benimsemeli miyim? Performans faktörlerini ve çeşitli temel kalıpların, React DevTools veya Lighthouse gibi analizi desteklemek için araçların kullanılmasına nasıl yardımcı olabileceğini anlamanız gerekecektir.

Erişilebilirlik, uygulamanın dahili veya harici olarak sunulmasından bağımsız olarak tüm uygulamalar için bir zorunluluktur. WCAG yönergelerine uygunluğu nasıl sağlayabilirim?

Özet olarak, sadece Ön Uç katmanında bilinecek çok şey var ve muhtemelen bu, onu hafif tutuyor. Kalan katmanlar farklı değildir ve çoğu durumda karmaşıklık artar. Ve işleri daha da kötü hale getirmek için, mimari kalıplar ve ilkeler, en iyi uygulamalar ve çerçeveler BİRLEŞMEYİN .

Öyleyse, her katman için kalıpları, standartları, en iyi uygulamaları ve uygulamalı becerileri patlamadan kafama sıkıştırmayı başardığımı varsayarsak, başka ne bilmem gerekiyor? Gerekli herhangi bir destek yeteneği var mı?

Destekleyici Yetenekler

Teknoloji yığınının yanında, çözümün tüm bileşenlerini tasarlamak, oluşturmak, teslim etmek ve çalıştırmak için gereken bir dizi destekleyici yetenek vardır.

Mimarlık ve Yazılım Mühendisliği

Herhangi bir dilde/çerçevede iyi bir uygulama oluşturan katmanlar boyunca mimari tasarımı desteklemek için temel beceriler seti

  • SOLID (Tek sorumluluk, Açık/Kapalı, Değiştirme, Arayüz ayrımı, Bağımlılık tersine çevirme)
  • yeniden kullanılabilirlik, sürdürülebilirlik, taşınabilirlik, genişletilebilirlik, …
  • Yatay ve dikey ölçeklendirme
  • Kodlama yapısı
  • Kerestecilik
  • Kod incelemeleri

Yukarıdaki basitleştirilmiş yığındaki katmanların ve bileşenlerin her biri (tarayıcı tarafından uygulandığı veya istemci tarafı olduğu için tipik olarak bizim kontrolümüz dışında olduğu için bir web kanalı perspektifinden Ön Uç göz ardı edilir) güvenlik açısından dikkatli bir şekilde ele alınmasını gerektirir. Örneğin

  • API'ler : TLS, DDoS, kimlik doğrulama ve yetkilendirme, COR'lar, içerik güvenlik politikası, …
  • Mikro hizmetler : TLS (MA dahil), erişim kontrolleri, gizli yönetim, kullanıcı girişi doğrulaması, …
  • Veri : erişim kontrolleri, bekleyen şifreleme, anahtar yönetimi, ağ güvenlik grupları ve alt ağlar, …
  • Platform (ek) : ağ güvenliği, sabit bileşen yapılandırmaları, örneğin ChefInspec

Tüm geliştiricilerin temel test becerilerine ihtiyacı vardır, kendi özelliklerinizi test edememek için hiçbir mazeret yoktur. Ve tam yığın bir ortamda bu, yukarıdaki şemadaki her bileşen anlamına gelir.

Farklı test türlerini ve aşamalarını anlama ve uygulayabilme (kendi ödevinizi işaretlemeden):

  • İşlevsel ve işlevsiz
  • Kara kutu vs beyaz kutu
  • Birim, entegrasyon, sistem, kullanıcı kabulü, gerileme, duman, …

Sürekli Entegrasyon ve Sürekli Dağıtım boru hatlarının geliştirilmesi ve sürdürülmesi

CICD için temel etkinleştiriciler genellikle merkezi / özel bir ekip tarafından oluşturulur, ancak herkes en azından ardışık düzenleri güncelleyebilmeli ve sürdürebilmelidir. (Evet, biliyorum; bir DevOps ekibiniz varsa DevOps yapmıyorsunuz ama birçok kuruluş yapıyor)

Aşağıdaki gibi araçları kullanmak:

  • Jenkins, TravisCI, Balon Balon
  • GitHub, Bitbucket
  • Sonarqube
  • zaproksi
  • Veracode, Snyk
  • Docker, Çapa, Liman

"Sen yap, sen çalıştır" yaklaşımını göz ardı edersek, tam yığın bir geliştiricinin operasyonlarla ilgili gereksinimleri önemli ölçüde basitleştirilir.

Çalışabilir olması için uygulamanızı oluşturmaya odaklanılması gerekir. Gerekli tüm teşhis kancaları, olay günlükleri ve çalıştırma ekibinin geliştirme ekibinin yardımına ihtiyaç duymadan sorunları öncelik sırasına koyabilmesi ve potansiyel olarak çözebilmesi için bir çalıştırma kitabı dahil

Tabii ki, yukarıdaki yeteneklerin sorumluluğu muhtemelen kuruluşunuzun nasıl yönetildiğine bağlı olacaktır - belki geliştirme kesinlikle yalnızca birim testidir veya güvenlik testi dışında tüm testler scrum ekibi içindedir. Ancak API geliştirme ve CICD ardışık düzen yönetimini başkalarından destek almadan üstlenebilirseniz, bu çok zaman kazandıracaktır.

Teknoloji yığınının katmanlarında olduğu gibi, tam yığın durumunu talep etmek için gereken destekleyici yeteneklerin kapsamı çok geniştir.

Çözüm

Gerçek tam yığın geliştiricinin bir efsane olduğuna inanıyorum (büyük ölçüde) ve yığın 1980'lerde 6502'de birleştirici çalıştırmanın ötesine geçtiğinden beri. K8 düğümünde çalışan Node'da yazılmış birkaç API ile ön uç kurmanın ve çalıştırmanın tam donanımlı bir geliştirici olduğunuz anlamına geldiğini düşünerek kendinizi kandırmayın.

Bu kişiler, yalnızca farklı teknik alanlarda sahip olmaları gereken bilgi ve deneyim derinliği nedeniyle değil, aynı zamanda bu kapsamın sürekli artması nedeniyle efsanevidir - her yıl, her alanda teknolojilerde ve modellerde büyük gelişmeler yaşanmaktadır. bugüne kadar çok, çok zor.

Ayrıca, bu kişiler genellikle çoğu BT kuruluşunun onlara ödeyebileceğinden daha fazla para isteyeceklerdir, ancak gerçekten tam yığınlarsa buna değer - reklamda olduğu gibi.

Ulaşmayı umabileceğiniz en iyi şeyin, seçtiğiniz alanda (bu katman içinde sınırlı bir teknoloji yığını olan belirli bir katman) ustalık ve en iyi ihtimalle, diğer alanlardaki bilgi eksikliğinizin yeterliliği ve farkındalığı olduğunu öneriyorum.

Bir ekibin başarılı olmasının daha iyi bir yolu, tam yığın geliştiricileri işe almaya veya eğitmeye çalışmak yerine, örneğin ön uç, arka uç, veritabanı vb. yüksek kaliteli geliştirmeyi desteklemek için çok net arayüzler, standartlar, en iyi uygulamalar ve çerçeveler ile diğer alanlara örtüşen/çapraz bilgi ile yığın sınırlı olacaktır. Bireyler, uzman düzeyinde birden fazla alanı kapsayabiliyorsa bu harika ama benim deneyimime göre bu gerçekten bir istisna.

Bonus yorum:

Bir veri bilimi geliştiricisi olarak "daha" başarılı olmak için neleri bilmeniz gerekiyor (orada veri bilimcisi terimi yerine geliştirici kelimesinin kullanıldığına dikkat edin - zaten iyi bir veri bilimcisi olduğunuzu varsayıyorum? Ve değilseniz, ben orada sana yardım edemem!). Bu geliştiriciyi, bu alanların her birinde geliştirme yapabilen ancak Veri Bilimi bölümünde* uzman olan biri olarak tanımlarsak, yani yukarıda belirtilen azaltılmış hedefim, daha geniş yığının sanayileştirilmesi bir Makine Öğrenimi Mühendisinin yapacağı bir şeydir… başka bir zaman için

*basitleştirilmiş yığınımızda, modelin mikro hizmetler bitine girdiğini söyleyebiliriz… biraz