จะรีบอย่างไรก็ต้องมีเวลาสำหรับเขียน Unit Testing
ช่วงนี้เราออก KnowledgeVolution ที่เพิ่มและเปลี่ยนแปลงความสามารถไปในหลายจุดเพื่อให้ใช้ในองค์กรได้ โดยเฉพาะสำหรับ share.psu.ac.th และทดลองใช้ใน GotoKnow นี่เป็นที่แรก
ในขณะเดียวกันเราก็ต้องเดินทางไป กทม. บ่อยมากในช่วงเดือนที่ผ่านมานี้ ทำให้ไม่มีเวลาแก้ไขปัญหาของระบบที่ผู้ใช้พบทันเวลาอย่าง best practices ที่เราพัฒนาขึ้น
ปัญหาของระบบที่เจอในช่วงนี้มีสองอย่างคือ usability problems และ functional problems
ปัญหาการใช้งาน (usability problems) นั้นเป็นปัญหาที่ต้องทดสอบกับผู้ใช้ อะไรที่ผู้ใช้ใช้ไม่ได้หรืองง นั่นคือ usability problems เพราะระบบที่ไม่มี usability problems คือระบบที่ผู้ใช้ใช้ได้โดยไม่ต้องคิด (intuitively without much thinking)
วิธีจัดการกับ usability problems คือนักพัฒนาต้องทดสอบกับผู้ใช้กลุ่มตัวอย่างก่อน แต่เราก็ไม่มีเวลาจัดหาผู้ใช้กลุ่มตัวอย่างในช่วงที่ผ่านมาอย่างเป็นระบบ และเราพัฒนา best practices ของเราเองในเรื่องนี้ คือใช้จริงเลย ถ้ามีปัญหาก็รีบแก้ทันที (on the spot)
ต่อไปถ้าได้มะปรางมาช่วยก็คงจัดการกับ usability problems ได้ดีขึ้น
ส่วนปัญหาของระบบ (functional problems) นั้นเป็นปัญหาที่ระบบทำงานผิดพลาด (bugs) ซึ่งปัญหาพวกนี้เป็นปัญหาที่จัดการได้โดยซอฟต์แวร์เอง วิธีการนั้นเรียกว่า Unit Testing
โดยพื้นฐานแล้ว Unit Testing คือการเขียนโปรแกรมคู่ขนานมาประกบโปรแกรมหลัก โดยโปรแกรมคู่ขนานนั้นจะทำการ "ใช้" โปรแกรมหลักเสมือนว่าเป็นผู้ใช้ โดยโปรแกรมคู่ขนานนั้นจะทดสอบโปรแกรมหลักเป็นส่วนๆ ไป (อ่านรายละเอียดต่อ )
unit tests เป็นโปรแกรมที่ผู้ใช้ไม่ได้ใช้ แต่เป็นโปรแกรมที่ทดสอบโปรแกรมหลักที่ผู้ใช้จะใช้งานจริง
ที่ผ่านมาผมไม่ได้เขียน unit tests เพราะ KnowledgeVolution ยังไม่ซับซ้อนเท่าไหร่ ยังรับหา bugs ด้วยมือได้ แต่พอผ่านมาเรื่อยๆ ความซับซ้อนเพิ่มขึ้นมา ผมก็ยังบอกตัวเองว่า "ค่อยเขียน" หรือ "ค่อยจ้างคนมาช่วยเขียน" เพราะการเขียน unit testing เป็นการฝึกคนอย่างเยี่ยมทีเดียว
ที่จริงแล้ว Ruby on Rails นั้นมีความสามารถที่ช่วยในการเขียน unit tests ได้อย่างสะดวกดีมาก (อ่านรายละเอียดต่อ )
การไม่เขียน unit tests ของผมเป็นการตัดสินใจที่ผิดอย่างยิ่ง เหมือนกับสำนวนอุปมาทาง software engineering ต่อไปนี้
I don't have time to stop for gas. I'm late now!! (ผมไม่มีเวลาจอดรถเพื่อเติมน้ำมัน ผมสายแล้ว!!)
ปรากฎว่าการไม่มี unit tests นั้น ทำให้ functional problems โผล่มาเป็นแถวเวลาเพิ่มหรือเปลี่ยนแปลงระบบ โดยเฉพาะในช่วงที่ไม่มีเวลาต้องเดินทางบ่อยเช่นนี้ เราไม่มีเวลาเข้าไปจัดการ "ด้วยมือ" อย่างเร็วก็ส่งผลกระทบแก่ผู้ใช้ทันที
บทเรียนสำหรับวันนี้คือ "อย่าบอกว่าไม่มีเวลาสำหรับเขียน unit tests" เพราะ unit tests จะช่วยลดเวลาในการหา bugs ในภายหลังอย่างมากมายมหาศาล
และสำหรับ live application ที่กำลัง up and running ใช้งานจริง (อย่าง KnowledgeVolution) นั้น "อย่าเริ่มเขียน unit tests ตอนที่ระบบซับซ้อนแล้ว เพราะจะเสียเวลา และทุกนาทีที่เสียเวลากับการเริ่มต้นนั้นคือปัญหาที่ผู้ใช้ต้องเจอ"
ตอนนี้ผมกลับใจมานั่งเขียน unit tests แล้วครับ
ในขณะเดียวกันเราก็ต้องเดินทางไป กทม. บ่อยมากในช่วงเดือนที่ผ่านมานี้ ทำให้ไม่มีเวลาแก้ไขปัญหาของระบบที่ผู้ใช้พบทันเวลาอย่าง best practices ที่เราพัฒนาขึ้น
ปัญหาของระบบที่เจอในช่วงนี้มีสองอย่างคือ usability problems และ functional problems
ปัญหาการใช้งาน (usability problems) นั้นเป็นปัญหาที่ต้องทดสอบกับผู้ใช้ อะไรที่ผู้ใช้ใช้ไม่ได้หรืองง นั่นคือ usability problems เพราะระบบที่ไม่มี usability problems คือระบบที่ผู้ใช้ใช้ได้โดยไม่ต้องคิด (intuitively without much thinking)
วิธีจัดการกับ usability problems คือนักพัฒนาต้องทดสอบกับผู้ใช้กลุ่มตัวอย่างก่อน แต่เราก็ไม่มีเวลาจัดหาผู้ใช้กลุ่มตัวอย่างในช่วงที่ผ่านมาอย่างเป็นระบบ และเราพัฒนา best practices ของเราเองในเรื่องนี้ คือใช้จริงเลย ถ้ามีปัญหาก็รีบแก้ทันที (on the spot)
ต่อไปถ้าได้มะปรางมาช่วยก็คงจัดการกับ usability problems ได้ดีขึ้น
ส่วนปัญหาของระบบ (functional problems) นั้นเป็นปัญหาที่ระบบทำงานผิดพลาด (bugs) ซึ่งปัญหาพวกนี้เป็นปัญหาที่จัดการได้โดยซอฟต์แวร์เอง วิธีการนั้นเรียกว่า Unit Testing
โดยพื้นฐานแล้ว Unit Testing คือการเขียนโปรแกรมคู่ขนานมาประกบโปรแกรมหลัก โดยโปรแกรมคู่ขนานนั้นจะทำการ "ใช้" โปรแกรมหลักเสมือนว่าเป็นผู้ใช้ โดยโปรแกรมคู่ขนานนั้นจะทดสอบโปรแกรมหลักเป็นส่วนๆ ไป (อ่านรายละเอียดต่อ )
unit tests เป็นโปรแกรมที่ผู้ใช้ไม่ได้ใช้ แต่เป็นโปรแกรมที่ทดสอบโปรแกรมหลักที่ผู้ใช้จะใช้งานจริง
ที่ผ่านมาผมไม่ได้เขียน unit tests เพราะ KnowledgeVolution ยังไม่ซับซ้อนเท่าไหร่ ยังรับหา bugs ด้วยมือได้ แต่พอผ่านมาเรื่อยๆ ความซับซ้อนเพิ่มขึ้นมา ผมก็ยังบอกตัวเองว่า "ค่อยเขียน" หรือ "ค่อยจ้างคนมาช่วยเขียน" เพราะการเขียน unit testing เป็นการฝึกคนอย่างเยี่ยมทีเดียว
ที่จริงแล้ว Ruby on Rails นั้นมีความสามารถที่ช่วยในการเขียน unit tests ได้อย่างสะดวกดีมาก (อ่านรายละเอียดต่อ )
การไม่เขียน unit tests ของผมเป็นการตัดสินใจที่ผิดอย่างยิ่ง เหมือนกับสำนวนอุปมาทาง software engineering ต่อไปนี้
I don't have time to stop for gas. I'm late now!! (ผมไม่มีเวลาจอดรถเพื่อเติมน้ำมัน ผมสายแล้ว!!)
ปรากฎว่าการไม่มี unit tests นั้น ทำให้ functional problems โผล่มาเป็นแถวเวลาเพิ่มหรือเปลี่ยนแปลงระบบ โดยเฉพาะในช่วงที่ไม่มีเวลาต้องเดินทางบ่อยเช่นนี้ เราไม่มีเวลาเข้าไปจัดการ "ด้วยมือ" อย่างเร็วก็ส่งผลกระทบแก่ผู้ใช้ทันที
บทเรียนสำหรับวันนี้คือ "อย่าบอกว่าไม่มีเวลาสำหรับเขียน unit tests" เพราะ unit tests จะช่วยลดเวลาในการหา bugs ในภายหลังอย่างมากมายมหาศาล
และสำหรับ live application ที่กำลัง up and running ใช้งานจริง (อย่าง KnowledgeVolution) นั้น "อย่าเริ่มเขียน unit tests ตอนที่ระบบซับซ้อนแล้ว เพราะจะเสียเวลา และทุกนาทีที่เสียเวลากับการเริ่มต้นนั้นคือปัญหาที่ผู้ใช้ต้องเจอ"
ตอนนี้ผมกลับใจมานั่งเขียน unit tests แล้วครับ
หมายเลขบันทึก: 81960เขียนเมื่อ 5 มีนาคม 2007 09:19 น. ()แก้ไขเมื่อ 22 มิถุนายน 2012 16:14 น. () สัญญาอนุญาต: จำนวนที่อ่านจำนวนที่อ่าน:
ความเห็น (5)
ยิ่งภาษาแบบ dynamic typing แบบ Ruby แล้ว Unit testing ก็ยิ่งสำคัญใหญ่
แต่ว่าไปผมก็เคยใช้ unit test แค่กับ library ที่เขียนด้วย python ยังไม่เคยเอามาใช้กับ web app ที่เขียนด้วย Rails เลย ดังนั้น ขอบคุณสำหรับ ลิงก์ ที่อาจารย์ ให้มาอ่านนะครับ ;-)
ขอขอบคุณอาจารย์ธวัชชัย...
- ผมไม่มีองค์ความรู้ด้าน software
- ทว่า... แวะมาขอบพระคุณอาจารย์สำหรับความพยายามเพื่อสังคมไทยมาโดยตลาดครับ... สาธุ สาธุ สาธุ
ขอบคุณอาจารย์หมอวัลลภที่มาเยี่ยมครับ
คุณวีร์ครับ unit testing ของ Python ก็มีอยู่หลาย framework นะครับ แต่ช่วงนี้ผมไม่ได้ใช้ Python เลย ที่จริงแล้วผมชอบ Python มากกว่า Ruby อีกครับ
ผมชอบ Ruby มากกว่า Python นะครับ แต่เขียน Python ด้วยหน้าที่การงาน :-P
test unit ผมใช้ตัวที่มากับ package หลักของ python เลยอะครับ import unittest
ถึงจะมี unittest แต่ก็มีแบบ แย่ๆ หน่อย -_-'