คอฟฟี่เบรค #43 ข้อผิดพลาดในการเขียนโปรแกรม 6 ข้อที่ทำให้คุณไม่สามารถได้งานในฝัน วิธีมีส่วนร่วมในซอฟต์แวร์โอเพ่นซอร์สเป็นครั้งแรก

ข้อผิดพลาดในการเขียนโปรแกรม 6 ข้อที่ทำให้คุณไม่สามารถได้งานในฝัน

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

ความคิดเห็นที่ล้าสมัย

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

การผสมผสานระหว่างไลบรารีและภาษาที่มีกรณีการใช้งานเดียวกัน

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

การทำซ้ำโค้ด

Don't Repeat Yourself (DRY) เป็นหลักการในการเขียนโปรแกรม การสร้างนามธรรมสำหรับโค้ดที่ซ้ำกันถือเป็นหัวใจสำคัญของการเขียนโปรแกรม ใช่ มันอาจเป็นเรื่องยากในตอนแรก เมื่อคุณต้องการแก้ไขปัญหา คุณต้องทำทุกวิถีทางที่เป็นไปได้ จากนั้นคุณก็ไปทำงานอื่นต่อและโค้ดที่ซ้ำกันก็จะอยู่กับคุณ คุณสามารถกำจัดนิสัยนี้ได้ด้วยการสร้างกฎเกณฑ์สำหรับตัวคุณเอง ทุกครั้งที่คุณปรับแต่งคุณสมบัติ ให้อ่านโค้ดอีกครั้งและดูว่ามีอะไรที่คุณสามารถทำได้เพื่อเปลี่ยนแปลงมันหรือไม่ โปรดจำไว้ว่าโค้ดเวอร์ชันแรกมักจะผิด และคุณสามารถปรับปรุงได้ เมื่อคุณสังเกตเห็นโค้ดที่ซ้ำกัน ให้ใช้เวลาศึกษามัน วิธีนี้จะทำให้คุณทราบวิธีที่ดีที่สุดในการเขียนใหม่ (เช่น การใช้การวนซ้ำหรือการสร้างฟังก์ชันใหม่) หากคุณทำความสะอาดทุกครั้ง คุณจะได้โค้ดที่เชื่อถือได้และสวยงามมากขึ้น

ข้อผิดพลาดที่ไม่สามารถจัดการได้

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

ขาดความสม่ำเสมอ

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

ความเข้าใจผิดเกี่ยวกับเครื่องมือ

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

วิธีมีส่วนร่วมในซอฟต์แวร์โอเพ่นซอร์สเป็นครั้งแรก

ที่มา: Jamestucker.dev เมื่อวันก่อนฉันเห็นทวีตจาก Evan Yu (ผู้สร้างVue.js ) เกี่ยวกับพื้นที่เก็บข้อมูลใหม่ที่เขากำลังดำเนินการอยู่ และทำให้ฉันสนใจ ฉันตัดสินใจว่าอยากจะมีส่วนร่วม! สิ่งที่จับได้ก็คือฉันไม่เคยมีส่วนร่วมในโครงการโอเพ่นซอร์สมาก่อนและไม่รู้ว่าจะเริ่มต้นจากตรงไหน แต่มันก็ไม่ได้ยากขนาดนั้นใช่ไหม? เมื่อฉันเข้าไปในที่เก็บฉันก็ตัวแข็งทันที “ฉันควรทำยังไงดี” ฉันคิดในใจ หากฉันทำการประชาสัมพันธ์ (คำขอดึง คำขอรวม) ผู้เชี่ยวชาญอาจจะฉีกโค้ดของฉันเป็นชิ้น ๆ ฉันจะเป็นที่รู้จักในโลกของการพัฒนาเสมอในฐานะคนที่ไม่รู้วิธีทำงานกับโอเพ่นซอร์สอย่างเหมาะสม และอาชีพของฉันก็จะจบลง โชคดีที่ฉันอ่านบทความ (ฉันจำไม่ได้ว่าอยู่ที่ไหน) ผู้เขียนแนะนำว่าการมีส่วนร่วมครั้งแรกของคุณในพื้นที่เก็บข้อมูลของคนอื่นควรระมัดระวังให้มากที่สุด นี่อาจเป็นเรื่องง่ายๆ เช่น การแก้ไขการพิมพ์ผิด และฉันก็ทำอย่างนั้น ฉันอ่านเอกสารของพื้นที่เก็บข้อมูล พบการพิมพ์ผิดเล็กน้อย เปิด PR และดูเถิด Evan อนุมัติการเปลี่ยนแปลงของฉัน ฉันเป็นผู้สนับสนุน Vue อย่างเป็นทางการ! บางทีฉันควรจะใส่สิ่งนี้ลงในประวัติ Twitter ของฉัน?

“ก็เยี่ยมมาก แต่ฉันจะเริ่มต้นยังไงล่ะ?”

เอาล่ะ มาเริ่มกันเลย ฉันจะแสดงขั้นตอนที่คุณสามารถทำได้เพื่อสร้างความแตกต่าง

1. ค้นหาโครงการ

หากต้องการแรงบันดาลใจ ลองนึกถึงเทคโนโลยีหรือเครื่องมือที่คุณชื่นชอบ สมมติว่าคุณทำงานกับ JavaScript และใช้Gatsby บ่อย ๆ ? ตรวจสอบพื้นที่เก็บข้อมูล ของพวกเขา ! คุณสามารถมีส่วนร่วมกับหนึ่งในที่เก็บของฉันได้ นี่คือรายการโปรเจ็กต์ส่วนหน้าของฉัน หากคุณมีสิ่งที่คุณรักหรือเห็นว่ามีประโยชน์ ฉันยินดีให้คุณเพิ่ม! สุดท้ายนี้Awesome First PR Opportunitiesคือแหล่งเก็บข้อมูลขนาดใหญ่ของโปรเจ็กต์โอเพ่นซอร์สสำหรับผู้เริ่มต้น มีโครงการใน 22 ภาษาที่แตกต่างกัน!

2. ตัดสินใจว่าคุณจะมีส่วนร่วมได้อย่างไร

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

3. การสร้างทางแยกของโครงการ

ทางแยก (ทางแยกของโครงการ) จะสร้างสำเนาที่แน่นอนของโครงการนั้นในพื้นที่เก็บข้อมูล Github ของคุณเอง

4. โคลนโครงการในเครื่อง

จากนั้นโคลนโปรเจ็กต์ไปยังโฟลเดอร์ในเครื่องโดยใช้ URL ของโปรเจ็กต์

git clone <project-url>

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

5. สร้างสาขาใหม่สำหรับการเปลี่ยนแปลงของคุณ

ถึงเวลาทำการเปลี่ยนแปลง/แก้ไขแล้ว! สร้างสาขาใหม่ที่การเปลี่ยนแปลงของคุณจะมีผล

git branch <branch-name>

คุณสามารถเรียกมันว่าอะไรก็ได้ที่คุณต้องการ แต่จากประสบการณ์ของฉัน คุณจะเห็นรูปแบบการตั้งชื่อสาขาในโครงการดั้งเดิม ในกรณีนี้ ฉันแนะนำให้ทำตามเทมเพลตที่มีอยู่ ชื่อสาขาที่ดีในการแก้ไขการพิมพ์ผิดคือpatch/typo- fix คุณสามารถสลับไปที่สาขานี้ได้โดยใช้git checkout <branch-name> ตอนนี้ทำการเปลี่ยนแปลงของคุณ!

6. เปิด PR (คำขอรวม)

คุณได้แก้ไขการพิมพ์ผิดที่เห็นได้ชัดหรืออัปเดตลิงก์ที่เสียหายแล้ว คุณภาคภูมิใจในงานของคุณ คุณอยากให้คนทั้งโลกรู้ว่าคุณเป็นหนึ่งในนักพัฒนาในตำนานที่สามารถเขียนโค้ด ลบ และรับชม Netflix ได้พร้อมๆ กัน พุชการเปลี่ยนแปลงของคุณไปยังที่เก็บ Github แบบแยกสาขาโดยใช้ git push -u origin <branch-name> ไปที่ที่เก็บ Github ที่แยกออกมาแล้วเปิด PR (คำขอดึง) หมายเหตุ: หากคุณไม่เคยทำการ Pull Request มาก่อน โปรดดูวิดีโอ นี้ โดย Kent Dodds เพื่อเรียนรู้วิธีดำเนินการ ตรวจสอบให้แน่ใจว่าสาขาของคุณชี้ไปที่สาขาหลักของแหล่งเก็บข้อมูลต้นทาง ตอนนี้คุณพร้อมที่จะเพิ่มรายละเอียดในการประชาสัมพันธ์ของคุณแล้ว ตรวจสอบให้แน่ใจว่าพาดหัวของคุณสื่อถึงเนื้อหาของ PR อย่างชัดเจน เพิ่มคำอธิบาย: หากคุณกำลังแก้ไขปัญหาที่มีอยู่ อย่าลืมใส่ลิงก์ไปยังปัญหานั้นด้วย เมื่อคุณอธิบายรายละเอียดเสร็จแล้ว ให้ส่ง PR ของคุณเพื่อรับการตรวจสอบ ใครก็ตามที่มีอำนาจในการอนุมัติ PR มักจะตรวจสอบใบสมัครของคุณภายในสองสามวัน และดำเนินการอย่างใดอย่างหนึ่งต่อไปนี้:

1. จะรวมการเปลี่ยนแปลงทันที
2. มันจะขอให้คุณทำการเปลี่ยนแปลง
3. จะปิด PR ของคุณ

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

คุณทำมัน!

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