เหตุใดการสร้างล้อใหม่จึงมีประโยชน์

วันก่อนฉันได้สัมภาษณ์นักพัฒนา JavaScript ที่กำลังรับสมัครตำแหน่งอาวุโส เพื่อนร่วมงานคนหนึ่งซึ่งเข้าร่วมการสัมภาษณ์ด้วย ขอให้ผู้สมัครเขียนฟังก์ชันที่จะสร้างคำขอ HTTP และหากไม่สำเร็จ ให้ลองใหม่หลายครั้ง

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

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

นักพัฒนาถือว่าโค้ดสำเร็จรูปมีความชัดเจนในตัวเอง

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

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

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

return new Promise((resolve, reject) => {
  functionWithCallback((err, result) => {
   return err ? reject(err) : resolve(result);
  });
});

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

กลับไปที่ราก

ในปี 2012 เมื่อความโดดเด่นของเฟรมเวิร์กเอนด์ยังไม่ได้รับการจัดตั้งขึ้น jQuery ได้ครองโลก และฉันก็อ่านหนังสือนี้ ความลับของ JavaScript Ninjaเขียนโดย John Resig ผู้สร้าง jQuery

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

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

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

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

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

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

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

สร้างวงล้อนี้ขึ้นมาใหม่

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

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

ที่มา: will.com