ทําความเข้าใจวงใน

วงภายในเป็นแนวคิดพื้นฐานในการพัฒนาซอฟต์แวร์ที่ส่งผลกระทบอย่างมากต่อประสิทธิภาพการทํางานของนักพัฒนาและวงจรข้อเสนอแนะ การทําความเข้าใจและเพิ่มประสิทธิภาพวงภายในเป็นสิ่งสําคัญสําหรับแนวทางปฏิบัติ DevOps ที่มีประสิทธิภาพและการปรับปรุงอย่างต่อเนื่อง

วงด้านในคืออะไร?

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

ลักษณะสําคัญ

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

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

รูปแบบลูปด้านในตามเทคโนโลยี

กิจกรรมเฉพาะในลูปภายในของนักพัฒนาซอฟต์แวร์ขึ้นอยู่กับ:

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

ตัวอย่าง: ลูปภายในการพัฒนาไลบรารี

สําหรับ การพัฒนาห้องสมุด วงภายในโดยทั่วไปประกอบด้วย:

1. เขียน โค้ด: เขียนหรือแก้ไขโค้ดไลบรารี
2. ตึก: รวบรวมไลบรารี
3. การทดสอบ: เรียกใช้การทดสอบหน่วยเพื่อตรวจสอบการทํางาน
4. การแก้จุดบกพร่อง: แก้ไขปัญหาที่พบระหว่างการทดสอบ
5. การกระทําความมุ่งมั่น: บันทึกการเปลี่ยนแปลงไปยังที่เก็บ Git ภายในเครื่อง

ตัวอย่าง: ลูปภายในการพัฒนาส่วนหน้าของเว็บ

สําหรับ งานส่วนหน้าของเว็บ ลูปภายในจะได้รับการปรับให้เหมาะสมแตกต่างกัน:

1. เขียน โค้ด: แก้ไข HTML, CSS และ JavaScript
2. การรวมกลุ่ม: เรียกใช้เครื่องมือสร้าง (Webpack, Vite ฯลฯ)
3. ชื่นใจ: โหลดเบราว์เซอร์ซ้ําเพื่อดูการเปลี่ยนแปลง
4. การแก้จุดบกพร่อง: ใช้ DevTools ของเบราว์เซอร์เพื่อตรวจสอบพฤติกรรม
5. การกระทําความมุ่งมั่น: บันทึกการเปลี่ยนแปลงไปยังที่เก็บ Git ภายในเครื่อง

การสลับตามบริบท

โค้ดเบสที่ทันสมัยส่วนใหญ่ประกอบด้วยหลายองค์ประกอบ ดังนั้นลูปภายในของนักพัฒนาอาจสลับกันไปขึ้นอยู่กับสิ่งที่กําลังดําเนินการอยู่:

• API แบ็กเอนด์: มุ่งเน้นไปที่โค้ด สร้าง ทดสอบ แก้ไขข้อบกพร่อง
• UI ส่วนหน้า: มุ่งเน้นไปที่โค้ด รวมกลุ่ม รีเฟรช ตรวจสอบ
• สคีมาฐานข้อมูล: มุ่งเน้นไปที่การโยกย้าย การทดสอบ การย้อนกลับ
• โครงสร้างพื้นฐาน: มุ่งเน้นไปที่การกําหนดค่า การปรับใช้ การตรวจสอบความถูกต้อง

การจัดหมวดหมู่กิจกรรมวงใน

ขั้นตอนภายในลูปภายในสามารถจัดกลุ่ม เป็นสามประเภทกิจกรรมกว้าง ๆ :

1. การทดลอง

กิจกรรมที่เพิ่มมูลค่าให้กับลูกค้า:

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

ลักษณะ: กิจกรรมเหล่านี้เป็นกิจกรรม เดียว ที่เพิ่มมูลค่าให้กับผลิตภัณฑ์ขั้นสุดท้ายโดยตรง

2. การรวบรวมข้อเสนอแนะ

กิจกรรมที่ตรวจสอบคุณภาพ:

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

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

3. ภาษี

กิจกรรมที่จําเป็นแต่ไม่ได้เพิ่มมูลค่าหรือข้อเสนอแนะ:

• การกระทําความมุ่งมั่น: การบันทึกโค้ดไปยังตัวควบคุมเวอร์ชัน
• การกําหนดค่า: การตั้งค่าสภาพแวดล้อมการสร้าง
• ซิ งโค รไนส์: การดึงการเปลี่ยนแปลงล่าสุดจากที่เก็บระยะไกล
• การอัปเดตเอกสารประกอบ: การอัปเดตไฟล์ README หรือข้อคิดเห็น

ลักษณะ: กิจกรรมเหล่านี้เป็น งานที่จําเป็น แต่ไม่ได้เพิ่มมูลค่าให้กับลูกค้าหรือให้ข้อเสนอแนะ หากกิจกรรมไม่ จําเป็น ก็เป็นการสูญเปล่าและควรกําจัด

ตัวอย่างการจัดหมวดหมู่: การพัฒนาห้องสมุด

สําหรับสถานการณ์การพัฒนาห้องสมุด:

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

การเพิ่มประสิทธิภาพลูปด้านใน

เมื่อจัดหมวดหมู่ขั้นตอนภายในลูปแล้ว ก็สามารถสร้าง หลักการเพิ่มประสิทธิภาพได้:

หลักการเพิ่มประสิทธิภาพหลัก

1. ความเร็วเป็นสัดส่วนกับการเปลี่ยนแปลง

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

2. เพิ่มคุณภาพข้อเสนอแนะให้สูงสุดลดเวลาข้อเสนอแนะ

• เป้าหมาย: รับข้อมูลที่เป็นประโยชน์สูงสุดในเวลาอันสั้น
• หลัก: สมดุลระหว่างการทดสอบที่ครอบคลุมและการทําซ้ําอย่างรวดเร็ว
• ผลประโยชน์: ตรวจจับปัญหาที่สําคัญได้อย่างรวดเร็วในขณะที่เลื่อนการตรวจสอบที่สําคัญน้อยลง

3. ลดหรือเลื่อนภาษี

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

4. ต่อสู้กับการเติบโตของความซับซ้อน

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

ปัญหาฐานรหัสเสาหิน

ใน โค้ดเบสเสาหินขนาดใหญ่ คุณอาจพบสถานการณ์ที่:

• การเปลี่ยนแปลงเล็กน้อย: แก้ไขหนึ่งฟังก์ชัน
• ค่าใช้จ่ายที่ไม่สมส่วน: รอ 10+ นาทีสําหรับชุดบิลด์และทดสอบเต็มรูปแบบ
• ความหงุดหงิดของนักพัฒนา: ผลผลิตลดลงเนื่องจากวงจรข้อเสนอแนะช้าลง
• การสลับบริบท: นักพัฒนาสูญเสียสมาธิเพื่อรอบิลด์

นี่เป็นปัญหาที่คุณต้องแก้ไขในเชิงรุก

กลยุทธ์สําหรับการเพิ่มประสิทธิภาพฐานโค้ดขนาดใหญ่

ทีมสามารถใช้กลยุทธ์หลายอย่างเพื่อเพิ่มประสิทธิภาพลูปภายในสําหรับฐานรหัสที่ใหญ่ขึ้น:

1. การสร้างและการทดสอบที่เพิ่มขึ้น

สร้างและทดสอบเฉพาะสิ่งที่เปลี่ยนแปลง:

• ระบบสร้างอัจฉริยะ: ตรวจหาไฟล์ที่เปลี่ยนแปลงและสร้างใหม่เฉพาะส่วนประกอบที่ได้รับผลกระทบ
• การเลือกการทดสอบ: เรียกใช้เฉพาะการทดสอบที่ได้รับผลกระทบจากการเปลี่ยนแปลงโค้ด
• การติดตามการพึ่งพา: ทําความเข้าใจว่าการทดสอบใดขึ้นอยู่กับโค้ดใด
• เครื่อง มือ: ใช้ระบบบิลด์ เช่น Bazel, Buck หรือ Gradle กับบิลด์ที่เพิ่มขึ้นอย่างชาญฉลาด

ประโยชน์:

• ลดเวลาในการสร้างลงอย่างมากสําหรับการเปลี่ยนแปลงเล็กน้อย
• เวลาป้อนกลับตามสัดส่วนเพื่อเปลี่ยนขนาด
• รอบการทําซ้ําที่เร็วขึ้น

2. การแคชผลลัพธ์ระดับกลาง

แคชสร้างสิ่งประดิษฐ์เพื่อเพิ่มความเร็วในการสร้างที่สมบูรณ์:

• การแคชในเครื่อง: จัดเก็บวัตถุที่คอมไพล์และผลการทดสอบไว้ในเครื่อง
• การแคชแบบกระจาย: แชร์สิ่งประดิษฐ์ในการสร้างระหว่างสมาชิกในทีม
• การดําเนินการระยะไกล: ถ่ายโอนการคอมไพล์ไปยังฟาร์มบิลด์บนคลาวด์
• เครื่อง มือ: ใช้การแคชด้วยระบบต่างๆ เช่น แคช สําเนา หรือโซลูชันบนคลาวด์

ประโยชน์:

• หลีกเลี่ยงการคอมไพล์โค้ดที่ไม่เปลี่ยนแปลงซ้ําซ้อน
• ทําความสะอาดได้เร็วขึ้นหลังจากเปลี่ยนสาขา
• ลดเวลาดําเนินการไปป์ไลน์ CI/CD

3. การแบ่งแยกส่วนและการแบ่งปันไบนารี

แบ่งฐานรหัสออกเป็นหน่วยเล็ก ๆ และแชร์ไบนารี:

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

ความระมัดระวัง: กลยุทธ์นี้อาจเป็น ดาบสองคม หากทําไม่ถูกต้อง (ดูส่วน Tangled Loops ด้านล่าง)

ประโยชน์เมื่อทําถูกต้อง:

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

ความเสี่ยงเมื่อทําผิด:

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

ทําความเข้าใจกับลูปพันกัน

แนวคิดของ ลูปพันกัน แสดงให้เห็นถึงสิ่งที่เกิดขึ้นเมื่อการทําโมดูลาร์ไม่ถูกต้องทําให้ลูปด้านในและด้านนอกพันกัน

วงรอบนอก

ก่อนที่จะทําความเข้าใจลูปที่พันกันเราจําเป็นต้องกําหนด ลูปด้านนอก:

ลักษณะวงด้านนอก:

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

สถานการณ์จําลองแบบแยกส่วน

พิจารณาสถานการณ์ทั่วไปนี้:

สถานะเริ่มต้น: แอปพลิเคชั่นเสาหินที่มี เฟรมเวิร์กเฉพาะแอปพลิเคชัน ที่ยกของหนัก

การตัดสินใจแบบแยกส่วน: แยกเฟรมเวิร์กลงในแพ็คเกจแยกต่างหาก

ขั้นตอนการดําเนินการ:

1. ดึงโค้ดลงในที่เก็บแยกต่างหาก: โค้ดเฟรมเวิร์กย้ายไปยังที่เก็บของตัวเอง
2. ตั้งค่าไปป์ไลน์ CI/CD: สร้างและเผยแพร่อัตโนมัติสําหรับแพ็คเกจเฟรมเวิร์ก
3. เพิ่มประตูคุณภาพ: การตรวจทานคําขอดึงข้อมูล การสแกนความปลอดภัย เวิร์กโฟลว์การอนุมัติ
4. เผยแพร่เป็นแพ็คเกจ: เฟรมเวิร์กกลายเป็นการขึ้นต่อกันตามเวอร์ชัน

ผลลัพธ์เบื้องต้น: สิ่งต่าง ๆ ทํางานได้ดีในตอนแรก เสาหินใช้เวอร์ชันเฟรมเวิร์กที่เสถียร

เมื่อเกิดการพันกัน

สถานการณ์ปัญหา: คุณต้องพัฒนา คุณลักษณะใหม่ ที่ต้องใช้ ความสามารถใหม่มากมาย ในเฟรมเวิร์ก

จุดปวด: ตอนนี้คุณต้อง พัฒนาโค้ดร่วมกัน ในที่เก็บสองที่แยกจากกันโดยมีการขึ้นต่อกันแบบไบนารีระหว่างกัน

สิ่งที่เกิดขึ้น:

1. เพิ่มวิธีการในเฟรมเวิร์ก: สร้างความสามารถใหม่ในที่เก็บเฟรมเวิร์ก
2. ผ่านวงรอบนอก: การตรวจสอบโค้ด การทดสอบ การสแกนความปลอดภัย การอนุมัติ
3. รอการเผยแพร่แพ็คเกจ: ต้องสร้างและเผยแพร่แพ็คเกจเฟรมเวิร์ก
4. อัปเดตแอปพลิเคชัน: แก้ไขแอปพลิเคชันเพื่อใช้วิธีการเฟรมเวิร์กใหม่
5. ซ้ำ: การทําซ้ําทุกครั้งต้องมีวงจรลูปด้านนอกเต็มรูปแบบ

ปัญหา:ลูปด้านใน ของฐานรหัสดั้งเดิม มีลูปด้านนอก ของโค้ดเฟรมเวิร์ก

ภาษีวงนอก

วงรอบนอกรวมถึงภาษีที่สําคัญ:

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

ผลกระทบ: คุณ ไม่ต้องการจ่ายภาษีนี้ ทุกครั้งที่คุณเพิ่มเมธอดในชั้นเรียนและต้องการใช้ทันที

วิธีแก้ปัญหาสําหรับนักพัฒนา

สิ่งที่มักเกิดขึ้น:

แฮ็กในพื้นที่: นักพัฒนาสร้างวิธีแก้ปัญหาเพื่อต่อลูปภายในเข้าด้วยกัน:

• การอ้างอิงแพ็คเกจท้องถิ่น: ชี้ไปที่ระบบไฟล์ภายในเครื่องแทนแพคเกจที่เผยแพร่
• โมดูลย่อย Git: รวมแหล่งที่มาของเฟรมเวิร์กโดยตรงในแอปพลิเคชัน
• ลิงค์ Sym : สร้างลิงก์ระหว่างที่เก็บ
• แพ็คเกจก่อนวางจําหน่าย: เผยแพร่ไปยังฟีดทดสอบ

ผล: วิธีแก้ปัญหาเหล่านี้ ยุ่งเหยิงอย่างรวดเร็ว และยังคงต้องจ่ายภาษีวงนอกในที่สุด

วิธีที่ถูกต้องในการทําให้เป็นโมดูลาร์

การทําให้เป็นโมดูลาร์ไม่ได้แย่โดยเนื้อแท้ - สามารถทํางานได้อย่างยอดเยี่ยมเมื่อทําอย่างถูกต้อง:

การทําให้เป็นโมดูลาร์ที่ดี:

• อินเทอร์เฟซที่เสถียร: Framework API เปลี่ยนแปลงไม่บ่อยนัก
• วิวัฒนาการอิสระ: เฟรมเวิร์กและแอปพลิเคชันพัฒนาแยกกัน
• ขอบเขตที่ชัดเจน: ความรับผิดชอบและสัญญาที่กําหนดไว้อย่างดี
• ข้อต่อหลวม: การพึ่งพาระหว่างส่วนประกอบน้อยที่สุด

การทําให้เป็นโมดูลาร์ไม่ดี:

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

หลักการสําคัญ: ทําแผลแบบแยกส่วน อย่างระมัดระวัง ตามขอบเขตทางสถาปัตยกรรมที่แท้จริง ไม่ใช่โครงสร้างองค์กร

แนวทางปฏิบัติที่ดีที่สุดสําหรับการเพิ่มประสิทธิภาพลูปภายใน

ตรวจสอบและวัดผล

ติดตามเมตริกวงใน:

• เวลาสร้าง: การรวบรวมใช้เวลานานแค่ไหน?
• เวลาดําเนินการทดสอบ: การทดสอบจะดําเนินการนานแค่ไหน?
• ความล่าช้าของข้อเสนอแนะ: เวลาตั้งแต่บันทึกจนถึงการดูผลลัพธ์
• ความพึงพอใจของนักพัฒนา: ทีมสํารวจเกี่ยวกับจุดบกพร่อง

เครื่องมือสําหรับการวัด:

• สร้างการวิเคราะห์ระบบ
• ตัวสร้างโปรไฟล์ประสิทธิภาพ IDE
• รายงานการดําเนินการทดสอบ
• แบบสํารวจประสิทธิภาพของนักพัฒนา

จัดการกับการชะลอตัวในเชิงรุก

สัญญาณเตือน:

• นักพัฒนาบ่นเกี่ยวกับการสร้างที่ช้า
• การสลับบริบทเพิ่มขึ้นระหว่างการรอสร้าง
• ทีมเริ่มข้ามการทดสอบในเครื่อง
• คําขอดึงข้อมูลมีโค้ด "ยังไม่ได้ทดสอบ"

กลยุทธ์การตอบสนอง:

• ตรวจสอบสาเหตุที่แท้จริงทันที
• จัดลําดับความสําคัญของงานเพิ่มประสิทธิภาพ
• มีส่วนร่วมทั้งทีมในโซลูชัน
• วัดผลการปรับปรุงเมื่อเวลาผ่านไป

การแลกเปลี่ยนยอดคงเหลือ

การแลกเปลี่ยนที่สําคัญที่ต้องพิจารณา:

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

หลัก: การปรับปรุงด้านหนึ่ง มักจะทําให้เกิดปัญหา ในอีกด้านหนึ่ง ประเมินการแลกเปลี่ยนอย่างต่อเนื่อง

การจัดตําแหน่งทีม

ความรับผิดชอบร่วมกัน:

• สถาปนิก: การออกแบบเพื่อการทดสอบและโมดูลาร์
• นัก พัฒนา: เขียนการทดสอบที่มีประสิทธิภาพและหลีกเลี่ยงการพึ่งพาที่ไม่จําเป็น
• DevOps: จัดเตรียมโครงสร้างพื้นฐานและแคช
• การจัดการ: จัดลําดับความสําคัญของงานเพิ่มประสิทธิภาพลูปภายใน

การปฏิบัติทางวัฒนธรรม:

• ถือว่าเวลาลูปภายในเป็นตัวชี้วัดประสิทธิภาพการทํางานที่สําคัญ
• ทําให้ "การสร้างช้า" เป็นเหตุผลที่ถูกต้องในการหยุดการทํางานของฟีเจอร์ชั่วคราว
• เฉลิมฉลองการปรับปรุงลูปภายใน
• แบ่งปันความรู้เกี่ยวกับการเพิ่มประสิทธิภาพระหว่างทีม

ประเด็นสำคัญ

จําหลักธรรมเหล่านี้

1. ไม่มีกระสุนเงิน: ไม่มีโซลูชันสากลสําหรับการเพิ่มประสิทธิภาพลูปภายใน
2. ทําความเข้าใจปัญหา: ระบุเวลาที่เกิดการชะลอตัวและสาเหตุที่แท้จริง
3. วัดทุกอย่าง: ติดตามเมตริกเพื่อทําความเข้าใจผลกระทบของการเปลี่ยนแปลง
4. ดําเนินการเชิงรุก: แก้ไขปัญหาก่อนที่จะส่งผลกระทบต่อประสิทธิภาพการทํางานอย่างรุนแรง
5. การแลกเปลี่ยนยอดคงเหลือ: การเพิ่มประสิทธิภาพทุกครั้งมีค่าใช้จ่าย เลือกอย่างชาญฉลาด
6. แยกส่วนอย่างระมัดระวัง: แยกฐานรหัสตามขอบเขตทางเทคนิค ไม่ใช่ความสะดวก
7. การปรับปรุงอย่างต่อเนื่อง: การเพิ่มประสิทธิภาพลูปภายในกําลังทํางานอย่างต่อเนื่อง

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