#priwreadbooks Agile Coaching — Chapter 11 — Clean Code (สรุป)

Photo by No Revisions on Unsplash

Previous chapter:

• Chapter 1 — Starting the Journey
• Chapter 2 — Working with People
• Chapter 3 — Leading Change
• Chapter 4 — Building an Agile Team
• Chapter 5 — Daily Standup
• Chapter 6 — Understanding What to Build
• Chapter 7 — Planning Ahead
• Chapter 8 — Keeping It Visible
• Chapter 9 — Getting to “Done”
• Chapter 10 — Driving Development with Tests

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

มาดูกันว่าคุณสามารถสร้าง Clean Code ให้เป็นที่สนใจสำหรับทีมได้อย่างไร และทำให้พวกเขาเริ่มต้นด้วยแนวทางปฏิบัติแบบ Agile เช่น Incremental Design, Collective Code Ownership และ Pair Programming นอกจากนี้ เราจะแบ่งปันเคล็ดลับบางประการเกี่ยวกับวิธีการแก้ไขปัญหาที่ขัดขวางทีมจากการทำงานร่วมกัน

Incremental Design

สละเวลาเพื่อปรับปรุงการออกแบบซอฟต์แวร์ในขั้นเล็กๆ ให้เป็นส่วนหนึ่งในทุกวันของนักพัฒนา “เสร็จสิ้น” ในทุกเรื่องราวของผู้ใช้ การทำงานในลักษณะนี้ นักพัฒนาจะคิดเกี่ยวกับการออกแบบซอฟต์แวร์ ในขณะที่เขียนการทดสอบ ในขณะที่เขียนโค้ดเพื่อให้ผ่านการทดสอบ และก่อนที่จะ check-in โค้ด

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

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

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

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

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

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

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

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

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

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

คุณยังสามารถช่วยทีมให้คำนึงถึงความสะอาดของโค้ดโดย รวมการตรวจสอบการออกแบบเข้ากับคำจำกัดความของคำว่า “เสร็จสิ้น” พวกเขาสามารถทำข้อตกลงในทีมได้ว่าโค้ดและ Unit Test จะต้องสามารถเข้าใจได้ง่ายโดยสมาชิกในทีมอย่างน้อยหนึ่งคน

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

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

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

Refactoring

การปรับโครงสร้างใหม่ คือการปรับปรุงการออกแบบซอฟต์แวร์โดยไม่เปลี่ยนพฤติกรรมการทำงานของระบบ ทำทีละขั้นตอนโดยใช้การปรับปรุงทีละเล็กทีละน้อย เช่น Rename Field หรือ Extract Method หลังจากการรีแฟคเตอร์แต่ละครั้ง ควรรันการทดสอบเสมอเพื่อดูว่ายังผ่านอยู่

อธิบายการทำ Refactoring ให้กับลูกค้าของคุณ

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

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

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

การรีแฟคเตอร์ทำได้สองวิธีคือ

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

โค้ดที่อ่านได้

ทีมจำเป็นต้องเขียนโค้ดที่ทุกคนในทีมสามารถเข้าใจได้ง่าย และโค้ดนั้นมีความสามารถในการอธิบายได้ด้วยตนเอง ดังที่ Kent Beck กล่าวไว้ใน Implementation Patterns ว่า “ไม่มีความมหัศจรรย์ในการเขียนโค้ดที่คนอื่นสามารถอ่านได้ ก็เหมือนงานเขียนทั่วไป — รู้จักผู้ฟังของคุณ มีโครงสร้างโดยรวมที่ชัดเจน แสดงรายละเอียดเพื่อให้พวกเขามีส่วนร่วมในเรื่องราว”

ขั้นตอนสำคัญคือ ใส่ใจ สนใจความต้องการของผู้อื่น

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

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

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

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

Refactoring Tools

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

Collective Code Ownership เป็นเจ้าของโค้ดร่วมกัน

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

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

Coding Style

นำทั้งทีมมารวมกันเพื่อตกลงเกี่ยวกับรูปแบบการเขียนโค้ด

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

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

จากตัวอย่างในหนังสือ เช่น

• name our test classes Testxxx, not xxxTest
• Any NEW functions should be less than ten lines long

เมื่อทีมมีแนวทางการเขียนโค้ดแล้ว ให้พวกเขาพูดคุยกันเรื่องการวัดผลว่าพวกเขาทำได้ดีเพียงใด เทียบกับเกณฑ์มาตรฐานที่เลือกไว้

การทำให้ผลลัพธ์ปรากฏอยู่เสมอจะเป็นการเตือนทุกคนถึงข้อตกลงและยังแสดงให้เห็นว่าพวกเขากำลังรักษาข้อตกลงนั้นอยู่หรือไม่

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

คุณยังต้องระวังว่า ความเป็นเจ้าของโค้ดร่วมกัน อาจทำให้นักพัฒนาซอฟต์แวร์ละเว้นความรับผิดชอบต่อโค้ด ใน The Pragmatic Programmer — Andy Hunt และ Dave Thomas พูดถึงทฤษฎี “หน้าต่างแตก” ไว้ว่า สัญญาณเล็กๆ น้อยๆ ของการไม่สนใจโค้ดอาจนำไปสู่หายนะที่ใหญ่ขึ้น คุณอาจต้องพูดคุยกับพวกเขาเป็นรายบุคคลเพื่อรับทราบข้อกังวลของพวกเขา

• อาจมีบางส่วนของโค้ดที่แย่มาก
• หรือความขัดแย้งภายในทีมเกี่ยวกับปัญหาการออกแบบ
• หรือในที่ที่ทีมกำลังทำงานกับโค้ดเก่าที่ยุ่งเหยิง
• พวกเขาอาจรู้สึกหนักใจกับงานจัดการ/ทำความสะอาดข้อมูล

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

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

Pair Programming

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

ประโยชน์บางประการที่จะได้รับเมื่อเวลาผ่านไป

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

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

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

อธิบายว่าคุณกำลังทำอะไรและทำไม

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

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

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

pair programming นั้นเข้มข้นมาก ต้องใช้สมาธิอย่างมาก เป็นความคิดที่ดีที่จะหยุดพักทุกๆ ชั่วโมง สนับสนุนให้นักพัฒนาสลับคู่อยู่เสมอ

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

อุปสรรคที่อาจเจอ

นักพัฒนาไม่ชอบ pair programming

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

นักพัฒนาไม่ปฏิบัติตามแนวทางปฏิบัติในการเขียนโค้ดของทีม

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

แต่หากเขาทราบและจงใจฝ่าฝืนข้อตกลง นี่อาจเป็นสัญญาณว่า เขาอาจเหมาะสมในการทำงานกับทีมอื่นมากกว่า

ช่องว่างในภาษาการเขียนโปรแกรมสร้างอุปสรรคใน pair programming

ทีมของคุณอาจทำงานบนระบบหลายชั้น ที่เทคโนโลยีส่วนหน้า (frontend) ส่วนกลาง (middle) และส่วนหลัง (backend) แตกต่างกันมาก นักพัฒนาในทีมอาจพบว่าช่วงการเรียนรู้สูงเกินไปที่จะเปลี่ยนการเขียนโปรแกรมจากภาษาหนึ่งไปเป็นอีกภาษา

ในสถานการณ์นี้ แนะนำให้ทีมได้รับการฝึกอบรมหรืออ่านหนังสือเกี่ยวกับภาษาใหม่ก่อน เพราะ pair programming จะเหมาะสม เมื่อนักพัฒนาคุ้นเคยกับภาษานั้นเท่านั้น