ประเด็นสำคัญ
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. พิจารณาความพร้อมเพรียงอย่างรอบคอบ
ความพร้อมเพรียงเป็นกลยุทธ์การแยกตัว มันช่วยให้เราสามารถแยกสิ่งที่ทำออกจากเวลาที่ทำ
เข้าใจความท้าทายของความพร้อมเพรียง การเขียนโปรแกรมพร้อม
สรุปรีวิว
Clean Code ได้รับการตอบรับที่ดีในด้านหลักการเขียนโค้ดที่อ่านง่ายและบำรุงรักษาได้ ผู้อ่านชื่นชมคำแนะนำที่เป็นประโยชน์เกี่ยวกับการตั้งชื่อ ฟังก์ชัน และการทดสอบ ข้อวิจารณ์ที่พบบ่อยคือการมุ่งเน้นที่ภาษา Java และแนวทางที่เข้มงวดเกินไป หลายคนมองว่าหนังสือเล่มนี้เป็นการอ่านที่จำเป็นสำหรับนักพัฒนา แม้ว่าบางคนจะพบว่ามันมีประโยชน์น้อยกว่าสำหรับโปรแกรมเมอร์ที่มีประสบการณ์ ตัวอย่างกรณีศึกษาและการปรับปรุงโค้ดได้รับการชื่นชมจากบางคน แต่ก็ถูกวิจารณ์จากคนอื่นว่าเกินจริง โดยรวมแล้ว ผู้วิจารณ์เห็นพ้องกันว่าหนังสือเล่มนี้นำเสนอข้อมูลเชิงลึกที่มีค่าเกี่ยวกับคุณภาพของโค้ด แม้ว่าคำแนะนำทั้งหมดจะไม่สามารถนำไปใช้ได้กับทุกคนก็ตาม
คนอื่นยังอ่าน
คำถามที่พบบ่อย
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.
