วิธีการจ้างนักพัฒนาเชิงมุม: ทักษะหลักและความรู้ที่ควรมองหา

ด้วยสถาปัตยกรรมที่ปรับขนาดได้สูง ทีมพัฒนาเว็บไซต์จำนวนมากเลือก Angular เพื่อสร้างแอปพลิเคชันหน้าเดียวที่มีประสิทธิภาพและซับซ้อน แต่การจ้างนักพัฒนา Angular นั้นพูดง่ายกว่าทำ แม้ว่าจะมีผู้สมัครจำนวนมาก แต่กุญแจสู่ประสบการณ์การพัฒนาที่ราบรื่นคือการหานักพัฒนา Angular ที่ยอดเยี่ยม ซึ่งใช้แนวทางปฏิบัติที่ดีที่สุดและเทคนิคขั้นสูงเพื่อให้ได้มาตรฐานการเข้ารหัสคุณภาพสูง

การทำความเข้าใจแนวคิดหลักเกี่ยวกับเฟรมเวิร์กส่วนหน้าที่เป็นที่นิยมของ Google จะเตรียมคุณให้พร้อมสัมภาษณ์ผู้มีแนวโน้มจะเป็นลูกค้าและจ้างนักพัฒนาที่มีความสามารถสูงสุด ผู้ที่มุ่งมั่นที่จะนำ codebase ไปสู่อีกระดับ บทความนี้กล่าวถึงทักษะและความรู้ที่สำคัญที่มืออาชีพระดับพรีเมียมของ Angular ควรมี

หมายเหตุ: คู่มือนี้ใช้กับ Angular เวอร์ชันล่าสุด ซึ่งไม่เป็นที่รู้จักในชื่อ AngularJS—“Angular” อีกต่อไปแล้ว ตั้งแต่ Angular 2 หากคุณกำลังจ้างงานสำหรับการบำรุงรักษาหรืออัปเกรดโครงการเว็บแอปพลิเคชัน AngularJS รุ่นเก่า (1.x สาขา) ดูวิธีการจ้าง Great AngularJS Developer

รู้หน้าที่หลักของ Angular

กรอบงานเชิงมุมทำงานบน TypeScript และโค้ดทั้งหมดที่เขียนภายในแอปพลิเคชันจะถูกแปลงเป็น JavaScript TypeScript เป็น superset ของ JavaScript ที่คอมไพล์เป็น JavaScript ธรรมดา รหัสเชิงมุมแสดงโดย superset นี้

นักพัฒนาจำนวนมากเรียนรู้ Angular แต่ขาดความเข้าใจที่ดีเกี่ยวกับแนวคิดหลักที่ JavaScript, TypeScript, HTML หรือ CSS ต้องการ หากขาดพื้นฐานเหล่านี้ นักพัฒนามักจะใช้วิธีแก้ไขปัญหาชั่วคราวที่ไม่เหมาะสม และทำให้หนี้ทางเทคนิคของโครงการเพิ่มขึ้นเป็นทวีคูณ

ดังนั้น ให้ถามผู้สมัครว่าพวกเขามีความรู้เกี่ยวกับ HTML5 และ CSS3 หรือไม่ นักพัฒนา Angular ที่ดีไม่จำเป็นต้องเป็นผู้เชี่ยวชาญ HTML หรือ CSS ตราบใดที่มีคนอื่นในทีม แต่พวกเขาควรเข้าใจแนวคิดหลักเหล่านี้:

• Flexbox
• ตัวแปร SCSS
• ความแตกต่างระหว่าง span และ div
• คลาสที่สำคัญใน CSS
• คุณลักษณะ

นักพัฒนาเชิงมุมควรมีความเข้าใจอย่างถ่องแท้เกี่ยวกับ JavaScript และ TypeScript รวมถึงทักษะ HTML และ CSS บางอย่าง

ทวีต

ออกแบบก่อนเขียนโค้ด

การออกแบบที่ดีเป็นหัวใจสำคัญของสถาปัตยกรรมแอปพลิเคชันที่ดี ถามผู้สมัครของคุณว่าพวกเขาออกแบบอย่างไรและเปรียบเทียบความคิดกับข้อพิจารณาในอุดมคติเหล่านี้:

• รหัสจะไปไหน จำเป็นต้องมีห้องสมุดใหม่หรือโมดูลหรือไม่?
• อินพุตและเอาต์พุตคืออะไร?
• ควรมีส่วนประกอบหรือคำสั่งที่นำกลับมาใช้ใหม่ได้หรือไม่?
• รัฐจะไปทางไหน? (กล่าวถึงเพิ่มเติมภายใต้ การจัดการของรัฐ ด้านล่าง)
• ตรรกะทางธุรกิจจะไปที่ไหน—เช่น บริการใด
• ส่วนประกอบบางอย่างสามารถแบ่งใช้ระหว่างไลบรารีเพื่อสร้างระบบการออกแบบ UI ได้หรือไม่

ลักษณะเฉพาะที่สมบูรณ์ของการออกแบบเฉพาะมีความสำคัญน้อยกว่าว่าผู้สมัครมีนิสัยชอบออกแบบหรือไม่ การออกแบบทั้งหมดเป็นแบบชั่วคราว ดังนั้น สำหรับการใช้งานส่วนใหญ่ การจัดทำเอกสารสามารถทำได้ง่ายเหมือนภาพถ่ายสเก็ตช์บนไวท์บอร์ด เว้นแต่ว่าจำเป็นต้องมีเอกสารที่เป็นทางการ ในระยะหลัง นักพัฒนาสามารถสร้างการออกแบบทางเทคนิคจากโค้ด (ด้วยเครื่องมือที่เหมาะสม) เพื่อให้ชัดเจนว่าส่วนต่างๆ มีความสัมพันธ์กันอย่างไร

การทำความเข้าใจวงจรชีวิตแอปพลิเคชันเชิงมุม

ถามผู้สมัครของคุณว่าพวกเขารู้อะไรเกี่ยวกับ วงจรชีวิตขององค์ประกอบเชิงมุม คำตอบของพวกเขาควรมีสามตะขอวงจรชีวิต: ngOnInit , ngOnChanges และ ngOnDestroy ตามชื่อที่แนะนำ ngOnInit ถูกเรียกเมื่อเริ่มต้นส่วนประกอบ ngOnDestroy ถูกเรียกเมื่อส่วนประกอบถูกทำลาย และ ngOnChanges จะถูกเรียกเมื่อแอตทริบิวต์เปลี่ยนแปลง หลังสามารถเกิดขึ้นได้ก่อน ngOnInit —เมื่อแอตทริบิวต์ถูกกำหนดไว้แล้วก่อนที่ส่วนประกอบจะเริ่มต้นอย่างสมบูรณ์ ngOnChanges จะถูกดำเนินการก่อน ngOnInit

หากผู้สมัครรู้เกี่ยวกับ ngDoCheck , ngAfterContentInit , ngAfterContentChecked , ngAfterViewInit และ ngAfterViewChecked ด้วยเช่นกัน พวกเขารู้จักตะขอตรวจจับการเปลี่ยนแปลงทั้งหมดสำหรับส่วนประกอบและก้าวไปข้างหน้า

คำถามติดตามผลที่ดีที่จะถามเกี่ยวกับตะขอใด ๆ: "การตรวจจับการเปลี่ยนแปลงนี้จะเกิดขึ้นเมื่อใด"

วงจรชีวิตที่ไม่ค่อยมีคนรู้จักคือวงจรชีวิตของ ผู้ให้บริการ ซึ่งมีเบ็ดเดียว: ngOnDestroy สิ่งนี้จะเรียกก็ต่อเมื่อผู้ให้บริการเชื่อมต่อที่ระดับส่วนประกอบ ซึ่งในกรณีนี้จะถูกทำลายพร้อมกับส่วนประกอบ หากมีให้ที่ระดับรูทหรือโมดูล มันจะไม่มีวันถูกทำลาย

คอนสตรัคเตอร์ของผู้ให้บริการจะถูกดำเนินการในครั้งแรกที่มีการใช้ตัวให้บริการ ดังนั้นจึงเป็นไปได้ที่คอนสตรัคเตอร์จะไม่ถูกดำเนินการ ตอบคำถามผู้สมัครของคุณเกี่ยวกับความเป็นไปได้นี้—ในสถานการณ์จริง อาจเป็นที่มาของข้อบกพร่องที่มักถูกมองข้าม!

ความรู้ที่มั่นคงเกี่ยวกับการเขียนโปรแกรมเชิงโต้ตอบ

ในแอปพลิเคชันเชิงมุม การเขียนโปรแกรมเชิงโต้ตอบมักเป็นส่วนที่เข้าใจยากที่สุด หลายคนคิดอย่างเป็นขั้นตอนเมื่อเริ่มเขียนโปรแกรมโค้ด โดยสมมติว่าเข้าใจและใช้งานได้ง่ายกว่า เช่น ขั้นตอนของสูตร

การเขียนโปรแกรมเชิงโต้ตอบเกี่ยวข้องกับการตอบสนองต่อสิ่งที่เราไม่สามารถควบคุมได้ และอาจเกิดขึ้นในลำดับที่คาดเดาไม่ได้ แม้ว่าเราจะตอบสนองต่อสิ่งต่าง ๆ ในลักษณะนี้ทุกวัน—เช่น การเบรกเมื่อรถข้างหน้าหยุดกะทันหัน—นักพัฒนาหลายคนพบว่าเป็นการยากที่จะใช้วิธีการเชิงโต้ตอบในการเขียนโปรแกรม

แต่ทุกสิ่งที่เกิดขึ้นภายในแอป Angular นั้นขึ้นอยู่กับการเขียนโปรแกรมเชิงโต้ตอบ ตัวอย่างบางส่วนของการเกิดปฏิกิริยาในแอปพลิเคชันการช็อปปิ้งเชิงมุม เช่น อาจรวมถึง:

• เมื่อผู้ใช้เข้าสู่ระบบ หมายเลขบนไอคอนตะกร้าสินค้าจะอัปเดต และรายการเมนูจะเปลี่ยนเป็นตัวเลือกที่เจาะจงมากขึ้น
• เมื่อผู้ใช้นำทางไปยังหมวดหมู่ ผลิตภัณฑ์จะอัปเดตตามประเภทที่เลือก
• เมื่อผู้ใช้เพิ่มสินค้าลงในรถเข็น ไอคอนตะกร้าสินค้าจะอัปเดตด้วยจำนวนสินค้า
• เมื่อสินค้าหมด (ลงทะเบียนผ่านผู้ฟังที่ตรวจสอบปริมาณสต็อกปัจจุบันจากส่วนหลัง) หน้า UI จะอัปเดต

โปรดทราบว่าสิ่งเหล่านี้เกิดขึ้นโดยอัตโนมัติ และไม่จำเป็นต้องมีการรีเฟรชหน้าจึงจะปรากฏขึ้น ในการสัมภาษณ์ ขอให้ผู้สมัครอธิบายว่าพวกเขาใช้การเขียนโปรแกรมเชิงโต้ตอบในแอปพลิเคชันที่พวกเขาพัฒนาขึ้นอย่างไร หากผู้สมัครอธิบายวิธีแก้ปัญหาที่เกี่ยวข้องกับการรีเฟรชหน้าหรือเรียก ChangeDetectorRef.detectChanges() ด้วยตนเองเพื่อรีเฟรชส่วนประกอบ ให้พิจารณาว่าเป็นค่าสถานะสีเหลือง

ข้อผิดพลาดกับการสังเกตในเชิงมุม

นักพัฒนาที่มีประสบการณ์น้อยบางครั้งอาจพบว่าโค้ดที่พวกเขาเขียนในแอปพลิเคชันเชิงมุมไม่สามารถใช้งานได้ นักพัฒนา Seasoned Angular สามารถระบุสาเหตุทั่วไป: ไม่มีการสมัครสมาชิก Observable ซึ่งเป็นประเภทวัตถุหลักในการเขียนโปรแกรมเชิงโต้ตอบ เฉพาะการสมัครรับข้อมูลเท่านั้นที่จะดำเนินการโทรแบ็คเอนด์หรือปฏิกิริยาอื่นๆ

มีสองวิธีในการสร้างการสมัคร: นักพัฒนาสามารถใช้ async หรือวิธีการ subscribe แต่มีข้อแม้: หากนักพัฒนาทำการสมัครสมาชิกด้วยตนเอง (ด้วยวิธี subscribe ) Observable จะต้องถูกทำลายด้วยตนเอง (แม้ว่าจะมีบางกรณีที่เกิดขึ้นโดยค่าเริ่มต้น) นักพัฒนาสามารถทำลาย Observables หลายวิธี:

• ใช้ async หากเป็นไปได้ (สิ่งนี้จะทำลาย Observable เมื่อไม่ต้องการส่วนประกอบอีกต่อไป)
• ยกเลิกการสมัครด้วยตนเองโดยใช้วิธีการ unsubscribe บน Observable เมื่อสิ้นสุดอายุการใช้งานของส่วนประกอบ ( ngOnDestroy )
• ในลักษณะที่เปิดเผยมากขึ้นด้วยตัวดำเนินการ takeUntil pipe ตัวดำเนินการไพพ์ และใช้หัวเรื่อง (เช่น บางอย่างที่ชื่อ destroy destroy$ ) ในกรณีนี้ หัวข้อจะปล่อย destroy$.next destroy$.next() เมื่อสิ้นสุดอายุการใช้งานของคอมโพเนนต์ ( ngOnDestroy ) หลังจากได้รับเหตุการณ์การทำลายแล้ว ตัวดำเนินการ takeUntil จะไม่ยอมรับเหตุการณ์จาก Observable ที่ผูกไว้อีกต่อไป เพื่อที่ตรรกะของผู้ติดตามจะไม่ถูกทริกเกอร์อีกต่อไป ตัวอย่างเช่น โปรดดูที่ตัวดำเนินการ takeUntil ในส่วนที่ 2 ฟังก์ชันที่คล้ายคลึงกันสามารถเปิดเผยได้ด้วยตัวดำเนินการ take และ takeWhile
• เนื่องจากแอปพลิเคชันเชิงมุมเปลี่ยนไปใช้คอมไพเลอร์ Ivy เราจึงสามารถใช้คำอธิบายประกอบได้ ห้องสมุด until-destroy หรือห้องสมุดบุคคลที่สามอื่น ๆ เช่น SubSink สามารถใช้เพื่อยกเลิกการสมัครรับข้อมูลที่สังเกตได้เมื่อส่วนประกอบถูกทำลาย

จุดปวดที่อาจเกิดขึ้นอีกประการหนึ่งกับการเขียนโปรแกรมเชิงโต้ตอบมาจากการรั่วไหลของหน่วยความจำและการเรียกไปยังส่วนหลังหลายครั้ง ถามผู้สมัครว่าทราบปัญหาเหล่านี้หรือไม่ และปกติจะแก้ปัญหาอย่างไร หน่วยความจำรั่วอาจเกิดขึ้นได้โดยไม่สามารถยกเลิกการสมัครรับข้อมูลจาก Observable ตามที่อธิบายไว้ข้างต้น การโทรไปยังแบ็กเอนด์หลายครั้งเนื่องจากการสมัครสมาชิกหลายครั้งในการโทรแบ็คเอนด์สามารถแก้ไขได้ด้วยการแชร์ Observable

รู้สถานะและวิธีใช้งาน

แอปพลิเคชันหน้าเดียวทั้งหมดมีสถานะ และสถานะนี้มีอยู่ที่ส่วนหน้า แต่รัฐคืออะไรกันแน่? ประกอบด้วยตัวแปรทั้งหมดเฉพาะสำหรับประสบการณ์ผู้ใช้ปัจจุบัน ตัวอย่างเช่น รายละเอียดผู้ใช้ที่ตรวจสอบสิทธิ์แล้ว เช่น ชื่อและ URL รูปภาพโปรไฟล์ รายการเมนูเฉพาะที่เลือก หรือรายการบนหน้าจอ เช่น รายการตะกร้าสินค้า

ในแอปพลิเคชันเชิงมุม มีสถานะส่วนหน้าที่ต้องพิจารณาหลักสามประเภท:

ความเข้าใจที่ดีว่าสถานะคืออะไร และเมื่อใดควรโหลดหรือโหลดซ้ำ เป็นหนึ่งในทักษะหลักที่ต้องมองหาเมื่อจ้างนักพัฒนา Angular นี่เป็นพื้นที่หลักในการสำรวจว่าทีมของคุณมีโอกาสตรวจสอบโค้ดตัวอย่างที่ผู้สมัครเขียนหรือไม่ หากผู้สมัครใช้ห้องสมุดเพื่อการจัดการของรัฐ:

• มองหาการใช้ NgRx, Akita, NgXs หรือไลบรารีเฉพาะสำหรับการจัดการสถานะที่คล้ายคลึงกัน
• จากนั้นดูเพื่อดูว่ามีการแจ้งเตือนสำหรับเอ effects กต์ action ตัว reducer การ store และ selector ในโค้ดที่เกี่ยวข้องหรือไม่

ลองดูขั้นตอนทั่วไปของสถานะแอปพลิเคชันใน NgRx (ซึ่งคล้ายกับของ Akita และไลบรารีอื่น ๆ ) เป็นตัวอย่าง:

หากนักพัฒนาสร้างสถานะของตนเองด้วยบริการ ความสามารถของพวกเขาในการจัดการสถานะอาจระบุได้ยากขึ้น:

• ค้นหาการอ้างอิงถึงคำว่า state หรือ effect
• ดูว่าโค้ดตอบสนองต่อการกระทำบางอย่างหรือไม่ เช่น หากผู้ใช้กดปุ่ม A ข้อความควรเปลี่ยนบนหน้าจอ B

คำถามสำหรับผู้สัมภาษณ์เกี่ยวกับรัฐ

คุณไม่สามารถค้นหาทุกสิ่งที่คุณจำเป็นต้องรู้ได้ตลอดเวลาโดยการตรวจสอบรหัสของผู้สมัคร เพิ่มข้อความค้นหาเหล่านี้ในรายการคำถามของคุณเพื่อตรวจสอบว่านักพัฒนา Angular ที่มีศักยภาพเข้าใจสถานะได้ดีเพียงใด:

• คุณเคยใช้ state ที่ไหนและอย่างไร? นี่เป็นจุดเริ่มต้นที่มั่นคงในการทำความเข้าใจประสบการณ์ของพวกเขากับรัฐ อย่ากลัวที่จะตรวจสอบข้อมูลเฉพาะ
• คุณตัดสินใจอย่างไรว่าจะใช้ห้องสมุดหรือไม่? เป็นสัญญาณที่ดีหากพวกเขารู้ว่าการรวมไลบรารีของรัฐไว้ในแอปพลิเคชัน ไม่เป็นประโยชน์เสมอ ไป
• คุณจะใส่อะไรลงไปในรัฐ คุณจะใส่มันไว้ที่ไหน และคุณจะใช้ประโยชน์จากระบบการจัดการของรัฐอย่างไร หากพวกเขาพูดว่า "ฉันใส่ทุกอย่างลงในสถานะแอปพลิเคชันส่วนกลางของฉัน" นี่เป็นสัญญาณที่แน่ชัดว่านักพัฒนาซอฟต์แวร์ไม่ได้ตระหนักถึงผลกระทบด้านลบที่ระบบดังกล่าวสามารถให้แอปพลิเคชันได้

นักพัฒนาที่เข้าใจสถานะต่างๆ จะหลีกเลี่ยงผลข้างเคียงเหล่านี้:

• ระบุว่าใช้กับองค์ประกอบเดียวเท่านั้นที่สามารถแก้ไขหรือเสียหายโดยส่วนประกอบอื่น
• ข้อมูลซ้อนอยู่ในร้านค้า ดังนั้นจึงยากที่จะติดตามข้อมูล และข้อมูลจะกลายเป็นข้อมูลที่มนุษย์ไม่สามารถอ่านได้ (เพื่อวัตถุประสงค์ในการดีบัก การแลกเปลี่ยนข้อมูล ฯลฯ)
• การแก้ไขข้อมูลภายในแบบฟอร์มจะส่งไปยังส่วนที่เหลือของแอปพลิเคชันแล้ว ในขณะที่ควรพุชไปที่ร้านค้าเมื่อบันทึกข้อมูลเท่านั้น กล่าวอีกนัยหนึ่ง แอปพลิเคชันที่เหลืออาจใช้ข้อมูลที่ไม่ถูกต้อง

ใช้เวลาไม่นานก่อนที่ร้านค้าทั่วโลกจะกลายเป็นระเบียบที่ไม่เป็นระเบียบ และไม่ชัดเจนว่าแต่ละส่วนของความยุ่งเหยิงนั้นมาจากไหน ทำให้ยากต่อการดีบักและบำรุงรักษา

การทำความเข้าใจความสำคัญของการทดสอบอัตโนมัติ

การทดสอบอัตโนมัติควรได้รับการพิจารณาว่ามีความสำคัญพอๆ กับคุณภาพของโค้ดสำหรับเว็บแอปพลิเคชันเชิงมุมใดๆ เหตุผลหลักประการหนึ่งสำหรับโปรแกรมเมอร์ในการเขียนการทดสอบคือการจัดทำเอกสารโค้ดของตน: หากนักพัฒนารายใหม่เข้าร่วมบริษัท ตรรกะทางธุรกิจและโฟลว์ UI บางอย่างควรมีความชัดเจนตามความคาดหวังของชุดทดสอบ นอกจากนี้ การทดสอบอัตโนมัติยังเผยให้เห็นจุดบกพร่องในช่วงเริ่มต้นของการพัฒนาอีกด้วย

ถามคำถามทดสอบสามข้อสำหรับนักพัฒนา Angular ของคุณ:

• คุณคิดอย่างไรกับการทดสอบ ผู้สมัครที่ไม่สนใจการทดสอบอัตโนมัติควรได้รับการพิจารณา แม้ว่าพวกเขาไม่ต้องการใช้การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD) นักพัฒนาที่มองไม่เห็นคุณค่าของการทดสอบอัตโนมัติจะทำให้บริษัทเสียเวลาในการทดสอบด้วยตนเอง และที่แย่กว่านั้นคือ เวลาหยุดทำงานของผู้ใช้ปลายทางเมื่อเกิดการถดถอยเมื่อมีการเปลี่ยนแปลงแอป ล่วงเวลา.
• คุณเน้นอะไรในการทดสอบ? แทนที่จะทดสอบสิ่งพื้นฐานเช่นสามารถกำหนดค่าให้กับฟิลด์หรือมุ่งมั่นสำหรับการวัดความครอบคลุมการทดสอบเฉพาะ (เช่น 85% ความครอบคลุม) นักพัฒนา Angular ที่ดีควรมุ่งเน้นไปที่การทดสอบตรรกะทางธุรกิจหลัก
• มักจะมีการทดสอบ E2E หรือการทดสอบหน่วยเพิ่มเติมหรือไม่? ทำไม ในฐานะแอปพลิเคชันส่วนหน้า แอปเชิงมุมสามารถใช้ประโยชน์จากการทดสอบอัตโนมัติสองประเภทหลัก: การทดสอบหน่วยและการทดสอบแบบ end-to-end (E2E) โดยปกติ ชุดทดสอบจะมีการทดสอบหลายหน่วยและการทดสอบ E2E ที่น้อยลง การทดสอบหน่วยมีขนาดเล็ก ดังนั้นจึงเขียนและดำเนินการได้อย่างรวดเร็ว การทดสอบ E2E นั้นใหญ่และช้ากว่า คำเตือนที่เป็นธรรม: ไม่ใช่นักพัฒนาทั้งหมดที่จะมีความเห็นเหมือนกันเกี่ยวกับอัตราส่วนที่ถูกต้องของการทดสอบหน่วยและการทดสอบ E2E ที่จะรักษา ในความเป็นจริง มันขึ้นอยู่กับความซับซ้อนของแอปที่กำลังทดสอบ และถึงกระนั้น คำตอบก็ยังเป็นที่ถกเถียงกันอยู่บ้าง

กรอบการทดสอบเชิงมุม

นักพัฒนาเชิงมุมมีตัวเลือกสำหรับเฟรมเวิร์กการทดสอบอัตโนมัติ การทดสอบหน่วยสามารถทำได้ผ่าน Jest หรือ Jasmine และ Karma นักพัฒนา Angular ทุกคนควรคุ้นเคยกับจัสมินและกรรม Jest ก็เป็นเรื่องธรรมดาเช่นกัน โดยทั่วไปแล้วจะเร็วกว่าและมีตัวเลือกการทดสอบขั้นสูงเพิ่มเติม

มาตรฐานการทดสอบ E2E สำหรับแอปพลิเคชันเชิงมุมคือ Protractor ซึ่งเป็นเครื่องมือเริ่มต้นที่สร้างโดย Angular CLI อีกทางเลือกหนึ่งคือ Cypress ซึ่งเป็นเฟรมเวิร์กการทดสอบ E2E ที่มีแนวโน้มว่าจะมีตัวเลือกมากมาย

ตรวจสอบให้แน่ใจว่าผู้สมัครมีความรู้เชิงลึกเกี่ยวกับเฟรมเวิร์กการทดสอบหน่วยอย่างน้อยหนึ่งเฟรมและเฟรมเวิร์กการทดสอบ E2E หนึ่งรายการ

รับทราบข้อมูลล่าสุดเกี่ยวกับการเผยแพร่เชิงมุม

นักพัฒนา Great Angular อาจไม่ได้ใช้เวอร์ชันล่าสุดในการพัฒนาด้วยเหตุผลหลายประการ แต่ควรทราบกำหนดการเปิดตัวของ Angular เพื่อให้ทันการเปลี่ยนแปลงและเตรียมพร้อมที่จะเปลี่ยน วิธีหนึ่งในการประเมินสิ่งนี้คือการถามผู้สมัครว่าพวกเขาคุ้นเคยกับกลยุทธ์การเปิดตัวของ Angular หรือไม่ Angular ตั้งเป้าที่จะเผยแพร่ครั้งใหญ่ทุก ๆ หกเดือน โดยทั่วไปประมาณเดือนกุมภาพันธ์และพฤษภาคม รุ่น Angular อยู่ภายใต้ "การสนับสนุนที่ใช้งานอยู่" ในช่วงหกเดือนแรกหลังจากวันที่เผยแพร่ และอยู่ภายใต้ "การสนับสนุนระยะยาว" เป็นเวลา 12 เดือนหลังจากวันที่เผยแพร่ นี่เป็นไทม์ไลน์ที่ค่อนข้างแน่นหนาเมื่อเทียบกับเทคโนโลยีอื่นๆ ซึ่งทำให้การตามล่าเป็นปัจจุบันเป็นสิ่งสำคัญอย่างยิ่ง

คุณอาจทำวิจัยเกี่ยวกับ Angular เวอร์ชันล่าสุด และถามผู้สมัครของคุณเกี่ยวกับประโยชน์ของคุณลักษณะใหม่เหล่านี้ ตัวอย่างเช่น ในช่วงเวลาที่ Angular 14 เปิดตัว คุณอาจเคยถามผู้สมัครเกี่ยวกับ:

• ส่วนประกอบแบบสแตนด์อโลนซึ่งช่วยลดความจำเป็นในการใช้โมดูลเชิงมุม คอมโพเนนต์แบบสแตนด์อโลนจะไม่ถูกประกาศใน NgModule ใดๆ ที่มีอยู่ และจะจัดการการพึ่งพาของตนเองโดยตรง เป็นผลให้สามารถพึ่งพาได้โดยตรงโดยไม่ต้องใช้ NgModule ระดับกลาง
• แบบฟอร์มที่พิมพ์ การอัปเดตที่สำคัญอีกอย่างหนึ่งใน Angular 14 ซึ่งตั้งค่าการพิมพ์แบบเข้มงวดเป็นค่าเริ่มต้นสำหรับแบบฟอร์มเชิงโต้ตอบเชิงมุม แบบฟอร์มที่พิมพ์ช่วยให้แน่ใจว่าค่าภายใน FormControls , FormGroups และ FormArrays นั้นปลอดภัยสำหรับพิมพ์ทั่วทั้งพื้นผิว API ซึ่งช่วยให้แบบฟอร์มปลอดภัยยิ่งขึ้น โดยเฉพาะอย่างยิ่งสำหรับกรณีที่ซับซ้อนที่ซ้อนกันอย่างลึกล้ำ

นักพัฒนาเชิงมุมที่ยอดเยี่ยมคนต่อไปสำหรับทีมส่วนหน้าของคุณ

โปรเจ็กต์และทีมพัฒนาเว็บทุกโครงการมีความแตกต่างกัน และจะให้ความสำคัญกับทักษะและความรู้ของนักพัฒนา Angular ในด้านต่างๆ แต่การทำความเข้าใจหัวข้อพื้นฐานที่เราได้นำเสนอในที่นี้จะช่วยให้ผู้จัดการการจ้างงานมีส่วนร่วมอย่างมีความหมายในการจ้างงาน แม้กระทั่งในการประเมินทางเทคนิคเพิ่มเติม

บล็อก Toptal Engineering ขอขอบคุณ Ramazan Yildiz สำหรับการทบทวนแนวคิดทางเทคนิคและไดอะแกรมที่นำเสนอในบทความนี้