Topic 5: Good-Enough Software

บ่อยครั้งที่ความพยายามจะทำให้ดียิ่งขึ้น กลับทำให้สิ่งที่ดีอยู่แล้วเสียไป

Shakespeare , King Lear 1.4

มีเรื่องตลกเก่าแก่เรื่องหนึ่งเกี่ยวกับบริษัทที่สั่งซื้อ IC จำนวน 100,000 ตัวจากผู้ผลิตสัญชาติญี่ปุ่น ส่วนหนึ่งของสเปกที่ระบุไว้คืออัตราของเสีย: 1 ชิ้นต่อ 10,000 ชิ้น ไม่กี่สัปดาห์ต่อมา สินค้าที่สั่งก็มาถึง: กล่องใหญ่หนึ่งกล่องบรรจุ IC หลายพันตัว และกล่องเล็กอีกหนึ่งกล่องที่มีแค่สิบตัว บนกล่องเล็กมีป้ายติดไว้เขียนว่า “นี่คือตัวที่เสียครับ”

ถ้าเราควบคุมคุณภาพได้แบบนี้จริงๆ ก็คงดีไม่น้อยครับ แต่โลกความเป็นจริงไม่เคยยอมให้เราสร้างอะไรที่สมบูรณ์แบบได้จริงๆ โดยเฉพาะซอฟต์แวร์ที่ปราศจากบั๊ก ทั้งเวลา เทคโนโลยี และอารมณ์ของคนเรา ต่างสมคบกันขัดขวางเราอยู่เสมอ

อย่างไรก็ตาม เรื่องนี้ไม่จำเป็นต้องทำให้เราหงุดหงิดครับ ดังที่ Ed Yourdon ได้อธิบายไว้ในบทความใน IEEE Software, When good-enough software is best  [You95] คุณสามารถฝึกวินัยให้ตัวเองเขียนซอฟต์แวร์ที่ “ดีพอ”—ดีพอสำหรับผู้ใช้ของคุณ สำหรับคนที่จะมาดูแลต่อในอนาคต และสำหรับความสบายใจของตัวคุณเอง คุณจะพบว่าตัวเองมีประสิทธิภาพในการทำงานมากขึ้น และผู้ใช้ของคุณก็มีความสุขมากขึ้นด้วย แล้วคุณอาจพบด้วยว่าโปรแกรมของคุณดีขึ้นจริงๆ เพราะใช้เวลาบ่มเพาะสั้นลง

ก่อนที่จะพูดต่อไป เราขอทำความเข้าใจให้ตรงกันก่อนครับ คำว่า “ดีพอ” ไม่ได้แปลว่าโค้ดที่สะเพร่าหรือผลิตออกมาอย่างลวกๆ ระบบทุกระบบต้องตอบโจทย์ความต้องการของผู้ใช้จึงจะประสบความสำเร็จได้ และต้องผ่านมาตรฐานพื้นฐานด้าน Performance ความเป็นส่วนตัว และความปลอดภัยด้วย สิ่งที่เราอยากสนับสนุนก็แค่ให้ผู้ใช้มีโอกาสเข้ามามีส่วนร่วมในการตัดสินใจว่าสิ่งที่คุณสร้างขึ้นมานั้น “ดีพอ” สำหรับความต้องการของพวกเขาแล้วหรือยัง

Involve Your Users in the Trade-Off (ให้ผู้ใช้มีส่วนร่วมในการตัดสินใจแลกเปลี่ยน)

โดยปกติแล้วคุณเขียนซอฟต์แวร์ให้คนอื่นใช้ และบ่อยครั้งที่คุณจะจำได้ว่าต้องไปถามว่าพวกเขาต้องการอะไร [8] แต่คุณเคยถามพวกเขาไหมว่าอยากได้ซอฟต์แวร์ที่ ดีแค่ไหน บางครั้งก็ไม่มีทางเลือกอื่นเลย ถ้าคุณกำลังทำงานเกี่ยวกับเครื่องกระตุ้นหัวใจ ระบบ Autopilot หรือ Library ระดับล่างที่จะถูกนำไปใช้อย่างแพร่หลาย ข้อกำหนดก็จะเข้มงวดขึ้น และตัวเลือกของคุณก็จะแคบลง

แต่ถ้าคุณกำลังทำงานกับผลิตภัณฑ์ใหม่เอี่ยม คุณก็จะเจอข้อจำกัดที่ต่างออกไป ฝ่ายการตลาดมีคำมั่นสัญญาที่ต้องรักษา ผู้ใช้ปลายทางอาจวางแผนไว้แล้วโดยอิงจากกำหนดการส่งมอบ และบริษัทของคุณก็ย่อมมีข้อจำกัดด้านกระแสเงินสดอยู่แล้ว การเพิกเฉยต่อความต้องการเหล่านี้ของผู้ใช้ เพียงเพื่อจะเพิ่ม Feature ใหม่เข้าไปในโปรแกรม หรือขัดเกลาโค้ดอีกสักรอบ ถือเป็นเรื่องที่ไม่เป็นมืออาชีพ แต่เราก็ไม่ได้สนับสนุนให้ตื่นตระหนกเช่นกัน เพราะการรับปากกำหนดเวลาที่เป็นไปไม่ได้ แล้วตัดขั้นตอนทางวิศวกรรมพื้นฐานทิ้งเพื่อให้ทันเดดไลน์ ก็ไม่เป็นมืออาชีพเช่นเดียวกันครับ

ขอบเขตและคุณภาพของระบบที่คุณสร้างขึ้นควรถูกนำมาพูดคุยกันในฐานะส่วนหนึ่งของ Requirement ของระบบนั้นครับ

บ่อยครั้งที่คุณจะต้องเจอสถานการณ์ที่ต้องแลกเปลี่ยนกัน น่าแปลกที่ผู้ใช้จำนวนมากกลับอยากได้ซอฟต์แวร์ที่ยังมีขอบคมๆ อยู่บ้าง ตอนนี้เลย มากกว่าจะรอเวอร์ชันเต็มพร้อมลูกเล่นครบครันไปอีกหนึ่งปี (และในความเป็นจริง สิ่งที่พวกเขาต้องการในอีกหนึ่งปีข้างหน้าก็อาจเปลี่ยนไปคนละเรื่องเลยก็ได้) ทีม IT จำนวนมากที่มีงบจำกัดก็คงเห็นด้วยกับเรื่องนี้ ซอฟต์แวร์ที่ดีในวันนี้มักจะดีกว่าความฝันถึงซอฟต์แวร์ที่สมบูรณ์แบบในวันพรุ่งนี้ ถ้าคุณให้ผู้ใช้ได้ลองเล่นตั้งแต่เนิ่นๆ Feedback ของพวกเขาก็มักจะพาคุณไปสู่ทางออกที่ดีกว่าในท้ายที่สุด (ดู Topic 12, ​ Tracer Bullets ​ )

Know When to Stop (รู้ว่าเมื่อไหร่ควรหยุด)

ในบางแง่ การเขียนโปรแกรมก็เหมือนกับการวาดภาพ คุณเริ่มต้นจากผ้าใบเปล่าๆ กับวัตถุดิบพื้นฐานบางอย่าง แล้วใช้ทั้งศาสตร์ ศิลป์ และฝีมือผสมผสานกันเพื่อตัดสินใจว่าจะทำอะไรกับมัน คุณร่างรูปทรงโดยรวมออกมาก่อน ลงสีพื้นหลัง แล้วค่อยๆ เติมรายละเอียด คุณจะถอยออกมามองด้วยสายตาที่วิพากษ์วิจารณ์อยู่เสมอว่าสิ่งที่ทำมานั้นเป็นอย่างไร และบางครั้งคุณก็จะโยนผ้าใบทิ้งแล้วเริ่มใหม่ตั้งแต่ต้น

แต่ศิลปินจะบอกคุณว่าความพยายามทั้งหมดจะพังทลายลงถ้าคุณไม่รู้ว่าเมื่อไหร่ควรหยุด ถ้าคุณเติมสีเป็นชั้นแล้วชั้นเล่า เติมรายละเอียดแล้วรายละเอียดเล่าไม่หยุดหย่อน ภาพนั้นก็จะจมหายไปในสีที่ทาทับซ้อนกันนั่นเอง .

อย่าทำลายโปรแกรมที่ดีอยู่แล้วด้วยการตกแต่งและขัดเกลามากเกินไป ก้าวต่อไปข้างหน้า แล้วปล่อยให้โค้ดของคุณยืนหยัดได้ด้วยตัวเองสักพัก มันอาจจะไม่สมบูรณ์แบบ แต่ไม่ต้องกังวลไป เพราะมันไม่มีทางสมบูรณ์แบบได้อยู่แล้วครับ (ใน Chapter 7, ​ While You Are Coding ​ เราจะพูดถึงแนวคิดในการพัฒนาโค้ดในโลกที่ไม่สมบูรณ์แบบกัน)

Related Sections Include (หัวข้อที่เกี่ยวข้อง)

• Topic 45, ​ The Requirements Pit ​
• Topic 46, ​ Solving Impossible Puzzles ​

Challenges (แบบฝึกหัดชวนคิด)

• ลองมองดูเครื่องมือซอฟต์แวร์และระบบปฏิบัติการที่คุณใช้อยู่เป็นประจำ คุณเห็นหลักฐานอะไรที่บ่งบอกว่าองค์กรหรือนักพัฒนาเหล่านี้สบายใจที่จะปล่อยซอฟต์แวร์ทั้งที่รู้อยู่แล้วว่ามันไม่สมบูรณ์แบบไหม ในฐานะผู้ใช้ คุณอยากจะ (1) รอให้พวกเขาแก้บั๊กให้หมดก่อน (2) ใช้ซอฟต์แวร์ที่ซับซ้อนและยอมรับว่ามีบั๊กอยู่บ้าง หรือ (3) เลือกใช้ซอฟต์แวร์ที่เรียบง่ายกว่าแต่มีข้อบกพร่องน้อยกว่า

• ลองพิจารณาผลกระทบของการแบ่งโมดูลที่มีต่อการส่งมอบซอฟต์แวร์ การทำให้ซอฟต์แวร์แบบ Monolithic ที่ผูกติดกันแน่น (Tightly Coupled) มีคุณภาพตามที่ต้องการนั้น จะใช้เวลามากกว่าหรือน้อยกว่าเมื่อเทียบกับระบบที่ออกแบบมาเป็น Module หรือ Microservice ที่เชื่อมโยงกันหลวมๆ (Loosely Coupled) แต่ละแนวทางมีข้อดีข้อเสียอย่างไรบ้าง

• คุณนึกถึงซอฟต์แวร์ยอดนิยมที่มีปัญหา Feature Bloat (ฟีเจอร์บวมเกินจำเป็น) ได้ไหมครับ นั่นคือซอฟต์แวร์ที่มี Feature มากเกินกว่าที่คุณจะใช้จริง โดยแต่ละ Feature ก็ยิ่งเพิ่มโอกาสเกิดบั๊กและช่องโหว่ด้านความปลอดภัย แถมยังทำให้ Feature ที่คุณ ใช้จริง หาเจอและจัดการได้ยากขึ้นไปอีก แล้วคุณเองมีความเสี่ยงที่จะตกหลุมพรางแบบนี้บ้างไหม