Robert Martin, Mã sạch. Review cuốn sách “mật mã kung fu” dành cho lập trình viên

Xin chào Javarashevites! Bài viết này là bài review cuốn sách “Clean Code” của Robert Martin. Chúng ta sẽ cùng nhau xem xét các cách cải thiện và tối ưu hóa mã của bạn và cuối cùng, một nhiệm vụ nhỏ nhưng thú vị đang chờ bạn. Hàng ngày, khi mở trình soạn thảo mã của bạn, chúng tôi sẽ gặp nhiều lớp, hàm và biến. Lựa chọn tốt nhất là nếu đây là mã của bạn được viết từ đầu, được viết một lần, có ít dòng trong đó, bạn đang làm việc một mình, không có chỉnh sửa và không có hỗ trợ thêm từ khách hàng. NHƯNG! Như thực tế cho thấy, vâng, tôi nghĩ bản thân bạn cũng hiểu rằng điều này không xảy ra. Về cơ bản, chúng tôi sẽ phải tương tác bằng cách nào đó với các thành viên trong nhóm của mình, duy trì mã “Hindu” và phân tích sản phẩm thành hàng triệu dòng. Tôi thường nghe những câu trả lời như thế này từ các đồng nghiệp đào tạo của mình: “Mã này do tôi viết và tôi sẽ không cho bất kỳ ai xem” nhưng khi tôi thấy các yêu cầu Trợ giúp về Trợ giúp với mã như vậy thì phải mất rất nhiều thời gian. thời gian (đôi khi thực sự là rất lâu) để tìm hiểu sâu và hiểu Người đó muốn nói gì với tôi, thậm chí tôi còn muốn nói “xóa đi viết lại”! Hãy trân trọng thời gian và sức lực của những người muốn giúp đỡ bạn, viết đúng và nếu bạn không biết cách thì không bao giờ là quá muộn để học. Cuốn sách của Robert Martin nổi bật trong số những cuốn sách thuộc định dạng này ở chỗ nó chứa nhiều ví dụ bằng Java. Về phần tôi, đây có thể là một tuyên bố hơi cuồng tín, nhưng nó được viết theo phong cách OOP, cụ thể là cách viết các phần và phần. Dễ hiểu và dễ đọc, cuốn sách rất dễ đọc khi đang di chuyển hoặc vào buổi tối trước khi đi ngủ. Clean Code được chia thành 3 phần. Phần đầu tiên chúng ta được yêu cầu tìm hiểu lý thuyết trong sách, tìm hiểu về các mẫu thiết kế và các quy tắc ứng xử tốt. Phần thứ hai mời chúng ta thực hành tái cấu trúc và viết, còn phần thứ ba là tóm tắt cuối cùng về đoạn mã “có mùi” trong các ví dụ. Chà, tác giả đã đề cập đến nhiều chủ đề mà bạn chủ yếu cần kiến ​​thức về Java Core, nhưng cũng có những phần dành riêng cho Kiểm tra đơn vị JUnit, Ghi nhật ký Log4j, kiến ​​thức về các mẫu đơn giản nhất trong thiết kế (nhưng như tôi đã nói ở trên, không có nhiều trong số chúng và mọi thứ khó hiểu đều có thể được tìm kiếm trên Google thành công, vâng và phân tích nó trong khóa học JavaRush). Tất cả các chương của cuốn sách không liên quan đến nhau, bạn có thể bắt đầu đọc thành công từ chương mình thích. Một bản tóm tắt ngắn gọn về những ý chính mà tôi đã thu thập được từ cuốn sách. Tôi sẽ biết ơn những nhận xét của bạn về chúng, trong đó bạn có thể chia sẻ tầm nhìn của riêng mình về những tuyên bố này.

1. Bình luận == ác.

Trong hầu hết các trường hợp, nhận xét là cái nạng để chúng ta cố gắng che đậy mã xấu của mình. Và trong một số trường hợp, họ còn nói dối về mục đích của các phương thức hoặc biến nếu việc tái cấu trúc mã liên tục.

2. Code bị comment, code chết.

Việc để lại những đoạn mã này trong ứng dụng của bạn chẳng khác nào rác rưởi. Mã không được sử dụng sẽ tích lũy theo thời gian và cản trở tính sạch sẽ của ứng dụng của bạn, thỉnh thoảng hãy kiểm tra mã cho các mô-đun đó.

3. Tiêu đề của phương thức, lớp và biến.

Đó là giá trị bài viết riêng biệt để thảo luận về chủ đề này. Đừng lười biếng và viết những cái tên có thể nói lên mục đích của chúng. Tìm hiểu một số tiêu chuẩn về chính tả trong tiêu đề. Chủ đề này là “Phải có” để nghiên cứu chi tiết.

4. Mỗi phương thức và biến đều có vị trí của nó trong hệ thống phân cấp lớp.

Thông thường, một lớp có thể có các biến và phương thức (tĩnh và không tĩnh), hàm tạo, các lớp lồng nhau và bên trong cũng như các enum. Tóm lại là có rất nhiều thông tin, cần phải xác định vị trí của mỗi người trong lớp. Nếu nhìn vào các lớp java core các bạn sẽ thấy cấu trúc có cấu trúc rõ ràng, chúng ta có thể thấy từng phần ở đúng vị trí của nó, tất nhiên trong dự án của bạn nó có thể thay đổi trong phạm vi dự án chứ không phải trong từng lớp. Đối với bản thân tôi, tôi đã xác định cấu trúc xây dựng sau: Đầu lớp tôi có các biến tĩnh, sau đó là các biến đối tượng + Enums nếu chúng tồn tại. Sau các biến, tôi định nghĩa các hàm tạo của lớp. Sau đó tôi viết các phương thức để làm việc với lớp. Sau các phương thức tôi viết getters và setters. Và cuối cùng tôi có các lớp bên trong. Bạn có thể sử dụng cấu trúc của tôi hoặc viết cấu trúc của riêng bạn trong phần bình luận.

5. Mức độ trừu tượng của phương pháp.

Đối với tôi đây là khám phá số 1. Mỗi phương thức chỉ chứa các toán tử ở một mức độ trừu tượng. Bạn không nên kết hợp các hoạt động đa cấp với nhau.

6. Xử lý lỗi.

Ngoại lệ đã được kiểm tra hoặc không được kiểm tra, cái nào tốt hơn để sử dụng trong dự án (bạn nghĩ sao?, viết bình luận)? Tôi là người ủng hộ việc kiểm tra, nhưng cuốn sách giúp xem xét các Ngoại lệ không được kiểm tra từ bên ngoài. Thật vậy, Ngoại lệ không được chọn không làm biến dạng chữ ký phương thức, đặc biệt khi xem xét các ngoại lệ đó “xuyên thủng” nhiều lớp cùng một lúc. Sự bất tiện của sự thay đổi nhỏ nhất dẫn đến việc xác định lại toàn bộ chuỗi phương pháp trước khi nắm bắt được nó, điều này cực kỳ bất tiện cho việc phát triển trong nhiều trường hợp.

7. Định dạng mã.

Mã được định dạng đúng không chỉ rõ ràng mà còn rất dễ đọc. Bạn ngay lập tức có ý tưởng về dấu ngoặc và các hành động bên trong. Sử dụng ví dụ về các điều kiện trong cấu trúc if, else, bạn không nên viết mọi thứ trong một dòng, tốt hơn nên di chuyển các chuỗi dài.

8. Phủ định trong điều kiện.

Cố gắng tránh sự từ chối trong các điều kiện, đây thiên về yếu tố tâm lý hơn, não của chúng ta không nhận thức rõ sự từ chối, và đúng vậy! trước biểu thức có thể không được chú ý. Ví dụ: phủ định if (!condition.isTrue) thì tốt hơn là viết lại phương thức, nó sẽ làm cho nó dễ dàng hơn nhiều như thế này (condition.isFalse)

9. Các hàm phải thực hiện một thao tác.

Nếu phương thức của bạn thực hiện nhiều thao tác thì hãy chia chúng thành các phương thức thao tác đơn. Những phương pháp này rất dễ hỗ trợ, dễ kiểm tra và nếu cần, có thể thay thế hoặc loại bỏ.

10. Đừng lặp lại chính mình.

Đừng lặp lại mã DRY (Đừng lặp lại chính mình). Đây là một trong những quy tắc cơ bản sẽ làm giảm đáng kể mã của bạn, hãy ghi nhớ điều này. Cố gắng đặt tất cả các đoạn mã lặp lại của bạn vào một hàm riêng biệt. Tất nhiên, chúng ta có thể nói nhiều hơn về DRY, KISS(Giữ cho nó đơn giản ngu ngốc), SOLID , YAGNI. Những thuật ngữ này rất cần thiết cho sự hiểu biết và thiết kế. Chúng xứng đáng có một bài viết riêng, có lẽ tôi sẽ viết lại về chúng, vì bài viết này được dành để đánh giá cuốn sách “Mã sạch”. Như đã hứa, một nhiệm vụ nhỏ và dễ dàng dành cho bạn. Chương trình phải tính toán Chỉ số Béo phì dựa trên dữ liệu đã cho. Viết vào phần bình luận số lỗi và cách sửa trong mã. tái bút Mã đang hoạt động và thực hiện chức năng của nó nếu được sử dụng đúng cách.

//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;
    }
}