โปรแกรมเมอร์รำพึง "เขียนโค้ดให้เหมือนเป็นมรดก ให้คนอื่นอ่านรู้เรื่อง เราจะโดนสิบล้อชนตายเมื่อไหร่ก็ไม่รู้"


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

10 สิงหาคม 2554

“พฤษภกาสร    อีกกุญชรอันปลดปลง

โททนต์เสน่งคง    สำคัญหมายในกายมี

นรชาติวางวาย    มลายสิ้นทั้งอินทรีย์

สถิตย์ทั่วแต่ชั่วดี    ประดับไว้ในโลกา”

(กฤษณาสอนน้องคำฉันท์)

“โคควายวายชีพได้    เขาหนัง

เป็นสิ่งเป็นอันยัง    อยู่ไซร้

คนเด็ดดับสูญสัง    ขารร่าง

เป็นชื่อเป็นเสียงได้    แต่ร้ายกับดี”

(โคลงโลกนิติ)

วันนี้ขอเอาคำโคลง, คำฉันท์มาจั่วหัวครับ สืบเนื่องมาจากข้อความที่ผมได้เคยโพสต์ไว้บนเฟซบุ๊คและทวิตเตอร์เมื่อวัน จันทร์ที่ 20 กันยายนที่ผ่านมานี้ ว่า “ข้อคิดจากงาน /* pOrt 80 BKK */ ‘เขียนโค้ดให้เหมือนเป็นมรดก ให้คนอื่นอ่านรู้เรื่อง เราจะโดนสิบล้อชนตายเมื่อไหร่ก็ไม่รู้'” และก็มีเพื่อนคนหนึ่งยุว่าน่าจะเขียนถึงประเด็นนี้ ไอ่กระผมมันก็ยุขึ้นเสียด้วย ก็เลยอยากจะขอเขียนถึงเรื่องนี้สักหน่อยครับ

ผมเชื่อว่าจากคำฉันท์และโคลงบทข้างบนนี้ เพื่อน ๆ คงจะทราบความหมายดีว่า อันวัว ควาย แลช้างนั้น เมื่อตายแล้วยังเหลือเขา เหลือหนัง เหลืองา ไว้ใช้ทำประโยชน์ แต่คนนั้นไม่เหลืออะไรที่จะเป็นประโยชน์ได้เลย คงมีแต่ความดีเลวเท่านั้นที่จะเป็นที่กล่าวถึงเมื่อตายไปแล้ว

แล้วมันเกี่ยวอะไรกับเรื่องเขียนโปรแกรมฟระ! ไอ่คนเขียนนี่มั่วอีกแล้ว! ดูก่อน…ท่านผู้เจริญ! ขอให้ลองติดตามอ่านต่อไปสักหน่อยครับ แล้วจะเห็นความเกี่ยวเนื่องกันทั้ง ๆ ที่มันไม่น่าจะมาเกี่ยวกันได้

พี่ ๆ เพื่อน ๆ น้อง ๆ โปรแกรมเมอร์หลาย ๆ คนคงจะเคยประสบเหตุการณ์ทำนองว่า เวลาที่ยูสเซอร์มาขอแก้งานที่เราเคยเขียนให้เขาเมื่อนานมาแล้ว เราก็จะมักบอกว่า “ขอเวลารื้อโค้ดดูหน่อยนะพี่ จำไม่ได้ว่าทำอะไรไปมั่งแล้ว” หรือ “อู้ยยยยย! มันนานแล้วอ้ะ ไม่รู้ว่าเก็บไว้ไหนแล้ว ขอหาก่อนนะพี่” หรืออาจจะโวยวายกับยูสเซอร์ว่า “ทำไมไม่สรุปงานให้เรียบร้อยเสียก่อนล่ะ มาขอแก้บ่อย ๆ เนี่ย กว่าจะแก้ได้แต่ละหนมันยากนะ” หรือ …..

ไม่อย่างนั้นก็อาจจะเคยต้องแก้งานของโปรแกรมเมอร์คนอื่น และแก้งานไปก็สบถก่นด่าบรรพบุรุษของผู้เขียนโปรแกรมคนก่อนอยู่ในใจไปว่า “มันเขียนโปรแกรมประสา…่าอะไร(วะ) อ่านไม่รู้เรื่องเลย แก้ยากฉิบ” หรืออาจจะเป็นถ้อยคำอะไรที่แรงกว่านี้ และอาจจะเป็นไปได้หากมีเวลาพอ ก็เขียนใหม่ให้ทำได้อย่างเก่า ง่ายกว่ามานั่งเสียเวลางัดแงะโค้ดไปและด่าไป

ปกติ โปรแกรมเมอร์อย่างเรา ๆ เนี่ย วัน ๆ แค่เขียนโปรแกรม, คิดหาอัลกอริธึมเพื่อมาแก้ปัญหา, ทดสอบโปรแกรม, แก้บั๊กโปรแกรม ฯลฯ ก็แทบจะไม่เหลือเวลาไปทำอย่างอื่นในชีวิตแล้ว ดังนั้นส่วนใหญ่เราก็จะเขียน ๆ ๆ ๆ ๆ แก้ ๆ ๆ ๆ ๆ โดยที่ไม่เคยบันทึกไว้เลยว่า เราได้เคยทำอะไรไปแล้วบ้างกับโปรแกรมที่เราได้เขียนไป ซึ่งก็เป็นที่มาของข้ออ้างยอดฮิตที่ว่า “ก็มันไม่มีเวลาทำนี่หว่า แค่นี้ก็ส่งงานจะไม่ทันอยู่แล้ว”

งานก็จะเอาเร็ว เอาถูกต้อง เอาสวย(หน้าจอ) เอานู่น เอานี่ เอานั่น เอาโน่น บลา บลา บลา บลา บลา  แต่เวลามีให้นิดเดียว ยิ่งถ้าเป็นเอาต์ซอร์สอาจจะเจอว่าตังค์ก็ยังจะให้นิดเดียวอีกด้วย นี่ยังไม่รวมที่เราจะต้องเขียนโปรแกรมให้รัดกุม ต้องมี security ต้องกันคนที่ไม่มีสิทธิ์เข้าถึงข้อมูลไม่ให้เข้าถึงได้ ต้องกันการป้อนข้อมูลที่ทำให้ระบบรวนหรือเสียหาย อ้อ! ต้องทำงานเร็วด้วยนะ แล้วก็ยังต้องทำอะไรอีกสารพัด โฮ่! ไปตายซะ!!! แล้วอย่างนี้ใคร้มันจะมีเวลามาเขียนคำอธิบายในโค้ดโปรแกรม หรือมาคิดตั้งชื่อตัวแปรให้มีความหมายอ่านรู้เรื่อง หรือมานั่งคิดประดิษฐ์ทำให้โค้ดโปรแกรมอ่านง่ายกันอีกล่ะ

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

1.1 ระบบงานหนึ่งมีโค้ดโปรแกรมที่เขียนมั่วมาก ตั้งชื่อไฟล์ซอร์สโค้ดมั่วมาก ตั้งชื่อตัวแปรมั่วมาก บางครั้งก็เอาชื่อเล่นแฟน เอาชื่อเล่นตัวเองมาตั้งเป็นชื่อตัวแปร แถมยังมีรันเป็นซีรี่ส์ (คือเอาชื่อเล่นแฟนหรือชื่อเล่นตัวเองแล้วก็ตามด้วยตัวเลข 1,2,3…) หรือไม่ก็ใช้ตัวอักษรอะไรที่ไม่มีความหมายเช่น a, b, c คอมเม้นต์อะไรไม่มีสักบรรทัด แถมไล่ไปไล่มาก็พบว่าตัวแปรบางตัวที่ตั้งขึ้นมาก็ไม่เห็นมันจะเอามาใช้ที่ไหนเลย

1.2 ระบบงานหนึ่ง มีคำอธิบายแนวคิดอัลกอริธึมของแต่ละโมดูลอย่างชัดเจน อธิบายและระบุชนิดของตัวแปร, พารามิเตอร์และค่าคืนกลับ (return value) อย่างละเอียดราวกับอ่านพ็อกเก็ตบุ๊ค อยู่ในโค้ดโปรแกรม แถมยังมีบอกด้วยว่า ใครเขียน เขียนเมื่อไร แนวความคิดในการเขียนเป็นอย่างไร ใครแก้ไข แก้ไขเมื่อไร เพราะอะไรถึงต้องแก้ไข แนวความคิดในการแก้ไขเป็นอย่างไร และแก้ไขอะไรบ้าง

หากคุณต้องบำรุงรักษาระบบงานใดระบบงานหนึ่งในสองระบบนี้ คุณอยากได้ระบบไหนมาดูแล ?

2.1 ช็อพพัฒนา (development shop) ช็อพหนึ่ง ก่อนจะพัฒนาระบบสักระบบต้องมีการสำรวจความต้องการของยูสเซอร์หลาย ๆ หน จากนั้นนำความต้องการของยูสเซอร์มาวิเคราะห์และออกแบบระบบ ออกแบบหน้าจอ ออกแบบรายงาน ออกแบบฐานข้อมูลและความสัมพันธ์ ออกแบบคลาสและความสัมพันธ์ วิเคราะห์ความยาก-ง่ายของแต่ละโมดูลและกำหนดวันแล้วเสร็จโดยคร่าว ๆ ของแต่ละโมดูล ตามความยาก-ง่ายนั้น และสามารถประมาณเวลาที่ต้องใช้ในการพัฒนาได้ใกล้เคียงกับความเป็นจริง มีการทำเอกสาร system specification, detail specification และแจกจ่าย specification เหล่านั้นให้กับโปรแกรมเมอร์แต่ละคน ส่วนโปรแกรมเมอร์มีหน้าที่เขียนตาม specification ที่ได้รับ มีทีมทดสอบระบบ มีทีมจัดทำเอกสารคู่มือการใช้งาน จัดทำและจัดเก็บเอกสารระบบ ฯลฯ อ่านมาถึงตรงนี้หลาย ๆ คนอาจจะบอกว่าอย่าอีเดียตน่า ช็อพพัฒนาที่ไหน ๆ เขาก็ทำกันอย่างนี้   แต่… อย่าเพิ่งด่วนสรุปครับเพราะก็ยังมีช็อพพัฒนาอีกแบบที่

2.2 สำรวจความต้องการของยูสเซอร์แค่หนสองหน แล้วก็มาเริ่มพัฒนาระบบ ไม่มีเอกสาร ทั้งซิสเต็มสเป็คฯ ดีเทลสเป็คฯ เวลาจะเขียนโปรแกรมก็เรียกโปรแกรมเมอร์มาเล่าให้ฟังว่ายูสเซอร์อยากจะได้อย่างไร จากนั้นโปรแกรมเมอร์ก็ไปด้นสด ๆ แบบคิดอะไรได้ก็เขียนมันออกมา เอาแค่ให้ตรงกับที่รับฟังมา มิพักจะต้องพูดถึงทีมทดสอบ คนเขียนน่ะแหละทดสอบ เอกสารระบบและการจัดเก็บเอกสารเหรอ? ลืมได้เลย! ประมาณเวลาที่ใช้ก็มั่ว ๆ ไป บอกยูสเซอร์ไปก่อนว่าเร็วที่สุดเท่าที่อยากจะได้น่ะแหละ เดือนนึง สองเดือน เสร็จไม่ทันก็ขอเลื่อนนะคร้าบพี่น้องคร้าบ

หากคุณมีโอกาสเลือกจะอยู่คุณอยากจะอยู่ช็อพไหน ?

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

เริ่มต้นที่ตัวเราเองก่อนเลยครับ โดยที่ถ้ายังไม่มีมาตรฐานก็กำหนดมาตรฐานเสีย การตั้งชื่อแฟ้ม, การตั้งชื่อตัวแปร ฯลฯ เขียนคอมเม้นต์ในโค้ดโปรแกรม เขียนแนวความคิด เขียนคำอธิบายการแก้ไขแต่ละครั้งว่าแก้ไขอะไร อย่างไร เพราะอะไร ตั้งชื่อตัวแปรให้มีความหมาย กำหนดชนิดของตัวแปรให้ชัดเจน สมัยก่อนที่ IDE ยังไม่ฉลาด ก็มีการคิดค้นวิธีที่ช่วยให้โค้ดอ่านง่าย เห็นชื่อตัวแปรแล้วเดาชนิดของมันได้ซึ่งเรียกว่า “Hungarian notation” โดยมีการกำหนด prefix ของชื่อตัวแปรตามชนิดของตัวแปรนั้น ๆ เช่น strName คือ string, iRange คือ integer เป็นต้น ซึ่งสิ่งที่เราทำเหล่านี้ก็ย้อนกลับมาช่วยเราเองด้วย เวลาที่เรากลับมาดูงานเราจะได้จำได้ว่าเราทำอะไรไว้บ้าง แต่ในปัจจุบัน การใช้ Hungarian notation อาจจะไม่ค่อยจำเป็นมากนักเพราะ IDE ฉลาดขึ้น แค่เราพาเมาส์พ้อยเตอร์ไปวางที่ชื่อตัวแปรเราก็จะรู้ชนิดของตัวแปรนั้น ๆ แล้ว

โค้ดบางช่วงที่เรามั่ว ๆ ทำให้เสร็จไปก่อนแบบแก้ผ้าเอาหน้ารอดนั้นก็ใส่คอมเม้นต์ พวก TODO: หรือ FIXME: ไว้ด้วยก็จะดี เพื่อที่เราจะได้หาที่ที่จะกลับมาแก้ไขหรือปรับปรุงในคราวหน้าได้ง่าย ๆ

เพียงเท่านี้โค้ดโปรแกรมก็จะอ่านง่ายขึ้น โปรแกรมเมอร์คนอื่น ๆ ก็อาจสามารถแก้ไขโค้ดโปรแกรมของคุณได้ง่ายขึ้น ในทางกลับกันคุณก็อาจสามารถแก้ไขโค้ดโปรแกรมที่คนอื่นเขียนไว้ได้ง่าย ๆ เช่น กัน ทีนี้คุณก็สามารถที่จะ”ตายตาหลับ”ได้แล้ว อย่าไปคิดว่า “ถ้าฉันเขียนโปรแกรมให้อ่านง่าย ๆ แก้ไขง่าย ๆ คนอื่นก็จะเอาโปรแกรมฉันไปแก้ได้สิ แล้วฉันก็จะหมดความสำคัญไปล่ะสิ” หมดเวลาสำหรับแนวคิดดีโน่ (dino = dinosaur ไดโนเสาร์นั่นแหละ) แบบนั้นแล้วครับ ลองคิดดูสิ ถ้ามีพวกโปรแกรมเมอร์สมองดีโน่อย่างนี้ทั้งโลก เราจะได้เห็นโครงการโอเพ่นซอร์สดี ๆ อย่าง OpenOffice, GIMP, Apache หรือ Linux ใน พ.ศ.นี้กะเขาเหรอครับ

ผมเองนับได้ว่าเป็นคนที่โชคดีคนหนึ่ง เพราะว่าที่ทำงานที่แรกที่ผมเริ่มต้นอาชีพโปรแกรมเมอร์นั้นเป็น Software House ที่มีการบริหารจัดการที่ดีพอสมควร เป็นประเภทช็อพที่ 2.1 เรื่องพื้นฐานเหล่านี้มันก็เลยติดตัวมา

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

ก่อนจบบทความนี้ผมก็ใคร่จะขอเอาคำฉันท์ที่จั่วหัวขึ้นต้นไว้กลับมาใช้อีกสักหน แต่ปรับเปลี่ยนเป็นแบบของผมนะครับ

พฤษภกาสร     อีกกุญชรอันปลดปลง

โททนต์เสน่งคง     สำคัญหมายในกายมี

โปรแกรมเมอร์เมื่อวางวาย     มลายสิ้นทั้งอินทรีย์

เหลือซอร์สโค้ด(ที่)เลวหรือดี     ประดับไว้ในโลกา

ราตรีสวัสดิ์ครับ

First Post: 22 กันยายน 2553
Last Post: 10 สิงหาคม 2554

3 comments

  1. ขอบคุณครับ…
    เป็นบทความที่เยี่ยมยอดจริงๆ…
    ตรงกับชีวิตจริง…ของใครหลายๆ คน…

    และความจริง…
    หลายๆ คนมักจะชมอยู่กับระบบงานเดียว…
    โดยปกปิดทุกอย่างเท่าที่จะสามารถทำได้…เหมือนกลัวคนอื่นจะมาแย่งงาน…

    ปล.
    ผมเคยเห็นโปรแกรมเมอร์ท่านหนึ่ง…
    เขียนโค้ด…

    If 1=1 then


    End If

  2. อ่านแล้วให้รู้สึกสะเทือนซางชอบกลแฮะ
    เจอบ่อยนะ ประเภทที่รักษาท่วงทีสไตล์การเขียนของตัวเอง
    ยึดลีลาไว้แน่นอย่างกะลิงเกาะกะลามะพร้าว

    มัง อ่าน ของ มัง รู้ เรื่อง คน เดียว

    กว่าที่ใครคนอื่นจะเข้าไปช่วยดูแล ช่วยจัดการ ต้องมานั่งทำความเข้าใจมังก่อน

    ไอ้ มัง .. เนี่ย มีเกลื่อนนัก

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s