ผมเรียนรู้อะไรจากการเขียนโปรแกรมใช้เอง (2) - การจัดการ

การจัดการ เป็นคู่แฝด ของการเขียนโปรแกรม

เมื่อ 20 ปีก่อน ผมใช้ตัว Basic compiler คือ TB ของค่ายบอร์แลนด์ กับ QB ของค่ายไมโครซอฟท์

สมัยนั้น ระบบปฎิบัติการยังเป็น DOS อยู่ ซึ่งทุกอย่างยังเป็นการสั่งแบบ text mode อยู่ อย่างที่ คลิก-คลิก-คลิก น่ะ ไม่มีหรอก ต้องรัวสั่งผ่านคีย์บอร์ดลูกเดียว

(ผม..จิ้มรัวครับ !) 

มีอยู่ช่วงหนึ่ง ผมเขียนโปรแกรมสำหรับคำนวณอะไรสักอย่าง (จำไม่ได้แล้วครับว่าเรื่องอะไร !) จำได้แต่ว่า ตอนนั้น ผมต้องการรายงาน 3 แบบ ซึ่งแต่ละครั้งที่ใช้โปรแกรม ก็จะต้องการไม่เหมือนกัน เอาแน่ไม่ได้

1. รายงานขึ้นจอ

2. รายงานออกเครื่องพิมพ์

3. รายงานเก็บลงแฟ้ม 

ตอนแรก ผมเขียน code ซ้ำกัน 3 รอบ แล้วให้มีการถามว่าจะเอารายงานแบบนี้ ๆ มั้ย ถ้าเอา ก็ทำให้

ดู ๆ ไป เอ๊ะ โค้ดรุงรังจัง ยุบได้มั้ยนี่ เพราะถ้าเกิดอยากเปลี่ยนรูปแบบรายงาน ผมต้องรื้อถึง 3 แห่ง ซึ่งพลาดง่าย สามแห่งออกมาต่างกันหมด

เอ้า ลองยุบดู ก็ยุบได้ โดยการมองแบบนามธรรม คือมองว่า รายงาน ก็คือการสื่อสารขาออก คือสื่อสารออกไปสู่แฟ้ม

หน้าจอก็คือแฟ้ม ("SCRN:")

เครื่องพิมพ์ก็คือแฟ้ม ("LPT1:")

แฟ้มก็คือแฟ้ม ("ชื่อแฟ้ม")

พอมองแบบนามธรรม อ๊ะ ได้นี่ ทุกอย่างออกแฟ้มกันดื้อ ๆ สามารถยุบจากเขียนโปรแกรมคล้าย ๆ กัน 3 รอบ ลงมาเหลือรอบเดียวได้

ตอนนั้นแม้จะเขียนภาษาเบสิก แต่ผมก็ซอกแซกไปอ่านตำราของภาษาซีและปาสคาล โดยไม่ได้คิดจะใช้ภาษาเหล่านั้น แต่อ่านเผื่อมีเคล็ดวิชาดี ๆ ติดมา

อ่านซี ทำให้ต้องอ่านบทนำยูนิกซ์เป็นของแถม ทำให้รู้จักการเปลี่ยนปลายทาง (redirection) ของรายงาน

อย่างเช่น ผมมีโปรแกรมชื่อ hello.exe ซึ่งพิมพ์คำว่า "Hello" ขึ้นจอ

ผมอยากเปลี่ยนทิศรายงานไปออกเครื่องพิมพ์ ผมก็สั่งว่า

hello > lpt1:

หรืออยากออกไปเก็บในแฟ้ม a.txt ก็สั่งว่า

hello > a.txt 

ผลก็คือ ผมกลับไปรื้อโค้ดอีกที คราวนี้ ไม่เอาแล้ว เรื่องรายงานผลออกแฟ้ม มันวุ่นวายไป ต้องสั่งเปิดแฟ้ม-ปิดแฟ้มกันเหนื่อย เอาให้พิมพ์ขึ้นจอกันตรง ๆ นี่แหละ อยากออกแฟ้มหรือออกเครื่องพิมพ์ ก็สั่งเปลี่ยนทิศการรายงาน

ผลคือ จากโค้ดยาวหน้ากว่า ๆ ลดเหลือไม่กี่บรรทัดเองครับ

ผลสืบเนื่องคือ ผมเลิกใช้ TB หันไปใช้ QB อย่างเดียว เพราะ TB ไม่สามารถทำคำสั่ง redirection ได้ เพราะ TB สร้าง code ที่ทำงานเร็วมากโดยการลัดขั้นตอน ไม่พึ่งระบบปฏิบัติการ แต่ยิง รายงานผลตรงเข้าตำแหน่งของหน้าจอ ผลคือ ระบบปฎิบัติการไม่รับรู้ว่ามีการรายงานขึ้นจอ ก็เลยไม่ยอมเปลี่ยนทิศให้

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

ขยายความนิดนึงครับ

pipeline (ต่อท่อ) เป็นการส่งต่อผลที่รายงานขึ้นจอ ไปเป็น input ให้โปรแกรมถัดไป โดยใช้เครื่องหมาย | ซึ่งเป็นสัญลักษณ์รูปกำแพงกั้นที่มีรูเจาะทะลุตรงกลาง

เช่น โปรแกรมชื่อ r.exe สร้างตัวเลข 100 บรรทัดที่ไม่เรียงกันเลย ผมก็สั่ง

         r.exe | sort > report.txt

ก็จะเกิดเป็นแฟ้มชื่อ report.txt ที่มีข้อมูล 100 บรรทัดนั้นอยู่เรียงกัน

ผลคือ ผมไม่ต้องเขียนโปรแกรมเรียงข้อมูลเองทุกครั้งอีกต่อไป แต่ใช้วิธี outsourcing แทน คือหาดูว่ามีโปรแกรมเอนกประสงค์ทำนองนี้ไหม ที่เมื่อใช้หลาย ๆ ตัวมาต่อจิ๊กซอว์กันแล้วจะทำให้ได้ผลเทียบเท่าการเขียนโปรแกรมยาวหลายหน้าเอง

ผมเรียนรู้จากการเขียนโปรแกรมเล็ก ๆ ลักษณะนี้หลายเรื่องครับ

เช่น

• เรียนรู้ว่า การหาความรู้ข้ามสาขา ช่วยให้มีวิธีที่ง่ายกว่าในการแก้ปัญหา
• เรียนรู้ว่า คิดแบบ abstract ก็อาจมีประโยชน์ (มองว่า รายงาน=สร้างแฟ้ม)
  
• เรียนรู้ว่า การจัดการ ก็เป็น ภาคต่อ การเขียนโปรแกรมเหมือนกัน เพราะผมหยิบใช้ เครื่องหมาย  > ของระบบปฎิบัติการเพียงหนวยเดียว ก็สามารถลดได้ทั้งความซับซ้อน (เปิดปิดแฟ้ม) และลดได้ทั้งความซ้ำซ้อน (เขียนโปรแกรมให้รายงาน 3 รอบ)
  
• เรียนรู้ว่า วิถีทางที่ไม่มาตรฐาน (การยิงรายงานอัดตรงเข้าหน้าจอโดยไม่ผ่านระบบปฎิบัติการ) แม้ทำให้ได้ผลเร็วกว่า(นิดหน่อย) แต่ก็จะทำให้ระบบขาดความยืดหยุ่น (ในกรณีนี้คือ ไม่สามารถสั่ง redirection)ซึ่งในระยะยาว..ไม่คุ้ม
• ...นอกเหนือจากนี้ คงขึ้นกับการตีความเรื่องเล่าแล้วครับ...