บันทึกการเดินทาง#21 : Code Retreat @ Geeky Base


Code Retreat คือ ... (under construction)
    Code Retreat คือกิจกรรมคู่เป็นหมู่ๆ สำหรับโปรแกรมเมอร์ โดยโจทย์ที่ใช้ในการทำ Code Retreat คือ Conway's Game of Life อธิบายง่ายๆ คือนึกภาพตารางขนาด M x N เราจะเรียกมันว่า "Universe" โดยในแต่ละช่องจะมีสิ่งมีชีวิตที่เรียกว่า "Cell" โดยตัว Cell ก็มีสถานะคือ "มีชีวิต (alive)" และ "ตาย (dead)" โดยในแต่ละรอบของสิ่งมีชีวิตเหล่านั้น (Generation) ก็จะมีการเปลี่ยนสถานะของ Cell ต่างๆ โดยมีกฎดังนี้ ... 

  1. ถ้า Cell เพื่อนบ้านของ Cell มีชีวิตที่พิจารณา (8 Cells) มี Cell ที่มีชีวิตอยู่น้อยกว่า 2 ตัว Cell นั้นจะตายเพราะความเหงา (Under Population Rules)
  2. ถ้า Cell เพื่อนบ้านของ Cell มีชีวิตที่พิจารณา มี Cell ที่มีชีวิตอยู่เกิน 3 ตัว Cell นั้นจะตายเนื่องจากมีประชากรมากเกินไปในบริเวณดังกล่าว (Overcrownding Rules)
  3. ถ้า Cell เพื่อนบ้านของ Cell มีชีวิตที่พิจารณามี Cell ที่มีชีวิต 2 หรือ 3 ตัว Cell นั้นจะยังมีชีวิตอยู่ใน Generation ถัดไป (Next Generation Rules)
  4. ถ้า Cell เพื่อนบ้านของ Cell ที่ตายที่พิจาณามี Cell ที่มีชีวิต 3 ตัว Cell นั้นจะเปลี่ยนสถานะกลับมามีชีวิตอีกครั้ง (Reproduction Rules)
เท่านี้เองครับ โจทย์ Programming ที่ไม่ยาก และน่าสนใจทีเดียว คราวนี้กิจกรรม Code Retreat จะให้ Programmer แต่ละคนจับคู่กันทำ Pair Programming เพื่อเขียนโปรแกรมแก้โจทย์ Conway's Game of Life ในเวลา 45 นาที (โดยไม่ได้สนใจว่าจะทำเสร็จหรือไม่ สนใจที่วิธีในการแก้ปัญหา) โดยในการเขียนโปรแกรมนั้น ให้ยึดในแนวทางของการทำ Test Driven Development ให้มั่น และในแต่ละ Session จะมีเงื่อนไขที่ทำให้เราต้องคิดแตกต่างขึ้นกว่าเดิม ซึ่ง Programmer แต่ละคู่จะต้องใช้ข้อจำกัดที่มี ทั้งเรื่องเวลาและเงื่อนไขในการแก้ปัญหาดังกล่าว ... โดยถ้าจบในแต่ละ Session จะต้องวิ่งหา Pair ใหม่และลบ Code ทั้งหมดทิ้ง ... โดยในการเขียนโปรแกรมนั้นมีกฎเหล็ก 1 ข้อที่ควรจะยึดมั่นนั่นคือ


Session#1 Ruby with P'Tua
    Warm up! รอบแรกนี่ยังไม่มีอะไรมาก ผม Wrap up กฎและกติกาของ Game of Life ให้พี่ตั้วฟังแล้วนั่งคิด Test Case กัน (ซึ่งใช้เวลามากเกินไป) พอเขียนโปรแกรมก็ยังไม่ได้อะไรมาก ได้ตารางปล่าวๆ ขนาด N x M และที่สามารถกำหนด Alive Cell ลงไปได้ พี่ตั้วไม่เคยเขียน Ruby เลยได้แชร์กัน

Session#2 Java with Win
    หลังจากทำ Retrospective ก็ได้ไอเดียว่า โจทย์ข้อนี้มี Domain Problem ทั้งหมด 2 อย่าง คราวนี้ พี่ดีนพยายามให้บอกให้พวกเราฟังว่า เราควรจะมอง Domain Problem ให้ทั้งหมดให้ออก เพราะการที่เราคิด 2 อย่างพร้อมกันมันใช้เวลาเยอะ แล้วไม่มีจุด Focus ดังนั้นมองไม่ออก และแก้ทีละปัญหา คราวนี้เราเลย Focus ไปที่ Cell และ Rule ซึ่งสามารถทำได้ โดยไม่ต้องอาศัย Universe พอเราเริ่มเขียน คราวนี้เป็น Java ก็เขียนแบบธรรมดาเลย Logic เช็คปกติ เริ่มเห็น Duplicate Code ก็เลยแยก Class AliveRule และ DeadRule ออกมา จากนั้นก็หาวิธีที่จะทำแนวคิดที่หลีกเลี่ยงการใช้งาน Primitive Data Type (ซึ่งยังคิดไม่ออกเลย) ได้เห็นการใช้ Abstract ใน Java ด้วย ไม่ได้เขียน Polymorphism มานานแล้ว 

Session#3 PHP with P'Pui
    คราวนี้เป็นการ Adopt Polymorphism ลงในโค้ด เนื่องจากทำใน Java มาเมื่อ Session ที่แล้ว (นึกไม่ออกว่ามันคือ Polymorphism นี่หว่า) คราวนี้ได้ลองเขียน PHP เป็นภาษาที่ไม่เคยเขียนมันแบบจริงจังเลย ก็ได้ Coach ดีๆ อย่างพี่ปุ๋ยมา Pair และเขาชี้นำได้ดี ให้เห็นภาพว่าทำ TDD แล้วมันดียังไง เรากล้าที่จะรันโค้ดอย่างมั่นมากขึ้น ผิดก็แค่แก้เทสที่ผิด และชี้นำการ Adopt Polymorphism ได้ดีมากๆ จากที่ตอนที่เขียนด้วย Java เมื่อกี้ทำเพราะมันสวยดี คราวนี้เราได้รู้ประโยชน์จริงๆ (เพราะพิมพ์เองหมด) เนื่องจากการที Code เองเราเห็น Step ทั้งหมดว่าทำไมต้องทำ Polymorphism แยกทำไม เพราะเราเห็นพฤติกรรมที่เราจะต้องเขียน Code ซ้ำกัน ทำให้เราเขียนสั้นลงเรื่อยๆ แบบรู้สึกได้เลยล่ะ แม้ว่า PHP จะไม่สามารถทำ Polymorphism ได้ชัดแบบ Java ก็เลยใช้ Overriding Function แทน แต่มันอยู่ที่แนวคิดการที่เราส่ง Message เดียวกัน แต่ Implement พฤติกรรมด้านในต่างกันในขณะ Compile Time/ Runtime ถ้าเราสร้างพฤติกรรมดังกล่าวขึ้นมาได้ นั่นแหละคือ Polymorphism มันไม่ได้ขึ้นกับกลไกของภาษาแต่อย่างใด

Session#4 CoffeeScript with P'Neng
  No Return Statement นี่คือเงื่อนไขของ Session นี้ ผมกับพี่เหน่งนั่งคิดกันอยู่สักพัก เราสรุปกันได้ว่า เราจะต้องหาวิธีที่จะเปลี่ยนมันจากด้านในโดยที่ไม่ต้องส่งอะไรกลับมา สิ่งที่ผมคิดออกกลับได้ผลนั่นคือ Pass by Reference ซึ่งเคยเขียนอะไรแบบนี้ในภาษา C/C++  แต่เราจะเลือกเขียน CoffeeScript กันก็เลยต้องคิดใหม่ คราวนี้พี่เหน่งพยายามอธิบายลักษณะของ Immutable Object ให้ฟัง แล้วค้นข้อมูลกัน จากนั้นก็ได้ข้อสรุปว่า เราจะใช้วิธีนี้แหละ นั่นคือให้ Cell มี Instance Variable ชื่อ Status เพื่อเก็บสถานะ และเปลี่ยนมันด้วยวิธีใดๆ ก็ตาม จากนั้นก็ Get ค่า Status ตัวนั้นออกมาทำงาน ... ซึ่งตอนแรกผมก็แย้งไปว่า ถ้าเราเรียก instance.attr ก็เหมือนเป็นการทำ implicit return statement อยู่ดีไม่ใช่หรอ ... แต่เหมือนว่าวิธีนี้กลับเป็นวิธีที่ถูกต้อง เพราะพี่ดีนเดินมาบอกว่า สามารถใช้วิธีนี้ได้ เนื่องจากพี่เหน่งและผมเขียน Ruby เป็นทั้งคู่ ตอนเวลาเหลือ เรามานั่งย่อ Code เล่นกัน ได้เห็นความสวยงามของ Coffee Script ไปเต็มๆ ในขณะที่มันก็ยังสวยอยู่ ลองนั่ง Adopt Ruby ลงไป ว่าถ้าเป็น Ruby เราจะทำให้สวยได้อีกไหม ซึ่งเห็นท่า self.public_send แล้วเท่มากก

Session#5 Python with P'March
    Shortest Code โค้ดใน Body ของแต่ละฟังก์ชั่นห้ามเกิน 4 บรรทัด และห้ามส่ง message (เรียก method) ไม่ว่าจะเป็น . (dot notation) หรือ -> (PHP, C++) เกิน 2 chain เงื่อนไขแบบนี้คือเป็นการฝึกนิสัยในการเขียน Function ด้วยหลัก Single Responsibilty นั่นคือ 1 Function จะทำ Process เพียงอย่างเดียวเท่านั้น คราวนี้ผมเลือก Python ซึ่งทางพี่มาร์ชเคยเขียนแต่พวกภาษา Compiling เป็นหลัก ก็เลยทำให้เขา Wow! ได้ในหลายๆ ท่าของ Python เช่น Ternary Operator แบบ Python หรือ method ช่วยต่างๆ ที่ทำให้ Code ของเราโครตจะสั้น และทำตามเงื่อนไขทุกเงื่อนไขอย่างสบายๆ เลย ฮ่าฮ่า ส่วนผมน่ะหรอ เมาสิครับ เขียนผิด เขียนถูกเหมือนเคย เอา Syntax Ruby มาใช้บ่อยมาก = =' มึนๆ ต้องขอโทษที่มาร์ชด้วย ... อ่อ คราวนี้ได้ลอง Ping Pong ด้วย ผมอยากให้พี่มาร์ชได้ลองเขียน Python ผมเลยทำหน้าที่คุม Flow และเขียนฟังก์ชั่นปล่าวไว้ (pass) จากนั่นสลับให้พี่มาร์ชเป็นคน Implement ด้วย Python ... เขาเขียนปกติ เราก็แก้ให้มันสั้น มันสวย ... สิ่งที่น่าตลกคือ สุดท้ายแล้ว Code เราแม่งอ่านยากมาก จากเขียน If else ปกติเปลี่ยนไปใช้ Shorten If else ยังไม่พอเนื่องจากเราเลือกสถานะของ Cell แต่ละตัวให้เป็น Boolean เราก็เขียนโปรแกรมให้มันส่งค่า Boolean Statement กลับไปซะเลย ... นั่นแหละครับ โค้ดสั้นก็ไม่ใช่ว่าจะสวยเสมอไปนะ

Coding Dojo 
    พึ่งมารู้จักที่นี่แหละครับ เป็น Cool Down Session ที่ทางพี่รูฟและทีมงานจัดขึ้น เพื่อคลายเครียดผู้เข้าร่วมในวันนี้ ... ลักษณะของ Coding Dojo คือคอมพิวเตอร์เครื่องเดียว ทุกๆ คนเลือกภาษาสักภาษา แล้วช่วยกันเขียนโจทย์สักอย่างให้เสร็จ ในที่นี้ก็โจทย์ Game of Life เหมือนเดิม เวลาเท่าเดิม ไปๆ มาๆ ก็เลือก Ruby กันครับ มีคนเขียนเป็นอยู่ 2 คนคือ ผมกับพี่เหน่งก็ต้องคอย Guide กันสนุกดีครับ ผมเองก็ได้เห็นท่าใหม่ๆ ในการเขียน Rspec จาก Expert ด้วย เท่จริงๆ ...

    สนุกมากๆ ได้ร่วมคิด ร่วมทำให้ Code แม้จะเป็นส่วนเล็กๆ สวยขึ้นเรื่อยๆ เมื่อได้ Pair ก็ได้คุย ในขณะฟัง ผมพยายามทำตัวเป็นผู้ฟังที่ดี และในขณะพูดผมก็ให้เต็มที่เท่าที่รู้เหมือนกัน ได้แชร์ในสิ่งที่คิด กับคนที่มี Domain Knowledge คล้ายๆ กัน ช่วยกันแก้ปัญหา มันคือความสุข ความสนุก ที่ไม่ได้เจอมานานแล้ว ขอบคุณพี่รูฟ พี่ดีน และชาวสยามชำนาญกิจทุกคน ที่จัดกิจกรรมนี้ขึ้น อุ่นเครื่องก่อนจะไปเรียน Geeky Academe Batch 2 และอุ่นเครื่องสำหรับ Global Code Retreat ในกลางเดือนหน้า 

Popular posts from this blog

[Android Dev] การติดตั้ง Eclipse+AndroidSDK เพื่อพัฒนาโปรแกรมบน Android

12 วิธี การบริการและดูแลลูกค้าในร้าน Starbucks

5 TED Talk ที่จะช่วยให้คุณทำงานดีขึ้น