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

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

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

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

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

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

3. คัดลอกและวางแบบตาบอด

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

4.โยนวิธีแก้ปัญหาที่ผิด

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

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

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

6.คาดหวังจากหัวหน้าทีมมากเกินไป

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

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

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

7. กลัวการทบทวนโค้ด

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

8. แนวโน้มที่จะแก้ปัญหาอย่างลึกซึ้ง

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

9. การประดิษฐ์จักรยาน

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

10. อย่าเขียนแบบทดสอบ

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

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

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

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

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

12. การตั้งชื่อไม่ถูกต้อง

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