หากคุณใช้เวลาทั้งวันไปกับการเขียนโค้ด คุณจะใช้เวลาหลายชั่วโมงอยู่ในสองสภาพแวดล้อม: หน้าต่างเบราว์เซอร์ที่งานของคุณทำงานจริง และ Git repository ที่จดจำทุกการตัดสินใจที่คุณทำเพื่อไปถึงจุดนั้น อย่างหนึ่งคือส่วนที่เปิดสู่สาธารณะและคาดเดาไม่ได้ ส่วนอีกอย่างคือส่วนที่เป็นส่วนตัวและมีความแม่นยำสูง การทำความเข้าใจทั้งสองอย่างไม่ใช่ทางเลือก แต่เป็นสิ่งจำเป็น การมีความเชี่ยวชาญในกลไกภายในของเบราว์เซอร์และตรรกะการ staging ของ Git คือสิ่งที่แยกนักพัฒนาที่ใช้การเดาออกจากนักพัฒนาที่รู้แน่ชัดว่าอะไรพังและพังเมื่อไหร่
โครงสร้างของ URL
ทุกการเข้าชมเว็บไซต์เริ่มต้นด้วยชุดตัวอักษรที่ดูเหมือนจะเรียบง่าย แต่กลับบรรจุคำสั่งที่แม่นยำไว้ URL อย่าง https://shop.example.com:443/products/id/42?sort=price#reviews แท้จริงแล้วคือการซ้อนกันของคำสั่งที่แยกจากกัน
protocol จะอยู่ด้านหน้าสุดและกำหนดกฎเกณฑ์ในการสื่อสาร เมื่อคุณเห็น https:// เบราว์เซอร์จะรู้ว่าต้องเข้ารหัสการเชื่อมต่อก่อนที่จะส่งข้อมูลใดๆ domain (shop.example.com) คือชื่อที่มนุษย์อ่านออกสำหรับที่อยู่เครือข่ายจริงของเซิร์ฟเวอร์ ซึ่งจะถูกแปลงผ่าน DNS เพื่อให้คอมพิวเตอร์ของคุณรู้ว่าจะต้องติดต่อที่ไหน port (:443) คือประตูเฉพาะบนเซิร์ฟเวอร์นั้น มักจะมองไม่เห็นเพราะเบราว์เซอร์จะสมมติว่าเป็น 443 สำหรับ HTTPS และ 80 สำหรับ HTTP แต่ในทางกลไกแล้วมันมีอยู่เสมอ path (/products/id/42) บอกเซิร์ฟเวอร์ว่าคุณต้องการทรัพยากรใด โดยจัดระเบียบเหมือนโฟลเดอร์ query string (?sort=price) ส่งข้อมูลแบบไดนามิกในรูปแบบคู่ key-value ซึ่งเหมาะสำหรับตัวกรอง คำค้นหา หรือการแบ่งหน้า (pagination) และสุดท้าย fragment (#reviews) จะชี้ไปยัง ID ขององค์ประกอบเฉพาะบนหน้าเว็บ ซึ่งจะไม่ถูกส่งไปยังเซิร์ฟเวอร์เลย แต่เบราว์เซอร์จะจัดการเองที่ฝั่ง client หลังจากที่หน้าเว็บมาถึงแล้ว
ควรวาง fragment ไว้ที่ส่วนท้ายเสมอ หากคุณย้ายมันไปไว้ก่อน query string ลิงก์จะเสีย เพราะทุกอย่างที่อยู่หลังเครื่องหมาย hash จะถูกปฏิบัติเหมือนเป็นบริบทฝั่ง client ไม่ใช่คำสั่งสำหรับเซิร์ฟเวอร์
DOM: ระบบประสาทที่มีชีวิตของหน้าเว็บคุณ
HTML ที่ส่งผ่านเครือข่ายมานั้นเป็นเพียงข้อความ เบราว์เซอร์จะอ่านข้อความนั้นและสร้าง Document Object Model ซึ่งเป็นแผนผังของวัตถุที่มีลักษณะเป็นต้นไม้ (tree-shaped map) ที่มีชีวิต เรียกว่า nodes แท็กของ element จะกลายเป็น element nodes ข้อความระหว่างแท็กจะกลายเป็น text nodes แม้แต่แอตทริบิวต์และคอมเมนต์ก็มีประเภทโหนดเป็นของตัวเอง ต้นไม้นี้ไม่ใช่แผนภาพที่หยุดนิ่ง แต่มันคือโครงสร้างข้อมูลที่มีชีวิตซึ่ง JavaScript สามารถอ่านและเขียนใหม่ได้ทันที
เมื่อสคริปต์ของคุณรัน document.getElementById หรือเปลี่ยน className คุณกำลังเข้าไปแก้ไขโครงสร้างต้นไม้นี้ เบราว์เซอร์จะสังเกตเห็นและทำการ repaint หน้าจอใหม่โดยไม่ต้องขอหน้าเว็บใหม่จากเซิร์ฟเวอร์ พลังนี้เองที่ทำให้เว็บแอปสมัยใหม่เป็นไปได้ แต่ก็ต้องแลกมาด้วยต้นทุน ทุกครั้งที่คุณแตะต้อง DOM เบราว์เซอร์อาจต้องคำนวณ layout และ styles ใหม่ หากคุณทำเช่นนั้นภายในลูปที่ทำงานหนักกับรายการนับร้อยรายการ เฟรมเรตของคุณจะตกลงอย่างมาก หากคุณต้องการแทรกรายการยาวๆ ให้สร้าง DocumentFragment ไว้ในหน่วยความจำก่อน แล้วค่อย append เข้าไปทีเดียว จงทำแบบ batch ทั้งการอ่านและการเขียน DOM นั้นมีความยืดหยุ่น แต่ก็ไม่ได้มาฟรีๆ
Browser Storage: สามเครื่องมือ สามหน้าที่
เบราว์เซอร์สมัยใหม่ช่วยให้คุณสามารถจัดเก็บข้อมูลไว้ในเครื่องของผู้ใช้ได้โดยตรง และการเลือกกลไกที่เหมาะสมนั้นสำคัญมาก เพราะแต่ละอย่างถูกสร้างขึ้นมาเพื่ออายุการใช้งานและความจุที่แตกต่างกัน
LocalStorage นั้นง่ายที่สุด มันจะบันทึกข้อมูลสตริงจำนวนเล็กน้อยไว้อย่างถาวรจนกว่าโค้ดของคุณหรือผู้ใช้จะลบมัน กรณีการใช้งานคลาสสิกคือการตั้งค่า dark-mode เมื่อมีคนสลับสวิตช์ ให้เขียน "theme": "dark" ลงใน LocalStorage ในการเข้าชมครั้งถัดไป ให้ดึงข้อมูลกลับมาและใช้คลาสนั้นก่อนการวาดหน้าจอครั้งแรก (first paint) มันทำงานแบบ synchronous และมีขอบเขตตาม origin ซึ่งทำให้ใช้งานง่าย แต่ก็หมายความว่าคุณไม่ควรเก็บ token ที่สำคัญไว้ในนั้น เพราะสคริปต์ใดๆ ที่รันบนหน้าเว็บของคุณสามารถอ่านมันได้
SessionStorage ใช้ API แบบ key-value เดียวกัน แต่ระยะเวลาการใช้งานจะผูกติดกับแท็บเบราว์เซอร์ มันจะยังคงอยู่แม้จะมีการรีเฟรชหน้าเว็บ ซึ่งทำให้เหมาะมากสำหรับการเก็บความคืบหน้าของฟอร์มชั่วคราว ลองจินตนาการว่าผู้ใช้กำลังกรอกแบบสำรวจยาวๆ แล้วเผลอกดรีโหลด แต่ยังคงเห็นคำตอบของพวกเขาอยู่เพราะคุณเก็บข้อมูลไว้ใน SessionStorage เมื่อพวกเขาปิดแท็บ ข้อมูลจะถูกล้างออกโดยอัตโนมัติ
Cache API ทำงานในสเกลที่แตกต่างออกไป มันจัดเก็บคู่ของ request และ response ซึ่งโดยปกติจะใช้โดย service workers เพื่อเก็บ static assets ขนาดใหญ่ เช่น รูปภาพ, ฟอนต์ และ script bundles แทนที่จะต้องดึงรูป hero image หรือ React bundle เดิมผ่านเครือข่ายทุกครั้งที่เข้าชม แอปของคุณสามารถดึงข้อมูลจาก disk cache ได้โดยตรง นี่คือวิธีที่เว็บไซต์ที่รองรับการทำงานแบบออฟไลน์สามารถโหลดได้อย่างรวดเร็วเมื่อกลับมาเข้าชมซ้ำ มันไม่ใช่ key-value store ทั่วไปเหมือนกับอีกสองตัวที่เหลือ แต่มันถูกสร้างขึ้นมาเพื่อ HTTP responses โดยเฉพาะ
กฎเหล็กข้อหนึ่งคือ: อย่าเก็บ authentication tokens หรือข้อมูลระบุตัวตนส่วนบุคคลไว้ใน LocalStorage โดยเด็ดขาด การโจมตีแบบ XSS สามารถกวาดข้อมูลเหล่านั้นไปได้ภายในเสี้ยววินาที ให้ใช้คุกกี้แบบ HttpOnly, Secure, SameSite สำหรับข้อมูลที่ละเอียดอ่อน และตรวจสอบพวกมันในแท็บ Application ซึ่งคุณสามารถยืนยันได้ว่ามีการตั้งค่า flags เหล่านั้นไว้จริง ๆ
Browser DevTools: เลิกเดา แล้วเริ่มอ่าน
แผง DevTools ไม่ได้มีไว้แค่เพื่อแก้ไขข้อผิดพลาดสีแดงใน console เท่านั้น แต่มันคือห้องแล็บวินิจฉัยสำหรับทุกสิ่งที่เกิดขึ้นภายในเบราว์เซอร์
ในแผง Elements คุณสามารถวางเมาส์เหนือ DOM tree และดูโหนดต่าง ๆ ไฮไลต์บนหน้าเว็บได้แบบเรียลไทม์ คุณสามารถแก้ไขค่า CSS ได้โดยตรงใน Styles pane เพื่อทดสอบ margin หรือสี ก่อนที่จะไปแตะต้องซอร์สโค้ดจริง ๆ ส่วน Console คือสมุดจดบันทึกของคุณ คุณสามารถ log วัตถุ (objects), ทดสอบ regex หรือเรียกใช้ฟังก์ชันต่าง ๆ กับสถานะปัจจุบันของหน้าเว็บได้ทันที หากตัวแปรทำงานไม่เป็นไปตามที่คิด ให้พิมพ์ชื่อของมันและตรวจสอบโดยตรง
แท็บ Network จะเผยความจริงเกี่ยวกับประสิทธิภาพ หน้าเว็บที่โหลดช้าอาจไม่ได้มาจาก JavaScript ของคุณ แต่อาจมาจากฟอนต์ของบุคคลที่สามที่ใช้เวลาตอบสนองถึงสี่วินาที หรือ API endpoint ที่ส่ง JSON payload ขนาดสองเมกะไบต์ที่คุณไม่ได้บีบอัดไว้ คุณสามารถติดตามวงจรชีวิตทั้งหมดของทุก request, กรองด้วย Fetch/XHR เพื่อดูการเรียก API ของคุณเอง และตรวจสอบ headers เพื่อดูว่ามีการปฏิบัติตามคำสั่ง caching หรือไม่ ในขณะเดียวกัน แท็บ Application จะช่วยให้คุณตรวจสอบการจัดเก็บข้อมูลของคุณได้ แอบดูคู่ key-value ใน LocalStorage, ตรวจสอบคุกกี้แต่ละตัวและ flags ของมัน และยืนยันว่า service worker ของคุณได้รับการลงทะเบียนและกำลังทำ caching ในสิ่งที่คุณคาดหวังไว้จริง ๆ
Git Workflow: ถังสามใบ
Git ไม่ใช่ซอฟต์แวร์สำรองข้อมูล แต่มันคือเครื่องมือสำหรับจัดการประวัติ (curating history) การคิดแบบนี้จะเปลี่ยนวิธีที่คุณใช้งานมัน Git จัดการโปรเจกต์ของคุณผ่านสามพื้นที่ที่แตกต่างกัน
working tree คือโต๊ะทำงานที่รก ๆ ของคุณ คุณแก้ไขไฟล์, ลบโฟลเดอร์ และทดลองสิ่งต่าง ๆ ที่นี่ แต่ยังไม่มีอะไรปลอดภัย staging area หรือ index คือที่ที่คุณเลือกอย่างเจาะจงว่าอะไรจะถูกนำไปใส่ใน snapshot ถัดไป การรัน git add กับไฟล์จะย้ายไฟล์นั้นจาก working tree เข้าสู่ staging ซึ่งช่วยให้คุณทำงานได้อย่างแม่นยำ คุณสามารถแก้ไขไฟล์สิบไฟล์ แต่เลือก stage เพียงสามไฟล์ และ commit snapshot ที่สะอาดและสมเหตุสมผลซึ่งอธิบายการเปลี่ยนแปลงเพียงอย่างเดียวได้ ส่วน local repository จะได้รับ snapshot เมื่อคุณรัน git commit ณ จุดนั้น Git จะบันทึกสถานะทั้งหมดของไฟล์ที่ถูก stage ไว้พร้อมกับข้อความของคุณ เพื่อสร้างจุดเช็คพอยต์ถาวรที่คุณสามารถย้อนกลับมาได้ในภายหลัง
ก่อนที่คุณจะ stage อะไรก็ตาม ให้รัน git status มันจะแสดงไฟล์ที่ไม่ได้ถูกติดตาม (untracked files) และไฟล์ที่ถูกแก้ไขที่คุณอาจลืมไปแล้ว ไฟล์ build ชั่วคราว, ไฟล์ log หรือไฟล์ environment อาจหลุดเข้าไปใน commit ได้หากคุณข้ามการตรวจสอบนี้ ไฟล์ .gitignore ที่ดีจะช่วยได้ แต่ git status คือการตรวจสอบขั้นสุดท้ายก่อนเริ่มงานจริง
การ staging ยังช่วยให้คุณแก้ไขข้อผิดพลาดก่อนที่จะกลายเป็นประวัติศาสตร์ หากคุณเพิ่มไฟล์เร็วเกินไป ให้ยกเลิกการ stage ด้วย git restore --staged หรือเขียน commit message ใหม่หากคุณเขียนไว้คลุมเครือเกินไป staging area มีไว้เพื่อให้ commit ของคุณเล่าเรื่องราวที่สอดคล้องกัน ไม่ใช่แค่การเทข้อมูลดิบจากการกดคีย์บอร์ดทุกครั้งที่คุณทำตั้งแต่ช่วงพักเที่ยง
สรุปภาพรวม
ทั้งสองโดเมนนี้ คือเบราว์เซอร์และ Git มีส่วนกำหนดแทบทุกชั่วโมงในกระบวนการทำงานของคุณ ในเบราว์เซอร์ คุณต้องเข้าใจว่า request ถูกจัดการอย่างไร, DOM ตอบสนองต่อสคริปต์ของคุณอย่างไร และข้อมูลถูกเก็บไว้ที่ไหนบนฝั่ง client การใช้ LocalStorage ผิดวัตถุประสงค์เพื่อเก็บความลับ หรือการรัวอัปเดต DOM แบบไม่รวมกลุ่ม (unbatched updates) จะทำให้แอปพลิเคชันเปราะบางและทำงานช้า ในเทอร์มินัล การปฏิบัติกับ Git เหมือนเป็นปุ่ม save จะสร้างประวัติที่ไม่มีใครอ่านออก รวมถึงตัวคุณเองในอนาคตด้วย จงใช้ staging area อย่างมีจุดมุ่งหมาย ตรวจสอบ status ของคุณ และเขียน commit ที่อธิบายว่า "ทำไม" ไม่ใช่แค่ "ทำอะไร"
นิสัยที่เชื่อมโยงทั้งสองโลกเข้าด้วยกันคือการตรวจสอบ ตรวจสอบ URL ก่อนที่จะโทษ API ทำการ profile DOM ก่อนที่จะเพิ่ม framework อ่านแท็บ Network ก่อนที่จะซื้อเซิร์ฟเวอร์ที่ใหญ่ขึ้น ตรวจสอบ git status ก่อนที่จะยืนยันข้อผิดพลาด เครื่องมือต่าง ๆ เปิดรออยู่บนหน้าจอของคุณแล้ว การเรียนรู้วิธีอ่านพวกมันอย่างตรงไปตรงมาคือหน้าที่ของคุณ