Angular Geliştiriciler Nasıl İşe Alınır: Aranacak Temel Beceriler ve Bilgi

Yüksek düzeyde ölçeklenebilir mimarisiyle birçok web geliştirme ekibi, verimli, karmaşık tek sayfalık uygulamalar oluşturmak için Angular'ı seçer. Ancak, Angular geliştiricilerini işe almak, söylemek yapmaktan daha kolaydır. Dışarıda pek çok aday olsa da, sorunsuz bir geliştirme deneyiminin anahtarı, yüksek kaliteli kodlama standartlarını karşılamak için en iyi uygulamaları ve gelişmiş teknikleri uygulayan harika bir Angular geliştirici bulmaktır.

Google'ın popüler ön uç çerçevesiyle ilgili temel kavramları anlamak, sizi potansiyel müşterilerle güvenle görüşmeye ve bir sonraki seviyeye bir kod tabanı getirmeye çalışan en yüksek kalibreli geliştiricileri işe almaya hazırlayacaktır. Bu makale, birinci sınıf bir Angular profesyonelinin sahip olması gereken önemli beceri ve bilgileri ortaya koymaktadır.

Not: Bu kılavuz, artık AngularJS olarak bilinmeyen en son Angular sürümleri için geçerlidir - “Angular”, Angular 2'den beri uygulanmaktadır. Eski bir AngularJS web uygulaması projesinin (1.x şube), Büyük Bir AngularJS Geliştiricisi Nasıl İşe Alınır bölümüne bakın.

Angular'ın Temel İşlevlerini Bilin

Angular çerçevesi TypeScript üzerinde çalışır ve bir uygulamanın içine yazılan tüm kodlar JavaScript'e aktarılır. TypeScript, düz JavaScript'i derleyen bir JavaScript üst kümesidir . Açısal kod bu üst küme ile temsil edilir.

Pek çok geliştirici Angular'ı öğrenir ancak JavaScript, TypeScript, HTML veya CSS'nin gerektirdiği temel kavramları iyi anlamaz. Bu temeller eksikse, geliştiriciler uygun olmayan geçici çözümler kullanmaya ve dolayısıyla bir projenin teknik borcunu çoğaltmaya eğilimlidir.

Bu nedenle, adaya HTML5 ve CSS3 bilgisi olup olmadığını sorun. İyi bir Angular geliştiricisinin, ekipte başka biri olduğu sürece bir HTML veya CSS uzmanı olması gerekmez, ancak bu temel kavramları anlamaları gerekir:

• esnek kutu
• SCSS değişkenleri
• Bir span ve bir div arasındaki fark
• CSS'deki önemli sınıflar
• Öznitellikler

Açısal geliştiriciler, JavaScript ve TypeScript hakkında sağlam bir anlayışa ve ayrıca bazı HTML ve CSS becerilerine sahip olmalıdır.

Cıvıldamak

Kodlamadan Önce Tasarım

İyi tasarım, iyi uygulama mimarisinin anahtarıdır. Adayınıza tasarımlarını nasıl yaptıklarını sorun ve düşüncelerini şu ideal düşüncelerle karşılaştırın:

• Kod nereye gidecek? Yeni bir kütüphane veya modüle ihtiyaç var mı?
• Girdiler ve çıktılar nelerdir?
• Yeniden kullanılabilir bileşenler veya yönergeler olmalı mı?
• Devlet nereye gidecek? (Aşağıda Devlet Yönetimi başlığı altında daha ayrıntılı tartışılmıştır.)
• İş mantığı nereye, yani hangi hizmete gidecek?
• Belirli bileşenler, esasen bir UI tasarım sistemi oluşturmak için kütüphaneler arasında paylaşılabilir mi?

Belirli bir tasarımın tüm özellikleri, adayın tasarım yapma alışkanlığında olup olmamasından daha az önemlidir. Tüm tasarımlar geçicidir, bu nedenle çoğu uygulama için belgeler, resmi belgeler gerekmedikçe beyaz tahtadaki bir eskizin fotoğrafı kadar basit olabilir. Daha sonraki bir aşamada geliştirici, tüm parçaların birbiriyle nasıl ilişkili olduğunu netleştirmek için teknik tasarımı koddan (doğru araçlarla) oluşturabilir.

Açısal Uygulama Yaşam Döngülerini Anlama

Adayınıza Angular bileşen yaşam döngüsü hakkında ne bildiklerini sorun. Cevapları üç yaşam döngüsü kancası içermelidir: ngOnInit , ngOnChanges ve ngOnDestroy . Adlarından da anlaşılacağı gibi, bileşen başlatılırken ngOnInit çağrılır, bileşen yok edildiğinde ngOnDestroy çağrılır ve bir öznitelik değiştiğinde ngOnChanges çağrılır. İkincisi, ngOnInit önce gerçekleşebilir - öznitelik, bileşen tamamen başlatılmadan önce zaten atandığında, ngOnChanges önce ngOnInit .

Aday ayrıca ngDoCheck , ngAfterContentInit , ngAfterContentChecked , ngAfterViewInit ve ngAfterViewChecked hakkında bilgi sahibiyse, bileşenler için tüm değişiklik algılama kancalarını bilir ve bir adım öndedir.

Kancalardan herhangi biri hakkında sorulacak iyi bir takip sorusu: "Bu değişiklik tespiti ne zaman gerçekleşir?"

Daha az bilinen bir yaşam döngüsü, yalnızca bir kancaya sahip olan sağlayıcı yaşam döngüsüdür: ngOnDestroy . Bu, yalnızca sağlayıcı bileşen düzeyinde eklendiğinde çağrılır, bu durumda bileşenle birlikte yok edilir. Kök veya modül düzeyinde sağlanırsa, asla yok edilmez.

Bir sağlayıcının kurucusu, sağlayıcı ilk kez kullanıldığında çalıştırılacaktır, bu nedenle kurucunun hiçbir zaman çalıştırılmaması mümkündür. Adayınızı bu olasılık hakkında sorgulayın - gerçek dünya senaryolarında, genellikle gözden kaçan bir hata kaynağı olabilir!

Sağlam Reaktif Programlama Bilgisi

Angular bir uygulamada, reaktif programlama genellikle anlaşılması en zor kısımdır. Birçok kişi, bir tarifin adımları gibi, anlaşılması ve üzerinde çalışılması daha kolay olduğunu varsayarak, bir kod parçasını programlamaya başladıklarında prosedürel bir şekilde düşünür.

Reaktif programlama, kontrol edemediğimiz şeylere tepki vermeyi içerir ve bu öngörülemeyen bir sırada gerçekleşebilir. Her gün olaylara bu şekilde tepki versek de (örneğin, önümüzdeki araba aniden durduğunda fren yapmak gibi), birçok geliştirici programlamaya reaktif bir yaklaşım benimsemeyi zor buluyor.

Ancak, bir Angular uygulamasında olan her şey reaktif programlamaya dayanır. Örneğin, bir Angular alışveriş uygulamasındaki bazı tepkisellik örnekleri şunları içerebilir:

• Kullanıcı oturum açtığında, alışveriş sepeti simgesindeki numara güncellenir ve menü öğeleri daha özel seçeneklere dönüşür.
• Kullanıcı bir kategoriye gittiğinde, ürünler seçilen kategoriye göre güncellenir.
• Kullanıcı sepetine bir ürün eklediğinde, alışveriş sepeti simgesi ürün sayısıyla güncellenir.
• Bir öğe stokta kalmadığında (arka uçtan mevcut stok miktarlarını izleyen bir dinleyici aracılığıyla kaydedilir), sayfa kullanıcı arabirimi güncellenir.

Bunların otomatik olarak gerçekleştiğini ve görünmesi için sayfanın yenilenmesi gerekmediğini unutmayın. Bir görüşmede adaydan geliştirdikleri bir uygulamada reaktif programlamayı nasıl uyguladıklarını açıklamasını isteyin. Aday, sayfayı yenilemeyi veya bir bileşeni yenilemek için ChangeDetectorRef.detectChanges() manuel olarak çağırmayı içeren çözümleri açıklıyorsa, bunun sarı bir bayrak olduğunu düşünün.

Açısalda Gözlenebilirlerle İlgili Tuzaklar

Daha az deneyimli geliştiriciler bazen Angular uygulamalarında yazdıkları kodun yürütülmediğini görebilirler. Deneyimli Angular geliştiricileri ortak bir neden belirleyebilir: Reaktif programlamada ana dayanak nesne türü olan Observable üzerinde abonelik yoktur. Yalnızca bir abonelikle arka uç aramaları veya diğer reaksiyonlar yürütülür.

Abonelikler oluşturmanın iki yolu vardır: Geliştiriciler zaman async boruyu veya subscribe olma yöntemini kullanabilir. Ancak bir uyarı var: Geliştiriciler manuel bir abonelik yaparlarsa ( subscribe olma yöntemiyle), Observable manuel olarak yok edilmesi gerekecektir (varsayılan olarak gerçekleştiği bazı uç durumlar olmasına rağmen). Geliştiriciler, Observables çeşitli şekillerde yok edebilir:

• Mümkün olduğunda zaman async boruyu kullanmak (bu, bileşene artık ihtiyaç duyulmadığında Observable yok eder).
• Bileşenin kullanım süresinin sonunda ( ngOnDestroy ) bir Observable unsubscribe yöntemini kullanarak manuel olarak abonelikten çıkma.
• Daha bildirimsel bir şekilde, pipe operatörü içindeki takeUntil operatörü ve bir özne (yani, destroy$ adında bir şey) kullanarak. Bu durumda, özne, bileşenin kullanım ömrünün sonunda ( ngOnDestroy ) destroy$.next() yayar. Yok etme olayını aldıktan sonra, takeUntil operatörü artık Observable'dan bağlı olduğu olayları kabul etmeyecek ve böylece abone mantığı artık tetiklenmeyecektir. Bir örnek için, 2. bölümdeki takeUntil operatörüne bakın. take ve takeWhile operatörleriyle benzer işlevler ortaya çıkarılabilir.
• Angular uygulamaları Ivy derleyicisine geçtiği için ek açıklamaları da kullanabiliriz. Yok until-destroy kitaplık veya SubSink gibi başka bir üçüncü taraf kitaplığı, bir bileşen yok edildikten sonra gözlemlenebilirlerden sorunsuz bir şekilde çıkmak için kullanılabilir.

Reaktif programlama ile ilgili bir başka potansiyel sorun, bellek sızıntılarından ve arka uca yapılan çoklu çağrılardan kaynaklanır. Adaya bu sorunların farkında olup olmadıklarını ve normalde bunları nasıl çözeceklerini sorun. Yukarıda açıklandığı gibi Observable s aboneliğinden çıkılmaması durumunda bellek sızıntıları meydana gelebilir. Bir arka uç aramasında birden çok abonelik nedeniyle arka uca yapılan birden çok arama, Observable paylaşılarak çözülebilir.

Durumu ve Nasıl Kullanılacağını Bilin

Tüm tek sayfalı uygulamaların bir durumu vardır ve bu durum ön uçta bir yerde mevcuttur. Ama tam olarak devlet nedir? Mevcut kullanıcı deneyimine özgü tüm değişkenleri içerir. Örneğin, ad ve profil resmi URL'si, seçilen belirli bir menü öğesi veya alışveriş sepeti öğeleri listesi gibi bir ekran listesi gibi kimliği doğrulanmış kullanıcı ayrıntıları.

Bir Angular uygulamasında, dikkate alınması gereken üç ana ön uç durum türü vardır:

Durumun ne olduğunu ve ne zaman yüklenmesi veya yeniden yüklenmesi gerektiğini iyi anlamak, Angular geliştiricileri işe alırken aranması gereken temel becerilerden biridir. Bu, ekibinizin aday tarafından yazılan bazı örnek kodları inceleme fırsatı olup olmadığını araştırmak için en önemli bölgedir. Başvuru sahibi devlet yönetimi için bir kütüphane kullanıyorsa:

• NgRx, Akita, NgXs veya benzer durum yönetimine özgü kitaplıkların kullanımına bakın.
• Ardından ilgili kodda effects , action , reducer , store , selector için bildirim olup olmadığına bakın.

Örnek olarak NgRx'teki (Akita ve diğer kütüphanelerinkine benzer) uygulama durumunun genel akışına bakalım:

Geliştirici hizmetlerle kendi durumunu yaratırsa, durum yönetimindeki yeterliliklerini belirlemek daha zor olabilir:

• state veya effect kelimelerinin referanslarını arayın.
• Kodun bir eyleme tepki verip vermediğine bakın, örneğin kullanıcı A Düğmesine basarsa, metin B Ekranında değişmelidir.

Mülakatçıların Devlet Hakkında Soracakları Sorular

Bir başvuru sahibinin kodunu inceleyerek bilmeniz gereken her şeyi her zaman öğrenemezsiniz. Potansiyel Angular geliştiricilerinin durumu ne kadar iyi anladığını araştırmak için bu sorguları soru listenize ekleyin:

• state nerede ve nasıl kullandınız? Bu, onların devletle olan deneyimlerini anlamak için sağlam bir başlangıç ​​noktasıdır; ayrıntıları araştırmaktan korkmayın.
• Kütüphane kullanıp kullanmamaya nasıl karar veriyorsunuz? Bir uygulamaya bir durum kitaplığı eklemenin her zaman yararlı olmadığını biliyorlarsa, bu iyiye işarettir.
• Devletin içine ne koyardınız, nereye koyardınız ve devlet yönetim sisteminden nasıl yararlanırsınız? “Her şeyi global uygulama durumuma koyuyorum” derlerse, bu, geliştiricinin böyle bir sistemin bir uygulamaya verebileceği olumsuz yan etkilerden haberdar olmadığının kesin bir işaretidir.

Çeşitli durum türlerini anlayan geliştiriciler, bu yan etkilerden kaçınacaktır:

• Yalnızca bir bileşen için geçerli olan durum, diğer bileşenler tarafından değiştirilebilir veya bozulabilir.
• Veriler depoda yuvalanmıştır, bu nedenle verileri takip etmek zorlaşır ve veriler insan tarafından okunamaz hale gelir (hata ayıklama, veri alışverişi vb. amaçlar için).
• Bir formun içindeki verileri düzenlemek, onu zaten uygulamanın geri kalanına yayar, oysa yalnızca verileri kaydederken mağazaya itilmesi gerekir; başka bir deyişle, uygulamanın geri kalanı geçersiz veriler kullanıyor olabilir.

Global mağazanın düzensiz bir karmaşaya dönüşmesi uzun sürmez ve dağınıklığın her bir parçasının nereden kaynaklandığı net değildir, bu da hata ayıklamayı ve bakımını zorlaştırır.

Otomatik Testin Önemini Anlamak

Otomatik test, herhangi bir Angular web uygulaması için kod kalitesi kadar önemli kabul edilmelidir. Programcıların test yazmalarının en önemli nedenlerinden biri kodlarını belgelemektir: Şirkete yeni bir geliştirici katılırsa, iş mantığı ve belirli UI akışları, test paketinin beklentilerine göre net olmalıdır. Ayrıca, otomatik test, geliştirmenin başlarında hataları ortaya çıkarır.

Potansiyel Angular geliştiricinize üç test sorusu sorun:

• Test hakkında düşünceleriniz nelerdir? Otomatik testi umursamayan herhangi bir adayın değerlendirilmesi durdurulmalıdır. Test odaklı geliştirmeyi (TDD) kullanmamayı tercih etseler bile, otomatik testin değerini göremeyen geliştiriciler, şirketinizin manuel test süresine ve daha da kötüsü, bir uygulamada değişiklik yapıldığında gerilemeler göründüğünde son kullanıcı kesinti süresine mal olur. mesai.
• Test ederken nelere dikkat ediyorsunuz? Harika bir Angular geliştiricisi, bir alana değerler atayabilmek veya belirli test kapsamı ölçümleri (yani, %85 kapsam) için çabalamak gibi temel verileri test etmek yerine, temel iş mantığını test etmeye odaklanmalıdır.
• Genellikle daha fazla E2E testi veya daha fazla birim testi var mı? Neden? Niye? Angular uygulamaları, ön uç uygulamalar olarak iki ana tür otomatik testten yararlanabilir: birim testleri ve uçtan uca (E2E) testler. Tipik olarak, bir test paketinde birçok birim testi ve daha az E2E testi bulunur. Birim testleri küçüktür, bu nedenle yazmaları ve yürütmeleri hızlıdır. E2E testleri daha büyük ve daha yavaştır. Adil uyarı: Tüm geliştiriciler, korunacak birim ve E2E testlerinin doğru oranı konusunda aynı görüşe sahip olmayacaktır. Gerçekte, test edilen uygulamanın karmaşıklığına bağlıdır ve o zaman bile cevap bir dereceye kadar tartışmalıdır.

Açısal Test Çerçeveleri

Açısal geliştiricilerin, otomatikleştirilmiş test çerçeveleri söz konusu olduğunda seçenekleri vardır. Birim testi, Jest veya Jasmine ve Karma aracılığıyla yapılabilir. Her Angular geliştiricisi Jasmine ve Karma'ya aşina olmalıdır. Jest de yaygındır; genellikle daha hızlıdır ve daha gelişmiş test seçenekleri sunar.

Bir Angular uygulaması için E2E test standardı, Angular CLI tarafından oluşturulan varsayılan araç olan İletki'dir. Bir alternatif, birçok seçeneğe sahip gelecek vaat eden bir E2E test çerçevesi olan Cypress'tir.

Adayın en az bir birim test çerçevesi ve bir E2E test çerçevesi hakkında derinlemesine bilgi sahibi olduğundan emin olun.

En Son Angular Sürümlerden Haberdar Olun

Great Angular geliştiricileri, çeşitli nedenlerle geliştirme aşamasında her zaman en son sürümü kullanmayabilir, ancak değişikliklerden haberdar olabilmeleri ve geçiş yapmaya hazır olabilmeleri için Angular sürüm programını bilmeleri gerekir. Bunu değerlendirmenin bir yolu, adaya Angular'ın yayın stratejisine aşina olup olmadıklarını sormaktır. Angular, her altı ayda bir, genellikle Şubat ve Mayıs aylarında büyük bir sürüm yayınlamayı hedefliyor. Bir Angular sürümü, çıkış tarihinden sonraki ilk altı ay boyunca "aktif destek" altındadır ve çıkış tarihinden sonraki 12 ay boyunca "uzun vadeli destek" altındadır. Bu, diğer bazı teknolojilere kıyasla oldukça dar bir zaman çizelgesidir ve güncel kalmayı özellikle önemli kılar.

Ayrıca Angular'ın en son sürümü hakkında biraz araştırma yapabilir ve adayınıza bu yeni özelliklerin faydalarını sorabilirsiniz. Örneğin, Angular 14 piyasaya sürüldüğü zaman, adaya şunları sormuş olabilirsiniz:

• Açısal modüllere olan ihtiyacı azaltan bağımsız bileşenler. Bağımsız bileşenler mevcut herhangi bir NgModule içinde bildirilmez ve doğrudan kendi bağımlılıklarını yönetirler. Sonuç olarak, bir ara NgModule ihtiyaç duymadan doğrudan bunlara güvenilebilir.
• Angular Reaktif Formlar için varsayılan olarak katı yazmayı ayarlayan Angular 14'teki bir başka önemli güncelleme olan yazılan formlar. Yazılan formlar, FormControls , FormGroups ve FormArrays içindeki değerlerin tüm API yüzeyinde tip açısından güvenli olmasını sağlar. Bu, özellikle iç içe geçmiş karmaşık durumlar için daha güvenli formlar sağlar.

Ön Uç Ekibiniz İçin Bir Sonraki Büyük Açısal Geliştirici

Her web geliştirme projesi ve ekibi farklıdır ve bir Angular geliştiricisinin beceri ve bilgisinin çeşitli yönlerine farklı önem verir. Ancak burada sunduğumuz temel konuları anlamak, işe alım yöneticilerinin işe alım sürecine – hatta daha teknik değerlendirmelerde bile – anlamlı bir şekilde katılmalarını sağlayacaktır.

Toptal Engineering Blog, bu makalede sunulan teknik kavramları ve diyagramları gözden geçirdiği için Ramazan Yıldız'a teşekkürlerini sunar.