จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 1)

16 Apr
2008

ผมขอเริ่มต้นการจุดประกายครั้งแรก ด้วยหัวข้อ “ทำไม Softwareต้องมี bug” ด้วยเหตุผลสองประการครับ

หนึ่งการมีตัวตนของ software bug เป็นต้นกำเนิดของอาชีพ software tester (สงสัยนี่ก็อาจเป็นส่วนนึงที่ทำให้ชื่อ webนี้เป็น welovebug กระมังครับ 555)

สอง - เคยมีคน(นอกวงการ IT)ถามผมว่า ทำไมคนในวงการ ITก็มีแต่เก่งๆทั้งนั้น projectแต่ละอันก็ราคาหลายแสนหลายล้านแต่ก็ยังทำระบบที่ไม่มีbugออกมากันไม่ได้ แม้กระทั่งบริษัทชื่อดังและรวยที่สุดอย่าง Microsoftก็ตาม (ตอนโดนถามก็จุกใช่เล่นครับ)

ก่อนที่จะไปไล่ดูสาเหตุของ software bug/defect กัน เรามาลองทำความเข้าใจให้ตรงกันก่อนดีมั๊ยครับ ว่า bug คืออะไรผมได้ไปรวบรวมมาจาก 3 แหล่งซึ่งความหมายค่อนข้างใกล้เคียงกันครับ

Wikipedia ซึ่งดูเหมือนจะเข้าใจง่ายที่สุด: A software bug (or just “bug”) is an error, flaw, mistake, “undocumented feature”, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result).

ISEB/ISTQB จะออกแนวทางการขึ้นมานิดๆ : A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.

CSTE ซึ่งแยกเป็นการมองสองมุมที่น่าสนใจไม่น้อย คือมุมผู้ผลิต กับมุมมองลูกค้า:
มุมผู้ผลิต : a product requirement that has not been met or a product attribute possessed by a product or a function performed by a product that is not in the statement of requirements that define the product;
มุมลูกค้า : anything that causes customer dissatisfaction, whether in the statement of requirements or not.

เอาล่ะครับ ได้เวลาไปไล่ดูสาเหตุของเจ้า software bug นี้กันแล้วครับผมจะเริ่มเปิดด้วยประเด็นแรกก่อนด้วยfocusที่ว่า การทำงานกับ software มีความซับซ้อนอยุ่หลายมิติปนๆกันอยู่ ลองไปดูกันเลยครับ

– Complexity and unique characteristics of software ด้วยลักษณะเฉพาะของ software

  • [1] software เป็นสิ่งที่จับต้องไม่ได้ – พอจับต้องไม่ได้ ก็สื่อสารยาก การวาดรูปหรือใช้ prototype tool ก็ไม่สามารถครอบคลุมทุกด้านของ spec ซึ่งยังจะมีส่วนประกอบหลักเป็น business logic ได้ อีกทั้งพอจับต้องไม่ได้ การ test ก็ทำได้ยากขึ้นเช่นกัน ต่างกับวิศวกรรมบางประเภท ที่สามารถจะ detect จุดบกพร่องได้ด้วยตาเปล่า เช่นสังเกตุจาก สี หรือเนื้อวัสดุที่ไม่ปกติ (โยธา) เสียงที่เกิดขึ้น หรือกลิ่นที่เกิดขึ้นจากการผิดปกติของการทำงาน (เครื่องกล) – พอจับต้องไม่ได้ การที่จะอธิบายว่าโครงสร้างหรือ design ของ software นั้นไม่สามารถ support change request หรือ new feature บางอย่างได้ ก็เป็นเรื่องที่ยากขึ้น ต่างกับการสร้างบ้าน ที่เมื่อตอกเสาเข็มสำหรับบ้านสองชั้นไปแล้ว ก็จะเป็นที่รู้กันว่า อยู่ๆจะเปลี่ยน spec บ้านเป็นสามชั้นเนี่ย เป็นงานช้างไม่คุ้มแน่ๆไม่ได้ เมื่อเป็น software แล้วลูกค้าส่วนใหญ่มักเชื่อว่า อะไรก็แก้ได้ แค่ปรับ code ซึ่งในความเป็นจริงแล้ว software ก็มีโครงสร้างของมันเอง และการปรับเปลี่ยนบางอย่าง ก็อาจส่งผลกระทบต่อโครงสร้างค่อนข้างมากและเป็นการสร้างความเสี่ยงต่อความเสถียรของระบบได้เช่นเดียวกัน
  • [2] software ไม่มีวัสดุ ไม่มีอะไหล่ เนื้องานของ software คือการนำลำดับความคิดของ programmer มาแปลงให้อยู่ในรูปแบบของ code ล้วนๆ เรื่องนี้มีปัจจัยสามอย่างที่ผมอยากจะยกขึ้นมาคือ 1. การแบ่งงานกันทำหรือประสานงานระหว่างบุคคลเป็นไปได้ยาก หากไม่มี document ที่เป็นแนวทางอย่างชัดเจน (เช่น coding comment, technical document) 2. การซ่อม/ปรับปรุงจุดบกพร่อง โดยเฉพาะในส่วนที่ตัวเองไม่ได้เป็นคนทำ เนื่องจากไม่สามารถไปหาซื้ออะไหล่ที่ดีมีแทนส่วนที่เสีย การซ่อม/ปรับปรุงsoftwareจึงจำเป็นจะต้องวิเคราะห์เพื่อทำความเข้าใจ code ที่มีอยู่ก่อนและดูถึงผลกระทบที่อาจเกิดขึ้นได้จากการแก้ code นั้นๆได้ 3. จริงอยู่ที่ว่า software สมัยใหม่หลายคนอาจมองว่าการใช้ third party tool หรือ DBMS ที่มีอยู่แล้วก็อาจมองเป็นอะไหล่หรือส่วนประกอบได้ หากแต่ความเป็นจริงแล้ว การเอา tool เหล่านี้มาใช้ก็มีทั้งข้อดีและข้อเสีย เพราะโดยปกติ tool พวกนี้แม้จะเป็น tool ที่มีการใช้กันอย่างแพร่หลาย ก็ยังมี bug ในตัวของมันเอง และการเอาระบบพวกนี้มาพัฒนาร่วม หรือพัฒนาต่อก็เป็นการเพิ่มความเสี่ยงในแง่ของ bug ที่จะเกิดขึ้นได้ด้วย …

สำหรับตอนที่ 1 นี้ผมขอทิ้งท้ายไว้แค่นี้ก่อน เพราะอยากให้หัวข้อจุดประกายเป็นการเกริ่นนำให้การครุ่นคิดโดยผู้อ่านได้ร่วมคิดไปด้วย มากกว่าจะเป็นการสื่อสารทางเดียว และอีกเหตุผลนึงคือผมอยากให้แต่ละตอนอ่านง่ายและไม่ยาวจนเกินไป ไว้ภายใน weekend ผมจะมาต่อตอนสองให้ครับ ระหว่างนี้ ถ้าใครแวะมา อยากจะให้ช่วย post comment กันได้ตามสบายเลยนะครับว่า คุณคิดว่าอะไรที่ทำให้ software ต้องมี bug แ้ล้วมาดูกันตอนสองครับว่าใจเราจะตรงกันมั๊ย ยังไงรับรองได้ หัวข้อของผมก็ไม่มีทางครอบคลุมที่ผู้อ่านแต่ละคนจะมา post รวมกันหมดได้หรอกครับ

Till this weekend .. with ทำไม Softwareต้องมี bug (ตอนที่ 2)

1 Response to จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 1)

Avatar

kira7

August 21st, 2008 at 8:26 am

ถ้าระบบซับซ้อนมากยังไงก็ต้องมีบั๊กอยู่ดีละครับ ไม่รู้สิ

Comment Form

top