คอฟฟี่เบรค #103. เพื่อปกป้อง "Clean Code": 100 เคล็ดลับเหนือกาลเวลา

ที่มา: Hackernoon “Clean Code” โดย Robert C. Martin เป็นหนังสือการเขียนโปรแกรมที่ได้รับการแนะนำมากที่สุดตลอดกาล ค้นหาหนังสือโดยใช้ข้อความค้นหา "หนังสือที่ดีที่สุดสำหรับนักพัฒนาซอฟต์แวร์" และคุณเกือบจะรับประกันว่าจะพบหนังสือเล่มนี้ในผลการค้นหา และในขณะที่บางคนรู้สึกว่า Clean Code ไม่ควรค่าแก่การใส่ใจ แต่ฉันขอแย้งว่าความรู้สึกดังกล่าวเป็นความผิดพลาดอย่างร้ายแรง ใช่ คำแนะนำบางอย่างในหนังสือเล่มนี้ยังเป็นที่น่าสงสัย ใช่ เนื้อหาบางส่วนดูเหมือนล้าสมัย ใช่ ตัวอย่างบางส่วนทำให้เกิดความสับสน มันเป็นความจริงทั้งหมด แต่อย่าเพิ่งด่วนสรุปเคล็ดลับที่เป็นประโยชน์มากมายที่หนังสือเล่มนี้นำเสนอ! การเพิกเฉยต่อ Clean Code โดยสิ้นเชิงเพียงเพราะความคิดที่ไม่ดีบางประการไม่ใช่วิธีแก้ปัญหาที่ดีที่สุด ดังนั้น เพื่อเป็นการไม่ให้เสียเวลา เรามาดูเคล็ดลับที่ดีที่สุดที่ Clean Code มอบให้กันดีกว่า! เราจะอธิบายแต่ละบทโดยสรุปแนวคิดที่ลุงบ๊อบและผู้เขียนร่วมนำเสนอ

บทที่ 1: รหัสสะอาด

1. จำนวนความยุ่งเหยิงโดยรวมเพิ่มขึ้นเมื่อเวลาผ่านไป

2. การกู้คืนระบบที่ล้าสมัยตั้งแต่เริ่มต้นเป็นเรื่องยากมาก การปรับโครงสร้างใหม่และการปรับปรุงส่วนเพิ่มจะเป็นตัวเลือกที่ดีที่สุดสำหรับสิ่งนี้

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

4. ใช้เวลาในการดำเนินการอย่างรวดเร็ว

5. Clean Code ทำหน้าที่ได้ดีอย่างหนึ่ง รหัสที่ไม่ดีพยายามทำมากเกินไป

6. รหัสสะอาดได้รับการทดสอบอย่างดี

7. เมื่ออ่านโค้ดที่เขียนอย่างดี แต่ละฟังก์ชันจะทำสิ่งที่คุณคาดหวังโดยประมาณ

8. หากคุณไม่เห็นด้วยกับหลักการที่สอนโดยผู้ที่มีประสบการณ์หลายปี อย่างน้อยคุณควรพิจารณามุมมองของพวกเขาก่อนที่จะเพิกเฉย

9. รหัสถูกอ่านบ่อยกว่าที่เขียนมาก

10. รหัสที่อ่านง่ายกว่าเปลี่ยนแปลงได้ง่ายกว่า

11. ทิ้ง codebase ไว้ดีกว่าตอนเจอ (Boy Scout Rule)

บทที่ 2: ความหมายของชื่อ

1. เลือกชื่อตัวแปรของคุณอย่างระมัดระวัง

2. การเลือกชื่อที่ดีเป็นเรื่องยาก

3. ชื่อของตัวแปรหรือฟังก์ชันควรบ่งชี้ว่ามันคืออะไรและใช้งานอย่างไร

4. หลีกเลี่ยงการใช้ชื่อตัวแปรที่มีอักขระตัวเดียว ยกเว้นชื่อที่ใช้โดยทั่วไป เช่น i สำหรับตัวแปรตัวนับในลูป

5. หลีกเลี่ยงการใช้คำย่อในชื่อตัวแปร

6. ชื่อตัวแปรควรออกเสียงได้เพื่อให้คุณสามารถพูดถึงและพูดออกมาดังๆ ได้

7. ใช้ชื่อตัวแปรที่ง่ายต่อการค้นหา

8. คลาสและวัตถุต้องมีชื่ออยู่ในรูปของคำนาม

9. ชื่อวิธีการและฟังก์ชันต้องเป็นคำกริยาหรือคู่คำกริยา-นาม

บทที่ 3: ฟังก์ชั่น

1. ฟังก์ชั่นควรมีขนาดเล็ก

2. ฟังก์ชันจะต้องดำเนินการอย่างใดอย่างหนึ่ง

3. ฟังก์ชันต้องมีชื่อที่สื่อความหมาย

4. แยกโค้ดในส่วนเนื้อหา if/else หรือเปลี่ยนคำสั่งให้เป็นฟังก์ชันที่มีชื่อชัดเจน

5. จำกัดจำนวนอาร์กิวเมนต์ที่ฟังก์ชันใช้

6. หากฟังก์ชันต้องการอาร์กิวเมนต์การกำหนดค่าจำนวนมาก ให้พิจารณารวมให้เป็นตัวแปรพารามิเตอร์การกำหนดค่าเดียว

7. ฟังก์ชันจะต้องบริสุทธิ์ ซึ่งหมายความว่าไม่มีผลข้างเคียง และไม่แก้ไขอาร์กิวเมนต์อินพุต

8. ฟังก์ชันจะต้องเป็นคำสั่งหรือแบบสอบถาม แต่ไม่ใช่ทั้งสองอย่างพร้อมกัน (Command Query Separation)

9. เป็นการดีกว่าที่จะลบข้อผิดพลาดและข้อยกเว้นออกจากโค้ดแทนที่จะทิ้งข้อผิดพลาดไว้ในโค้ด

10. แยกโค้ดที่ซ้ำกันออกเป็นฟังก์ชันที่มีชื่อชัดเจน (อย่าทำซ้ำตัวเอง)

11. การทดสอบหน่วยทำให้การปรับโครงสร้างใหม่ง่ายขึ้น

บทที่ 4: ความคิดเห็น

1. ความคิดเห็นอาจจะไม่ถูกต้อง อาจมีข้อผิดพลาดตั้งแต่แรก หรืออาจมีความถูกต้องตั้งแต่แรกแล้วจึงล้าสมัยเมื่อเวลาผ่านไปเมื่อโค้ดมีการเปลี่ยนแปลง

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

3. ความคิดเห็นมักจะสามารถหลีกเลี่ยงได้โดยใช้ตัวแปรที่มีชื่อชัดเจนและแยกส่วนของโค้ดออกเป็นฟังก์ชันที่มีชื่อชัดเจน

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

5. อย่าใช้ Javadocs เพียงเพื่อประโยชน์ในการใช้งาน ความคิดเห็นที่อธิบายว่าเมธอดทำอะไร ต้องใช้ข้อโต้แย้งอะไรบ้าง และส่งคืนอะไรซ้ำซ้อนอย่างดีที่สุดและทำให้เข้าใจผิดอย่างเลวร้ายที่สุด

6. ความคิดเห็นควรมีข้อมูลและบริบทที่เกี่ยวข้องทั้งหมดที่ผู้อ่านต้องการ อย่าขี้เกียจเมื่อเขียนความคิดเห็น

7. ไม่จำเป็นต้องใช้ความคิดเห็นในบันทึกและความคิดเห็นของผู้เขียนไฟล์ เนื่องจากมีการควบคุมเวอร์ชันและคอมไพล์คอมไพล์

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

บทที่ 5: การจัดรูปแบบ

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

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

3. เพิ่มช่องว่างแนวตั้งระหว่างบรรทัดของโค้ดเพื่อแยกบล็อกโค้ดที่เกี่ยวข้องกันด้วยสายตา สิ่งที่คุณต้องมีคือสร้างบรรทัดใหม่ระหว่างกลุ่ม

4. ไฟล์ขนาดเล็กจะอ่าน ทำความเข้าใจ และย้ายได้ง่ายกว่าไฟล์ขนาดใหญ่

5. ควรประกาศตัวแปรใกล้กับตำแหน่งที่ใช้ สำหรับฟังก์ชันขนาดเล็ก โดยปกติจะอยู่ที่ด้านบนของฟังก์ชัน

6. แม้ว่าจะเป็นฟังก์ชันแบบสั้นหรือหากเป็นคำสั่งก็ตาม ก็ยังคงจัดรูปแบบให้ถูกต้องแทนที่จะเขียนไว้ในบรรทัดเดียว

บทที่ 6: วัตถุและโครงสร้างข้อมูล

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

2. โค้ดที่กำหนดใดๆ ไม่ควรมีความรู้เกี่ยวกับภายในของวัตถุที่โค้ดนั้นทำงานอยู่

3. เมื่อทำงานกับอ็อบเจ็กต์ คุณควรต้องการให้อ็อบเจ็กต์ดำเนินการคำสั่งหรือการสืบค้น แทนที่จะถามเกี่ยวกับระบบภายใน

บทที่ 7: การแก้ไขข้อผิดพลาด

1. การจัดการข้อผิดพลาดไม่ควรรบกวนโค้ดที่เหลือในโมดูล

2. เป็นการดีกว่าที่จะลบข้อผิดพลาดและข้อยกเว้นออกจากโค้ดแทนที่จะทิ้งข้อผิดพลาดไว้ในโค้ด

3. เขียนการทดสอบที่มีข้อผิดพลาดเพื่อให้แน่ใจว่าโค้ดของคุณระบุได้และไม่พลาด

4. ข้อความแสดงข้อผิดพลาดควรให้ข้อมูลพร้อมบริบทที่จำเป็นทั้งหมดที่บุคคลอาจจำเป็นต้องแก้ไขปัญหาอย่างมีประสิทธิภาพ

5. การรวม API ของบริษัทอื่นไว้ในชั้นนามธรรมแบบบางทำให้ง่ายต่อการแทนที่ไลบรารีหนึ่งด้วยอีกไลบรารีหนึ่งในอนาคต

6. การรวม API ของบริษัทอื่นไว้ในชั้นนามธรรมบางๆ ช่วยให้จำลองไลบรารีระหว่างการทดสอบได้ง่ายขึ้น

7. ใช้รูปแบบกรณีพิเศษหรือรูปแบบ Null Object เพื่อจัดการกับพฤติกรรมพิเศษ เช่น เมื่อไม่มีข้อมูลบางอย่าง

บทที่ 8: ขอบเขต

1. ห้องสมุดบุคคลที่สามช่วยเพิ่มความเร็วในการจัดส่งผลิตภัณฑ์โดยอนุญาตให้คุณจ้างบุคคลภายนอกเพื่องานต่างๆ

2. เขียนการทดสอบเพื่อให้แน่ใจว่าคุณใช้ไลบรารีบุคคลที่สามอย่างถูกต้อง

3. ใช้รูปแบบอะแดปเตอร์เพื่อเชื่อมช่องว่างระหว่าง API ของไลบรารีบุคคลที่สามและ API ที่คุณต้องการ

4. การรวม API ของบริษัทอื่นไว้ในชั้นนามธรรมแบบบางทำให้ง่ายต่อการแทนที่ไลบรารีหนึ่งด้วยอีกไลบรารีหนึ่งในอนาคต (ซ้ำจากบทที่ 7)

5. การรวม API ของบริษัทอื่นไว้ในชั้นนามธรรมบางๆ ช่วยให้จำลองไลบรารีระหว่างการทดสอบได้ง่ายขึ้น (ซ้ำจากบทที่ 7)

6. พยายามอย่าบอกข้อมูลแอปพลิเคชันของคุณเกี่ยวกับรายละเอียดของไลบรารีบุคคลที่สามมากเกินไป

7. เป็นการดีกว่าที่จะขึ้นอยู่กับสิ่งที่คุณควบคุมมากกว่าสิ่งที่คุณไม่ได้ควบคุม

บทที่ 9: การทดสอบหน่วย

1. รหัสทดสอบควรสะอาดพอๆ กับรหัสที่ใช้งานจริง (โดยมีข้อยกเว้นบางประการ ซึ่งมักเกี่ยวข้องกับหน่วยความจำหรือประสิทธิภาพ)

2. เมื่อรหัสการผลิตเปลี่ยนแปลง รหัสทดสอบก็เปลี่ยนเช่นกัน

3. การทดสอบช่วยให้โค้ดการผลิตของคุณมีความยืดหยุ่นและบำรุงรักษาได้

4. การทดสอบช่วยให้คุณทำการเปลี่ยนแปลงได้ ทำให้คุณสามารถปรับโครงสร้างใหม่ได้อย่างมั่นใจโดยไม่ต้องกลัวว่าจะไม่สังเกตเห็นด้วยตัวคุณเอง

5. จัดโครงสร้างการทดสอบของคุณโดยใช้รูปแบบ Arrange-Act-Assert (หรือที่เรียกว่า Build-Operate-Check, Setup-Exercise-Verify หรือ Give-When-Then)

6. ใช้ฟังก์ชันเฉพาะโดเมนเพื่อทำให้การทดสอบเขียนและอ่านได้ง่ายขึ้น

7. ให้คะแนนหนึ่งแนวคิดต่อการทดสอบ

8. การทดสอบจะต้องรวดเร็ว

9. การทดสอบจะต้องเป็นอิสระ

10. การทดสอบจะต้องทำซ้ำได้

11. การทดสอบไม่ควรต้องมีการยืนยัน

12. การทดสอบควรเขียนในเวลาที่เหมาะสม ก่อนหรือหลังการเขียนโค้ดการผลิตไม่นาน ไม่ใช่หลายเดือนหลังจากนั้น

13. หากการทดสอบของคุณไม่ดี คาดว่าจะมีข้อบกพร่องในโค้ดของคุณ

บทที่ 10: ชั้นเรียน

1. ชั้นเรียนควรมีขนาดเล็ก

2. ชั้นเรียนควรรับผิดชอบเพียงสิ่งเดียวและควรมีเหตุผลเดียวในการเปลี่ยนแปลง (หลักความรับผิดชอบเดียว)

3. หากคุณไม่สามารถตั้งชื่อชั้นเรียนให้ชัดเจนได้ ก็อาจจะใหญ่เกินไป

4. งานของคุณไม่สิ้นสุดเมื่อคุณได้รับโค้ดมาใช้งาน ขั้นตอนต่อไปคือการปรับโครงสร้างใหม่และล้างโค้ด

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

6. การมีชุดการทดสอบที่ดีช่วยให้คุณจัดโครงสร้างใหม่ได้อย่างมั่นใจเมื่อคุณแยกคลาสใหญ่ออกเป็นคลาสย่อย

7. ชั้นเรียนควรเปิดเพื่อขยายเวลา แต่ปิดเพื่อแก้ไข (หลักการเปิด-ปิด)

8. อินเทอร์เฟซและคลาสนามธรรมสร้างรอยต่อที่ทำให้การทดสอบง่ายขึ้น

บทที่ 11: ระบบ

1. ใช้การขึ้นต่อกันเพื่อให้นักพัฒนามีความยืดหยุ่นในการส่งอ็อบเจ็กต์ใดๆ ด้วยอินเทอร์เฟซที่เหมาะสมไปยังคลาสอื่น

2. ใช้การฉีดขึ้นต่อกันเพื่อสร้างอินเทอร์เฟซระหว่างออบเจ็กต์ในแอปพลิเคชันของคุณเพื่อให้การทดสอบง่ายขึ้น

3. ระบบซอฟต์แวร์ไม่เหมือนอาคารที่ต้องออกแบบล่วงหน้า พวกเขาเป็นเหมือนเมืองที่เติบโตและขยายตัวเมื่อเวลาผ่านไป โดยปรับตัวให้เข้ากับความต้องการในปัจจุบัน

4. เลื่อนการตัดสินใจไปจนถึงช่วงเวลาวิกฤติสุดท้าย

5. ใช้ภาษาเฉพาะโดเมนเพื่อให้ผู้เชี่ยวชาญโดเมนและนักพัฒนาใช้คำศัพท์เดียวกัน

6. อย่าทำให้ระบบของคุณซับซ้อนเกินไป ใช้สิ่งที่ง่ายที่สุดที่ได้ผล

บทที่ 12: การปรับใช้

1. ระบบที่ไม่สามารถทดสอบได้ไม่สามารถตรวจสอบได้ และระบบที่ไม่สามารถตรวจสอบได้ไม่ควรนำไปใช้งาน

2. การทดสอบการเขียนนำไปสู่การออกแบบที่ดีขึ้น เนื่องจากโค้ดที่ทดสอบได้ง่ายมักจะใช้ dependency inserts อินเทอร์เฟซ และ abstraction

3. ชุดการทดสอบที่ดีจะขจัดความกลัวว่าแอปพลิเคชันของคุณเสียหายในขณะที่ปรับโครงสร้างใหม่

4. การทำซ้ำโค้ดทำให้เกิดความเสี่ยงมากขึ้น เนื่องจากมีตำแหน่งในโค้ดที่สามารถเปลี่ยนแปลงได้มากขึ้น และยังมีตำแหน่งที่สามารถซ่อนข้อผิดพลาดได้มากขึ้นอีกด้วย

5. โค้ดที่คุณเขียนตอนนี้เข้าใจง่ายกว่าเพราะคุณมีส่วนร่วมอย่างลึกซึ้งในการทำความเข้าใจ ไม่ใช่เรื่องง่ายสำหรับผู้อื่นที่จะบรรลุความเข้าใจในระดับเดียวกันอย่างรวดเร็ว

6. ต้นทุนส่วนใหญ่ของโครงการซอฟต์แวร์เกี่ยวข้องกับการบำรุงรักษาระยะยาว

7. การทดสอบทำหน้าที่เป็นเอกสารที่มีชีวิตว่าแอปพลิเคชันของคุณควร (และดำเนินการ) อย่างไร

8. อย่าย้ายอีกต่อไปเมื่อโค้ดของคุณใช้งานได้ ใช้เวลาเพื่อทำให้ชัดเจนและเข้าใจมากขึ้น

9. คนถัดไปที่จะอ่านโค้ดของคุณในอนาคตอันใกล้นี้น่าจะเป็นคุณมากที่สุด มีน้ำใจต่อตนเองในอนาคตด้วยการเขียนโค้ดที่เข้าใจง่าย

10. ต่อต้านความเชื่อ โอบกอดลัทธิปฏิบัตินิยม

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

บทที่ 13: ความเท่าเทียม

1. การเขียนโค้ดแบบขนานเป็นเรื่องยาก

2. จุดบกพร่องและปัญหาที่เกิดขึ้นเป็นครั้งคราวซึ่งยากต่อการทำซ้ำมักเป็นปัญหาที่เกิดขึ้นพร้อมๆ กัน

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

4. เรียนรู้เกี่ยวกับปัญหาการทำงานพร้อมกันทั่วไปและแนวทางแก้ไขที่เป็นไปได้

บทที่ 14: การปรับแต่งตามลำดับ

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

2. เป็นความผิดพลาดที่จะหยุดทำงานกับโค้ดทันทีที่โค้ดเริ่มทำงานแล้ว ใช้เวลาเพื่อทำให้ดียิ่งขึ้นหลังจากที่มันได้ผลแล้ว

3. ความไม่สงบกำลังทวีความรุนแรงขึ้นเรื่อยๆ

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

5. การเปลี่ยนแปลงที่เพิ่มขึ้นมักจะดีกว่าการสร้างใหม่ตั้งแต่ต้น

6. ใช้ Test-Driven Development (TDD) เพื่อทำการเปลี่ยนแปลงเล็กๆ น้อยๆ จำนวนมาก

7. การออกแบบซอฟต์แวร์ที่ดีเกี่ยวข้องกับการแยกข้อกังวลในโค้ดของคุณ และการแยกโค้ดออกเป็นโมดูล คลาส และไฟล์ที่มีขนาดเล็กลง

8. การทำความสะอาดทันทีหลังจากที่คุณทำเสร็จแล้ว ง่ายกว่าการทำความสะอาดในภายหลัง

บทที่ 15: JUnit Internals

1. ชื่อตัวแปรเชิงลบหรือนิพจน์เงื่อนไขนั้นเข้าใจยากกว่าตัวแปรเชิงบวกเล็กน้อย

2. การรีแฟคเตอร์เป็นกระบวนการทำซ้ำที่เต็มไปด้วยการลองผิดลองถูก

3. ทิ้ง codebase ไว้ดีกว่าตอนเจอ (Boy Scout Rule) (ซ้ำจากบทที่ 1)

บทที่ 16: การรีแฟคเตอร์ SerialDate

1. การตรวจสอบโค้ดและการวิจารณ์โค้ดของเราทำให้เราดีขึ้น และเราควรยินดีด้วย

2. ขั้นแรกให้โค้ดใช้งานได้ จากนั้นจึงแก้ไข

3. ไม่ใช่ทุกบรรทัดของโค้ดที่จำเป็นต้องมีการทดสอบ

บทที่ 17: กลิ่นและการวิเคราะห์พฤติกรรม

1. Clean Code ไม่ใช่ชุดของกฎ แต่เป็นระบบค่านิยมที่กำหนดคุณภาพงานของคุณ

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

บทสรุป

มาจบที่จุดเริ่มต้นกันดีกว่า: Clean Code โดย Robert C. Martin เป็นหนังสือการเขียนโปรแกรมที่ได้รับการแนะนำมากที่สุดตลอดกาล มีเหตุผลที่ดีสำหรับเรื่องนี้