คำว่า full-stack developer นั้นถูกใช้บ่อยขึ้นเรื่อยๆ ในช่วงหลังๆ มานี้ โดยเฉพาะอย่างยิ่งในการอภิปรายเกี่ยวกับโครงสร้างทีม ข้อกำหนดในการสรรหาบุคลากร หรือการสรุปความสุดยอดของแต่ละคน

เมื่อฉันเห็นข้อความลักษณะนี้ในประวัติย่อหรือได้ยินใครบางคนอธิบายตัวเองว่าเป็นคำถามเต็มกองหลายข้อผุดขึ้นในใจ:

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

• Full-Stack Developer เป็นของจริงหรือไม่? พวกเขามีอยู่จริงหรือไม่?
• หากมีอยู่จริงเหตุใดจึงมีประโยชน์
• ฟูลสแตกเป็นอีกวิธีหนึ่งในการพูดว่า Jack of all trades, master of none?

พื้นหลัง

ก่อนที่เราจะลงรายละเอียด มันคุ้มค่าที่จะกำหนดสิ่งที่เรามีเป้าหมายที่จะพัฒนาและส่งมอบ

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

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

สำหรับจุดประสงค์ของโพสต์นี้ เราจะพิจารณาระบบที่ประมวลผลข้อมูลลูกค้าจริงจำนวนมาก (10s GBs ต่อวัน) (รวมถึง PII) และให้บริการทางธุรกิจที่สำคัญโดยมีความพร้อมใช้งานอย่างน้อย 2 9 วินาที

เหตุใดนักพัฒนาฟูลสแต็กจึงมีคุณค่า

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

ดังนั้น จากผลประโยชน์ที่ชัดเจนเหล่านี้ เหตุใดจึงไม่มีทีมที่ประกอบด้วยบุคคลเหล่านี้ในองค์กรไอทีทั้งหมด เหตุใดบริษัทต่างๆ จึงไม่รับสมัครและฝึกอบรมอย่างจริงจังเพื่อสร้างทีมนินจาเหล่านี้ เป็นเพราะการพัฒนาที่เทียบเท่ากับ Batman หรือ Tony Stark ไม่มีอยู่จริงหรือ?

เพื่อตอบคำถามเหล่านี้ เราต้องดูว่าสแต็กแบบง่าย (มาก) มีลักษณะอย่างไร

สแต็คแบบง่าย

ฉันกำลังละทิ้งโครงสร้างพื้นฐานของแพลตฟอร์มเพื่อจุดประสงค์ในการทำให้เข้าใจง่าย

เมื่อพิจารณาจากองค์ประกอบข้างต้น เห็นได้ชัดว่าการเป็นผู้เชี่ยวชาญในแต่ละชั้นนั้นเป็นเรื่องที่ท้าทาย อย่างไรก็ตาม สมมติว่าฉันไม่จำเป็นต้องรู้ทุกอย่างในแต่ละเลเยอร์ ฉันจะสามารถลดความรู้ที่จำเป็นลงและยังถือว่าเต็มสแต็กได้ไหม การใช้แอป Front-End เป็นโดเมนตัวอย่าง เราสามารถลบ Android และ iOS ได้อย่างง่ายดาย และเน้นเฉพาะช่องทางบนเว็บ และอาจปรับแต่งเพิ่มเติมและบอกว่าจำกัดเฉพาะ React นั่นจะช่วยได้อย่างไร

ตามขอบเขตการลดของเรา ฉันจำเป็นต้องรู้อะไรบ้างเกี่ยวกับ React web app?

ก่อนอื่น คุณจะต้องเข้าใจว่าแอปหน้าเดียวทำงานอย่างไร โดยเฉพาะอย่างยิ่งหลักการสำคัญที่จำเป็นในการสร้าง แก้ไขจุดบกพร่อง และเรียกใช้เว็บแอป และเครื่องมือที่เกี่ยวข้อง เช่น npm, webpack, การจัดการเนื้อหา, react devtools, แนวทาง UX, …

นอกจากนี้ คุณจะต้องคุ้นเคยกับฟังก์ชันการทำงานจากบุคคลที่สาม เช่น UI ของวัสดุ, redux, bootstrap, … และโซลูชันการจัดการแพ็คเกจ เช่น npm (รวมถึงการจัดการช่องโหว่ด้านความปลอดภัย - โดยทั่วไปแล้วการพิจารณา DevOps โปรดดูหมายเหตุในภายหลัง)

แล้วประสิทธิภาพล่ะ เช่น เวลาในการลงสีอย่างมีเนื้อหาในครั้งแรก เวลาในการโต้ตอบ เวลาในการบล็อก … ฉันควรใช้สถาปัตยกรรมเว็บแอปแบบโปรเกรสซีฟและ/หรือพนักงานบริการมาช่วยหรือไม่ คุณจะต้องเข้าใจปัจจัยด้านประสิทธิภาพและวิธีที่รูปแบบหลักต่างๆ สามารถช่วยใช้เครื่องมือเพื่อสนับสนุนการวิเคราะห์ เช่น React DevTools หรือ Lighthouse

การเข้าถึงเป็นสิ่งจำเป็นสำหรับแอปพลิเคชันทั้งหมด ไม่ว่าแอปนั้นจะถูกส่งภายในหรือภายนอกก็ตาม ฉันจะปฏิบัติตามหลักเกณฑ์ของ WCAG ได้อย่างไร

โดยสรุปในเลเยอร์ Front-End มีหลายสิ่งที่ต้องรู้และเนื้อหานี้ทำให้เบาลง เลเยอร์ที่เหลือไม่แตกต่างกัน และในหลาย ๆ กรณีความซับซ้อนก็เพิ่มขึ้น และที่แย่ไปกว่านั้นคือรูปแบบและหลักการทางสถาปัตยกรรม แนวทางปฏิบัติที่ดีที่สุดและกรอบการทำงาน ต้อง ไม่ทับซ้อนกัน

ดังนั้น สมมติว่าฉันสามารถยัดรูปแบบ มาตรฐาน แนวปฏิบัติที่ดีที่สุด และทักษะการปฏิบัติจริงสำหรับแต่ละเลเยอร์เข้ามาในหัวของฉันโดยที่มันไม่ระเบิด ฉันต้องรู้อะไรอีกบ้าง จำเป็นต้องมีความสามารถสนับสนุนหรือไม่?

รองรับความสามารถ

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

สถาปัตยกรรมและวิศวกรรม SW

ชุดทักษะหลักในการสนับสนุนการออกแบบสถาปัตยกรรมตลอดทั้งชั้นเพื่อสร้างการใช้งานที่ดีในภาษา / กรอบงานใดๆ

• SOLID (ความรับผิดชอบเดี่ยว, เปิด/ปิด, การทดแทน, การแยกส่วนต่อประสาน, การผกผันการพึ่งพา)
• ความสามารถในการนำกลับมาใช้ใหม่ 'illities', การบำรุงรักษา, การพกพา, ความสามารถในการขยาย, ...
• การปรับขนาดแนวนอนและแนวตั้ง
• โครงสร้างการเข้ารหัส
• การบันทึก
• รีวิวโค้ด
• …

แต่ละเลเยอร์และส่วนประกอบภายในแต่ละเลเยอร์ (ละเว้น Front-End จากมุมมองของช่องทางเว็บเนื่องจากใช้งานโดยเบราว์เซอร์หรือโดยทั่วไปอยู่นอกเหนือการควบคุมของเราเนื่องจากเป็นฝั่งไคลเอนต์) ในสแต็กแบบง่ายด้านบนจำเป็นต้องได้รับการพิจารณาอย่างรอบคอบจากมุมมองด้านความปลอดภัย เช่น

• APIs : TLS, DDoS, การรับรองความถูกต้องและการอนุญาต, CORs, นโยบายความปลอดภัยของเนื้อหา, ...
• Microservices : TLS (รวมถึง MA), การควบคุมการเข้าถึง, การจัดการความลับ, การตรวจสอบอินพุตของผู้ใช้, …
• ข้อมูล : การควบคุมการเข้าถึง, การเข้ารหัสเมื่อไม่มีการใช้งาน, การจัดการคีย์, กลุ่มความปลอดภัยเครือข่ายและซับเน็ต, …
• แพลตฟอร์ม (เพิ่มเติม) : ความปลอดภัยของเครือข่าย การกำหนดค่าส่วนประกอบคงที่ เช่น ChefInspec

นักพัฒนาทุกคนต้องการทักษะการทดสอบหลัก ไม่มีข้อแก้ตัวใด ๆ ที่จะไม่สามารถทดสอบคุณลักษณะของคุณเองได้ และในสภาพแวดล้อมแบบ full-stack ซึ่งหมายถึงทุกส่วนประกอบในไดอะแกรมด้านบน

การทำความเข้าใจและสามารถนำประเภทและขั้นตอนต่างๆ ของการทดสอบไปใช้ได้ (โดยไม่ต้องทำการบ้านของคุณเอง):

• ใช้งานได้และไม่ใช้งานได้
• กล่องดำ vs กล่องขาว
• หน่วย การบูรณาการ ระบบ การยอมรับของผู้ใช้ การถดถอย ควัน ...

การพัฒนาและบำรุงรักษาการรวมอย่างต่อเนื่องและไปป์ไลน์การปรับใช้อย่างต่อเนื่อง

ตัวเปิดใช้งานหลักสำหรับ CICD มักจะสร้างโดยทีมงานส่วนกลาง/เฉพาะ แต่ทุกคนควรสามารถอัปเดตและบำรุงรักษาไปป์ไลน์ได้อย่างน้อยที่สุด (ใช่ ฉันรู้ หากคุณมีทีม DevOps แสดงว่าคุณไม่ได้ทำ DevOps แต่องค์กรจำนวนมากทำ)

โดยใช้เครื่องมือเช่น:

• เจนกินส์, ทราวิสซีไอ, สปินเนเกอร์
• GitHub, Bitbucket
• โซนาร์คิวบ์
• แซพร็อกซี่
• เวราโค้ด, สนีค
• นักเทียบท่า, ผู้ประกาศข่าว, ท่าเรือ
• …

หากเราเพิกเฉยต่อ "คุณสร้างมัน คุณรันมัน" เข้าใกล้ข้อกำหนดของนักพัฒนาแบบฟูลสแต็กรอบ ๆ การดำเนินการจะง่ายขึ้นอย่างมาก

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

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

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

บทสรุป

ฉันเชื่อว่าผู้พัฒนาฟูลสแต็กที่แท้จริงเป็นตำนาน (ส่วนใหญ่) และนับตั้งแต่นั้นมาสแต็กก็ไปไกลกว่าการรันแอสเซมเบลอร์บน 6502 ในปี 1980 อย่าหลอกตัวเองให้คิดว่าการได้รับ front end และทำงานโดยคุยกับ API บางตัวที่เขียนใน Node ที่ทำงานบนโหนด K8 หมายความว่าคุณเป็นนักพัฒนาแบบ full-stack

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

นอกจากนี้ บุคคลเหล่านี้มักจะขอเงินมากกว่าที่องค์กรด้านไอทีส่วนใหญ่จะสามารถจ่ายให้พวกเขาได้ แต่ถ้าพวกเขาเป็นฟูลสแต็กจริง ๆ พวกเขาก็คุ้มค่าตามที่โฆษณากล่าว

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

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

ความคิดเห็นโบนัส:

คุณจำเป็นต้องรู้อะไรบ้างจึงจะประสบความสำเร็จ "มากขึ้น" ในฐานะนักพัฒนาด้านวิทยาการข้อมูล (สังเกตการใช้คำว่านักพัฒนาที่นั่นแทนที่จะใช้คำว่านักวิทยาศาสตร์ข้อมูล — ฉันถือว่าคุณเป็นนักวิทยาศาสตร์ข้อมูลที่ดีอยู่แล้ว และถ้าคุณไม่ใช่ ฉัน ไม่สามารถช่วยคุณได้!) หากเรานิยามนักพัฒนารายนี้ว่าเป็นผู้ที่สามารถพัฒนาในแต่ละด้านเหล่านี้ได้ แต่เป็นผู้เชี่ยวชาญในส่วน Data Science* นั่นคือเป้าหมายที่ลดลงของฉันข้างต้น การทำให้เป็นอุตสาหกรรมของสแต็กที่กว้างขึ้นเป็นสิ่งที่ Machine Learning Engineer จะทำ … แต่การอภิปรายนั้นคือ อีกครั้งหนึ่ง

*ในสแต็กแบบง่ายของเรา เราสามารถพูดได้ว่าโมเดลนี้อยู่ในไมโครเซอร์วิสบิต … นะ