Tư duy lập trình – Tư duy code ngược

Nghe thì có vẻ hàn lâm nhỉ, thú thực mà nói thì mình chẳng có trình độ để hướng dẫn các bạn về cách làm thế nào để có tư duy lập trình tốt hay cách làm thế nào để có tư duy code tốt.

Thế nên trong seri bài viết về Tư duy lập trình mình sẽ share các kinh nghiệm mà mình đã có trong quá trình làm việc, những suy nghĩ của mình về cái gọi là code đẹp, code dễ hiểu.

Phần 1: Tư duy lập trình – Tư duy code

Tư duy lập trình

Ở đây mình hoàn toàn không nói đến yêu cầu của cả một chương trình lớn mà chỉ đang đề cập tới một chức năng, một đoạn code nhỏ, hay xử lý một tác vụ nhỏ trong yêu cầu của bài toán tổng thế.

Thông thường đứng trước những vấn đề như trên xử lý của mình sẽ đi qua 3 giai đoạn chính:

  • Phân tích tìm hiểu xem vấn đề là gì? Chúng ta sẽ định làm những gì ?.
  • Bắt tay vào Code và cố gắng áp dụng tư duy ngược khi code.
  • Kiểm tra lại và xem có thể tối ưu tốt hơn không.

1. Phân tích tìm hiểu xem vấn đề là gì? Chúng ta sẽ định làm những gì ?

Phần đông các bạn trẻ mới lập trình, khi nhận được một yêu cầu nào đó đều ngay lập tức cắm mặt vào code luôn. Và cứ đọc lần lượt code từ trên xuống dưới.

Xin thưa rằng đó là nguyên nhân lớn nhất dẫn đến việc code trở lên phức tạp rối rắm. Vậy giải quyết nó thì nên làm gì ?

Vâng việc đầu tiên bạn nên thở chậm một chút, đừng cắm đầu vào làm luôn hãy đọc qua toàn bộ yêu cầu ít nhất một lần và thử phân tích và trả lời các câu hỏi bên dưới:

  • Yêu cầu của nó là gì ?
  • Nó có thể làm bằng những cách nào?
  • Nó có ảnh hưởng gì đến các phần khác, chức năng khác không ?
  • Có phần nào, chức năng nào sử dụng đến nó không?
  • Nó có thể chia nhỏ nữa được không? Nếu được nó có thể viết thành hàm common hay class common hay không ?

Nếu bạn đã nghĩ về những vấn đề trên 1 lần, 2 lần … n lần hay đã rất kĩ rồi thì đã đến lúc bạn bước vào giai đoạn code.

2. Bắt tay vào Code và cố gắng áp dụng tư duy ngược khi code

Enter your text here...

Enter your text here...

Tuy duy ngược? Nghe lạ nhỉ, vì tôi quen gọi nó là như vậy rồi nên cũng không rõ gốc gác nó gọi là gì nữa. Nhưng tôi sẽ cố gắng giải thích đơn giản cho các bạn thế này nhé.

Thông thường khi đọc một yêu cầu và code các bạn sẽ code như thế nào? Tôi đoán đa số sẽ code từ trên xuống dưới theo yêu cầu. Thế nhưng đôi khi bạn hãy thử suy nghĩ ngược đi một chút bạn sẽ thấy kết quả rất hay đó.

Chúng ta thử tìm hiểu thông qua ví dụ bên dưới:

Yêu cầu: Tạo một method tính tổng 3 số nguyên với tham số đầu vào lần lượt là a, b , c. Trong đó thỏa mãn các điều kiện sau.

  • Nếu a lớn hơn 0 thì check b, còn người lại thì trả về 0.
  • Nếu b lớn hơn 0 thì check c, còn người lại thì trả về 0.
  • Nếu c lớn hơn 0 thì trả về tổng của a + b + c , còn người lại thì trả về 0.

Ở ví dụ này tôi sẽ đưa ra 2 kiểu code, các bạn hãy xem mình đang định đi theo kiểu nào nhé.

  • Cách 1:

public int sunM(int a, int b, int c) {
  if (a > 0) {
    if (b > 0) {
      if (c > 0) {
        return a + b + c;
      } else {
        return 0;
      }
    } else {
      return 0;
    }
  } else {
    return 0;
  }
}

  • Cách 2:

public int sunM(int a, int b, int c) {
  if (a <= 0) {
    return 0;
  }
  if (b <= 0) {
    return 0;
  }
  if (c <= 0) {
    return 0;
  }
  return a + b + c;
}

  • Cách 3:

public int sunM(int a, int b, int c) {
  if ( a <=0 || b <=0 || c <=0){
    return 0;
  } else {
    return a+b+c;
  }
}

Dõ dàng ở cả hai ví dụ thì kết quả đều trả ra là như nhau. Nhưng nếu nhìn style code trường hợp thứ 2, 3 chúng ra có thể thấy dễ nhìn hơn rất nhiều.

Thay vì check các trường hợp a, b, c > 0 như trong yêu cầu, ta có thể suy nghĩ ngược lại để loại bỏ các trường hợp abnormal trước . Như thế theo cách này các bạn sẽ thấy trường hợp normal luôn năm ở cấp 1 của tab source.

Bạn hãy thử tư duy thế này một vài lần xem nhé

3. Kiểm tra lại và xem có thể tối ưu tốt hơn được không

Mình rất hay thấy các bạn mới code thường code xong thấy chạy được case normal là xong. Coi như xong và vứt ngay cho bên test để run test.

Gần như đây là điểm đen nhất trong tư duy code của các bạn. Hãy tưởng tượng nó là còn đẻ của mình, mình code ẩu xong bug phát sinh đầy thì chúng ta thấy thế nào đấy nhỉ.

Vậy nên sau khi code xong thì nhất thiết phải :

  • Review lại source code.
  • Viết junit cho source code.

Review lại source code

Bạn sẽ review lại như thế nào? Cơ bản khi chúng ta code ra mà lại review lại thì chắc chắn sẽ chẳng thế tìm ra lỗi nào cả. Đơn giản là vì mình làm thì chẳng bao giờ sai hết .

Chính ví thế bạn phải dung đến checklist ( một danh sách các mục cần phải kiểm tra tính đúng đắn của source code ).

Nếu bạn có một checklist tốt và check cẩn thận từng Item thì mình chắc chắn là bạn sẽ có một chương trình ít lỗi.

Nhưng check list ở đâu ra? Bạn phải tự làm trước nó khi bắt đầu dự án, cần phải dựa vào tiêu chuẩn coding convension chung, cùng với các yêu cầu cụ thể từ khách hàng.

Chú ý: Khách hàng là người quyết định sản phẩm của bạn là tốt hay xấu, đúng hay sai nên điều quan trong nhất cứ checklist mà bán sát yêu cầu của Khách hàng.

Viết Junit cho source code

Bạn phải luôn hiểu rằng source code do bạn viết ra và bạn chính là người chịu trách nhiệm cho đoạn code đó. Trách nhiệm rằng nó sẽ chạy đúng, nó sẽ chạy không có lỗi và toàn bộ nhánh của source code đều khả thì ( tức là đều có thể chạy qua được ).

Junit và dJunit sẽ giúp bạn check được được độ bao phủ ( coverage ) source cdoe của bạn. Bạn không thể gửi cho Khác hàng sản phẩm mà có những đoạn code thừa không thế chạy qua.

Với tôi code không thể chạy qua thì sẽ là code thừa và bắt buộc phải xóa đi.

Ví dụ đoạn code như bên dưới

public int sampleMethod(int a) {
  if (a > 0) {
    return a;
  } else if (a <= 0) {
    return 0;
  } else {
    return -1;
  }
}

Nếu nhìn đoạn code trên thì có thể thấy trường hợp return -1 là không thể xảy ra do các trường hợp đã được bao hết ở 2 trường hợp bên trên rồi.

Vì thế về nguyên tắc cần phải sửa và xóa trường hợp return -1 đi.

Như vậy bạn cũng có thể thấy, tư duy lập trình cũng chẳng có gì cao siêu, hàm lâm cả. Chúng đôi khi chỉ là các quy tắc mà nếu nhớ được chúng ta có thể làm tốt hơn rất nhiều.

Chính vì thế đừng lo bạn không thông minh, chỉ cần bạn có thể áp dụng triệt để những quy tắc như trên thì bạn vẫn có thể tự tạo khi tạo ra những chương tình chất lượng.

5 (100%) 1 vote
Đinh Thế Hiển
 

Mình là người thích viết lách, chia sẻ các trải nghiệm trong cuộc sống. Thích thể thao đặc biệt là thể hình. Hãy kết nối với mình nhé.

Click Here to Leave a Comment Below 0 comments