ต่อจากฉบับที่แล้ว …
ที่จริงผมนั้นมั่นใจในการวินิจฉัยของผมมันชัดเจนมาก และการหาปัญหาแบบส่งงานทีไรก็ไม่ผ่าน (ภาษาไทยเรียกว่าส่งงานทีไรก็ตาย) นั้นหาปัญหาได้ง่ายกว่า ส่งบางครั้งก็ตาย บางครั้งไม่ตาย อยู่แล้ว แต่เมื่อมีข้อโต้แย้ง (อย่างหนักแน่นอย่างนั้น) ผมเลยขอให้ Compile โปรแกรม Cobol Source Code ให้ใหม่ โดยใส่ Option List เข้าด้วย เพื่อให้ Cobol Compiler แตก Cobol Instructions ให้แสดง Assembler Instructions ออกมาด้วย ผมเขียนโปรแกรม Cobol ไม่เป็น แต่สำหรับภาษา Assembler คือภาษาที่จำเป็นที่สุดที่จะเข้าใจการ Execute Instruction ของ CPU เพราะ Assembler Instructions จะ Map 1:1 กับ Machine Instruction ที่ CPU Execute ทำให้เราเข้าใจ Flow การทำงานของคอมพิวเตอร์ ซึ่งจำเป็นแก่การหาปัญหาในระบบ ไม่ว่าจะเป็น OS หรือ PP ก็ตาม
บทความที่เกี่ยวข้องกับตัวอย่างของกับดักของนักเขียนโปรแกรมคอมพิวเตอร์รุ่นเก่า…
ผมเทียบ Instruction ที่มีปัญหาจาก Dump กับ Instruction ใน Compiler List แล้วบอกกับ System Programmer ว่า ผมมั่นใจมาก และบอกฝากไปว่า ให้คนเขียนโปรแกรมไปตรวจเช็คดูที่ Cobol Instruction แถว ๆ นี้ (1 Instruction ของ Cobol Program สามารถแตกออกมาได้หลาย Instruction ของ Assembler Program) ให้เขาแก้แล้วผมจะนั่งรอดูผล ไม่ไปไหนหรอก
ต้องขอเกริ่นก่อนว่า ภาษา COBOL (โคบอล) หรือ Common Business Oriented Language คือภาษาคอมพิวเตอร์สำหรับใช้ในงานธุรกิจภาษาแรกของโลก สามารถใช้งานแฟ้มข้อมูลได้หลายแบบ กำหนดโครงสร้างข้อมูลได้สะดวก มีลักษณะการเขียนโปรแกรมแบบเอกสารอธิบายโปรแกรม ช่วยให้นักพัฒนารุ่นถัดไปเข้าใจได้ง่าย การเขียนโปรแกรมภาษา COBOL ทำได้ง่ายมาก เพราะไม่มีลูกเล่นให้ใช้มาก ๆ เหมือนพวก VB (วีบี), C (ซี), Pascal (ปาสคาล) หรือ dBase (ดีเบส) หน้าที่หลักของ COBOL คืออ่านข้อมูลจากแฟ้มมาประมวลผลทางธุรกิจเป็นหลัก
พูดได้เลยว่า นี่เป็นภาษาที่เก่าแก่ของนักเขียนโปรแกรม ภาษานี้ยังถูกพัฒนาอยู่เรื่อย ๆ ภาษาโคบอลที่เชื่อมโยงกับหน้าจอสีเขียวและการเชื่อมต่อเมนเฟรมดั้งเดิมได้อย่างรวดเร็วก่อนดูเหมือนจะขัดแย้งกับวัตถุ เทคโนโลยีอินเตอร์เฟสแบบกราฟิกปุ่มกดและสภาพแวดล้อมการพัฒนาแบบโต้ตอบ เป็นสิ่งที่ไม่ลงรอยกับการรับรู้ แต่เป็นภาพสะท้อนของความสามารถในเมนเฟรมกับนวัตกรรมของเดสก์ทอปและคอมพิวเตอร์ไคลเอ็นต์และเซิร์ฟเวอร์ มากกว่าข้อบกพร่องในภาษา COBOL
และในตอนนั้นด้วยความกล้า ๆ กลัว ๆ เพราะระดับตำแหน่งในธนาคารของ System Programmer ที่จริงก็รองจาก Application Programmer คนดังกล่าวเขาก็จำใจไปส่งข้อความให้ เพราะผมยืนยันหนักแน่นว่า ปัญหาอยู่ตรงนั้น ถ้าอยากจะรันโปรแกรมนี้ในวันนี้ เพื่อคำนวณดอกเบี้ยให้ทันเวลา เขาก็ต้องแก้ไขโปรแกรม ผมนั่งรออยู่ที่ห้อง System Programmer อยู่ประมาณเกือบชั่วโมง System Programmer ก็มาแจ้งว่า ทีแรก Senior Programmer คนนั้นก็ฮึดฮัดไม่ค่อยจะเชื่อถือผมนัก เพราะเหตุที่โปรแกรมถูกใช้งานมานานแล้ว และไม่เคยไปแก้ไขอะไร แต่เมื่อดู Instruction ที่ผมชี้เป้าไป เขาก็พบปัญหา ทำการแก้ไขและส่งงานไป Execute ใหม่ ปรากฏว่าทำงานได้ถูกต้องเรียบร้อย
Senior Application Programmer ถามว่าผมชื่ออะไร และชมว่าเรานั้นถูกจริง ๆ ด้วย สุดท้าย Senior Application Programmer คนนั้นกลายเป็นเพื่อนสนิทของผม ในวงการ Platform Mainframe Computer ใน Banking Industry และปัญหาในวันนั้นคือโปรแกรมไม่ได้ตรวจสอบว่า วันนั้นเป็นวันสิ้นเดือนกุมภาพันธ์ในปีที่มี 29 วัน (ปีอธิกสุรทิน/Leap Year) Key Learning Points
เราต้องมั่นใจในทฤษฎีและข้อมูลที่เกิดขึ้นจริงที่พิสูจน์การค้นพบของเรา และยืนหยัดอยู่อย่างนั้น เพื่อให้ปัญหาถูกแก้ไขอย่างถูกต้องในเวลาอันสมควร หากเราถูกโต้แย้งด้วยสถานะ/ประสบการณ์/เครดิต ของคนอื่นที่เหนือกว่าในวงการ แล้วเราถอย ปัญหาก็ไม่ถูกแก้ไขในเวลาที่สมควร ลูกค้าของธนาคารอันเป็นคนหมู่มากก็จะยังเดือดร้อนอยู่ แม้แต่ตัวเราเองก็จะไม่ได้รับการพิสูจน์และยอมรับไปด้วย กรณีนี้ ผมยืนยันด้วยหลักฐานเพิ่มเติม แถมคำแนะนำ ชี้เป้าไปให้ด้วย ทำให้ผมได้รับการยอมรับ ลูกค้าธนาคารก็ได้รับประโยชน์ บริษัทของผมก็ได้รับความเชื่อถือไปด้วย
ปัญหาแบบนี้ ภาษาโปรแกรมสมัยใหม่อาจจะไม่เกิดแล้ว แต่ในภาษาโปรแกรมเก่า ๆ ผู้เขียนโปรแกรมจะต้องเช็คเงื่อนไขต่างๆ ด้วยตัวเอง อย่างไรก็ตาม จุดที่โปรแกรมควรจะต้องถูกทดสอบว่าทำงานได้อย่างถูกต้อง คือ การที่โปรแกรมต้องจัดการกับข้อมูลอินพุต ที่ข้ามเดือน (รอยต่อระหว่างเดือนที่ 1 กับเดือนที่ 2) ข้ามไตรมาส (รอยต่อของไตรมาสที่ 1 และไตรมาสที่ 2 เช่น รายงานส่งตลาดหลักทรัพย์) ข้ามครึ่งปี (รอยต่อของเดือนมิถุนายนกับกรกฎาคม เช่น การปิดบัญชีครึ่งปีของธนาคาร) ข้ามปี (รอยต่อของธันวาคมปีนี้กับมกราคมปีหน้า เช่น การปิดบัญชีสิ้นปีของธนาคารและบริษัทอื่น ๆ) ข้ามหลายปี Leap Year ดังตัวอย่างนี้ หากภาษาที่ใช้ในปัจจุบันได้ Handle Condition เหล่านี้ไว้แล้ว อย่างน้อยที่สุดในการทดสอบ หรือ Quality Control (QC) ก็อย่าลืมที่จะต้องทดสอบเงื่อนไขเหล่านี้ให้มั่นใจด้วย
ที่มา: อินทาเนีย ฉบับที่ 3 ปี พ.ศ. 2565 คอลัมน์ เรื่องเล่าชาวอินทาเนีย โดย อดิศร แก้วบูชา วศ.17