โปรแกรมแก้ไขเอกสารที่มองภาพรวมเป็นต้นไม้!?
วันนี้เห็น @awkwin ทวีตเกี่ยวกับความ wtf อันสุดจะบรรยายของ JavaScript เลยได้ฤกษ์ขุดกระทู้ในตำนานมาอ่านอีกรอบ แล้วก็ได้สัมผัสถึงความ !@#$%^&* ของภาษา APL ซึ่งคอมเมนท์ในนั้นบอกไว้ว่า มันคงเป็นภาษาที่เจ๋งและกี๊คมากเลยถ้าอยู่ในหนัง ก็เลยทำให้นึกถึงหนังเรื่อง Stealth ตอนที่ศูนย์คอมเข้าไปดูโค้ดของโปรแกรมเพื่อหาบั๊ก (ส่วนนี้ในหนังกากมาก เพราะแม่งเล่นง่าย เอาโค้ดส่วนที่เป็นบั๊กไปไว้ “ระหว่างบรรทัด” เลย ซึ่งในความเป็นจริงโค้ดมันจะซ้อนอยู่ตรงนั้นได้ยังไงวะ) ถึงตอนนี้ก็ฉุกคิดได้ว่า เอ่อ ไม่เห็นจะเจ๋งตรงไหนเลย ถ้ามันแต่งมาเวอร์ๆ แต่ไม่มีทางเป็นไปได้ในโลกความเป็นจริง …
… แล้วก็มาคิดได้ว่า อึม หรือโปรแกรมแก้เอกสารในหนังนั้นมันเป็นแบบโคตรล้ำยุคหว่า สามารถแสดงข้อความซ้อนๆ กันแบบ 3 มิติได้ เลยนั่งคิดต่ออีกซักพักนึงแล้วพบว่าโคตรไร้สาระ โค้ดที่เขียนกันอยู่ 2 มิติจะไปแสดงผลแบบ 3 มิติให้งง+เก็บบั๊กยากขึ้นทำไมหละ
ถอยกลับมา 1 ก้าว.. เอ่อ แต่ถ้าได้เขียนโค้ดแบบ 3 มิติจริงๆ คงเจ๋งไม่น้อยเลยนะ ก็เลยลองออกแบบว่า ไอ้การเขียนโค้ด 3 มิติ (ถ้ามันจะมีจริง) มันควรจะเป็นยังไงกันนะ?
คิดไปเรื่อยๆ โดยอิงจากตัวอย่างในปัจจุบัน ก็พบว่ารูปแบบโค้ดโดยทั่วไปจะออกแนวๆ นี้
ซึ่งถ้ามองในมุมของโปรแกรมเมอร์ที่เชี่ยวแล้วคงไม่มีปัญหา (เริ่มอ่านโปรแกรมจาก main ด้านล่างสุด แล้วโดดไปดูคลาส/ฟังก์ชันแค่เวลาที่ต้องการข้อมูลเพิ่มเติม)
แต่สำหรับโปรแกรมเมอร์มือใหม่ (อย่างผม) นี่ทำให้เกิดปัญหาที่เรียกว่า “เริ่มไม่ถูก” ขั้นรุนแรง ตั้งแต่เริ่มไม่ถูกว่าจะดูโค้ดที่ไหนก่อนดี? ทำไมต้องมองโปรแกรมตามแบบที่คอมพิวเตอร์ทำงานโดยการเริ่มจาก import requirement/dependency ต่างๆ ให้ครบก่อนแล้วจึงจะเริ่ม main ได้? ทิศทางการเขียนโปรแกรมควรจะเขียนแบบ top-down หรือ bottom-up กันแน่?
เลยได้ข้อสรุปสำหรับตัวเองว่า มันคงจะเหมาะกว่า ถ้าเริ่มมาก็สามารถเขียน concept ทั้งหมดของ main ได้เลย อยากใช้ฟังก์ชันใหม่ชื่ออะไรก็เขียนๆ ไปก่อน พอวางโครงเสร็จก็ค่อยกลับมาดูว่ามีฟังก์ชันไหนที่ยังไม่ได้เขียนกฎให้มัน ซึ่งพอดับเบิลคลิกที่ชื่อฟังก์ชันนั้นๆ ก็จะเป็นการเปิดป๊อปอัพหน้าต่างใหม่สำหรับเขียนกฎให้มันนั่นเอง (ยืมแนวคิดมาจาก lambda)
โดยรวมแล้วก็คงคล้ายๆ กับ Inspect Element ของเว็บเบราว์เซอร์ คือเริ่มดูจาก root node ไล่ลงไปเรื่อยๆ นั่นเอง เพียงแต่เปลี่ยนการ expand tag ไปเป็นการเปิดหน้าต่างใหม่แทน
รายละเอียดปลีกย่อย (ถ้าจะทำจริงๆ) ก็คงต้อง highlight สีของฟังก์ชันที่ยังไม่ได้เขียนกฎให้เด่นหน่อย ส่วนถ้าฟังก์ชันไหนเขียนไปแล้วแต่ติดแท๊ก FIXME หรือ TODO ไว้ ก็เปลี่ยนไป highlight ด้วยอีกสีหนึ่ง (จะได้รู้ว่ามีข้อผิดพลาดที่ฟังก์ชันนี้ และกลับมาแก้ไขทีหลังได้ง่าย) แล้วก็คงต้องดักพวก recursion ด้วย ส่วนการเขียนเพิ่มฟังก์ชันใหม่ๆ เข้าไป ต้องเอามันไปแทรกไว้ก่อน main เสมอ
คิดออกแค่นี้ ง่วงแล้ว ลองนอนดูก่อนว่าจะหายบ้ามั้ย 555
author