Adam Smith กับนักพัฒนา fullstack - และประสิทธิภาพใน DevOps

โดย Adam Smith แผนกแรงงานสามารถทำให้คุณมีประสิทธิภาพมากขึ้น240 เท่า (ตัวอย่างเช่นโรงงานผลิตพินใน 18 ขั้นตอน)

ทำไมจึงมีบทบาทที่มีทักษะหลากหลายเป็นที่ต้องการอย่างมากถ้าสิ่งนี้ช่วยลดประสิทธิผลได้จริงหรือมิ ธ ผิดไปทำไม

ค้นหา "fullstack developer" ยังคงมีแนวโน้มใน Google แต่ดูเหมือนจะช้ากว่าสองปีที่ผ่านมา:

=====

ในการสรุปผู้พัฒนาสแต็คเต็มรูปแบบสามารถทำทุกห่วงโซ่คุณค่า (แก้ไขฉันถ้าฉันผิด):

• พูดคุยกับลูกค้าและปรับแต่งข้อกำหนดความคล่องตัวที่สามารถทำงานได้สำหรับส่วนของงาน
• ตัดสินใจเลือกสถาปัตยกรรมเครื่องมือและส่วนประกอบ - เพียงมอบโน้ตบุ๊กให้เขา
• เขียนโค้ดสำหรับ frontend, backend, ingration ซึ่งรองรับการทำงานข้ามอุปกรณ์และไม่ต้องการการทดสอบมากหรือรวมถึงมัน
• โปรไฟล์และข้อมูลภูมิประเทศใช้ Cloud AI / ML APIs สำหรับคุณสมบัติขั้นสูง
• เขียนรหัส IaC และการเปิดตัวที่จำเป็น
• โทรแจ้งในกรณีที่เกิดข้อผิดพลาดหรือกระบวนการขาย
• ระวังการออกแบบที่เกี่ยวข้องกับความปลอดภัยการแพตช์โดยรวมการโยกย้ายและความทันสมัย
• ตารางเวลาบัญชีในลักษณะที่ละเอียดเพื่อลดความยุ่งยากในการออกใบแจ้งหนี้ของนายจ้าง
• ... ฉันลืมอะไรไปหรือเปล่า

UPD - " เราต้องการผลิตภาพของความเชี่ยวชาญ แต่เราไม่ต้องการมุมมองที่โดดเดี่ยวของ" การแบ่งงานที่รุนแรง "(DevOps Guys, " DevOps, Adam Smith และตำนานของ Generalist " , 2013-2016)

มีงานสองประเภท:

1. การเอารัดเอาเปรียบ - งานที่กำหนดไว้อย่างดีซึ่งสามารถแบ่งออกเป็นขั้นตอนที่กำหนดได้ง่ายซึ่งแต่ละขั้นตอนสามารถเรียนรู้และเข้าใจในตัวเองและส่งมอบระหว่างขั้นตอนไม่จำเป็นต้องมีการสื่อสาร

2. การสำรวจ - งานที่ไม่ได้กำหนดซึ่งต้องการการเรียนรู้และการทดลองเพื่อให้บรรลุแต่ละขั้นตอนและส่งมอบระหว่างขั้นตอนต้องใช้การสื่อสารจำนวนมากของการเรียนรู้ทั้งหมดและสถานะของโครงการ

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

แต่เราได้เห็นแล้วว่าในขั้นตอนการปรับปรุงอย่างต่อเนื่องในภายหลังซึ่งเป็นงานที่เอาเปรียบส่วนหนึ่งการประยุกต์ใช้ CI / CD สามารถนำมาซึ่งผลกำไรที่คล้ายคลึงกันซึ่งในทางใดทางหนึ่ง

อดัมสมิ ธ ไม่จำเป็นต้องพิจารณาการส่งผ่านข้อมูลจากเวทีหนึ่งไปอีกเวทีหนึ่ง นี่เป็นส่วนสำคัญของโครงการด้านไอทีที่สำคัญ นักพัฒนา fullstack จึงมีข้อได้เปรียบที่สำคัญที่:

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับความสำคัญของข้อมูลที่ผ่านในโครงการไอทีเห็นเฟร็ดลำธารกับ myth Man เดือน

IMHO คำตอบมีส่วนเกี่ยวข้องกับความพร้อมของเครื่องชั่งและทรัพยากร

ฉันเชื่อว่าทฤษฎีของอดัมสมิ ธ สามารถใช้ได้เฉพาะในระดับใหญ่ - ทั้งประเทศ / เศรษฐกิจในบริบทดั้งเดิมหรือในบริบทการพัฒนา SW - ทีมพัฒนาขนาดใหญ่

ในทีมขนาดใหญ่ย่อมมีประสิทธิภาพมากกว่าในการจ้างทรัพยากรบุคคลที่มีความเชี่ยวชาญเฉพาะทางมากขึ้น:

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

โอ้และทีมดังกล่าวสามารถทำงานได้ก็ต่อเมื่อได้รับการเสริมด้วยทรัพยากรสถาปนิกคุณภาพสูงซึ่งจำเป็นต้องแบ่งผลิตภัณฑ์ออกเป็นงานพิเศษที่มีขนาดเล็กลงซึ่งสามารถแก้ไขได้ด้วยทรัพยากรเฉพาะ

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

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

ฉันถือว่าตัวเองเป็นผู้พัฒนาแบบเต็มสต็อกบนพื้นฐานของการผสมผสานความรับผิดชอบต่อไปนี้:

การเขียนโปรแกรมส่วนหน้าและส่วนหลัง

ฉันสามารถทำการเปลี่ยนแปลง UI ได้จนถึงระดับหนึ่ง: เขียน html, css (ในฐานะนักพัฒนาเว็บ) และในทางกลับกันบางส่วนจะให้ข้อมูลไปยัง UI จากฐานข้อมูลจัดเตรียมไว้ในบริการอื่น ๆ

ฉันออกจากการทดสอบสถาปัตยกรรมและที่นอกเหนือจากการพบปะลูกค้าอาจถูกเพิ่มไปยังคำอธิบายการทำงาน

ตรงข้าม

ตรงกันข้ามกับมุมมองของฉันจะเป็นบทบาทที่เข้มงวดของ UI ของคนและคนที่อยู่ด้านหลัง

สรุปผลการวิจัย

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

ในระยะสั้นฉันไม่คิดว่า Adam Smith ผิด แต่ฉันคิดว่ามีความแตกต่างที่รุนแรงระหว่างรูปแบบแผนกแรงงานของเขาในการผลิตและไซโลในการพัฒนาซอฟต์แวร์

ครั้งแรกตัวอย่างโรงงานพิน (เท่าที่ฉันรู้) เป็นเพียงแค่สมมุติ; แม้ว่าโรงงานผลิตที่ทันสมัยส่วนใหญ่สามารถติดตามรากของพวกเขาไปยังแผนกแรงงานนี้ได้ แต่ฉันไม่ทราบว่ามีการศึกษาใดที่ได้ทดสอบสมมติฐานนี้ทางวิทยาศาสตร์

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

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

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

ประเด็นสำคัญที่ต้องเข้าใจคือการแบ่งงานไม่ได้หมายถึงคนที่แตกต่างกันไปในแต่ละขั้นตอน

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

ตรงนี้เป็นแผนกแรงงานที่คุณทำเพียงขั้นตอนเดียวของการชุมนุมในเวลาที่กำหนดซึ่งไม่ได้ป้องกันไม่ให้คุณทำสมัชชาเต็ม

ตามที่ระบุไว้แล้วในคำตอบอื่น ๆ นี้แตกต่างจากการพัฒนาซอฟต์แวร์เล็กน้อย แต่ฉันคิดว่าสิ่งนี้ให้ความกระจ่างว่าเหตุใดนักพัฒนา Full Stack จึงไม่ร่วมกันเป็นเอกเทศกับแผนกแรงงานผู้ที่มีความสามารถในการจัดการวงจรชีวิตทั้งหมด จำเป็นต้องทำตลอดเวลา

โดยทั่วไปเมื่อฉันได้ยินนักพัฒนา FullStack ฉันคิดว่ามีใครบางคนที่สามารถใช้รหัสแบ็กเอนด์ที่มีประสิทธิภาพและ UI ที่ดีได้ในเวลาเดียวกันเมื่อเทียบกับ Front และ Back Dev