บทความนี้จะอธิบายแนวทางทางวิทยาศาสตร์ในการแก้ปัญหา แม้ว่าจะเขียนขึ้นเพื่อแก้ไขปัญหาที่เกี่ยวข้องกับเทคโนโลยีสารสนเทศ แต่แนวคิดนี้อาจนำไปใช้ในสาขาอื่นๆ ได้เช่นกัน วิธีการ แนวคิด และเทคนิคที่อธิบายไว้ในที่นี้ไม่ใช่เรื่องใหม่ แต่น่าตกใจที่ “นักแก้ปัญหา” จำนวนมากใช้ไม่ได้ ในระหว่างนี้ฉันจะรวมตัวอย่างในชีวิตจริงไว้ด้วย
เหตุใดนักแก้ปัญหาจึงเดาแทนการปฏิบัติตามแนวทางทางวิทยาศาสตร์ในการแก้ปัญหา อาจเป็นเพราะรู้สึกเร็ว? อาจขาดประสบการณ์ในการแก้ปัญหาอย่างมีประสิทธิภาพ? หรืออาจเป็นเพราะรู้สึกว่าเป็นงานหนักที่จะทำทางวิทยาศาสตร์? บางทีในขณะที่คุณเดาไปเรื่อย ๆ และไม่ได้แก้ไขจริง ๆ คุณสร้างรายได้และเพิ่มความมั่นคงในอาชีพการงานหรือไม่? หรืออาจเป็นเพราะคุณละเมิดหลักการข้อแรกของการแก้ปัญหา: เข้าใจปัญหา
หลักการ #1. เข้าใจปัญหา *จริง*
ไม่ชัดเหรอว่าก่อนจะแก้ต้องเข้าใจปัญหาก่อน? อาจจะ. แต่ส่วนใหญ่แล้วผู้แก้ปัญหาจะเริ่มแก้ปัญหาโดยไม่ทราบปัญหาที่แท้จริง สิ่งที่ลูกค้าหรือผู้ใช้อธิบายว่า “ปัญหา” มักจะเป็นเพียงอาการเท่านั้น! “คอมพิวเตอร์ของฉันไม่ต้องการเปิด” เป็นอาการ ปัญหาที่แท้จริงอาจเป็นไปได้ว่าทั้งอาคารไม่มีไฟฟ้า “ทุกครั้งที่ฉันพยายามเพิ่มสินค้าใหม่ ฉันได้รับข้อความแสดงข้อผิดพลาด” คืออาการ ปัญหาที่แท้จริงอาจเป็น “เฉพาะผลิตภัณฑ์ 2 รายการล่าสุดที่ฉันพยายามเพิ่มเท่านั้นที่มีข้อผิดพลาด ‘ผลิตภัณฑ์มีอยู่แล้ว'” อีกตัวอย่างคลาสสิก: “ไม่มีอะไรทำงาน”…
คุณเริ่มการตรวจสอบโดยกำหนด “ปัญหาที่แท้จริง” สิ่งนี้จะนำมาซึ่งการถามคำถาม (และบางครั้งก็ตรวจสอบ) และทำการทดสอบขั้นพื้นฐาน ถามคำถามผู้ใช้ เช่น “ครั้งสุดท้ายที่ระบบทำงานสำเร็จเมื่อใด” “คุณใช้ระบบมานานแค่ไหนแล้ว” “ระบบนี้ทำงานบนพีซีเครื่องอื่นหรือผู้ใช้รายอื่นได้หรือไม่” “ข้อความแสดงข้อผิดพลาดที่แน่นอนคืออะไร ” ฯลฯ ขอพิมพ์หน้าจอของข้อผิดพลาดหากเป็นไปได้ การทดสอบขั้นพื้นฐานของคุณคือเพื่อให้แน่ใจว่าอุปกรณ์แบบ end-to-end พร้อมใช้งานแล้ว ตรวจสอบพีซีของผู้ใช้, เครือข่าย, เว็บเซิร์ฟเวอร์, ไฟร์วอลล์, เซิร์ฟเวอร์ไฟล์, แบ็คเอนด์ของฐานข้อมูล ฯลฯ ในกรณีที่ดีที่สุด คุณจะระบุปัญหาได้อย่างชัดเจน กรณีที่แย่ที่สุดคุณสามารถกำจัดสาเหตุของปัญหาได้มากมาย
ตัวอย่างชีวิตจริง อาการตามผู้ใช้: “ระบบแฮงค์สุ่มครั้งเมื่อฉันสั่ง” สภาพแวดล้อม: ผู้ใช้ป้อนรายละเอียดการสั่งซื้อในแบบฟอร์มในแอปพลิเคชันเมนเฟรม เมื่อรายละเอียดทั้งหมดเสร็จสิ้น ผู้ใช้จะปิดแบบฟอร์ม จากนั้นเมนเฟรมจะส่งรายละเอียดนี้ผ่านซอฟต์แวร์การสื่อสารไปยังระบบ Oracle Client/Server ที่โรงงาน ระบบ Oracle จะทำการวางแผนกำลังการผลิตและส่งกลับข้อผิดพลาดหรือวันที่สั่งซื้อที่คาดไว้กลับไปยังระบบเมนเฟรม ปัญหานี้ค่อนข้างร้ายแรง เพราะคุณสามารถสูญเสียลูกค้าได้หากพวกเขาพยายามที่จะสั่งซื้อ และระบบไม่ยอมรับพวกเขา! เพื่อพยายามแก้ปัญหานี้ ผู้คนเริ่มต้นด้วยการตรวจสอบ: 1) โหลดและความจุของฮาร์ดแวร์เมนเฟรม 2) ตรวจสอบโหลดเครือข่ายระหว่างเมนเฟรมและระบบ Oracle 3) ว่าจ้างที่ปรึกษาเพื่อดีบักซอฟต์แวร์การสื่อสาร 4) ดีบักความจุของ Oracle ระบบการวางแผน หลังจากใช้เวลาสองสามเดือนก็ไม่สามารถแก้ปัญหาได้
มีการเรียก “ตัวแก้ปัญหาทางวิทยาศาสตร์” เข้ามา ใช้เวลาน้อยกว่าหนึ่งวันและปัญหาก็ได้รับการแก้ไข! ยังไง? นักแก้ปัญหาใช้เวลาทั้งวันกับผู้ใช้เพื่อดูว่า “ปัญหาที่แท้จริง” คืออะไร โดยพบว่าปัญหาเกิดกับออร์เดอร์ส่งออกเท่านั้น จากการตรวจสอบหน้าจอการจับภาพและการดำเนินการของผู้ใช้ พบว่าด้วยคำสั่งส่งออก ฟิลด์สุดท้ายในแบบฟอร์มจะเว้นว่างไว้เสมอ และผู้ใช้ไม่ได้ปิดแท็บฟิลด์นี้ ระบบไม่ได้หยุดทำงาน แต่จะรอให้ผู้ใช้กด “แท็บ” อีกครั้ง แก้ไขปัญหา. สังเกตได้ว่า “Scientific Problem Solver” มีความรู้จำกัดมากเกี่ยวกับเมนเฟรม ระบบจับคำสั่ง ซอฟต์แวร์สื่อสาร และระบบการวางแผนความสามารถของ Oracle และสิ่งนี้นำเราไปสู่หลักการข้อที่ 2
หลักการ #2. อย่ากลัวที่จะเริ่มกระบวนการแก้ปัญหาแม้ว่าคุณจะไม่เข้าใจระบบก็ตาม
กี่ครั้งแล้วที่คุณได้ยิน “ฉันไม่สามารถแตะรหัสนั้นได้ เพราะมันถูกพัฒนาโดยคนอื่น!” หรือ “ฉันไม่สามารถช่วยได้เพราะฉันเป็นที่ปรึกษาด้านทรัพยากรบุคคลและนั่นคือปัญหาทางการเงิน” หากเครื่องซักผ้าของคุณไม่ต้องการเปิดสวิตช์ คุณไม่จำเป็นต้องเป็นวิศวกรไฟฟ้า ผู้เชี่ยวชาญด้านการซ่อมเครื่องซักผ้า ช่างเทคนิค หรือผู้เชี่ยวชาญใดๆ เพื่อทำการค้นหาข้อผิดพลาดพื้นฐาน ตรวจสอบให้แน่ใจว่าปลั๊กใช้งานได้ ตรวจสอบสวิตช์การเดินทาง ฯลฯ “ฉันไม่เคยเห็นข้อผิดพลาดนี้มาก่อน” ไม่ควรหยุดคุณจากการพยายามแก้ไข ด้วยข้อความแสดงข้อผิดพลาดและเครื่องมือค้นหาทางอินเทอร์เน็ต คุณจะได้รับจุดเริ่มต้นมากมาย
ในทุกระบบที่ซับซ้อนมีหลักการทำงานพื้นฐานสองสามข้อ ระบบ A ที่อ่านข้อมูลจากระบบ B อาจซับซ้อนอย่างน่ากลัว (อาจเป็นสเปกโตรมิเตอร์ในห้องปฏิบัติการที่อ่านข้อมูลจากคอมพิวเตอร์ลอจิกที่ตั้งโปรแกรมได้ผ่านพอร์ต RS-232) แต่พื้นฐานบางอย่างในการทดสอบ: ทั้งสองระบบมีพลังงานหรือไม่? มีข้อความแสดงข้อผิดพลาดในบันทึกเหตุการณ์ในระบบใดระบบหนึ่งเหล่านี้หรือไม่ คุณสามารถ “ping” หรือติดตามแพ็คเก็ตเครือข่ายจากระบบหนึ่งไปยังอีกระบบหนึ่งได้หรือไม่? ลองใช้สายเคเบิลสื่อสารอื่น ค้นหาอินเทอร์เน็ตสำหรับข้อความแสดงข้อผิดพลาด
เมื่อคุณกำหนดได้ว่าปัญหาคืออะไร คุณต้องเริ่มแก้ปัญหานั้น บางครั้งการตรวจสอบเบื้องต้นจะชี้ให้คุณเห็นแนวทางแก้ไขปัญหาโดยตรง (เปิดสวิตช์เครื่อง เปลี่ยนสายเคเบิลที่ชำรุด ฯลฯ) แต่บางครั้งปัญหาที่แท้จริงก็ซับซ้อนในตัวเอง ดังนั้น หลักการต่อไปคือการแก้ปัญหาง่ายๆ
หลักการ #3. พิชิตมันง่ายๆ
เริ่มส่วนนี้ด้วยตัวอย่างในชีวิตจริง ภายใต้เงื่อนไขบางประการ กระบวนงานที่เก็บไว้จะหยุดทำงาน โดยปกติขั้นตอนการจัดเก็บจะใช้เวลาดำเนินการประมาณหนึ่งชั่วโมง (เมื่อไม่ได้หยุดทำงาน) ดังนั้นผู้พัฒนาจึงพยายามแก้ไขข้อบกพร่อง ทำการเปลี่ยนแปลงบางอย่างแล้วรอประมาณหนึ่งชั่วโมงเพื่อดูว่าปัญหาได้รับการแก้ไขหรือไม่ หลังจากผ่านไปหลายวัน ผู้พัฒนาก็ยอมแพ้และ “ตัวแก้ปัญหา” ก็เข้ามาแทนที่ “ผู้แก้ปัญหา” ต้องกำจัดความรู้ของเขาภายใต้เงื่อนไขของแม่มดที่ขั้นตอนการจัดเก็บจะหยุดทำงาน ดังนั้นจึงเป็นแบบฝึกหัดง่ายๆ ในการทำสำเนาขั้นตอน จากนั้นคัดลอกโค้ดที่ไม่จำเป็นทั้งหมดออกด้วยสำเนานี้ พารามิเตอร์ทั้งหมดมีการเปลี่ยนแปลงด้วยค่าฮาร์ดโค้ด บิตของโค้ดถูกดำเนินการในแต่ละครั้ง และชุดผลลัพธ์จะถูกฮาร์ดโค้ดอีกครั้งในสำเนาของโพรซีเดอร์ ภายใน 3 ชั่วโมง ปัญหาก็ได้รับการแก้ไข มีการค้นพบวงวนไม่สิ้นสุด
สิ่งที่ “ตัวแก้ปัญหา” ทำคือการทำซ้ำปัญหาและในขณะเดียวกันก็พยายามแยกรหัสที่ทำให้เกิดปัญหา ในการทำเช่นนั้น ขั้นตอนการจัดเก็บที่ซับซ้อน (และใช้เวลานาน) กลายเป็นสิ่งที่ง่ายและรวดเร็ว
หากปัญหาอยู่ภายในแอปพลิเคชัน ให้สร้างแอปพลิเคชันใหม่และพยายามจำลองปัญหาภายในแอปพลิเคชันใหม่ให้เรียบง่ายที่สุดเท่าที่จะเป็นไปได้ หากปัญหาเกิดขึ้นเมื่อมีการเรียกใช้เมธอดบางอย่างสำหรับการควบคุมบางอย่าง ให้ลองรวมเฉพาะการควบคุมนี้ในแอปพลิเคชันเปล่า และเรียกใช้เมธอดนั้นด้วยค่าฮาร์ดโค้ด หากปัญหาเกิดขึ้นกับ SQL ที่ฝังอยู่ภายในแอปพลิเคชัน C# ให้ลองจำลอง SQL ภายในเครื่องมือสืบค้นฐานข้อมูล (เช่น SQL*Plus สำหรับ Oracle, Query Analyzer สำหรับ SQL Server หรือใช้โค้ดใน MS Excel ผ่าน ODBC กับฐานข้อมูล ).
ทันทีที่คุณสามารถทำซ้ำปัญหาด้วยวิธีง่ายๆ คุณมีเวลามากกว่า 80% ในการแก้ปัญหา
หากคุณไม่ทราบว่าปัญหาอยู่ที่ใดในโปรแกรม ให้ใช้ DEBUG
หลักการ #4. ดีบัก
เครื่องมือพัฒนาแอปพลิเคชันส่วนใหญ่มาพร้อมดีบักเกอร์เป็นมาตรฐาน ไม่ว่าจะเป็น Macromedia Flash, Microsoft Dot Net, Delphi หรือสภาพแวดล้อมการพัฒนาใดก็ตามที่จะมีดีบักเกอร์บางประเภท หากเครื่องมือไม่ได้มาพร้อมกับดีบักเกอร์มาตรฐาน คุณสามารถจำลองได้
สิ่งแรกที่คุณต้องการทำกับดีบักเกอร์คือการระบุว่าปัญหาอยู่ที่ใด คุณทำได้โดยการเพิ่มเบรกพอยต์ที่บริเวณสำคัญ จากนั้นคุณรันโปรแกรมในโหมดดีบัก แล้วคุณจะรู้ว่าเบรกพอยต์ใดที่เกิดปัญหาขึ้น เจาะลึกลงไปแล้วคุณจะพบจุดนั้น ตอนนี้คุณรู้แล้วว่าปัญหาอยู่ที่ไหน คุณก็สามารถ “เอาชนะมันได้ง่ายๆ”
คุณสมบัติที่ดีอีกประการหนึ่งของดีบักเกอร์ส่วนใหญ่รวมถึงสิ่งอำนวยความสะดวกในการดูตัวแปร ค่า พารามิเตอร์ ฯลฯ ขณะที่คุณดำเนินการผ่านโปรแกรม ด้วยค่าเหล่านี้ที่ทราบในบางขั้นตอน คุณสามารถฮาร์ดโค้ดค่าเหล่านี้ลงในโปรแกรม “รุ่นที่เรียบง่าย” ของคุณได้
หากเครื่องมือการพัฒนาไม่รองรับการดีบัก คุณสามารถจำลองได้ ใส่ขั้นตอนในโปรแกรมที่ส่งออกค่าตัวแปรและข้อความ “สวัสดี ฉันอยู่ที่นี่” ไปยังหน้าจอ ไปยังไฟล์บันทึก หรือไปยังตารางฐานข้อมูล อย่าลืมนำออกเมื่อปัญหาได้รับการแก้ไขแล้ว… คุณคงไม่อยากให้ระบบไฟล์ของคุณรกรุงรังหรือเต็มไปด้วยไฟล์บันทึก!
หลักการ #5. มีข้อมูลมากมายในส่วนหลังของฐานข้อมูลที่จะช่วยในการแก้ปัญหา
“ผู้แก้ปัญหา” ถูกเรียกให้ช่วยแก้ปัญหาที่ยุ่งยากมาก โครงการกำลังย้ายระบบจากเมนเฟรมไปยังเทคโนโลยีไคลเอนต์-เซิร์ฟเวอร์ ทุกอย่างเป็นไปด้วยดีระหว่างการทดสอบ แต่เมื่อระบบเริ่มใช้งานจริง จู่ๆ ก็มี “ความผิดพลาดในการป้องกันทั่วไป” เกิดขึ้นค่อนข้างน้อยและค่อนข้างสุ่ม (ข้อผิดพลาด GPF เป็นกับดักข้อผิดพลาดทั่วไปใน Windows 95 และ 98) มีการพยายามทำให้โค้ดง่ายขึ้น มีการพยายามดีบัก แต่ไม่สามารถทำซ้ำได้ ในสภาพแวดล้อม LAB ปัญหาจะไม่เกิดขึ้น! การดีบักข้อความติดตามไปยังล็อกไฟล์บ่งชี้ว่าปัญหาเกิดขึ้นแบบสุ่มมาก ผู้ใช้บางคนมีประสบการณ์มากกว่าคนอื่น ๆ แต่ในที่สุดผู้ใช้ทุกคนก็จะได้รับมัน! ปัญหาที่น่าสนใจ
“ตัวแก้ปัญหา” แก้ไขปัญหานี้หลังจากที่เขาเริ่มวิเคราะห์ส่วนหลังของฐานข้อมูล ไม่แน่ใจว่าเป็นความบังเอิญหรือเพราะเขาเดินไปในทิศทางที่ถูกต้องอย่างเป็นระบบเพราะแนวทางทางวิทยาศาสตร์ จากการติดตามสิ่งที่เกิดขึ้นในระดับแบ็คเอนด์ พบว่าแอปพลิเคชันทั้งหมดเหล่านี้กำลังสร้างการเชื่อมต่อกับฐานข้อมูลมากขึ้นเรื่อยๆ ทุกครั้งที่ผู้ใช้เริ่มทำธุรกรรมใหม่ มีการสร้างการเชื่อมต่อกับฐานข้อมูลอีกครั้ง ผลรวมของการเชื่อมต่อจะถูกปล่อยออกมาเมื่อปิดแอปพลิเคชันเท่านั้น เมื่อผู้ใช้นำทางไปยังหน้าต่างใหม่ภายในแอปพลิเคชันเดียวกัน การเชื่อมต่อจะเปิดขึ้นมากขึ้นเรื่อยๆ และหลังจากจำนวนการเชื่อมต่อที่กำหนด แอปพลิเคชันจะมีเพียงพอและจากนั้นจะหยุดทำงาน นี่เป็นข้อผิดพลาดในการเขียนโปรแกรมในเทมเพลตที่นักพัฒนาทั้งหมดใช้ วิธีแก้ไขคือให้ทดสอบก่อนว่าเคอร์เซอร์ไปยังฐานข้อมูลเปิดอยู่หรือไม่ ก่อนที่จะเปิดอีกครั้ง
คุณติดตามฐานข้อมูลส่วนหลังได้อย่างไรว่าเกิดอะไรขึ้น ผู้ให้บริการฐานข้อมูลหลักมีเครื่องมือ GUI ที่ช่วยให้คุณติดตามหรือวิเคราะห์ว่าข้อความค้นหาใดที่ส่งไปยังฐานข้อมูล นอกจากนี้ยังจะแสดงให้คุณเห็นเมื่อมีคนเชื่อมต่อ ตัดการเชื่อมต่อ หรือไม่สามารถเชื่อมต่อได้เนื่องจากการละเมิดความปลอดภัย ฐานข้อมูลส่วนใหญ่ยังมีตารางพจนานุกรมของระบบที่สามารถสอบถามเพื่อรับข้อมูลนี้ได้ ร่องรอยเหล่านี้บางครั้งสามารถบอกเรื่องราวทั้งหมดว่าทำไมบางสิ่งถึงล้มเหลว รหัสแบบสอบถามที่คุณดึงมาจากการติดตามสามารถช่วย “ทำให้การค้นหาง่ายขึ้น” คุณสามารถดูได้จากร่องรอยว่าโปรแกรมติดต่อกับฐานข้อมูลสำเร็จหรือไม่ คุณสามารถดูระยะเวลาที่ใช้ในการดำเนินการค้นหา
เพิ่มในหลักการ #2 (อย่ากลัวที่จะเริ่มต้น…); คุณสามารถวิเคราะห์ข้อมูลการติดตามนี้ได้ แม้ว่าคุณอาจไม่ทราบรายละเอียดเกี่ยวกับแอปพลิเคชันเลยก็ตาม
โปรดจำไว้ว่าการติดตามส่วนหลังเหล่านี้สามารถสร้างภาระให้กับทรัพยากรส่วนหลังได้ อย่าปล่อยให้ทำงานนานโดยไม่จำเป็น
หลักการ #6. ใช้ตาสด.
นี่คือหลักการสุดท้าย อย่าใช้เวลากับปัญหามากเกินไปก่อนที่จะขอความช่วยเหลือ ความช่วยเหลือไม่จำเป็นต้องมาจากคนที่อาวุโสกว่าคุณ หลักการคือคุณต้องมีดวงตาที่สดใสคู่หนึ่งเพื่อมุมมองที่สดใส และบางครั้งอากาศบริสุทธิ์ด้วยการหยุดพัก อีกฝ่ายจะมองแล้วถามคำถามหนึ่งหรือสองคำถาม บางครั้งมันเป็นสิ่งที่ชัดเจนมากที่พลาดไป บางครั้งเพียงแค่ตอบคำถามก็ทำให้คุณคิดไปในทิศทางใหม่ นอกจากนี้ หากคุณใช้เวลาหลายชั่วโมงในการดูโค้ดชิ้นเดียวกัน การเริ่มมองหาข้อผิดพลาดโง่ๆ นั้นเป็นเรื่องง่ายมาก ปัญหาความสมดุลทางการเงินมากมายได้รับการแก้ไขด้วยเบียร์ อาจเป็นการเปลี่ยนทิวทัศน์และ/หรือบรรยากาศที่ผ่อนคลายซึ่งจะช่วยแก้ปัญหาได้ อาจจะเป็นออกซิเจนบริสุทธิ์ที่ไปเลี้ยงสมองขณะเดินไปผับ อาจเป็นเพราะปัญหาได้พูดคุยกับคนอื่น
บทสรุป
หลังจากอ่านบทความฉบับนี้แล้ว ผู้เขียนหวังว่าคุณจะลองทำสิ่งเหล่านี้ในครั้งต่อไปที่คุณพบปัญหาให้แก้ไข หวังว่าการใช้หลักการทั้งหกนี้ คุณจะตระหนักถึงข้อดีที่พวกเขานำมา แทนที่จะ “คาดเดา” วิธีการแก้ปัญหาของคุณ