Uncategorized

Don’t Design Up-front : Code Reviews

ในกิจกรรม Sprint Planning Part II (Design) สิ่งที่ผมมักจะพาน้อง ๆ ในทีมทำ คือการ Design แบบลง Detail บางครั้งก็มั่วไปถึงขนาด ตามหา Method ที่ต้องแก้ การกำหนดว่าจะต้องมี Class อะไรอยู่ที่ไหน ซึ่งหลาย ๆ ผลมักจะออกมาไม่ดี เพราะทั้งต้องใช้เวลาเยอะ  ทั้งมีน้อง ๆ บางคนรู้สึกว่าเราลงรายละเอียดมากเกินไปหรือเปล่า ตัวผมเองซึ่งยังไม่มีหนทางออก ก็ทนกล้ำกลืน บางครั้งก็ Design ไม่ Detail สลับกันไปมาแล้วแต่เรื่อง แต่มาเจอ Class CSD เหมือนกับโดนตบกระโหลกแรง ๆ ไป 1 ที

จริง ๆ ใน Class CSD ก็มีการทำ Sprint Planning Part II และ Sprint 0 (เตรียม Environment) ในช่วงบ่ายของวันจันทร์แรก (ช่วงนี้ไม่ได้เข้าติดงาน … พลาดอย่างแรง)  ซึ่งตามปกติที่ผมเข้าใจก็คือการเอา Requirement ที่เลือกมาจาก Sprint Planning Part I มาช่วยกัน Design เลือก Solution แล้วก็แตก Task ย่อย ซึ่งก็ไม่ได้แหวกแนวอะไรนัก แต่มีข้อสังเกตุนึงที่ Terry แนะนำคือ

  • Design เป็น Activity ต้องมี Output
  • Design มอง “Make it complete only”
  • Design คือ Planning , Plan for Re-plan
  • Speculation of Design พูดถึง How much it work ? ,Split Work

ซึ่งสิ่งที่ทีมของผมเลือกก็คือเราจะใช้ Java และ Spring Framework ในการพัฒนา มาถึงจุดนี้ เราจึงเริ่มทำ Detail Design โดยคุยกันว่าจะต้องมี JSP, Spring Controller, Spring Service, ORM และอื่น ๆ อีกมากมาย แต่ละตัวจะชื่ออะไร จะคุยกันด้วย Protocol ไหน แต่ละคลาสจะมี เรียกกันยังไง จบตรงนี้เราก็เริ่มลงมื่อทำแต่เนื่องจากงานในตอนบ่ายส่วนมากจะเป็น การเตรียม Environment เพื่อให้พร้อมสำหรับทำงานในวันถัด ๆ ไป จบวันเราจึงได้ Environment ต่าง ๆ พร้อมใชในวันพรุ่งนี้

วันรุ่งขึ้นเราจึงเริ่มลุยงานที่เตรียมไว้ทั้งหมด ผลของการ Design ที่เราทำไว้ก็ออกมาแต่เป็นภาพที่ทุกคนพยายามทำ Unit ของตัวเองให้เสร็จก่อน แล้วจึงเอามารวมเพื่อประกอบเข้าด้วยกัน จริงอยู่ในวันแรก ๆ การทำ Code Reviews ของ Terry จะเน้นไปที่ระดับ Unit เพราะพวกเรายังเขียน Code/Test ด้วย TDD ได้ไม่คล่องมากนัก แต่สิ่งที่น่าสนใจเกิดขึ้นตอน Code Reviews ในวันต่อ ๆ มา Terry เน้นย้ำในสิ่งที่เรา Design ไว้ว่าเป็น Design Up-front จริง ๆ ผมเคยได้ยินคำนี้มานานมากแล้ว และผมเองก็เข้าใจว่ามันคือการ Design เผื่อมากจนเกินไป แต่พอมาเจอ Terry Comment ก็เริ่มรู้สึกว่า Up-Front แต่ละคนดูว่าจะไม่เหมือนกันซะแล้ว

ประเด็นแรก ในตอนทำ Sprint Planning Part II เราคิดกันว่าจำเป็นต้องมีการเก้บข้อมูลบางอย่างลง DB เพื่อให้มันไม่หายไปไหน แต่พอถามไปถามมา PO กลับบอกว่ายังไม่จำเป็นเขาอยากได้ของเอามาทำงานก่อน ยอมให้มันหายตอนที่ Server ถูก Restart ก็ยังได้ งาน Install DB Server, Design Table จึงมีอันต้องพับไปทั้ง ๆ ที่ทำไปบางส่วนแล้ว

มีสิ่งนึงที่ผมจำได้ตอน Reviews Class ที่เป็น Value Object ประมาณมี Setter/Getter เต็มไปหมดตาม Attribute ภายใน ซึ่ง Terry บอกว่าอย่าใช้ Tools Generate Getter อย่างพร่ำเพื่อ จะใช้อะไรก็สร้าง Getter สำหรับตัวนั้น

ประเด็นต่อมาคือ เมื่อเราตัดสินใจใช้ Spring MVC Framework เราจึงออกแบบทั้ง Class ของ Controller, Service และพยายามร้อยเรียงมันเข้าด้วย Annotation ทั้ง @Controller @Service รวมทั้ง @Autowired ซึ่ง Terry ถามในตอน Reviews Code ว่า ที่เขียน ๆ ไปเนี่ย Test First ไหม รู้ได้ไงว่ามันทำงานได้ มาถึงจุดนี้พวกเราถึงขั้นอึ้ง และพยายามตอบไปว่าเราทำเป็น Guide ของ Spring ที่ควรจะแยกเป็น Layer ต่าง ๆ แล้วทำให้สามารถถอด Dependency ของ Class แต่ละตัวออกจากกันได้ Terry ถามว่าไอ้ @Service กับ @Autowired มันจำเป็นจริง ๆ เหรอ หรือที่คุณทำก็เพราะ Framework บอกให้ทำ ระบบที่คุณทำอยู่ มันจะมีอะไรซับซ้อนจนถึงขั้นต้องทำ Dependency Injection กันเลยหรือเปล่า ถ้าสิ่งที่ Spring MVC ต้องการจริง ๆ คือมี Controller คอยรับ Request จาก Front-End ก็ควรจะ Design ให้มีแค่ส่วนนั้น เพื่อให้ระบบสามารถทำงานได้ โดยใช้พลังงานให้น้อยที่สุด การใส่ @Service กับ @Autowired ไปนั่นแปลว่าเรากำลังเริ่มคิดเผื่อแล้วแถมสิ่งที่ใส่เข้าไปไม่ใช่สิ่งที่ลูกค้าต้องการจริง ๆ สักหน่อย ส่วนมากจะเป็นเพราะ Developer ใส่สิ่งที่ตัวเองสนใจเข้าไปในงาน ก็เท่านั้นเอง

สิ่งที่ Terry ให้ข้อสังเกตุไว้อีกอย่างคือ เมื่อไหร่ที่เราเอา Framework มาใช้ต้องระวังดี ๆ เพราะ Framework มักจะมี Suite ของมันการเอาของเขามาใช้โดยไม่สนใจว่ามันใช้ทำอะไร หรือสักแต่ว่าใช้ ๆ ไปตามที่เขาบอกเนี่ยเป็นความเสี่ยงที่จะทำงานบนความไม่เข้าใจได้ …

สรุป

จากที่เข้า CSD เลยทำให้ได้เห็นว่า Design ที่อยู่ใน Sprint Planning Part II คือการ Design อย่างคร่าว ๆ เท่าที่จำเป็นเพื่อให้สามารถเห็นภาพร่างของระบบ สร้าง Task และแยกย่อย Task ต่าง ๆ ที่จำเป็นเพื่อสามารถแบ่งงานกันได้ ส่วนถ้าต้องการให้ Code สวย Reuse ได้ หรืออะไรก็ตาม ก็สามารถทำได้โดยการ Refactor ซึ่งก็คงค่อยว่ากันอีกที …

credit image : http://randomarchitecture.files.wordpress.com/2013/07/bduf-vs-emergent-design1.png?w=441&h=179

Advertisements

2 thoughts on “Don’t Design Up-front : Code Reviews

  1. แหะๆ สะดุดตา Spring MVC แล่ะ… แหล่งให้ถามอยู่ใกล้แค่เอื้อม…
    จะเขียน Spring ก็สนใจว่า ไอ Spring MVC มันน่าใช้ไหม หรือจะลดรูปเหลือแค่ Spring Core + Jersey แล้วเอา ColdFusion ครอบดีกว่า… กลับไปกลับมาหลายรอบแล้วเนี่ย
    ได้อะไรดีๆ ของ Spring MVC อย่าลืม blog นะคร้าบบบ

    1. อ่า … ผมยังตื้นเขินยิ่งนักครับ แค่ได้ลองเรียน/ใช้ใน geeky academy เท่านั้นยังไม่เคยเอามาใช้จริงเลย ส่วนตัวชอบ Spring Core มากครับ (เท่าที่เรียนมา) รู้สึกได้ว่ามัน minimum + powerful มาก ๆ

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s