Engineer Pratices,Testing,Visualization

Rule, Workflow and Technical Activity on Code Reviews

สิ่งสำคัญอย่างนึงที่ได้จากคลาส CSD แบบเน้น ๆ คือทุกเช้า 9:00 – 10:00 จะมีการทำ Code Reviews ซึ่ง Terry จะเอา Code ที่เขียนเมื่อวานขึ้นจอแล้วก็เริ่มจัดการ Reviews Code ในทุก ๆ ส่วนตาม Coding Agreement ที่กำหนดกัน 4 ข้อ โดยการไปอบรมครั้งนี้ผมเกือบจะจมอยู่กับ Robot Framework อาจจะมีบ้างก็ไปทำ Jenkins ให้ Start Server Tomcat เพื่อเทสแบบ Local แต่เวลาส่วนมากจะไปอยู่ที่การเขียน Script เพื่อทำ Automate Acceptance Test ส่วนนึงอาจจะเพราะวันแรก ๆ ผมเองอยากเขียน Robot Framework เลยหยิบ Task ของ Backlog Item แรกมาทำ พอรู้ตัวว่าอยากเขียน Java ก็ไม่เหลือแล้ว หลุดออกมาจากตรงนั้นก็เจอ Task Robot ของ Item ที่ 2 รออยู่ ผมจึงเป็นคนอาภัพที่อยากเรียน CSD Java แต่ไม่ได้เขียน Java เลย (T-T) แต่สิ่งดีที่ผมได้พบคือ หลังจากที่เราเขียน Robot Framework แล้วถูกเอามา Reviews ทั้งจาก Terry และ จั๊ว ทำให้ผมมองภาพของการเขียน ATDD เปลี่ยนไปเยอะมาก ๆ

ATDD มันคือเทส ???

ก่อนหน้านี้ผมมันจะ Map ATDD เข้ากับ Test Case เพียงแต่สิ่งที่มันต่างกันก็แค่ มันถูกเขียนออกมาก่อนที่จะมีการ Implement ซึ่งจะเป็นการ Drive ให้เกิด Code เหมือนกับ TDD หรือเปล่านั้น จริง ๆ ต้องบอกว่าผมยังมองไม่ค่อยออก แต่สิ่งที่มองว่ายังไง ๆ มันก็คือ Test มันทำให้ วิธีในการ Implement Test Case ใน Robot Framework (เริ่มไม่กล้าใช้ ATDD เพราะตอนที่ทำมันไม่ได้ Drive Code) ผมก็ซัดกันตรง ๆ คือ ต้องกรอกอะไรในช่องไหนแล้วผลออกมามันจะเป็นยังไง Coding ของ Robot จึงออกมาประมาณนี้

first step

ปรับเอา Technical Activity ออกไปหน่อย

จะเห็นได้ถึงความโหดส์ของ Robot ของผมซึ่งตอนนั้นผมก็รู้สึกธรรมดานะ ก็เราทำให้ Code เราสามารถ Execute ได้แล้วนี่ (ก็ไม่รู้สินะ) ผมก็เลยลุยต่อ โดยการเพิ่ม Test Case ที่ 2 เข้าไป เป็น Invalid Case พอถึงจุดนี้ พี่รุ่งที่ Pair คู่กับผมในวันแรกก็เริ่มทักว่า Input Text คืออะไรนะ มันดูเป็น Keyword (Robot Framework ใช้หลักการของ Keyword ในการทำเป็นเหมือน Method ต่าง ๆ ในการทำงาน) ที่เป็นทางด้าน Technic เกินไปยากต่อการอ่านเหมือนกันนะ เราเลยปรับ Code ของเราเพื่อให้อ่านเป็น Business มากขึ้นโดยไม่ยึดติดกับหน้า Web Page เราจึงสร้าง Fill In Recipients, Fill In Topic, Fill In Message มาเพื่อทดแทนเพราะ Fill In จะเป็น Web หรือ App ก็สามารถใช้คำนี้ได้

2

ถึงตอนนี้จะยังดูไม่ได้ต่างอะไรกับตอนแรก ๆ เท่าไหร่ แต่หลักการของเราคือค่อย ๆ เป็นค่อย ๆ ไปครับ อย่างเช่น Open Browser ซึ่งจำเป้นต้องมีการรอจนกว่า Page จะ Load เสร็จเราก็ยุบมันออกมาเป็น Open Sendmail Browser อะไรประมาณนั้น ลืมบอกไปว่าตอนนี้เราเขียน Robot แบบแห้งมาก เพราะเราไม่สามารถทดสอบได้เลยว่ามันทำงานได้จริง ๆ หรือเปล่าเพราะทางฝั่ง Dev ยังทำไม่เสร็จ สิ่งที่เราทำคือ ในแต่ละ Test Case เราจำเป็นต้องใส่ [Tags] not_ready เพื่อให้ Robot Framework รันเทสนี้โดยไม่แจ้งว่า Error

3

อย่าลืมกฏทั้ง 4 

พอมันเริ่มเข้าเค้าแล้วว่าจะเขียนออกมายังไง พวกผมเลยเริ่มเพลิน ใช้ Mode Hyper-productivity ปั้ม Code ออกมากันอย่างเมามันส์ โดยดูจาก Scenario Case ที่เราคุยกับ PO ไว้ และแน่นอนผมใช้คำว่าปั้มเพราะผมปั้มมันจริง ๆ (Copy-Paste ล้วน ๆ) เลยได้ Code ที่ Duplicate กันแบบสุดโต่ง แทนที่เราจะเพิ่ม Case แล้ว Re-factor ก็กลายเป็นเพิ่ม Case ไปเรื่อย ๆ ลืมทุกกฏ ลืมทุกความถูกต้อง แต่ตอนนั้นกำลังปั่นกันอย่างเมามัน เลยไม่ค่อยได้สนใจกับมันนัก และแล้วเราก็ได้กลับบ้านกันอย่างสุขใจ งานเดินตามปกติ โดยที่ไม่รู้เลยว่าเราเริ่มสร้าง สัตว์ประหลาด ลงใน Code ที่เป็น Test ของเราเรียบร้อยแล้ว

4

และแล้วก็เจอ Reviews ครั้งที่ 1 

แน่นอนว่าเรามี Reviews Code กันทุกวัน มาถึง Terry ก็เริ่มที่ Robot เลยซึ่งอารมย์ ณ ตอนนั้น ก็ยังมึน ๆ เบลอ ๆ กับ ขี้หูขี้ตาอยู่ ประโยคแรกที่ Terry ชมคือ Fill In เป็นอะไรที่ Make sense กว่า Input Text มาก ๆ  ยกความดีความชอบให้พี่รุ่ง … หลังจากนั้นเราก็โดนกระหน่ำด้วย Comment ประกอบการ แซวเล็ก ๆ อย่าง

  • เขาไปยืนอยู่นอก Geekbase ก็ยังเห็นเลยว่ามี Duplicate Code (T-T มันชัดขนาดนั้นเลย)
  • คำว่า Test Send Valid Email เนี่ยถ้าจะเขียน Test อย่าให้มีคำว่า Test ให้บอกไปเลยว่าเราทำอะไรแล้วได้อะไร เช่น ถ้าส่งเมลล์ที่ผิด Format จะเกิดอะไรขึ้น
  • ถึงเราจะเอา Input Text ออกมาเป็น Fill In แล้ว แต่มันก็ยังไม่ Practical เพราะเจ้าของ Product เขาไม่ต้องการรู้หรอกว่ากรอกอะไรบ้าง เขาแค่อยากเห็นภาพที่ใหญ่กว่านั้น
  • Code Robot ของเรารกมาก มีทั้ง Level ที่เป็น Technical และที่เหมือนจะเป็น Business อยู่ใน File เดียวกัน มันทำให้ยากต่อการ Focus ไปที่ Business Rule ของลูกค้า

หลังจาก Code Reviews ในส่วนของ Robot ซึ่ง Terry เน้นที่ Business Rule และลูกค้าสามารถอ่านมันแล้วเข้าใจเลยว่ามันคืออะไร ทำให้ผมเริ่มตะหงิด ๆ แล้วว่า เราไม่ได้ทำลังเขียน Test Script แล้วสินะ แต่เรากำลังจะได้ทำ Automate Specification ของจริง

ปรับ Code ให้อ่านง่ายขึ้นมาหน่อย

หลังจาก Reviews กับ Terry เสร็จก็มีการสลับคู่ Pair ผมหน่ะโดดออกอย่างเร็วเพราะผมเริ่มอยากเขียน Java กับเขาแล้ว ช่วงบ่ายเลยได้มีโอกาสไปทำ Java แล้ว แต่สักพักก็มีประเด็นว่าผมกับคู่ Pair จมอยู่และหาทางออกกันไม่ได้เลย ประจวบกับคู่พี่รุ่งที่ทำ Robot บน Jenkins อยู่นั้น พบปัญหาทำให้จมกันทั้งคู่เหมือนกัน เราเลยคุยกันว่าออกจากโคลนกันดีกว่า เลยทำการสลับคู่ Pair ผมเลยต้องกลับมาดู Robot ต่อ จึงเริ่มคุยกับคู่ Pair ว่าเอาสิ่งที่เราถูก Reviews เมื่อเช้ามา Re-factor ดีกว่า ซึ่งเราก็พยายามยุบให้เป็น Keyword ที่อย่างเช่น “Invalid Email Should Be Inform To Penny” เพื่อบอกว่า ถ้า Penny (เลขาของ PO) ส่ง Invalid Email นะจะต้องมีอะไรบางอย่างมา Inform Penny และตอนนี้ทุก Case เราเน้นไปที่การ Validate Email เราเลยสร้าง Keyword “Send Email About New Gadget To” เพื่อยุบขั้นตอนการกรอก Topic, Message และการกดส่งซ้ำ ๆ กัน มาเป็นประโยคเดียวเพื่อให้เข้าใจง่ายมาขึ้น เลยได้ Spec เริ่มหล่อส์นิด ๆ ออกมาดังนี้

6

Split Business Rule + แปลงเป็น Table ถ้าจำเป็น

พอเราเริ่มรู้สึกว่า Coding ของเราเริ่มสวย แน่นอนเราก็อยากจะ โชว์ให้ PO ได้ดูว่าเขาอ่านสิ่งที่เราสื่อได้เข้าใจอย่างที่เขาอยากได้ไหม PO (เทพ Robot) ก็ให้ Comment กลับมาดังนี้

  • ส่วนของ Keyword ที่อยู่ข้างล่างคืออะไรเลยเหรอ เขาอ่านไม่เข้าใจ
  • ส่วนของ Setting คืออะไร Library คืออะไร เขาต้องรู้ไหม
  • เขาเคยเห็นบางที่เขาแยก Success Case กับ Fail Case ออกจากกัน เพราะถ้าเกิดมีคนทำอะไรจน Fail Case รันไม่ผ่าน เขาก็อาจจะยอมให้ขึ้น Production ก็เป็นได้เพราะ Fail Case เราดขียนมาป้องกันการผิดพลาด แต่ Function หลักก็ยังสามารถทำงานได้อยู่
  • เขาเคยเห็นบางที่เขาทำข้อมูลเป็นตาราง ๆ มันดูง่ายดี ไม่ซ้ำ ๆ ซ้อน ๆ แบบนี้ ไปลองดูไหม
  • PO แนะนำให้แยก Rule กับ Workflow ออกจากกันไหมเพื่อให้เห็นชัดว่า Rule อย่าง “Invalid Email Should Be Inform To Penny” เนี่ยจริง ๆ จะมี Workflow เช่น ส่ง Email, Penny Will See ?, จะเเกิดอะไรต่อไป เป็นตัวบอกรายละเอียดของมันต้องทำอะไรบ้าง

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

7 8

109

Code Reviews อีกครั้ง โดย Terry

มาถึงตรงนี้ Code เราเริ่มสวยแล้ว (ในความคิดผมนะ) เพราะออกมาเป็นตารางที่พอจะดูง่าย แถมพยายามเขียนให้อ่านเป็นภาษาคน ไม่ได้เป็นภาษา Logic บ้างแล้ว ผมเองกระหยิ่มยิ้มย่องอยู่ว่ามันจะเหลืออะไรให้ Comment อีกเหรอไม่มีทาง แต่เราก็ยังโดนอยู่ดี

  • การใส่ คำว่า Rule กับ Workflow เข้าไปใน Test Case แปลว่าเราไม่สามารถอ่าน Code แล้วรู้เรื่องด้วยตัวมันเอง แถม Rule และ Workflow เป็น Term ของเราองไม่เกียวกับลูกค้า
  • การใส่คำประเภท Successfully, Failed เป็นคำที่ไม่ควรใส่เพราะอย่างนึงคือมันกำกวม ต้องมานั่งคิดอีกว่าอะไรคือ Success แทนที่จะบอกไปเลยว่าผลลัพท์จะเป็นยังไง
  • การใส่ Boolean true/false ลงใน Test Case หรือ ชื่อของเทสเคสเช่น “After Click Send It Will Return True” มันเป็นภาษา Technic ให้งดใช้มันเลย
  • Step ที่อยู่ภายใต้ Rule (Workflow) ควรจะอ่านแล้วอธิบายได้ว่าขั้นตอนการทำงานเป็นอย่างไร (ลูกค้าต้องอ่านรู้เรื่อง)
  • ส่วนไหนที่มีแค่บรรทัดเดียวจะทำ Table ทำไม แยกไม่ดีกว่าเหรอ

สรุป

หลังจากจบการ Reviews ของ Terry เราก็ลุยต่อจนได้ Robot ที่ผมคิดว่ามันอ่านรู้เรื่องได้ในระดับนึงเลย โดยผมลองเอา Source Code ของ Project นี้ขึ้นไว้บน Github เผื่อใครจะสนใจลองเอาไศึกษาดู สิ่งนึงที่เราต้องนึกอยู่เสมอในการทำ Robot คือเรากำลังเขียน Spec ที่ Execute ได้ และมันควรจะเป็น Spec ที่เป็น Business Rule จริง ๆ ไม่ใช่มีแต่ Technical  Activity เต็มไปหมด อ่านไม่รู้เรื่อง แถมยัง Maintain ยากส์อีก และจากการ Reviews ทั้งหมดนั้นจะเป็นได้ว่า Terry ไม่ได้สนใจเรื่อง Coding Format เลยเพราะคำที่ติดปากเขาอยู่เสมอคือ “Show your intent in your code” และ “The young people see your style, Please show your intention” หมายถึง Style ของแต่ละคนไม่เหมือนกัน ควรมองที่ เจตนาของ Code ที่เราเขียนว่า เราเขียนมันให้มันทำอะไร …

code reference : https://github.com/bomb0069/pennymail

 

 

 

Advertisements

ใส่ความเห็น

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