Tag Archives: Pair Programming

สอน TDD, Rails ผ่าน Remote Pair Programming

ผมจำไม่ได้แล้วว่าผมแปะประกาศรับคนที่สนใจ TDD, Ruby, Rails มา pair ด้วยกันไว้ที่แถบด้านขวาของบล็อกและใน profile ของผมตั้งแต่เมื่อไหร่ น่าจะซักครึ่งปีได้ละมั้ง ตลอดเวลาที่ผ่านมาไม่เคยมีใครติดต่อมาเลยจนกระทั่งเมื่อ 3 อาทิตย์ก่อน มีผู้ขยันและกล้าหาญติดต่อมาคนแรก น้องวินปี 1 ลาดกระบังฯ ติดต่อมาว่าอยากจะศึกษา TDD เรานัดตอนหัวค่ำของวันนึงใช้ Google Hangout คุยกัน

ก่อนหน้านี้เคย remote pair ที่ไม่ใช่ตอนทำงานอยู่บ้างกับพี่รูฟ แต่ครั้งนี้จะเป็นครั้งแรกที่จะ remote pair กับคนที่ไม่เคยเขียน TDD มาเลย ช่วงนั้นเห็นพี่รูฟและหลายๆ คนเล่นโจทย์ Fizzbuzz กัน ก็เลยเอาโจทย์นี้แหละ

วันนั้นเราใช้ tmux/vim กัน โดยน้อง ssh เข้ามาที่เครื่องผม นี่คือโค้ดที่ได้จากวันนั้น

Continue reading

Advertisements

[Presentation note] Does pair programming have to suck?

ช่วงนี้ติดตาม podcast ของ Ruby Rouges อยู่เป็นประจำ เค้าคุยกันเรื่องสัพเพเหระของ software development เกี่ยวกับ Ruby บ้างไม่เกี่ยวกับ Ruby บ้าง แต่เข้าใจว่าผู้ร่วมรายการส่วนใหญ่เป็นคนที่ใช้ Ruby

แล้วได้ฟังตอน 049 RR Agile Communication with Angela Harms ได้ยินผู้ร่วมรายการคนหนึ่งชม presentation ของแขกรับเชิญในเทปนั้นเรื่อง pair programming มาก บวกกับยังมีอารมณ์ค้างจาก session Pair Programming Done Right ใน CITCON อยู่ เลยตามไปดู presentation นั้นซะหน่อย

Does pair programming have to suck?

เค้าก็พูดถึงประโยชน์ของ Pair Programming และเล่าถึงเหตุการณ์ไหนที่มักทำให้คนไม่อยาก pair เช่น

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

แต่การที่ pair ไม่ได้ด้วยเหตุผลข้างต้นนี้ อาจจะมองได้ว่าเรามีปัญหาหรือไม่อยาก communicate หรือเปล่า ซึ่งจริงๆแล้วสิ่งนี้เป็นสิ่งที่สำคัญที่สุดสำหรับ software development นะ

Screen_shot_2012-04-23_at_10

ประสบการณ์ Pair Programming

เริ่มทำงานที่ปัจจุบันมาได้เดือนกว่าๆ ได้มีโอกาสทำ Pair Programming ตลอดเวลา เลยมีประเด็นต่างๆ ที่สังเกตได้มาเล่าให้ฟังครับ

เริ่มจากตัว pair programming เองก่อน

  • มันบังคับให้เรา concentrate กับงานได้ 8 ชั่วโมงเต็มๆ จริงๆ ลืมไปได้เลย social networks, blogs ข่าวต่างๆ หรือแม้กระทั่งเวลานั่งง่วง เหม่อ
  • ทำให้เราต้องมีเหตุผลในการทำสิ่งต่างๆ มากขึ้น ความผิดพลาดจากการลืมทำบางอย่าง หรือพิมพ์ผิด น้อยลงมาก เพราะมีคนคอยจ้องเราพิมพ์ตลอดเวลา
  • ได้เรียนรู้นิสัย วิธีคิดของเพื่อนร่วมงานอย่างรวดเร็ว เพราะต้องคุยกันตลอด
  • เรียนรู้สิ่งใหม่ๆ ได้เร็วขึ้น เช่น ภาษาใหม่, framework ใหม่, domain knowledge ใหม่, codebase ของบริษัท
  • ได้ศึกษา tips หรือ technique ในการเขียนโปรแกรมของคนอื่น มาปรับใช้กับตัวเอง เช่น short-key, สไตล์การ debug, สไตล์การ organize code
  • ลดโอกาสการเรียนรู้บางอย่างในเวลางาน พวกทักษะที่ต้องใช้เวลาในการเรียนรู้ ไม่ใช่เห็นแล้วจำได้ทันที จะไม่มีเวลาได้ทดลองหัด เพราะจะโดน pair แย่งทำอย่างรวดเร็ว ส่วนตัวที่เจอคือ RegEx กับ SQL ต้องกลับมาทำการบ้านทดแทน

ส่วนพฤติกรรมของ pair ที่สังเกตได้มีดังนี้

  • พฤติกรรมการเคาะ keyboard (Esc, Ctrl-C)แรงๆหลายๆที เวลาเครื่องแฮงค์/ตอบสนองช้า เป็นพฤติกรรมที่ไม่ค่อยหน้าอยู่ใกล้เลย รู้สึกมันทำให้บรรยากาศดูเครียด ส่วนตัวคิดว่าตัวเองก็ทำอยู่บ้าง ต่อไปจะพยายามไม่ทำ
  • การหลุด focus ขณะที่เราทำ task หนึ่งๆอยู่ บางครั้งเราจะหลุดไปทำอย่างอื่น เช่น เห็น code หรือ CSS เน่า(ที่ส่วนอื่น)แวะผ่านตาก็แวบไป clean มัน การหลุด focus แบบนี้ส่งผลมากกว่าที่คิด นอกจากจะทำให้ task ที่ทำอยู่เสร็จช้าลงแล้ว บางทีอาจพบปัญหา code พังโดยไม่รู้ว่าผิดที่การแก้ไขตรงไหน, ทำให้ commit ของเราไม่ clean กลายเป็น commit ที่ทำหลายอย่างไป และหลายๆครั้งที่สิ่งที่หลุดไปแก้มันยากเกินที่จะทำให้เสร็จในเวลาอันสั้น กลายเป็นครึ่งๆ กลางๆ ไม่สามารถถอยกลับได้ และถ้าไม่ระวังตัวให้ดีจะเกิดซ้อนๆๆๆ กันยิ่งยุ่งไปใหญ่
  • คนที่รู้ว่าควรทำอะไร แต่ไม่ทำหรือไม่เห็นความสำคัญที่จะทำ พูดด้วยยากกว่าคนที่ไม่รู้เยอะ
  • คนชอบทำเผื่อ “เดี๋ยวก็ได้ใช้”, “มันจะได้ยืดหยุ่น” ก็พูดด้วยยากเหมือนกัน
  • คนที่ชอบเขียน production code ก่อน test code เมื่ออยากรู้ functionality ใดๆ ก็จะไปเปิด code ดูก่อนเสมอ ทำให้ไม่เห็นความสำคัญของการเขียน test code ให้อ่านรู้เรื่อง เราควรเขียน test code ให้เราอยากอ่านเวลาต้องการรู้ functionality มากกว่า production code

แถมสิ่งอื่นๆ ที่ได้ ระหว่างการ pair

  • เราควร give point ให้ task เมื่อรู้แล้วเท่านั้นว่าต้องทำอย่างไร ให้ task นี้เสร็จ ถ้าไม่สามารถรู้ได้ อาจจะเป็นสัญญาณบอกว่า task นั้นใหญ่เกินไปต้องหาทางหั่นลงมาอีก
  • การเขียน test code หลัง production code มักทำให้เกิด production code ที่ทำงานเกินความต้องการเสมอ