
บทที่ 1: รหัสสะอาด
-
จำนวนความยุ่งเหยิงโดยรวมเพิ่มขึ้นเมื่อเวลาผ่านไป
-
การกู้คืนระบบที่ล้าสมัยตั้งแต่เริ่มต้นเป็นเรื่องยากมาก การปรับโครงสร้างใหม่และการปรับปรุงส่วนเพิ่มจะเป็นตัวเลือกที่ดีที่สุดสำหรับสิ่งนี้
-
ในโค้ดเบสที่ยุ่งเหยิง งานที่ใช้เวลาเพียงไม่กี่ชั่วโมงอาจใช้เวลาหลายวันหรือหลายสัปดาห์จึงจะเสร็จสมบูรณ์
-
ใช้เวลาในการดำเนินการอย่างรวดเร็ว
-
Clean Code ทำหน้าที่ได้ดีอย่างหนึ่ง รหัสที่ไม่ดีพยายามทำมากเกินไป
-
รหัสสะอาดได้รับการทดสอบอย่างดี
-
เมื่ออ่านโค้ดที่เขียนอย่างดี แต่ละฟังก์ชันจะทำสิ่งที่คุณคาดหวังโดยประมาณ
-
หากคุณไม่เห็นด้วยกับหลักการที่สอนโดยผู้ที่มีประสบการณ์หลายปี อย่างน้อยคุณควรพิจารณามุมมองของพวกเขาก่อนที่จะเพิกเฉย
-
รหัสถูกอ่านบ่อยกว่าที่เขียนมาก
-
รหัสที่อ่านง่ายกว่าเปลี่ยนแปลงได้ง่ายกว่า
-
ทิ้ง codebase ไว้ดีกว่าตอนเจอ (Boy Scout Rule)
บทที่ 2: ความหมายของชื่อ
-
เลือกชื่อตัวแปรของคุณอย่างระมัดระวัง
-
การเลือกชื่อที่ดีเป็นเรื่องยาก
-
ชื่อของตัวแปรหรือฟังก์ชันควรบ่งชี้ว่ามันคืออะไรและใช้งานอย่างไร
-
หลีกเลี่ยงการใช้ชื่อตัวแปรที่มีอักขระตัวเดียว ยกเว้นชื่อที่ใช้โดยทั่วไป เช่น i สำหรับตัวแปรตัวนับในลูป
-
หลีกเลี่ยงการใช้คำย่อในชื่อตัวแปร
-
ชื่อตัวแปรควรออกเสียงได้เพื่อให้คุณสามารถพูดถึงและพูดออกมาดังๆ ได้
-
ใช้ชื่อตัวแปรที่ง่ายต่อการค้นหา
-
คลาสและวัตถุต้องมีชื่ออยู่ในรูปของคำนาม
-
ชื่อวิธีการและฟังก์ชันต้องเป็นคำกริยาหรือคู่คำกริยา-นาม
บทที่ 3: ฟังก์ชั่น
-
ฟังก์ชั่นควรมีขนาดเล็ก
-
ฟังก์ชันจะต้องดำเนินการอย่างใดอย่างหนึ่ง
-
ฟังก์ชันต้องมีชื่อที่สื่อความหมาย
-
แยกโค้ดในส่วนเนื้อหา if/else หรือเปลี่ยนคำสั่งให้เป็นฟังก์ชันที่มีชื่อชัดเจน
-
จำกัดจำนวนอาร์กิวเมนต์ที่ฟังก์ชันใช้
-
หากฟังก์ชันต้องการอาร์กิวเมนต์การกำหนดค่าจำนวนมาก ให้พิจารณารวมให้เป็นตัวแปรพารามิเตอร์การกำหนดค่าเดียว
-
ฟังก์ชันจะต้องบริสุทธิ์ ซึ่งหมายความว่าไม่มีผลข้างเคียง และไม่แก้ไขอาร์กิวเมนต์อินพุต
-
ฟังก์ชันจะต้องเป็นคำสั่งหรือแบบสอบถาม แต่ไม่ใช่ทั้งสองอย่างพร้อมกัน (Command Query Separation)
-
เป็นการดีกว่าที่จะลบข้อผิดพลาดและข้อยกเว้นออกจากโค้ดแทนที่จะทิ้งข้อผิดพลาดไว้ในโค้ด
-
แยกโค้ดที่ซ้ำกันออกเป็นฟังก์ชันที่มีชื่อชัดเจน (อย่าทำซ้ำตัวเอง)
-
การทดสอบหน่วยทำให้การปรับโครงสร้างใหม่ง่ายขึ้น
บทที่ 4: ความคิดเห็น
-
ความคิดเห็นอาจจะไม่ถูกต้อง อาจมีข้อผิดพลาดตั้งแต่แรก หรืออาจมีความถูกต้องตั้งแต่แรกแล้วจึงล้าสมัยเมื่อเวลาผ่านไปเมื่อโค้ดมีการเปลี่ยนแปลง
-
ใช้ความคิดเห็นเพื่ออธิบายว่าเหตุใดจึงเขียนเช่นนั้น แทนที่จะอธิบายว่ากำลังเกิดอะไรขึ้น
-
ความคิดเห็นมักจะสามารถหลีกเลี่ยงได้โดยใช้ตัวแปรที่มีชื่อชัดเจนและแยกส่วนของโค้ดออกเป็นฟังก์ชันที่มีชื่อชัดเจน
-
ใส่คำนำหน้าความคิดเห็น TODO ด้วยคำนำหน้าที่สอดคล้องกันเพื่อให้ค้นหาได้ง่ายขึ้น ตรวจสอบและล้างความคิดเห็น TODO ของคุณเป็นระยะ
-
อย่าใช้ Javadocs เพียงเพื่อประโยชน์ในการใช้งาน ความคิดเห็นที่อธิบายว่าเมธอดทำอะไร ต้องใช้ข้อโต้แย้งอะไรบ้าง และส่งคืนอะไรซ้ำซ้อนอย่างดีที่สุดและทำให้เข้าใจผิดอย่างเลวร้ายที่สุด
-
ความคิดเห็นควรมีข้อมูลและบริบทที่เกี่ยวข้องทั้งหมดที่ผู้อ่านต้องการ อย่าขี้เกียจเมื่อเขียนความคิดเห็น
-
ไม่จำเป็นต้องใช้ความคิดเห็นในบันทึกและความคิดเห็นของผู้เขียนไฟล์ เนื่องจากมีการควบคุมเวอร์ชันและคอมไพล์คอมไพล์
-
อย่าแสดงความคิดเห็นโค้ดที่ไม่ทำงาน เพียงแค่ลบมัน หากคุณคิดว่าคุณจะต้องใช้โค้ดในอนาคต นั่นคือสิ่งที่มีไว้สำหรับการควบคุมเวอร์ชัน
บทที่ 5: การจัดรูปแบบ
-
ในฐานะทีม ให้เลือกชุดกฎสำหรับการจัดรูปแบบโค้ดของคุณ จากนั้นใช้กฎเหล่านั้นอย่างสม่ำเสมอ ไม่ว่าคุณจะเห็นด้วยกับกฎเกณฑ์ใดก็ตาม คุณจะต้องทำข้อตกลง
-
ใช้การจัดรูปแบบโค้ดอัตโนมัติและตัววิเคราะห์โค้ด อย่าพึ่งพาผู้อื่นเพื่อค้นหาและแก้ไขข้อผิดพลาดในการจัดรูปแบบด้วยตนเอง สิ่งนี้ไม่มีประสิทธิภาพ ไม่เกิดผล และเสียเวลาในการตรวจสอบโค้ด
-
เพิ่มช่องว่างแนวตั้งระหว่างบรรทัดของโค้ดเพื่อแยกบล็อกโค้ดที่เกี่ยวข้องกันด้วยสายตา สิ่งที่คุณต้องมีคือสร้างบรรทัดใหม่ระหว่างกลุ่ม
-
ไฟล์ขนาดเล็กจะอ่าน ทำความเข้าใจ และย้ายได้ง่ายกว่าไฟล์ขนาดใหญ่
-
ควรประกาศตัวแปรใกล้กับตำแหน่งที่ใช้ สำหรับฟังก์ชันขนาดเล็ก โดยปกติจะอยู่ที่ด้านบนของฟังก์ชัน
-
แม้ว่าจะเป็นฟังก์ชันแบบสั้นหรือหากเป็นคำสั่งก็ตาม ก็ยังคงจัดรูปแบบให้ถูกต้องแทนที่จะเขียนไว้ในบรรทัดเดียว
บทที่ 6: วัตถุและโครงสร้างข้อมูล
-
รายละเอียดการใช้งานในออบเจ็กต์จะต้องซ่อนอยู่ด้านหลังอินเทอร์เฟซของออบเจ็กต์ ด้วยการจัดเตรียมอินเทอร์เฟซสำหรับการใช้งานโดยผู้บริโภคของอ็อบเจ็กต์ คุณสามารถทำให้รายละเอียดการใช้งานในภายหลังง่ายขึ้นโดยไม่ทำให้เกิดการเปลี่ยนแปลง นามธรรมทำให้การปรับโครงสร้างใหม่ง่ายขึ้น
-
โค้ดที่กำหนดใดๆ ไม่ควรมีความรู้เกี่ยวกับภายในของวัตถุที่โค้ดนั้นทำงานอยู่
-
เมื่อทำงานกับอ็อบเจ็กต์ คุณควรต้องการให้อ็อบเจ็กต์ดำเนินการคำสั่งหรือการสืบค้น แทนที่จะถามเกี่ยวกับระบบภายใน
บทที่ 7: การแก้ไขข้อผิดพลาด
-
การจัดการข้อผิดพลาดไม่ควรรบกวนโค้ดที่เหลือในโมดูล
-
เป็นการดีกว่าที่จะลบข้อผิดพลาดและข้อยกเว้นออกจากโค้ดแทนที่จะทิ้งข้อผิดพลาดไว้ในโค้ด
-
เขียนการทดสอบที่มีข้อผิดพลาดเพื่อให้แน่ใจว่าโค้ดของคุณระบุได้และไม่พลาด
-
ข้อความแสดงข้อผิดพลาดควรให้ข้อมูลพร้อมบริบทที่จำเป็นทั้งหมดที่บุคคลอาจจำเป็นต้องแก้ไขปัญหาอย่างมีประสิทธิภาพ
-
การรวม API ของบริษัทอื่นไว้ในชั้นนามธรรมแบบบางทำให้ง่ายต่อการแทนที่ไลบรารีหนึ่งด้วยอีกไลบรารีหนึ่งในอนาคต
-
การรวม API ของบริษัทอื่นไว้ในชั้นนามธรรมบางๆ ช่วยให้จำลองไลบรารีระหว่างการทดสอบได้ง่ายขึ้น
-
ใช้รูปแบบกรณีพิเศษหรือรูปแบบ Null Object เพื่อจัดการกับพฤติกรรมพิเศษ เช่น เมื่อไม่มีข้อมูลบางอย่าง
บทที่ 8: ขอบเขต
-
ห้องสมุดบุคคลที่สามช่วยเพิ่มความเร็วในการจัดส่งผลิตภัณฑ์โดยอนุญาตให้คุณจ้างบุคคลภายนอกเพื่องานต่างๆ
-
เขียนการทดสอบเพื่อให้แน่ใจว่าคุณใช้ไลบรารีบุคคลที่สามอย่างถูกต้อง
-
ใช้รูปแบบอะแดปเตอร์เพื่อเชื่อมช่องว่างระหว่าง API ของไลบรารีบุคคลที่สามและ API ที่คุณต้องการ
-
การรวม API ของบริษัทอื่นไว้ในชั้นนามธรรมแบบบางทำให้ง่ายต่อการแทนที่ไลบรารีหนึ่งด้วยอีกไลบรารีหนึ่งในอนาคต (ซ้ำจากบทที่ 7)
-
การรวม API ของบริษัทอื่นไว้ในชั้นนามธรรมบางๆ ช่วยให้จำลองไลบรารีระหว่างการทดสอบได้ง่ายขึ้น (ซ้ำจากบทที่ 7)
-
พยายามอย่าบอกข้อมูลแอปพลิเคชันของคุณเกี่ยวกับรายละเอียดของไลบรารีบุคคลที่สามมากเกินไป
-
เป็นการดีกว่าที่จะขึ้นอยู่กับสิ่งที่คุณควบคุมมากกว่าสิ่งที่คุณไม่ได้ควบคุม
บทที่ 9: การทดสอบหน่วย
-
รหัสทดสอบควรสะอาดพอๆ กับรหัสที่ใช้งานจริง (โดยมีข้อยกเว้นบางประการ ซึ่งมักเกี่ยวข้องกับหน่วยความจำหรือประสิทธิภาพ)
-
เมื่อรหัสการผลิตเปลี่ยนแปลง รหัสทดสอบก็เปลี่ยนเช่นกัน
-
การทดสอบช่วยให้โค้ดการผลิตของคุณมีความยืดหยุ่นและบำรุงรักษาได้
-
การทดสอบช่วยให้คุณทำการเปลี่ยนแปลงได้ ทำให้คุณสามารถปรับโครงสร้างใหม่ได้อย่างมั่นใจโดยไม่ต้องกลัวว่าจะไม่สังเกตเห็นด้วยตัวคุณเอง
-
จัดโครงสร้างการทดสอบของคุณโดยใช้รูปแบบ Arrange-Act-Assert (หรือที่เรียกว่า Build-Operate-Check, Setup-Exercise-Verify หรือ Give-When-Then)
-
ใช้ฟังก์ชันเฉพาะโดเมนเพื่อทำให้การทดสอบเขียนและอ่านได้ง่ายขึ้น
-
ให้คะแนนหนึ่งแนวคิดต่อการทดสอบ
-
การทดสอบจะต้องรวดเร็ว
-
การทดสอบจะต้องเป็นอิสระ
-
การทดสอบจะต้องทำซ้ำได้
-
การทดสอบไม่ควรต้องมีการยืนยัน
-
การทดสอบควรเขียนในเวลาที่เหมาะสม ก่อนหรือหลังการเขียนโค้ดการผลิตไม่นาน ไม่ใช่หลายเดือนหลังจากนั้น
-
หากการทดสอบของคุณไม่ดี คาดว่าจะมีข้อบกพร่องในโค้ดของคุณ
บทที่ 10: ชั้นเรียน
-
ชั้นเรียนควรมีขนาดเล็ก
-
ชั้นเรียนควรรับผิดชอบเพียงสิ่งเดียวและควรมีเหตุผลเดียวในการเปลี่ยนแปลง (หลักความรับผิดชอบเดียว)
-
หากคุณไม่สามารถตั้งชื่อชั้นเรียนให้ชัดเจนได้ ก็อาจจะใหญ่เกินไป
-
งานของคุณไม่สิ้นสุดเมื่อคุณได้รับโค้ดมาใช้งาน ขั้นตอนต่อไปคือการปรับโครงสร้างใหม่และล้างโค้ด
-
การใช้คลาสขนาดเล็กจำนวนมากแทนคลาสขนาดใหญ่หลายๆ คลาสในแอปพลิเคชันของคุณจะช่วยลดปริมาณข้อมูลที่นักพัฒนาต้องเข้าใจเมื่อทำงานใดๆ ที่กำหนด
-
การมีชุดการทดสอบที่ดีช่วยให้คุณจัดโครงสร้างใหม่ได้อย่างมั่นใจเมื่อคุณแยกคลาสใหญ่ออกเป็นคลาสย่อย
-
ชั้นเรียนควรเปิดเพื่อขยายเวลา แต่ปิดเพื่อแก้ไข (หลักการเปิด-ปิด)
-
อินเทอร์เฟซและคลาสนามธรรมสร้างรอยต่อที่ทำให้การทดสอบง่ายขึ้น
บทที่ 11: ระบบ
-
ใช้การขึ้นต่อกันเพื่อให้นักพัฒนามีความยืดหยุ่นในการส่งอ็อบเจ็กต์ใดๆ ด้วยอินเทอร์เฟซที่เหมาะสมไปยังคลาสอื่น
-
ใช้การฉีดขึ้นต่อกันเพื่อสร้างอินเทอร์เฟซระหว่างออบเจ็กต์ในแอปพลิเคชันของคุณเพื่อให้การทดสอบง่ายขึ้น
-
ระบบซอฟต์แวร์ไม่เหมือนอาคารที่ต้องออกแบบล่วงหน้า พวกเขาเป็นเหมือนเมืองที่เติบโตและขยายตัวเมื่อเวลาผ่านไป โดยปรับตัวให้เข้ากับความต้องการในปัจจุบัน
-
เลื่อนการตัดสินใจไปจนถึงช่วงเวลาวิกฤติสุดท้าย
-
ใช้ภาษาเฉพาะโดเมนเพื่อให้ผู้เชี่ยวชาญโดเมนและนักพัฒนาใช้คำศัพท์เดียวกัน
-
อย่าทำให้ระบบของคุณซับซ้อนเกินไป ใช้สิ่งที่ง่ายที่สุดที่ได้ผล
บทที่ 12: การปรับใช้
-
ระบบที่ไม่สามารถทดสอบได้ไม่สามารถตรวจสอบได้ และระบบที่ไม่สามารถตรวจสอบได้ไม่ควรนำไปใช้งาน
-
การทดสอบการเขียนนำไปสู่การออกแบบที่ดีขึ้น เนื่องจากโค้ดที่ทดสอบได้ง่ายมักจะใช้ dependency inserts อินเทอร์เฟซ และ abstraction
-
ชุดการทดสอบที่ดีจะขจัดความกลัวว่าแอปพลิเคชันของคุณเสียหายในขณะที่ปรับโครงสร้างใหม่
-
การทำซ้ำโค้ดทำให้เกิดความเสี่ยงมากขึ้น เนื่องจากมีตำแหน่งในโค้ดที่สามารถเปลี่ยนแปลงได้มากขึ้น และยังมีตำแหน่งที่สามารถซ่อนข้อผิดพลาดได้มากขึ้นอีกด้วย
-
โค้ดที่คุณเขียนตอนนี้เข้าใจง่ายกว่าเพราะคุณมีส่วนร่วมอย่างลึกซึ้งในการทำความเข้าใจ ไม่ใช่เรื่องง่ายสำหรับผู้อื่นที่จะบรรลุความเข้าใจในระดับเดียวกันอย่างรวดเร็ว
-
ต้นทุนส่วนใหญ่ของโครงการซอฟต์แวร์เกี่ยวข้องกับการบำรุงรักษาระยะยาว
-
การทดสอบทำหน้าที่เป็นเอกสารที่มีชีวิตว่าแอปพลิเคชันของคุณควร (และดำเนินการ) อย่างไร
-
อย่าย้ายอีกต่อไปเมื่อโค้ดของคุณใช้งานได้ ใช้เวลาเพื่อทำให้ชัดเจนและเข้าใจมากขึ้น
-
คนถัดไปที่จะอ่านโค้ดของคุณในอนาคตอันใกล้นี้น่าจะเป็นคุณมากที่สุด มีน้ำใจต่อตนเองในอนาคตด้วยการเขียนโค้ดที่เข้าใจง่าย
-
ต่อต้านความเชื่อ โอบกอดลัทธิปฏิบัตินิยม
-
กว่าจะเป็นวิศวกรซอฟต์แวร์ที่ดีจริงๆ ต้องใช้เวลาหลายทศวรรษ คุณสามารถเร่งการเรียนรู้ของคุณได้โดยการเรียนรู้จากผู้เชี่ยวชาญรอบตัวคุณ และเรียนรู้รูปแบบการออกแบบที่ใช้กันทั่วไป
บทที่ 13: ความเท่าเทียม
-
การเขียนโค้ดแบบขนานเป็นเรื่องยาก
-
จุดบกพร่องและปัญหาที่เกิดขึ้นเป็นครั้งคราวซึ่งยากต่อการทำซ้ำมักเป็นปัญหาที่เกิดขึ้นพร้อมๆ กัน
-
การทดสอบไม่ได้รับประกันว่าแอปพลิเคชันของคุณจะปราศจากข้อบกพร่อง แต่จะลดความเสี่ยงให้เหลือน้อยที่สุด
-
เรียนรู้เกี่ยวกับปัญหาการทำงานพร้อมกันทั่วไปและแนวทางแก้ไขที่เป็นไปได้
บทที่ 14: การปรับแต่งตามลำดับ
-
โค้ดที่สะอาดมักจะไม่ขึ้นต้นด้วยกระดานชนวนว่างเปล่า คุณต้องเขียนวิธีแก้ปัญหาคร่าวๆ ก่อน จากนั้นจึงปรับโครงสร้างใหม่เพื่อให้สะอาดขึ้น
-
เป็นความผิดพลาดที่จะหยุดทำงานกับโค้ดทันทีที่โค้ดเริ่มทำงานแล้ว ใช้เวลาเพื่อทำให้ดียิ่งขึ้นหลังจากที่มันได้ผลแล้ว
-
ความไม่สงบกำลังทวีความรุนแรงขึ้นเรื่อยๆ
-
หากคุณพบว่าตัวเองอยู่ในจุดที่การเพิ่มคุณสมบัติยากเกินไปหรือใช้เวลานานเกินไป ให้หยุดเขียนคุณสมบัติและเริ่มปรับโครงสร้างใหม่
-
การเปลี่ยนแปลงที่เพิ่มขึ้นมักจะดีกว่าการสร้างใหม่ตั้งแต่ต้น
-
ใช้ Test-Driven Development (TDD) เพื่อทำการเปลี่ยนแปลงเล็กๆ น้อยๆ จำนวนมาก
-
การออกแบบซอฟต์แวร์ที่ดีเกี่ยวข้องกับการแยกข้อกังวลในโค้ดของคุณ และการแยกโค้ดออกเป็นโมดูล คลาส และไฟล์ที่มีขนาดเล็กลง
-
การทำความสะอาดทันทีหลังจากที่คุณทำเสร็จแล้ว ง่ายกว่าการทำความสะอาดในภายหลัง
บทที่ 15: JUnit Internals
-
ชื่อตัวแปรเชิงลบหรือนิพจน์เงื่อนไขนั้นเข้าใจยากกว่าตัวแปรเชิงบวกเล็กน้อย
-
การรีแฟคเตอร์เป็นกระบวนการทำซ้ำที่เต็มไปด้วยการลองผิดลองถูก
-
ทิ้ง codebase ไว้ดีกว่าตอนเจอ (Boy Scout Rule) (ซ้ำจากบทที่ 1)
บทที่ 16: การรีแฟคเตอร์ SerialDate
-
การตรวจสอบโค้ดและการวิจารณ์โค้ดของเราทำให้เราดีขึ้น และเราควรยินดีด้วย
-
ขั้นแรกให้โค้ดใช้งานได้ จากนั้นจึงแก้ไข
-
ไม่ใช่ทุกบรรทัดของโค้ดที่จำเป็นต้องมีการทดสอบ
บทที่ 17: กลิ่นและการวิเคราะห์พฤติกรรม
-
Clean Code ไม่ใช่ชุดของกฎ แต่เป็นระบบค่านิยมที่กำหนดคุณภาพงานของคุณ
GO TO FULL VERSION