[หนังสือแปล] Refactoring JavaScript: บทนำ

บทนำ

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

ที่มาที่ไป

ไม่ว่าคุณจะชอบใจหรือไม่ก็ตาม JavaScript คือภาษาที่จะยังไม่หายไปไหนในเร็ววันนี้ และไม่ว่าคุณจะพัฒนาระบบด้วย JS Frameword/Library ขั้นเทพแค่ไหนก็ตาม ตราบใดที่คุณภาพของ code JavaScript ยังห่วยอยู่ ตราบนั้น bug และความช้าของระบบก็จะคงอยู่ตลอดไป การเลือกที่จะเขียน code ขึ้นมาใหม่ทั้งหมด หรือการโยกไปใช้ framework ตัวอื่น ก็ไม่ใช่ทางเลือกที่ดี แถมยัง “แพง” ได้โล่ และคาดเดาผลลัพธ์ได้ยากมาก

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

หนังสือเล่มนี้จะบอกถึงแนวทางที่ช่วยให้คุณหยุดเขียน Bad code และหากจำเป็นต้องดีลกับพวกมัน ก็ไม่ต้องกลัว เพราะการเปลี่ยนให้มันเป็น better code นั้น ไม่ยาก และไม่แพงอย่างที่คิด (หากใช้วิธีในหนังสือเล่มนี้)

ใครที่ควรอ่านหนังสือเล่มนี้

คุณควรจะเป็นโปรแกรมเมอร์ที่ผ่านสมรภูมิ Bad Code มาบ้าง ที่สำคัญควรจะเป็นคนที่อยากปรับปรุง Code ของตัวเองให้ดีขึ้น จะเป็น Frontend หรือ Backend ก็ได้หมด ไม่สำคัญว่าคุณจะเลือกทำงานกับ JavaScript ด้วยตัวเอง หรือโชคชะตาบังคับให้ต้องอยู่กับมัน หนังสือเล่มนี้ช่วยคุณได้

แต่หากคุณเป็นมือใหม่หัดขับ และไม่แคร์ว่า Code ที่คุณเขียนออกไปจะมีหน้าตาเป็นอย่างไร (ขอเพียงแค่ให้งานจบเป็นพอ) คุณก็อาจจะทนอ่านหนังสือเล่มนี้ได้ไม่นาน แต่หากคุณคือมือใหม่ ที่มีใจใฝ่ Good Code คุณ อ่านหนังสือถูกเล่มแล้วครับ

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

หรือหากคุณคือคนที่กำลังประสบปัญหากับการ Testing, Debugging หรือขาดความเชื่อมั่นใน Codebase ของตัวเอง นี่คือหนังสือที่คุณจะต้องอ่าน

พวกเราแทบทุกคนต่างก็คงไม่มีใครได้อยู่กับ Perfect Codebase (ยิ่ง JavaScript ยิ่งไม่ต้องพูดถึง) ซักเท่าไหร่ ไม่ว่า Code เหล่านั้นจะเขียนด้วย Ruby, Python, Java ฯลฯ หนังสือเล่มนี้ขออาสามาช่วยให้คุณมีความสามารถในการค้นหา และระบุ Bad Code ภายใน Codebase แล้วจู่โจมความ Bad เหล่านั้นด้วยแทคติกอันหลากหลาย

เนื้อหาโดยรวมของหนังสือ

บทที่ 1–5 จะบรรยายให้ผู้อ่านรู้จักถึง “ผู้เล่น” แต่ละตัวว่าหากจะจัดทีมให้พวกมันเล่นด้วยกัน ต้องทำอย่างไรบ้าง อันได้แก่ JavaScript, Refactoring, Quality, Confidence และ Testing หนังสือหลายต่อหลายเล่มในท้องตลาดมักจะชอบยกเอาเรื่องของการ Testing ไปอยู่ในตอนท้ายของหนังสือ (อันนี้โคตรเห็นด้วย –ผู้แปล) แต่ด้วยสไตล์ของเนื้อหาในหนังสือเล่มนี้ เราคงไม่สามารถเอาหัวข้อ Testing ไปไว้ตอนท้ายได้แบบเล่มอื่นๆ เพราะ Testing คือแกนกลางของ Confidence; Confidence คือรากของการ Refactoring; Refactoring คือจุดเริ่มต้น และเป็นหัวใจของ Quality อันเป็นเป้าหมายสูงสุดของเรา

Testing -> Confidence -> Refactoring -> Quality

JavaScript และผองเพื่อน (ecosystem) ต่างก่อกำเนิดขึ้นมาเพื่อเอื้อให้เกิดการเปลี่ยนแปลงดังกล่าวได้ดีกว่าเดิม ด้วยเหตุนี้ เนื้อหาภายใน 5 บทแรกย่อมจะต้องมีเนื้อหาที่เกี่ยวกับการศึกษาตัว JavaScript อย่างหลีกเลี่ยงไม่ได้ แต่หากคุณคุ้นเคยกับเนื้อหาเหล่านี้อยู่แล้ว จะอ่านแบบผ่าน หรือข้ามไปเลยก็ไม่ผิดกติกาแต่อย่างใด (แต่ผมไม่แนะนำ 5555) ก็มันหนังสือของคุณนี่นา จะอ่านแบบไหน จะข้ามบทไหนมันก็ต้องแล้วแต่คุณผู้อ่านอยู่แล้ว แต่หากคุณจะใช้ทั้ง 5 บทแรกเป็นเสมือนประตูที่พาคุณก้าวเข้าสู่โลกใหม่อย่างเรื่อง quality code ก็ไม่ผิดกติกา หากคุณมีปัญหาในการใช้งานหนังสือ ได้โปรดบอกผมที ตัวผมเองจะสถิตอยู่ที่ http://evanburchard.com/contact หรือหากสะดวกติดต่อผ่าน Twitter และ GitHub ก็มาคุยกับผมได้ที่ @evanburchard

ผ่านบทที่ 5 ไป เนื้อหาจะเริ่มยากขึ้น และจะยากสุดๆ สำหรับคนที่อ่านข้ามบทที่ 1–5 มา (แล้วเมิงจะอนุญาตให้อ่านข้ามทำม๊ายยย –ผู้แปล) คุณจะต้องเขียน code ตามหนังสือหนักขึ้นกว่าเดิม ในบทที่ 6 และ 7 เราจะว่ากันด้วยเรื่องการ Refactoring Functions/Objects ถึงตอนนี้เราจะไม่ยั้งมือ อะไรที่จำเป็นต้องซับซ้อน เราก็จะอ้วกมันออกมาเต็มที่ ซึ่งเป้าหมายหลักๆ ของสองบทนี้ก็คือเสนอ options ต่างๆ ที่ใช้สำหรับปรับปรุง code โดยไม่ต้องไปยุ่งกับ code ในระดับ interface

เมื่อคุณได้ลองนำเทคนิคจากทั้งสองบทนี้ไปลองใช้จริง คุณจะสามารถเปลี่ยน codebase ที่แสนจะยุ่งเหยิง ให้กลายมาเป็นเสาเข็มของระบบคุณภาพได้ไม่ยาก

บทที่ 8 ว่าด้วยเรื่องของ Architecture โดยรวมไปถึง (หรือตัดออก) เนื้อหาของ Hierarchies

บทที่ 9, 10 และ 11 จะพูดถึงเนื้อหาเฉพาะมากขึ้น ได้แก่ Design Patterns, Asynchronous Programming และ Functional Programming ตามลำดับ code ที่ปรากฏในสามบทนี้จะเป็นส่วนต่อขยายจากพื้นฐานใน 8 บทก่อนหน้า ซึ่งจะมีความดุเดือดมากยิ่งขึ้น เนื้อหา Design Pattern ในบทที่ 9 จะว่าด้วยเรื่องของ JavaScript Object-Oriented Programming (OOP) โดยเนื้อหาจะครอบคลุมไปถึงเรื่องราว และที่มาที่ไปของความสัมพันธ์ระหว่าง Refactoring และ Object-Oriented Programming ส่วนในบทที่ 10 เราจะมาคุยกันถึงแนวทางในการเขียนโปรแกรมที่ทำงานหลายอย่างได้พร้อมๆ กัน บทที่ 11 เราจะมาทำความรู้จักกับ Functional Programming ผ่าน library สองตัวที่สามารถทำงานได้เหนือกว่า Standard Array

เฉพาะสามบทสุดท้ายเท่านั้น ที่ เนื้อหาจะค่อนข้างฉีกออกไปจากกรอบการเขียน ของผมพอสมควร เพราะมันจะเริ่มเข้าไปยุ่งกับ code ในระดับ interface แต่ในแปดบทแรก ผมจะเน้นแต่การ Refactoring เพื่อเปลี่ยนแปลง code ในระดับ implementation โดยไม่เข้าไปยุ่งกับระดับ interface

สาเหตุที่ผมวางกรอบเนื้อหาไว้แบบนี้เนื่องเพราะ interface ต่างๆ ที่ติดมากับ library ที่ถูกเลือกนำมาใช้นั้น ก็ดีพออยู่แล้ว และในบางงานเราก็ต้องใช้งานพวกมันอย่างหลีกเลี่ยงไม่ได้ บางครั้งเราก็อยากจะเขียน Asynchronous Code เพื่อเหตุผลด้าน performance หรือบางครั้งเราก็อาจจะต้องเข้าไปเกี่ยวข้องกับ code ที่พยายามจะแปลงตัวเองเป็น OOP หรือเป็น Functional Programming ทั้งในรูปแบบที่ดีและเลว สรุปคือ เราคือผู้รับมรดกต่อมาจากคนทำงานที่มาก่อนหน้าเรา ทั้ง code, practice ที่เลือกใช้ และเฟรมเวิร์คต่างๆ เมื่อเราต้องทำงานกับมรดกเหล่านี้ หน้าที่ของเราก็คือเราต้องปรับปรุง code ให้มันดีที่สุด

มีจุดนึงที่ผมอยากเตือนไว้ตรงนี้ก็คือ การเปลี่ยน code โดยใช้ชุดความคิด (Paradigm) ที่แตกต่างจากเดิมอย่างสิ้นเชิง เช่น เปลี่ยนจาก OOP มาเป็น Functional เป็นต้น แบบนี้ไม่ถือว่าเป็นการ Refactoring ในมุมมองของหนังสือเล่มนี้

ด้วยเหตุนี้เนื้อหาในแต่ละบทจะทำการ Refactoring code โดยใช้ชุดความคิดเดิม เช่น OOP -> better OOP, async -> better async หรือ Functional -> better Functional เป็นต้น ที่ผมอยากแนะนำก็คือ ให้เราลองมองในมุมกว้าง โดยอาจจะโฟกัสไปที่ระดับเหนือ code นั่นคือ ระดับของโปรแกรมที่พร้อมรัน เมื่อนั้น สมองของเราจะพร้อมย้ายจากชุดความคิดหนึ่งไปยังอีกชุดหนึ่งได้โดยไม่ลำบากมากนัก และอีกสิ่งหนึ่งที่ผมอยากจะแนะนำก็คือ เวลาจะเปลี่ยน code ให้เปลี่ยนทีละเล็กทีละน้อย เน้นขนาด “พอดีคำ” โดยเน้นเปลี่ยน code ในส่วนที่ง่ายต่อการทดสอบ และมีความมั่นใจว่าแก้แล้วไม่พัง

ตรงนี้ ผมขอยก quote ของ William Opdyke คัดมาจากวิทยานิพนธ์เรื่อง Refactoring ของเขา ดังนี้

ความหมายของการ Refactoring ก็คือ การอนุญาตให้มีการเปลี่ยนแปลงได้ทั้งโปรแกรม ตราบใดที่การไหลของข้อมูลระหว่าง input -> output ยังเหมือนเดิมไม่เปลี่ยนแปลง ให้จินตนาการว่าเราวาดลงกลมลงไปในจุดที่ได้รับผลกระทบจากการ Refactoring ส่วนที่อยู่นอกวงกลมคือส่วนที่ไม่ถูกเปลี่ยน

สำหรับการ Refactoring บางตัว อาจจะส่งผลให้วงกลมถูกวาดออกไปจนครอบคลุมโปรแกรมเกือบทั้งหมด ยกตัวอย่างเช่น การ refactor เพื่อเปลี่ยนชื่อ variable ที่ถูก reference จากทั้งโปรแกรม เป็นต้น

อาจจะมีการ Refactoring บางตัว ก็อาจจะสร้างวงกลมวงเล็กที่กระทบกับพื้นที่ส่วนน้อยเท่านั้น เช่น การ refactoring ที่ทำให้ code บางส่วนใน function ตัวเดียวได้รับผลกระทบ เป็นต้น จากทั้งสองกรณี จุดสำคัญอยู่ตรงที่ผลลัพธ์ (รวมถึง ผลข้างเคียง) ของการ invoke function และการ reference ที่เกิดขึ้นอยู่นอกพื้นที่วงกลมต้องไม่เปลี่ยนแปลง

บางครั้ง เราอาจจะเคยได้ยินใครๆ ชอบมาพูดกันว่าการ Refactoring คือการ “change code” ซึ่งหากเป็นโปรเจ็กท์ในสเกลเล็กๆ ก็อาจจะมองแบบนั้นได้ (ซึ่งเนื้อหาส่วนใหญ่ภายในหนังสือเล่มนี้จะพูดถึงโปรเจ็กท์ระดับนี้) แต่หากเป็นเนื้อหาในบทที่ 8, 9 และ 10 ที่พูดถึงเรื่องของ architectural และแนวทางที่สองในการสร้าง better code ก็อาจจะถือเอาความหมายดั้งเดิมของ Refactoring ไม่ได้อีกต่อไป ยกตัวอย่างเช่น หากมีบางคนมาสั่งคุณว่า “จง Refactoring เพื่อเปลี่ยนไปใช้ Asynchronous Code” ถือเป็นคำสั่งที่คลุมเครือเกินไป และไม่สามารถเอาไปทำงานต่อได้ และบทที่ 9 ก็ช่วยให้คุณทำงานตามคำสั่งที่คลุมเครือแบบนี้ไม่ได้อยู่ดี

หากคุณผู้อ่านเริ่มรู้สึกสับสนกับเครื่องมือ และหลักคิดต่างๆ ภายในหนังสือเล่มนี้ ผมก็ได้เตรียม Appendix ไว้ด้วยหวังว่ามันจะสามารถช่วยคุณได้บ้าง

ดังนั้น โดยสรุปแล้ว หนังสือเล่มนี้จะพูดถึง

· Refactoring

· Testing

· JavaScript

· Refactoring และการ Testing JavaScript

· ชุดความคิดในการเขียน code (Paradigms)

· การ Refactoring และการ Testing JavaScript ตามชุดความคิดนั้นๆ

หากคุณติดปัญหาอะไร มีคำถาม อยากด่าผม หรืออ่านแล้วรู้สึกดีจนอยากชม ก็สามารถมาคุยกับผมได้ที่เว็บไซต์ส่วนตัวของผม (http://evanburchard.com/contact)

ตัวอย่าง Code

ตัวอย่าง code จริงสามารถ download ได้ที่ github

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

เครื่องมือที่ถูกนำมาใช้ภายในหนังสือเล่มนี้สามารถอ้างอิงผ่าน Appendix ได้ สำหรับคนใจร้อน ข้างล่างนี้คือรายการเครื่องมือที่ถูกนำมาใช้ภายในหนังสือ พร้อมเวอร์ชั่นประกอบ ดังนี้

• node 6.7.0

• npm 3.10.3

• wish 0.1.2

• mocha 3.2.0

• deep-equal 1.0.1

• testdouble 1.10.0

• tape 4.6.3

• lodash 4.17.2

• assert 1.4.1

• underscore 1.8.3

• ramda 0.22.1

• sanctuary 0.11.1

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