JavaRush /จาวาบล็อก /Random-TH /โรเบิร์ต มาร์ติน คลีนโค้ด บทวิจารณ์หนังสือเรื่อง “รหัสกัง...
Artem Murk
ระดับ
Днепр

โรเบิร์ต มาร์ติน คลีนโค้ด บทวิจารณ์หนังสือเรื่อง “รหัสกังฟู” สำหรับนักพัฒนา

เผยแพร่ในกลุ่ม
สวัสดีชาว Javarashevites! บทความนี้เป็นการทบทวนหนังสือ “Clean Code” โดย Robert Martin เราจะร่วมกันหาวิธีปรับปรุงและเพิ่มประสิทธิภาพโค้ดของคุณ และท้ายที่สุดแล้ว งานเล็กๆ แต่น่าสนใจก็รอคุณอยู่
"รหัสสะอาด" โดย Robert Martin  บทวิจารณ์หนังสือเรื่อง "รหัสกังฟู" สำหรับนักพัฒนา - 1
ทุกๆ วัน เมื่อเราเปิดตัวแก้ไขโค้ด เราจะพบกับคลาส ฟังก์ชัน และตัวแปรมากมาย ตัวเลือกที่ดีที่สุดคือถ้านี่คือโค้ดของคุณที่เขียนตั้งแต่เริ่มต้น เขียนครั้งเดียว มีไม่กี่บรรทัด คุณกำลังทำงานคนเดียว ไม่มีการแก้ไข และไม่มีการสนับสนุนเพิ่มเติมจากลูกค้า แต่! ตามที่แสดงในทางปฏิบัติ ใช่ ฉันคิดว่าคุณเองก็เข้าใจว่าสิ่งนี้จะไม่เกิดขึ้น โดยพื้นฐานแล้ว เราจะต้องโต้ตอบกับสมาชิกในทีมของเรา รักษาโค้ด "ฮินดู" และแยกวิเคราะห์ผลิตภัณฑ์เป็นล้านบรรทัด ฉันมักจะได้ยินคำตอบเช่นนี้จากเพื่อนร่วมงานฝึกอบรม: “โค้ดนี้เขียนโดยฉัน และฉันจะไม่แสดงให้ใครเห็น” แต่เมื่อฉันเห็นคำขอใน Help เพื่อขอความช่วยเหลือเกี่ยวกับโค้ดดังกล่าว มันใช้เวลานานมาก เวลา (บางทีก็นานมากจริงๆ) ที่จะเจาะลึกและทำความเข้าใจว่าคนๆ นี้ต้องการบอกอะไรฉัน ฉันยังอยากจะพูดว่า “ลบแล้วเขียนใหม่อีกครั้ง” ซะด้วยซ้ำ! ขอบคุณเวลาและพลังงานของผู้ที่ต้องการช่วยเหลือคุณ เขียนอย่างถูกต้อง และหากคุณไม่รู้ว่าต้องทำอย่างไร ก็ไม่สายเกินไปที่จะเรียนรู้ หนังสือของ Robert Martin โดดเด่นในบรรดาหนังสือรูปแบบนี้ตรงที่ประกอบด้วยตัวอย่างมากมายในภาษา Java นี่อาจเป็นข้อความที่คลั่งไคล้เล็กน้อยในส่วนของฉัน แต่มันถูกเขียนในรูปแบบ OOP กล่าวคือในการเขียนส่วนและส่วนต่างๆ เข้าใจและอ่านง่ายหนังสือเล่มนี้อ่านง่ายทุกที่ทุกเวลาหรือตอนเย็นก่อนนอน Clean Code แบ่งออกเป็น 3 ส่วน ในส่วนแรกเราจะต้องศึกษาทฤษฎีของหนังสือ เรียนรู้เกี่ยวกับรูปแบบการออกแบบและกฎเกณฑ์มารยาทที่ดี ส่วนที่สองเชิญชวนให้เราฝึกการปรับโครงสร้างใหม่และการเขียน และส่วนที่สามเป็นบทสรุปสุดท้ายของโค้ด “กลิ่น” ในตัวอย่าง ผู้เขียนได้กล่าวถึงหลายหัวข้อซึ่งคุณจะต้องมีความรู้เกี่ยวกับ Java Core เป็นหลัก แต่ยังมีส่วนต่างๆ สำหรับการทดสอบหน่วย JUnit, การบันทึก Log4j, ความรู้เกี่ยวกับรูปแบบที่ง่ายที่สุดในการออกแบบ (แต่อย่างที่ฉันกล่าวไว้ข้างต้น ไม่มี หลายคนและทุกสิ่งที่เข้าใจยากสามารถค้นหาใน Google ได้สำเร็จใช่และวิเคราะห์ในหลักสูตร JavaRush) ทุกบทของหนังสือไม่เกี่ยวข้องกัน คุณสามารถเริ่มอ่านจากบทที่ต้องการได้สำเร็จ สรุปแนวคิดหลักๆ สั้นๆ ที่ผมหยิบมาจากหนังสือ ฉันจะขอบคุณสำหรับความคิดเห็นของคุณ ซึ่งคุณสามารถแบ่งปันวิสัยทัศน์ของคุณเองเกี่ยวกับข้อความเหล่านี้ได้

1. ความเห็น == ชั่วร้าย.

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

2. รหัสแสดงความคิดเห็น รหัสที่ไม่ทำงาน

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

3. หัวข้อของเมธอด คลาส และตัวแปร

เป็นมูลค่าบทความแยกต่างหากเพื่อหารือเกี่ยวกับหัวข้อนี้ อย่าขี้เกียจและเขียนชื่อที่สามารถบอกจุดประสงค์ของพวกเขาได้ เรียนรู้มาตรฐานบางประการในการสะกดชื่อ หัวข้อนี้ “ต้องมี” เพื่อศึกษาอย่างละเอียด

4. แต่ละวิธีและตัวแปรมีตำแหน่งในลำดับชั้นของคลาส

โดยทั่วไปแล้ว คลาสสามารถมีตัวแปรและวิธีการ (แบบคงที่และไม่คงที่) ตัวสร้าง คลาสแบบซ้อนและคลาสภายใน และแจงนับ กล่าวโดยสรุป มีข้อมูลมากมาย และจำเป็นต้องระบุตำแหน่งของทุกคนในชั้นเรียน หากคุณดูที่คลาส Java Core คุณจะเห็นว่าโครงสร้างนั้นมีโครงสร้างที่ชัดเจน เราสามารถมองเห็นแต่ละส่วนในตำแหน่งของมัน แน่นอนว่าในโปรเจ็กต์ของคุณมันสามารถเปลี่ยนแปลงภายในโปรเจ็กต์ได้ แต่ไม่ใช่ในแต่ละคลาส สำหรับตัวฉันเอง ฉันได้กำหนดโครงสร้างการสร้างต่อไปนี้: ที่จุดเริ่มต้นของคลาสฉันมีตัวแปรคงที่ จากนั้นตัวแปรอ็อบเจ็กต์ + Enums หากมีอยู่ หลังจากตัวแปร ฉันจะกำหนดตัวสร้างคลาส จากนั้นฉันก็เขียนวิธีการทำงานร่วมกับชั้นเรียน หลังจากวิธีการที่ฉันเขียน getters และ setters และท้ายที่สุดแล้ว ฉันมีชั้นเรียนภายใน คุณสามารถใช้โครงสร้างของฉันหรือเขียนของคุณเองในความคิดเห็น

5. ระดับของนามธรรมของวิธีการ

สำหรับฉันนี่คือการค้นพบครั้งที่ 1 แต่ละวิธีมีตัวดำเนินการในระดับนามธรรมเพียงระดับเดียวเท่านั้น คุณไม่ควรผสมผสานการดำเนินงานหลายระดับเข้าด้วยกัน

6. การจัดการข้อผิดพลาด

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

7. การจัดรูปแบบโค้ด

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

8. การปฏิเสธในสภาวะ

พยายามหลีกเลี่ยงการปฏิเสธในสภาวะต่างๆ นี่เป็นปัจจัยทางจิตวิทยามากกว่า สมองของเรารับรู้การปฏิเสธได้ไม่ดีนัก และใช่! ก่อนที่จะไม่อาจสังเกตเห็นการแสดงออก เช่น การปฏิเสธถ้า (!condition.isTrue) ดีกว่าเขียนเมธอดใหม่ จะทำให้ง่ายขึ้นมาก (condition.isFalse)

9. ฟังก์ชันต่างๆ จะต้องดำเนินการเพียงครั้งเดียว

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

10. อย่าพูดซ้ำตัวเอง

อย่าทำซ้ำโค้ด DRY (อย่าทำซ้ำตัวเอง) นี่เป็นหนึ่งในกฎพื้นฐานที่จะลดโค้ดของคุณลงอย่างมาก โปรดจำไว้เสมอ พยายามนำโค้ดที่ทำซ้ำทั้งหมดไปไว้ในฟังก์ชันแยกกัน แน่นอน เราสามารถพูดคุยเกี่ยวกับ DRY, KISS(Keep it simple Stupid), SOLID , YAGNI ได้อีกมากมาย ข้อกำหนดเหล่านี้จำเป็นสำหรับการทำความเข้าใจและการออกแบบ คุ้มค่ากับบทความแยกต่างหาก บางทีฉันจะเขียนเกี่ยวกับพวกเขาอีกครั้ง เนื่องจากบทความนี้มีไว้สำหรับการทบทวนหนังสือ "Clean Code"
"รหัสสะอาด" โดย Robert Martin  บทวิจารณ์หนังสือเรื่อง "รหัสกังฟู" สำหรับนักพัฒนา - 2
ตามที่สัญญาไว้ งานเล็กและง่ายสำหรับคุณ โปรแกรมจะต้องคำนวณดัชนีโรคอ้วนตามข้อมูลที่ให้มา เขียนความคิดเห็นจำนวนข้อผิดพลาดและการแก้ไขในโค้ด ป.ล. รหัสใช้งานได้และทำงานได้หากใช้อย่างถูกต้อง
//Weight in kg.
//Height in metres.
public class sample {
    public static void main (String[] args) {
        humanIMB humanIMB = new humanIMB(80,1.52);
        System.out.println(humanIMB.Result());
    }
}
class humanIMB {
    public double W; //Weight Human
    public double H; // Height Human
    private static double imb;
    public humanIMB(double w, double h) {
        W = w;
        H = h;
        imb = W / (H * H);
    }
    public double takeW() {
        return W;
    }
    public void putW(double w) {
        W = w;
        imb = W / (H * H);
    }
    public double takeH() {
        return H;
    }
    public void putH(double h) {
        H = h;
        imb = W / (H * H);
    }
    public static double takeImt() {
        return imb;
    }
    public static String Result() {
        String  string = null;
        if (imb >=18.5 & imb <25) {
            string ="Норма, ты в форме!";
        }
        if (imb >=25 & imb <30) {
            string ="Предожирение. Эй, поосторожнее с пирожными ";
        }
        if (imb >=30) {
            string ="Ожирение. SCHWEINE! Хватит жрать, иди на треню!";
        }
        if (imb <18.5) {
            string ="Дефицит массы тела. В модели решил переквалифицироваться?";
        }
        return string;
    }
}
ความคิดเห็น
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION