การผลิตซอฟต์แวร์ที่มีคุณภาพแพงกว่าจริงเหรอ

ถ้าพูดถึงเรื่องต้นทุนในการผลิตซอฟต์แวร์ เรามักจะนึกถึงค่าจ้าง programmer มานั่งเขียน Code ให้เรา ถ้าถึงเวลางานที่ได้เป็นไปตามเป้าหมายที่เราต้องการนั่นก็เป็นเรื่องที่ดี แต่ถ้าไม่ก็ต้องหาทางกดดันให้ได้ผลลัพธ์ที่ต้องการไม่ว่าด้วยวิธีการยังไงก็ตาม ปัญหาเกิดจากการ (under estimate) หรือการประเมินราคาออกมาต่ำเกินไปนั่นเอง

วันนี้เรายังไม่ได้พูดถึงเรื่องของการประเมินราคาของซอฟต์แวร์ แต่เราจะพูดถึงเรื่องของต้นทุนที่แท้จริงในการเขียนโปรแกรม ซึ่งนอกจากการจ้าง programmer มานั่งเขียน Code แล้วเรายังต้องมีต้นทุนในเรื่องของการทดสอบและแก้ไขเพื่อให้โปรแกรมทำงานได้ อย่างที่เราต้องการ

ซึ่งโดยต้นทุนของการคำนวนเรื่องของต้นทุน เราจะพูดถึงค่า Cost of Quality (COQ) ซึ่ง COQ จะมีสมการดังนี้

ซึ่งค่าของค่าของ Cost ทั้งสองตัวมีความหมาย ดังนี้

  • Appraisal Cost คือต้นทุนในการป้องกันปัญหา ไม่ให้เกิด
  • Failure Cost คือต้นทุนที่ทำการแก้ไขหลังจากเกิดปัญหาขึ้นมาแล้ว

คือทั้งสองตัวนี้จะเป็นต้นทุนในการแก้ปัญหาเหมือนกัน แต่ทั้ง 2 ตัวนี้จะทำก่อนเกิดปัญหาและหลังจากเกิดปัญหา ซึ่งวิธีในการป้องกันปัญหามีหลายวิธี เช่นการทำ Code Review หรือ Design Review (ในกระบวนการของการ Review ก็มีให้เลือกหลายวิธีด้วยกัน)

แต่เราจะทำการวิเคาระห์จากสมการนี้กันว่าจริงๆแล้วการผลิตซอฟต์แวร์ที่มีคุณภาพสูงนั้นต้องมีต้นทุนที่สูงจริงหรือไม่

เริ่มจากการทำความเข้าใจธรรมชาติของการผลิตซอฟต์แวร์  ต้นทุนของการแก้ไขข้อผิดพลาดหรือ จัดการกับ Bug นั้นจะสูงขึ้นเมื่อเวลาผ่านไป ยิ่งผ่านไปแต่ละ Phase ต้นทุนก็จะยิ่งสูงขึ้นเรื่อยๆ ดังนั้นต้นทุนในการ Fix Bug จะสูงที่สุดเมื่ออยู่ใน Operation หรือเอาไปใช้งานจริงเรียบร้อยแล้ว

ดังนั้น ถ้าเราเอาต้นทุนที่คิดจากเวลาของทีมงานที่ใช้ในการป้องกันปัญหา เช่น จากเดิมเราไม่เคยทำการ Review เลย เราต้องเสียเวลาของคนในทีม แทนที่จะได้เขียน code แต่ต้องมานั่งอ่าน Code ของเพื่อนแทน

ซึ่งเราจะเทียบง่ายๆว่า ถ้าเวลาในการอ่าน Code ของเพื่อน 1 ชั่วโมง กับเวลาที่เราใช้ในการจัดการ Bug ของเราเอง อันไหนน่าจะได้ผลงานมากกว่า ซึ่งในงานวิจัยโดยส่วนใหญ่เราจะพบว่าในเวลา 1 ชั่วโมงที่เสียไป กับการ review จะทำให้ Defect หรือ Bug ที่เกิดขึ้นลดลงอย่างเห็นได้ชัด เนื่องจากจะได้ Code ที่เขียนจาก 2 มุมมองคือ เจ้าของ Code และคน Review

ดังนั้นการที่เราทำการเสียเวลา ทำการ Reviewใน Phase ต้นๆ นั้นจะลดภาระใน Testing ไปได้เยอะ เราจึงสรุปได้ว่า การที่เราจะผลิตซอฟต์แวร์ที่มีคุณภาพที่สูงนั้น ไม่ได้มีต้นทุนที่สูงกว่าเสมอไป ขึ้นอยู่กับกระบวนการผลิตของแต่ละองค์กร ดังนั้นเราสามารถที่จะเพิ่ม Quality และลดต้นทุนได้พร้อมๆ กัน เรียกได้ว่ายิงปืนนัดเดียวได้นกสองตัวเลยทีเดียว

 

หลักการเขียนโปรแกรม ตอนที่ 3

การเขียนโปรแกรมที่ดีควรจะมีการทำ Coding Standard หมายถึงเอกสารที่เป็นข้อตกลงร่วมกันของคนในทีมพัฒนา เป็นแนวทางหรือรูปแบบในการเขียนโปรแกรม ไม่ว่าจะเป็นรูปแบบการประกาศตัวแปร หรือ การกำหนดโครงสร้างของ if-else รายละเอียดทุกอย่างในการเขียน Code จะอยู่ในเอกสารชุดนี้

แน่นอนว่าเราต้องมีการตรวจสอบอย่างสม่ำเสมอ ว่าในทีมพัฒนาได้มีการนำข้อกำหนดตัวนี้ไปใช้หรือไม่ ไม่เช่นนั้นก็จะกลายเป็นแค่เศษกระดาษชุดนึงเท่านั้นเอง

ตัวอย่าง Coding Standard ที่ใช้โดยทั่วไป

  • ชื่อ Class ต้องนำหน้าด้วยตัวใหญ่เสมอ
  • ชื่อ function และ ชื่อ Class จะเป็น CamelCase (แต่ละคำจะขึ้นต้นด้วยตัวใหญ่ เช่น PowertPivot, iPhone, getName เป็นต้น)
  • ใช้ 1 tab = 4 space
  • การตั้งชื่อตัวแปรที่เป็น Array หรือ Collection อื่นๆ เป็น พหูพจน์ ส่วนตัวแปรอื่นๆจะตั้งชื่อเป็นเอกพจน์

รูปแบบของการตรวจสอบอาจใช้การทำ Code Review  ซึ่งการทำ Code Review มีหลายรูปแบบด้วยกัน การ Review ที่ง่ายที่สุดจะเป็นการใช้ Peer Review คือให้คนในทีมที่ level ใกล้ๆกัน ทำการแลกกัน Review ก็จะเป็นการตรวจสอบการนำ Conding Standard ไปใช้ที่ง่ายที่สุด

นอกจากการ Review จะมีประโยชน์ในเรื่องของการตรวจสอบรูปแบบของ Code ให้เป็นไปตาม Conding Standard ยังได้ในเรื่องของการลด Defect หรือ ข้อผิดพลาดที่เกิดขึ้นลงได้ด้วย