การวิเคราะห์ข้อผิดพลาดทั่วไปที่เกิดขึ้นโดยโปรแกรมเมอร์มือใหม่ pt. 1

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

1. กลัวการขอความช่วยเหลือจากเพื่อนร่วมงานที่มีประสบการณ์มากกว่า

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

2. ไม่พยายามค้นหาข้อมูลด้วยตนเอง

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

3. สุ่มสี่สุ่มห้าคัดลอกและวาง

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

4. ติดกับวิธีแก้ปัญหาที่ไม่ถูกต้อง

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

5. กลัวการถามคำถามเกี่ยวกับงานปัจจุบันของคุณ

การทำงานในโครงการพัฒนาซอฟต์แวร์มักจะทำงานเฉพาะด้าน ตัวอย่างเช่นในจิระ. งานเหล่านี้ไม่ได้ระบุไว้อย่างชัดเจนและละเอียดเสมอไป คำอธิบายงานมักเขียนโดยหัวหน้าทีมซึ่งเป็นเพียงปุถุชน พวกเขาอาจลืมที่จะเพิ่มบางอย่างหรือไม่ได้คำนึงถึงความจริงที่ว่าคุณไม่คุ้นเคยกับฟังก์ชันนี้หรือฟังก์ชันนั้น หรือบางทีคุณอาจไม่มีสิทธิ์เข้าถึงโครงการ (เช่น เข้าถึงฐานข้อมูล เซิร์ฟเวอร์บันทึก และอื่นๆ) และตอนนี้ คุณได้รับงาน ศึกษามันนานกว่าสองสามชั่วโมง แต่คุณยังคงนั่งอยู่ที่นั่น จ้องมองที่หน้าจอด้วยความงุนงง แทนที่จะพยายามทำความเข้าใจสิ่งนี้ต่อไปโดยไม่ประสบความสำเร็จ คุณควรเริ่มขอคำชี้แจงหรือคำแนะนำจากใครก็ตามที่สร้างงาน ตัวอย่างเช่น ในแอปที่ทีมของคุณใช้ในการสื่อสาร (เช่น Microsoft Teams) คุณอาจถามคำถามหรือแสดงความคิดเห็นโดยตรงเกี่ยวกับงาน ในแง่หนึ่ง หากคุณเขียนคำถามของคุณในข้อความส่วนตัว คุณอาจจะได้คำตอบเร็วขึ้น เนื่องจากบุคคลนั้นจะเห็นคำถามของคุณทันที ในทางกลับกัน การถามคำถามใน Jira เป็นการพิสูจน์ว่าคุณกำลังทำอะไรบางอย่าง นั่นคือการวิเคราะห์ปัญหา มีวิธีเร่งกระบวนการนี้: ถามคำถามของคุณในความคิดเห็นใน Jira จากนั้นใน DM วางลิงก์ไปยังความคิดเห็นของคุณแล้วขอให้ลองดู

6. วางความคาดหวังสูงเกินจริงกับหัวหน้าทีม

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

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

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

7. กลัวการตรวจสอบโค้ด

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

8. แนวโน้มในการตัดสินใจที่ลึกลับ

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

9. คิดค้นล้อใหม่

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

10. ความล้มเหลวในการเขียนการทดสอบ

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

11. แสดงความคิดเห็นมากเกินไป

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

Cat cat = new Cat(); // Cat object

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

12. การตั้งชื่อที่ไม่ดี

มือใหม่กำลังเล่นอย่างรวดเร็วและหลวมตัวในการตั้งชื่อคลาส ตัวแปร เมธอด ฯลฯ ตัวอย่างเช่น โดยการสร้างคลาสที่ชื่อไม่ได้อธิบายถึงจุดประสงค์ของมันเลย หรือประกาศตัวแปรด้วยชื่อสั้นๆเช่น x พวกเขาเมื่อมีตัวแปรอีกสองตัวชื่อnและyถูกสร้างขึ้น การจดจำสิ่งที่ x รับผิดชอบกลายเป็นเรื่องยากมาก เมื่อเผชิญกับสถานการณ์นี้ คุณต้องคิดอย่างรอบคอบเกี่ยวกับโค้ด วิเคราะห์โค้ดด้วยกล้องจุลทรรศน์ (อาจใช้ดีบักเกอร์) ศึกษาฟังก์ชันการทำงานเพื่อให้เข้าใจสิ่งที่เกิดขึ้นได้ง่าย นี่คือที่ที่หลักการตั้งชื่อที่ถูกต้องที่ฉันกล่าวถึงข้างต้นมาช่วยเรา ชื่อที่ถูกต้องช่วยเพิ่มความสามารถในการอ่านโค้ด ซึ่งช่วยลดเวลาที่ต้องใช้ในการทำความคุ้นเคยกับโค้ด เนื่องจากการใช้วิธีจะง่ายกว่ามากเมื่อชื่ออธิบายถึงฟังก์ชันการทำงานโดยประมาณ ทุกอย่างในโค้ดประกอบด้วยชื่อ (ตัวแปร เมธอด คลาส ออบเจกต์ ไฟล์ ฯลฯ) ดังนั้นจุดนี้จึงมีความสำคัญมากเมื่อสร้างโค้ดที่ถูกต้องและสะอาด คุณควรจำไว้ว่าชื่อนั้นควรสื่อความหมาย เช่น ทำไมตัวแปรถึงมีอยู่ มันทำอะไร และวิธีการใช้งาน ฉันจะสังเกตมากกว่าหนึ่งครั้งว่าความคิดเห็นที่ดีที่สุดสำหรับตัวแปรคือการตั้งชื่อที่ดี สำหรับการศึกษาความคิดเห็นในเชิงลึกและการตั้งชื่อที่ถูกต้อง ฉันขอแนะนำให้อ่านคลาสสิกอมตะ:"รหัสสะอาด: คู่มือของงานฝีมือซอฟต์แวร์ Agile" โดย Robert Martin ในบันทึกนั้น ส่วนแรกของบทความนี้ (การไตร่ตรองของฉัน) ได้สิ้นสุดลงแล้ว ยังมีต่อ...