ขอเอาของเก่ามาขายกินใหม่อีกเช่นเคย ผมเคยโพสต์บทความนี้เมื่อสักราว ๆ ปีหนึ่งมาแล้ว แต่ดั๊นไปแปะไว้ในเฟซบุ๊ค ซึ่งผมคิดว่ามันคงจะไม่ได้เผยแพร่ในวงกว้างอย่างที่ตั้งใจเท่าที่ควร เนื่องจากระบบความปลอดภัยของเฟซบุ๊คเองที่จำกัด เลยทำให้ต้องเอามา 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
0.000000
0.000000