ข้อสำคัญ
1. เขียนโค้ดให้สะอาด อ่านง่าย และบำรุงรักษาได้
การวัดคุณภาพโค้ดที่ถูกต้องเพียงอย่างเดียว: WTFs/นาที
ความอ่านง่ายเป็นสิ่งสำคัญที่สุด โค้ดที่สะอาดควรเข้าใจได้ง่ายโดยนักพัฒนาคนอื่น ควรมีความเรียบง่าย สวยงาม และปราศจากความยุ่งเหยิง พยายามเขียนโค้ดที่แสดงเจตนาของมันอย่างชัดเจนโดยไม่ต้องใช้คอมเมนต์มากมาย ใช้ชื่อของตัวแปรและฟังก์ชันที่มีความหมาย รักษาฟังก์ชันให้เล็กและมุ่งเน้น และจัดระเบียบโค้ดให้มีลำดับที่ชัดเจน
การบำรุงรักษาช่วยให้เกิดการพัฒนา โค้ดที่ยากต่อการเปลี่ยนแปลงจะกลายเป็นภาระ ออกแบบโค้ดของคุณให้มีความยืดหยุ่นและโมดูลาร์เพื่อให้สามารถปรับตัวเข้ากับความต้องการที่เปลี่ยนแปลงได้ ปฏิบัติตามหลักการเช่น DRY (Don't Repeat Yourself) และ SOLID เพื่อสร้างระบบที่มีการเชื่อมโยงน้อยและมีความสอดคล้องสูง ปรับโครงสร้างโค้ดอย่างไม่ปราณีเพื่อปรับปรุงโครงสร้างโดยไม่เปลี่ยนพฤติกรรม
โค้ดที่สะอาดให้ผลตอบแทน แม้ว่าการเขียนโค้ดที่สะอาดจะใช้ความพยายามมากขึ้นในตอนแรก แต่จะช่วยประหยัดเวลาและลดความยุ่งยากในระยะยาว โค้ดที่สะอาดจะง่ายต่อการดีบัก ขยาย และบำรุงรักษา ช่วยให้นักพัฒนาทำงานได้อย่างมีประสิทธิภาพมากขึ้นและลดความเสี่ยงในการเกิดบั๊กระหว่างการเปลี่ยนแปลง ทำให้โค้ดที่สะอาดเป็นส่วนสำคัญในแนวทางการพัฒนาของคุณ
2. ปฏิบัติตามแนวทางการตั้งชื่อที่มีความหมาย
ชื่อของตัวแปร ฟังก์ชัน หรือคลาส ควรตอบคำถามใหญ่ ๆ ทั้งหมด มันควรบอกคุณว่าทำไมมันถึงมีอยู่ ทำอะไร และใช้อย่างไร
ใช้ชื่อที่เปิดเผยเจตนา เลือกชื่อที่สื่อถึงวัตถุประสงค์และพฤติกรรมของตัวแปร ฟังก์ชัน และคลาสอย่างชัดเจน หลีกเลี่ยงชื่อที่เป็นตัวอักษรเดียวหรือย่อที่เข้าใจยาก ใช้ชื่อที่ออกเสียงได้ง่ายและค้นหาได้สะดวก เช่น:
- ไม่ดี: d (เวลาที่ผ่านไปในวัน)
- ดี: elapsedTimeInDays
มีความสอดคล้องและแม่นยำ ใช้แนวทางการตั้งชื่อที่สอดคล้องกันทั่วทั้งโค้ดเบสของคุณ มีความแม่นยำเพื่อหลีกเลี่ยงความคลุมเครือ - เช่น ใช้ความแตกต่างที่มีความหมายเช่น getActiveAccounts() และ getActiveAccountInfo. หลีกเลี่ยงการเข้ารหัสหรือคำนำหน้าที่เพิ่มเสียงรบกวนโดยไม่มีค่า ชื่อคลาสควรเป็นคำนาม ชื่อเมธอดควรเป็นกริยา
ความยาวของชื่อควรตรงกับขอบเขต ใช้ชื่อที่ยาวขึ้นและมีรายละเอียดมากขึ้นสำหรับตัวแปรและฟังก์ชันที่มีขอบเขตใหญ่ ชื่อสั้น ๆ ยอมรับได้สำหรับขอบเขตเล็ก ๆ ในท้องถิ่น ความยาวของชื่อควรสอดคล้องกับขอบเขตการใช้งาน ปรับให้เหมาะสมกับความอ่านง่ายและความเข้าใจในบริบทที่ชื่อถูกใช้
3. รักษาฟังก์ชันให้เล็กและมุ่งเน้น
ฟังก์ชันควรทำเพียงสิ่งเดียว ควรทำได้ดี และควรทำเพียงอย่างเดียว
เล็กคือความสวยงาม ฟังก์ชันควรมีขนาดเล็ก - โดยทั่วไปยาว 5-10 บรรทัด ควรพอดีกับหน้าจอหนึ่งและเข้าใจได้ทันที แยกโค้ดออกเป็นฟังก์ชันช่วยที่มีชื่อที่ดีแทนการเขียนฟังก์ชันยาว ๆ ที่ซับซ้อน ฟังก์ชันเล็ก ๆ จะเข้าใจง่าย ทดสอบได้ และบำรุงรักษาได้ง่าย
ทำสิ่งเดียวให้ดี ฟังก์ชันแต่ละตัวควรมีวัตถุประสงค์ที่ชัดเจนเพียงอย่างเดียว หากฟังก์ชันทำหลายสิ่งหลายอย่าง ให้แยกสิ่งเหล่านั้นออกเป็นฟังก์ชันที่แยกต่างหาก สัญญาณที่ฟังก์ชันทำมากเกินไป ได้แก่:
- หลายระดับของนามธรรม
- หลายส่วนหรือบล็อกโค้ด
- พารามิเตอร์จำนวนมาก
รักษาระดับนามธรรมเดียว คำสั่งภายในฟังก์ชันควรอยู่ในระดับนามธรรมเดียวกัน อย่าผสมผสานตรรกะระดับสูงกับรายละเอียดระดับต่ำ แยกการดำเนินการระดับต่ำออกเป็นฟังก์ชันที่แยกต่างหาก สิ่งนี้ช่วยปรับปรุงความอ่านง่ายโดยการรักษาฟังก์ชันให้มุ่งเน้นและเรียบง่ายในเชิงแนวคิด
4. ฝึกฝนการจัดรูปแบบและการจัดระเบียบที่เหมาะสม
การจัดรูปแบบโค้ดเกี่ยวกับการสื่อสาร และการสื่อสารคือสิ่งสำคัญอันดับแรกของนักพัฒนามืออาชีพ
การจัดรูปแบบที่สอดคล้องกันมีความสำคัญ ใช้การเยื้อง บรรทัดใหม่ และช่องว่างที่สอดคล้องกันทั่วทั้งโค้ดของคุณ สิ่งนี้ช่วยปรับปรุงความอ่านง่ายและลดภาระทางปัญญา ตกลงเกี่ยวกับมาตรฐานการจัดรูปแบบกับทีมของคุณและใช้เครื่องมืออัตโนมัติเพื่อบังคับใช้ มาตรฐานการจัดรูปแบบที่สำคัญ ได้แก่:
- การเยื้องที่เหมาะสม
- การวางวงเล็บที่สอดคล้องกัน
- การแบ่งบรรทัดที่มีลำดับ
- ช่องว่างที่เหมาะสม
จัดระเบียบโค้ดให้มีลำดับ รวมกลุ่มโค้ดที่เกี่ยวข้องเข้าด้วยกันและแยกโค้ดที่ไม่เกี่ยวข้อง ใช้บรรทัดว่างเพื่อสร้างการแบ่ง "ย่อหน้า" ระหว่างส่วนที่มีลำดับ วางฟังก์ชันที่เกี่ยวข้องใกล้กัน รักษาไฟล์ให้มุ่งเน้นไปที่แนวคิดหรือส่วนประกอบเดียว แยกไฟล์ขนาดใหญ่เป็นไฟล์ที่เล็กลงและมุ่งเน้นมากขึ้นเมื่อเหมาะสม
ปฏิบัติตามแนวทางมาตรฐาน ปฏิบัติตามแนวทางมาตรฐานสำหรับภาษาของคุณและชุมชน สิ่งนี้ทำให้โค้ดของคุณคุ้นเคยและเข้าถึงได้ง่ายขึ้นสำหรับนักพัฒนาคนอื่น ๆ ตัวอย่างเช่น ใน Java:
- ชื่อคลาสใช้ PascalCase
- ชื่อเมธอดใช้ camelCase
- ค่าคงที่ใช้ ALL_CAPS
5. จัดการการพึ่งพาและหลีกเลี่ยงการทำซ้ำ
การทำซ้ำอาจเป็นรากของความชั่วร้ายทั้งหมดในซอฟต์แวร์
กำจัดการทำซ้ำ โค้ดที่ทำซ้ำเป็นโอกาสที่พลาดไปสำหรับการทำให้เป็นนามธรรม เมื่อคุณเห็นการทำซ้ำ ให้แยกโค้ดที่ใช้ร่วมกันออกเป็นฟังก์ชันหรือคลาสที่สามารถนำกลับมาใช้ใหม่ได้ สิ่งนี้ช่วยปรับปรุงการบำรุงรักษาโดยการรวมตรรกะและลดความเสี่ยงของการเปลี่ยนแปลงที่ไม่สอดคล้องกัน ประเภทของการทำซ้ำที่ควรระวัง ได้แก่:
- บล็อกโค้ดที่เหมือนกัน
- อัลกอริธึมที่คล้ายกันที่มีความแตกต่างเล็กน้อย
- การทำซ้ำของ switch/case หรือ if/else
จัดการการพึ่งพาอย่างระมัดระวัง ลดการพึ่งพาระหว่างโมดูลเพื่อลดการเชื่อมโยง ใช้การฉีดการพึ่งพาและการกลับด้านการควบคุมเพื่อทำให้โค้ดมีความโมดูลาร์และทดสอบได้ ปฏิบัติตามหลักการการกลับด้านการพึ่งพา - พึ่งพานามธรรม ไม่ใช่ความเป็นจริง สิ่งนี้ทำให้โค้ดของคุณมีความยืดหยุ่นมากขึ้นและง่ายต่อการเปลี่ยนแปลง
ใช้หลักการของความรู้ที่น้อยที่สุด โมดูลไม่ควรรู้เกี่ยวกับรายละเอียดภายในของวัตถุที่มันจัดการ สิ่งนี้ช่วยลดการเชื่อมโยงระหว่างโมดูล ตัวอย่างเช่น ใช้กฎของเดเมเตอร์ - เมธอดควรเรียกใช้เมธอดเฉพาะจาก:
- วัตถุของมันเอง
- วัตถุที่ส่งเป็นพารามิเตอร์
- วัตถุที่มันสร้างขึ้น
- วัตถุส่วนประกอบโดยตรงของมัน
6. จัดการข้อผิดพลาดอย่างมีสติ
การจัดการข้อผิดพลาดมีความสำคัญ แต่ถ้ามันทำให้ตรรกะไม่ชัดเจน มันก็ผิด
ใช้ข้อยกเว้นแทนรหัสข้อผิดพลาด ข้อยกเว้นนั้นสะอาดกว่าและไม่ทำให้ตรรกะหลักของโค้ดของคุณยุ่งเหยิง พวกมันช่วยให้การจัดการข้อผิดพลาดแยกออกจากเส้นทางที่ราบรื่น เมื่อใช้ข้อยกเว้น:
- สร้างข้อความข้อผิดพลาดที่มีข้อมูล
- ให้บริบทกับข้อยกเว้น
- กำหนดคลาสข้อยกเว้นตามความต้องการของผู้เรียก
อย่าคืนค่า null การคืนค่า null จะนำไปสู่ข้อผิดพลาดของตัวชี้ null และทำให้โค้ดยุ่งเหยิงด้วยการตรวจสอบ null แทนที่จะ:
- คืนค่าคอลเลกชันว่างแทน null สำหรับรายการ
- ใช้รูปแบบวัตถุ null
- ใช้ Optional ใน Java หรือ Maybe ในภาษาฟังก์ชัน
เขียน try-catch-finally ก่อน เริ่มต้นด้วย try-catch-finally เมื่อเขียนโค้ดที่อาจโยนข้อยกเว้น สิ่งนี้ช่วยกำหนดขอบเขตและความคาดหวังสำหรับโค้ดที่เรียก ใช้ให้แน่ใจว่าทรัพยากรถูกจัดการและปล่อยอย่างเหมาะสม แม้ในสถานการณ์ที่เกิดข้อผิดพลาด
7. เขียนการทดสอบหน่วยอย่างละเอียด
โค้ดการทดสอบมีความสำคัญเท่าเทียมกับโค้ดการผลิต
ปฏิบัติตามกฎสามข้อของ TDD การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD) ช่วยปรับปรุงคุณภาพและการออกแบบโค้ด:
- เขียนการทดสอบที่ล้มเหลวก่อนที่จะเขียนโค้ดการผลิตใด ๆ
- เขียนเพียงพอของการทดสอบเพื่อแสดงความล้มเหลว
- เขียนเพียงพอของโค้ดการผลิตเพื่อผ่านการทดสอบ
รักษาการทดสอบให้สะอาดและบำรุงรักษาได้ ใช้มาตรฐานคุณภาพโค้ดเดียวกันกับการทดสอบของคุณเช่นเดียวกับโค้ดการผลิต ปรับโครงสร้างและปรับปรุงโค้ดการทดสอบอย่างสม่ำเสมอ การทดสอบที่มีโครงสร้างดีจะทำหน้าที่เป็นเอกสารและช่วยให้สามารถปรับโครงสร้างโค้ดการผลิตได้อย่างกล้าหาญ
มุ่งหวังให้การครอบคลุมการทดสอบครอบคลุมอย่างทั่วถึง เขียนการทดสอบที่ครอบคลุมกรณีขอบ ข้อกำหนดขอบเขต และสถานการณ์ข้อผิดพลาด - ไม่ใช่แค่เส้นทางที่ราบรื่น ใช้เครื่องมือการครอบคลุมโค้ดเพื่อตรวจสอบช่องว่างในการครอบคลุมการทดสอบ จำไว้ว่าการครอบคลุม 100% ไม่รับประกันโค้ดที่ปราศจากบั๊ก แต่จะช่วยให้มั่นใจในการปรับโครงสร้างและการเปลี่ยนแปลง
8. ปรับโค้ดอย่างต่อเนื่อง
ทิ้งแคมป์ให้สะอาดกว่าที่คุณพบ
ปรับโครงสร้างอย่างมีโอกาส ปรับปรุงโครงสร้างโค้ดเมื่อใดก็ตามที่คุณทำงานกับโค้ดชิ้นหนึ่ง ปฏิบัติตามกฎของลูกเสือ: ทิ้งโค้ดให้ดีกว่าที่คุณพบ มันเป็นการปรับปรุงเล็ก ๆ น้อย ๆ ที่สะสมกันไปตามเวลาและป้องกันไม่ให้โค้ดเสื่อมสภาพ เทคนิคการปรับโครงสร้างทั่วไป ได้แก่:
- การแยกวิธีหรือคลาส
- การเปลี่ยนชื่อเพื่อความชัดเจน
- การทำให้เงื่อนไขที่ซับซ้อนง่ายขึ้น
- การกำจัดการทำซ้ำ
ปรับโครงสร้างอย่างปลอดภัยด้วยการทดสอบ ควรมีชุดการทดสอบที่มั่นคงก่อนการปรับโครงสร้าง ทำการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ และรันการทดสอบบ่อย ๆ สิ่งนี้จะช่วยให้คุณมั่นใจได้ว่าการเปลี่ยนแปลงของคุณจะไม่ทำให้ฟังก์ชันการทำงานที่มีอยู่เสียหาย ใช้เครื่องมือการปรับโครงสร้างอัตโนมัติเมื่อมีให้เพื่อลดความเสี่ยงในการเกิดข้อผิดพลาด
สร้างสมดุลระหว่างการปรับโครงสร้างกับการส่งมอบคุณค่า แม้ว่าการปรับโครงสร้างอย่างต่อเนื่องจะมีความสำคัญ แต่ก็อย่าให้มันทำให้ความก้าวหน้าหยุดชะงัก มุ่งหวังไปที่ "ดีพอ" แทนที่จะเป็นความสมบูรณ์แบบ มุ่งเน้นการปรับโครงสร้างไปที่พื้นที่ที่มีปัญหามากที่สุดหรือมีการเปลี่ยนแปลงบ่อยที่สุด สื่อสารคุณค่าของการปรับโครงสร้างให้กับผู้มีส่วนได้ส่วนเสียเพื่อให้แน่ใจว่ามีการสนับสนุนในการปรับปรุงโค้ดอย่างต่อเนื่อง
9. ใช้หลักการการเขียนโปรแกรมเชิงวัตถุและฟังก์ชันอย่างชาญฉลาด
วัตถุซ่อนข้อมูลของตนไว้เบื้องหลังนามธรรมและเปิดเผยฟังก์ชันที่ทำงานกับข้อมูลนั้น โครงสร้างข้อมูลเปิดเผยข้อมูลของตนและไม่มีฟังก์ชันที่มีความหมาย
ใช้หลักการเชิงวัตถุอย่างชาญฉลาด ใช้หลักการเช่นการห่อหุ้ม การสืบทอด และพหุรูปเพื่อสร้างการออกแบบที่ยืดหยุ่นและโมดูลาร์ ปฏิบัติตามหลักการ SOLID:
- หลักการความรับผิดชอบเดียว
- หลักการเปิด-ปิด
- หลักการการแทนที่ของลิสคอฟ
- หลักการการแยกส่วนของอินเทอร์เฟซ
- หลักการการกลับด้านการพึ่งพา
ใช้แนวคิดการเขียนโปรแกรมเชิงฟังก์ชัน แม้ในภาษาที่เน้นวัตถุ เทคนิคการเขียนโปรแกรมเชิงฟังก์ชันสามารถนำไปสู่โค้ดที่สะอาดกว่า:
- ฟังก์ชันที่บริสุทธิ์โดยไม่มีผลข้างเคียง
- ข้อมูลที่ไม่เปลี่ยนแปลง
- ฟังก์ชันระดับสูง
- การรวมฟังก์ชัน
เลือกวิธีการที่เหมาะสมกับปัญหา พาราไดม์เชิงวัตถุและฟังก์ชันแต่ละแบบมีจุดแข็งและจุดอ่อน ใช้การออกแบบเชิงวัตถุเมื่อคุณต้องการจำลองโดเมนที่ซับซ้อนด้วยพฤติกรรม ใช้แนวทางเชิงฟังก์ชันสำหรับการแปลงข้อมูลและกระบวนการประมวลผล หลายภาษาสมัยใหม่สนับสนุนแนวทางแบบผสมผสาน ทำให้คุณสามารถใช้เครื่องมือที่ดีที่สุดสำหรับแต่ละส่วนของระบบของคุณ
10. พิจารณาความพร้อมเพรียงอย่างรอบคอบ
ความพร้อมเพรียงเป็นกลยุทธ์การแยกตัว มันช่วยให้เราสามารถแยกสิ่งที่ทำออกจากเวลาที่ทำ
เข้าใจความท้าทายของความพร้อมเพรียง การเขียนโปรแกรมพร้อม
อัปเดตล่าสุด:
FAQ
What's "Clean Code: A Handbook of Agile Software Craftsmanship" about?
- Focus on Clean Code: "Clean Code" by Robert C. Martin emphasizes writing code that is easy to read, understand, and maintain.
- Professionalism in Coding: It argues that clean code is a hallmark of professionalism in software development.
- Practical Advice: The book provides guidelines, examples, and case studies to help developers write clean and efficient code.
Why should I read "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Improve Coding Skills: It teaches how to write code that is clean, efficient, and maintainable.
- Learn from Experts: Part of the Robert C. Martin series, known for its technical and pragmatic approach.
- Long-term Benefits: Writing clean code reduces maintenance costs and makes you a more valuable developer.
What are the key takeaways of "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Code Readability: Emphasizes that code should be easy to read and understand.
- Single Responsibility Principle: Advocates for each class or function to have one reason to change.
- Continuous Improvement: Encourages developers to continuously improve their code, following the Boy Scout Rule.
How does "Clean Code: A Handbook of Agile Software Craftsmanship" define clean code?
- Elegance and Efficiency: Clean code is described as elegant and efficient, with minimal dependencies.
- Readable and Maintainable: It should read like well-written prose, making the designer's intent clear.
- Focused and Single-minded: Each function, class, and module should have a single, clear purpose.
What is the Single Responsibility Principle in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- One Reason to Change: A class or module should have one, and only one, reason to change.
- Improves Cohesion: Ensures that classes are cohesive, with closely related methods and variables.
- Facilitates Maintenance: Makes the code easier to maintain and extend, reducing the impact of changes.
What is the "Boy Scout Rule" mentioned in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Continuous Improvement: Suggests leaving the codebase cleaner than you found it.
- Small, Incremental Changes: Encourages making small improvements, like renaming variables or breaking up functions.
- Professional Responsibility: Presented as a professional responsibility to ensure maintainability.
How does "Clean Code: A Handbook of Agile Software Craftsmanship" approach Test-Driven Development (TDD)?
- Fundamental Discipline: TDD is crucial for writing clean, reliable code.
- Three Laws of TDD: Write a failing test first, write code to pass the test, then refactor.
- Benefits: Helps catch bugs early and improves code design.
What are "code smells" according to "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Definition: Indicators of potential problems that hinder readability or maintainability.
- Examples: Long methods, large classes, and duplicated code.
- Addressing Smells: Provides heuristics and refactoring techniques to improve code quality.
How does "Clean Code: A Handbook of Agile Software Craftsmanship" suggest handling exceptions?
- Prefer Exceptions: Use exceptions instead of error codes for better context and management.
- Provide Context: Include meaningful messages and context when throwing exceptions.
- Avoid Checked Exceptions: Suggests using unchecked exceptions for cleaner code.
What role do unit tests play in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Ensure Code Quality: Unit tests ensure code works as intended and remains maintainable.
- Test-Driven Development: Advocates writing tests before production code.
- Clean and Readable Tests: Tests should be as clean and readable as production code.
What is the role of refactoring in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Continuous Improvement: Refactoring improves code structure and readability without changing functionality.
- Techniques: Provides techniques like Extract Method and Rename Variable to enhance code quality.
- Fearless Refactoring: With comprehensive tests, developers can refactor confidently.
What are the best quotes from "Clean Code: A Handbook of Agile Software Craftsmanship" and what do they mean?
- "Clean code does one thing well." Emphasizes focus and clarity in code.
- "Leave the campground cleaner than you found it." Encourages continuous improvement of the codebase.
- "You know you are working on clean code when each routine you read turns out to be pretty much what you expected." Highlights the importance of readability and predictability.
รีวิว
Clean Code ได้รับการตอบรับที่ดีในด้านหลักการเขียนโค้ดที่อ่านง่ายและบำรุงรักษาได้ ผู้อ่านชื่นชมคำแนะนำที่เป็นประโยชน์เกี่ยวกับการตั้งชื่อ ฟังก์ชัน และการทดสอบ ข้อวิจารณ์ที่พบบ่อยคือการมุ่งเน้นที่ภาษา Java และแนวทางที่เข้มงวดเกินไป หลายคนมองว่าหนังสือเล่มนี้เป็นการอ่านที่จำเป็นสำหรับนักพัฒนา แม้ว่าบางคนจะพบว่ามันมีประโยชน์น้อยกว่าสำหรับโปรแกรมเมอร์ที่มีประสบการณ์ ตัวอย่างกรณีศึกษาและการปรับปรุงโค้ดได้รับการชื่นชมจากบางคน แต่ก็ถูกวิจารณ์จากคนอื่นว่าเกินจริง โดยรวมแล้ว ผู้วิจารณ์เห็นพ้องกันว่าหนังสือเล่มนี้นำเสนอข้อมูลเชิงลึกที่มีค่าเกี่ยวกับคุณภาพของโค้ด แม้ว่าคำแนะนำทั้งหมดจะไม่สามารถนำไปใช้ได้กับทุกคนก็ตาม
Similar Books
