Version Control – สิ่งสำคัญที่ทุกโปรเจคต้องใช้

พอดีวันนี้ได้คุยกับน้องฝึกงานที่บริษัท ผมไม่ได้เป็นผู้ดูแลน้องเขา แต่ก็ช่วยเหลือกันเพราะพี่ที่ดูแลแกโหดเหลือเกิน (ฮา) พอดีได้จังหวะก็เลยบอกน้องไปว่า ตั้งแต่วันนี้ไปให้ใช้ Version Control นะ จะได้เก็บรักษาโค๊ดได้ดีหน่อย

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

Version Control System หรืออาจจะถูกเรียกว่า Revision Control System หรือ Source Control System เป็นระบบหรือชุดของซอฟต์แวร์ที่ทำหน้าที่เก็บรักษาซอร์สโค๊ด และไฟล์รีซอร์สต่าง ๆ ของโปรแกรมที่เราทำงานด้วย โดยมันจะเก็บการเปลี่ยนแปลงของทุกไฟล์ในระบบเป็น version หรือ revision ของไฟล์ เพื่อที่ว่าเราสามารถดูประวัติย้อนหลังไปได้ว่าโค๊ดของโปรแกรมนั้นเคยถูกเปลี่ยนแปลงอะไรมาบ้าง และด้วยสาเหตุใดถึงต้องทำเช่นนั้น

นอกจากนี้ไฟล์โค๊ดแต่ละไฟล์อาจจะมีเวอร์ชั่นล่าสุดได้มากกว่า 1 เวอร์ชั่น ซึ่งจะเรียกว่าการแตกกิ่ง หรือ Branching ซึ่งจะมีประโยชน์มากในการที่เราต้องทำงานกับโปรแกรมมากกว่า 1 เวอร์ชั่นขึ้นไป สมมติว่าเรามีโปรแกรมเวอร์ชั่น 1 และเวอร์ชั่น 2 เราก็สร้าง Branch ขึ้นมาสองกิ่งเพื่อที่จะเก็บไฟล์ของโปรแกรมแต่ละเวอร์ชั่น

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

เราสามารถแบ่ง VCS ออกเป็นสองประเภทใหญ่ ๆ ดังนี้

  1. Centralized — ก็คือ VCS ที่มี server กลางคอยเก็บเวอร์ชั่นของไฟล์ทุกเวอร์ชั่น ผู้ใช้จะใช้ client ต่อเข้ามาเพื่อที่จะดึงโค๊ดไปใช้งานในเครื่องของตัวเอง
  2. Distributed — ก็คือ VCS ที่ผู้ใช้แต่ละคนจะเก็บเวอร์ชั่นของไฟล์เอาไว้ในเครื่องของตัวเอง และสามารถที่จะ synchronize ความเปลี่ยนแปลงของไฟล์ในแต่ละเครื่องให้เหมือนกันได้

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

ข้างล่างนี้เป็นตัวอย่างระบบ VCS ที่ได้รับความนิยมในปัจจุบัน

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

แต่กับคนที่ไม่ต้องการจะทำเองก็มีผู้ให้บริการ VCS อยู่หลายเจ้าเหมือนกัน โดยที่ได้รับความนิยมก็มีดังนี้ครับ

โดยบริการเหล่าจะฟรีเมื่อโปรเจคของเราเป็น Open Source แต่เราสามารถเสียเงินซื้อบริการ (ในราคาไม่สูงมากนัก) ถ้าเราต้องการที่จะใช้กับโปรเจคที่ไม่ใช่ Open Source นอกจากนี้เว็บไซต์ดังกล่าวยังให้บริการอื่นนอกจาก VCS อีกด้วย

สุดท้ายนี้อยากแนะนำสักนิดว่า ถ้าเกิดว่าเรากำลังจะเริ่มต้นเขียนโค๊ดโปรแกรมอะไรสักอย่าง  ให้ใช้ VCS กับโปรเจคนั้นด้วยเสมอ แล้วงานจะราบรื่นขึ้นมากครับ

    คอมเมนท์ในโค๊ด – มลภาวะสำหรับโปรแกรมเมอร์

    ถ้าเปรียบโค๊ดโปรแกรมหนึ่งเป็นเหมือนเมืองเมืองหนึ่ง สิ่งที่จะเปรียบเทียบได้กับมลภาวะนั้นก็คือ “comment”

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

    ตอนเด็ก ๆ ผมมีความเชื่ออย่างหนึ่งว่าโค๊ดที่ดีต้องมี comment ครบถ้วนสมบูรณ์ เป็น comment ที่อธิบายว่าคำสั่งนั้นนี้ทำอะไรมีผลลัพท์อะไร ความคิดนี้มีมาถึงตอนที่เขียนโปรแกรมเป็นอาชีพในปีแรก ๆ ผมเสียแรงเขียน comment เป็น code document ฝังเอาไว้เป็นจำนวนมาก

    แต่คราวนี้มาดูกันครับว่าทำไมเราถึงไม่ควรเขียน comment เยอะ ๆ ต่อไปนี้จะเป็นประเภทของ comment ที่เห็นได้ทั่วไปครับ

    Comment ประเภทคำอธิบายว่าโค๊ดทำอะไร หรือทำงานอย่างไร
    หลาย ๆ คนคงเขียน comment กำกับที่โค๊ดเอาไว้ว่าโค๊ดมันทำงานอะไร ทำงานยังไง input คืออะไรและ output คำนวนอย่างไร

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

    แต่พอมีคนอ่าน คนจะอ่าน comment เพราะว่ามันอ่านง่ายกว่า …

    ลองคิดดูเล่น ๆ นะครับ ว่าทำไมเราถึงเขียน comment ในจุดนี้ตั้งแต่แรก ? … คำตอบของหลาย ๆ คนคือ “ก็เพราะโค๊ดมันซับซ้อน อ่านไม่รู้เรื่อง ก็เลยเขียน comment เอาไว้ให้คนอ่านรู้ว่าเขียนอะไรไว้”

    คำถามต่อมาของผมคือ “แล้วเขียนให้มันอ่านรู้เรื่องตั้งแต่แรกไม่ได้เหรอ ???”

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

    ทางเลือกที่ดีกว่าคือการเขียน code ให้เข้าใจง่ายขึ้น และควรเขียน unit test กำกับเอาไว้ว่าถ้า input เป็นอะไร output ต้องเป็นอะไร เมื่อทำทั้งสองส่วนนี้แล้วความจำเป็นของการเขียน comment กำกับเอาไว้ก็จะหมดไป

    Comment ประเภท ประวัติการแก้ไขไฟล์
    ประวัติการแก้ไขไฟล์ หรือที่เรียกกันว่า version history นั้นเป็นวิถีปฎิบัติกันของโปรแกรมเมอร์ตั้งแต่สมัยโบราณกาล … คือเราต้องมีการ track ว่าไฟล์นั้นเคยแก้ไขอะไรมาบ้างก็เลยต้องหาที่ใส่เอาไว้ ก็เลยใส่มันไปตรงหัวไฟล์นั่นแหละ

    แต่ … คุณมั่นใจหรือเปล่าว่า version history นั้นถูกต้อง ? คุณเอาความมั่นใจนี้มาจากไหน ??

    มันเป็นเรื่องที่เป็นไปได้และเกิดขึ้นประจำครับ คือ … มันจะมีโปรแกรมเมอร์ประเภทที่ว่าเวลาเขาเขียน fix code อะไรเขาจะทำสำเนาแยกเป็นอีกไฟล์ แล้วก็พอทำเสร็จก็ก๊อปไฟล์มาทับดื้อ ๆ แล้วถ้าไอ้ตอนที่ทำสำเนาเขาไม่ได้สำเนา version history ติดมาด้วย (ซึ่งมันอยู่ใน comment จะมีหรือไม่มีก็ไม่ผลต่อโปรแกรม) ก็จะกลายเป็นว่าประวัติศาสตร์บางอย่างก็หายไป …

    ทีนี้ไอ้คนที่มาอ่านก็งงสิครับ เอ้ ตกลงว่ามันแก้ไปแล้วหรือยังไม่ได้แก้ บางทีเห็นไม่มีใน history ก็คิดไปเองว่ายังไม่ได้แก้ ก็มานั่งงมหาต่อว่าต้องแก้ยังไงก่อนจะพบว่ามีคนแก้ไปแล้ว ….

    เสียเวลา เสียเงินเสียทอง เสียอารมณ์ และเสียความรู้สึกครับ เจอแบบนี้

    แล้วนึกสภาพว่ามีโปรแกรมเมอร์คนนึง พี่ท่านรีบมากเพราะต้องรีบปิดงาน ก็เลยรีบแก้ไฟล์ให้เสร็จ แล้วก็ดันลืมเขียน version history ในไฟล์ไปซะ … ก็เจ๊งสิครับ

    ทีนี้ผมบอกว่า version history ในไฟล์นั้นเป็นวิถีปฎิบัติของโปรแกรมเมอร์มาตั้งแต่สมัยโบราณ … ที่จริงผมพูดผิดไปหน่อย

    version history นั้นเป็นวิถีปฎิบัติของโปรแกรมเมอร์ “โบราณ” ต่างหาก

    ทำไมถึงเป็นเช่นนั้น คือ หลังจากที่โปรแกรมเริ่มมีขนาดใหญ่ขึ้นเรื่อย ๆ เริ่มมีความซับซ้อนมากขึ้น ไอ้การมาเขียนแค่ว่าแก้อะไรไปบ้างแล้วมันก็ไม่พอใช่ไหมครับ มันต้องมีการเก็บไฟล์หลาย ๆ เวอร์ชั่นเพื่อที่จะเป็นหลักฐานได้ว่าในอดีตเคยเป็นอย่างไรอะไรทำนองนี้ ก็เลยมีการพัฒนาระบบที่เรียกว่า VCS หรือ Version Control System (บางคนจะเรียกว่า SCM หรือ Software Configuration Management ผมมองว่ามันต่างกันนิดหน่อยนะ) เพื่อที่เก็บว่าแต่ละเวอร์ชั่นของไฟล์นั้นมีหน้าต่างเป็นอย่างไร และเราสามารถระบุได้ด้วยว่าแต่ละเวอร์ชั่นนั้นทำอะไร

    ดังนั้นเราจึงสามารถระบุ version history ได้ใน VCS ได้เลย! … ไม่ต้องเอาไปใส่ไฟล์ให้ “ซ้ำซ้อน” อีก

    อันที่จริงการระบุว่าการเปลี่ยนแปลงของแต่ละเวอร์ชั่นนั้นทำอะไรทั้งบน version history ในไฟล์กับบน VCS นั้นเป็นการซ้ำซ้อนและสามารถนำไปสู่ความสับสน นึกสภาพว่าถ้าไอ้คนเขียนโค๊ดมันดันเมาโคล่า เขียน comment ในไฟล์กับใน VCS ไม่เหมือนกัน คนอ่านก็คงมานั่งงงว่าตกลงจะเอาอะไรกันแน่ และถ้าในโค๊ดมันดันผิด … ก็บรรลัยกันไปใหญ่

    ดังนั้น กรุณาใส่ประวัติการแก้ไขไฟล์ลงไปเฉพาะบน VCS นะครับ อย่าใส่ในไฟล์เพิ่มอีกให้สับสนเล่น

    VCS นั้นมีข้อดีอีกอย่างตรงที่สามารถบังคับให้ผู้ที่เอาโค๊ดเข้าไปในระบบต้องเขียน version history ในตัว VCS เองทุกครั้ง ดังนั้นเราจึงแก้ไขปัญหาประเภทลืมเขียนได้อีกด้วย

    Comment ประเภทโค๊ดที่ไม่ต้องการให้ถูกทำงาน
    คิดว่าทุก ๆ ท่านคงเคยเขียนนะครับแบบนี้ ก็คือเรามีโค๊ดแล้วไป comment มันออกให้มันไม่ทำงานไปชั่วคราว เพื่อวัตถุประสงค์อะไรบางอย่าง

    ปัญหาก็คือ คำว่า “ชั่วคราว” ของคนหนึ่งมันคือ “ตลอดกาล” ใช่ครับ มันมีบางคนที่ดันส่งงานไปทั้ง ๆ ที่ยังมี comment ประเภทนี้ติดไปด้วย

    ทีนี้มันก็จะเป็นปัญหาของคนอ่านโค๊ด (อีกแล้ว) ว่าจะเอาอย่างไรกับไอ้ comment นี่ดี ตกลงจะควรจะเก็บไว้หรือควรจะลบทิ้ง และส่วนใหญ่แล้วเขาก็จะทิ้งเอาไว้ครับ เพราะว่าการไปแก้ไฟล์ในจุดที่ไม่ได้เกี่ยวกับงานตัวเองมันเป็นการหาภาระใส่ตัวซะงั้น

    ทุกครั้งที่มีคนจะแก้ไฟล์นี้ก็จะมานั่งคิด ตกลงตูควรจะทำไงกับ comment นี้ดีฟะ ? แล้วก็จะผ่านไป กลายเป็นภาระของลูกหลาน

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

    ดังนั้น โปรแกรมเมอร์ทุกคนควรจะเอา comment ประเภทนี้ออกก่อนส่งงานทุกครั้ง เพราะนอกจากจะไม่เป็นภาระต่อลูกหลานแล้ว ยังจะทำให้แน่ใจได้ว่าเราทำงานเสร็จสมบูรณ์ก่อนแล้วนะครับ

    ที่ว่ามานั้นเป็นตัวอย่างของ comment ที่ไม่ควรมีในไฟล์ครับ เราก็น่าจะพอเห็นแล้วว่า comment นั้นคือมลภาวะในโค๊ด ก็เหมือนกับ CO2 กับฝุ่นทั้งหลายที่อยู่ในอากาศ ที่นอกจากจะไม่มีประโยชน์ต่อร่างกายแล้วยังสามารถทำให้เราเจ็บป่วยได้อีกด้วย ดังนั้นถ้าลดได้ก็ลดเถอะครับ

    สุดท้ายนี้จริง ๆ แล้วมันก็มี comment บางประเภทที่ควรต้องมี เพราะไม่มีอะไรแทนทีได้หรือแทนได้ก็ทำได้ไม่ดี ยกตัวอย่างเช่น

    1. คำประกาศการอนุญาตใช้งาน (License) ก็คือ ระบุว่า ใครเป็นเจ้าของ จะเอาไฟล์ไปใช้อย่างไรได้บ้าง และอย่างไรไม่ได้บ้าง
    2. ข้อมูลคร่าว ๆ เกี่ยวกับไฟล์ เช่น ใครเป็นผู้สร้าง สร้างขึ้นเมื่อไหร่ เพื่ออะไร

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

    ปล. เกือบลืม เดี๋ยวจะเข้าใจผิดว่าเป็นความคิดของผมเองทั้งหมด post นี้ผมอ้างอิงจากหนังสือ Clean Code: A Handbook of Agile Software Craftsmanship โดย Robert C. Martin ครับ เล่มนี้น่าสนใจถึงแม้ว่าคุณจะไม่ได้ใช้ Agile เลยก็ตาม (อันที่จริงผมว่าเนื้อหาส่วนใหญ่ก็ไม่ได้เกี่ยวกับ Agile ตรง ๆ นะ)

    เล่นให้เหมือน …หรือ… เล่นให้ต่าง

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

    ผมเริ่มเล่นดนตรีด้วยการเลียนแบบเหมือนกัน ผมเริ่มเล่นกีตาร์จริงจังจากการแกะเพลงที่ชื่อว่า The Heart of Matter ของ Don Henley ที่เล่นในคอนเสิร์ต Hell Freezes Over หนึ่งใน Laser Disc ที่ขายดีตลอดกาลอีกแผ่นในบ้านเรา (เพลงนี้ไม่มีใน CD)

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

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

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

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

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

    ที่จริงการเล่นให้ต่างแบบสุดโต่งไปเลยก็เป็นการแต่งเพลงขึ้นมาอีกเพลงโดยใช้พื้นฐานจากเพลงเพลงนึง เรียกกันง่าย ๆ ว่าการเรียบเรียงใหม่ หรือการทำ rearrange นั่นเอง บางครั้งการทำ rearrange อาจจะถึงขั้นระดับที่ว่าเปลี่ยนทำนองหลักไปเลยก็มี หรือจะแค่ทำดนตรีขึ้นมาใหม่ก็มีเหมือนกัน ที่จริงสมัยเด็ก ๆ ก็มีงานแข่ง Hotwave Music Award (ผมไม่ได้แข่งกับเขานะ) ในกติกาก็มีการทำ Rearrange ด้วยหนึ่งเพลง นั่นคือนักดนตรีระดับเด็กมัธยมนะ (แต่เด็กทำเองหรือเปล่านี่แล้วแต่วงแฮะ วงเพื่อนผมทำกันเอง แต่อีกวงที่รู้จักกันอ.ทำให้ 55)

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

    ข้อสรุปก็คือ จะเล่นให้เหมือนหรือต่างก็ต้องดูว่า เล่นแล้วออกมาดีหรือเปล่า ถ้าผลลัทพ์ออมาดีก็ถือว่าโอเคแหละ