ช่วงนี้เราออก 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 แล้วครับ