Một số quy tắc code giúp bạn trở nên pờ rồ hơn

Đặt vấn đề

Khi làm việc trong dự án không phải xây dựng từ đầu (maintainable) hoặc code theo team, thì để code tiếp được thì bạn phải đọc hiểu được code, flow code. Điều này cũng phụ thuộc lớn vào người viết code trước có dễ hiểu, clean hay không

Trong bài viết này, chúng ta cùng xem một số quy tắc mà bạn có thể áp dụng để cải thiện code của mình.

1. Readable code is maintainable code

Code dễ đọc là code có thể maintainable - rule đơn giản nhỉ

2. Remove unnecessary code comments

Xóa các comment không cần thiết.

Tất nhiên, một số đoạn code dài và phức tạp chúng ta cần comment, tuy nhiên cần comment ngắn gọn, dễ hiểu.

Ví dụ đoạn code dưới đây sẽ merge nhiều mảng lại với nhau thành mảng mới

function mergeArrays(...arrays) {
  let mergedArray = []

  arrays.forEach(array => {
      mergedArray = [...mergedArray, ...array]
  })

  return mergedArray
}

Thêm comment vào function này không cải thiện được gì nhiều, khi review code, trong quá trình review code có thể hỏi.

3. Focus on naming

Tập trung vào việc đặt tên - việc đặt tên biến và tên biến có thể nói là đau đầu với các dev

Nếu bạn nhìn vào tên mergeArrays ,thì rất rõ ràng, hàm này kết hợp nhiều mảng thành một mảng mới. Việc đặt tên cho mọi thứ là rất khó, và các hàm phức tạp thì đặt tên lại càng khó khăn hơn...Hãy sử dụng quy tắc đặt tên dễ dàng cho bản thân hoặc trong team.

Hãy tưởng tượng, một hàm merge 2 mảng số và tạo ra một danh sách số unique - bạn sẽ đặt tên cho nó như thế nào ?

Ví dụ

function mergeNumberListIntoUniqueList(listOne, listTwo) {
  return [...new Set([...listOne, ...listTwo])]
}

Tên của hàm đúng là không tồi, vì nó mô tả đúng những gì đã làm. Vấn đề là hàm này đang làm 2 việc. Càng nhiều chức năng, càng khó đặt tên cho nó. Chúng ta sẽ tách nó thành 2 hàm với 2 chức năng riêng biệt , làm chúng ta dễ đọc và có thể tái sử dụng.

Ví dụ

function mergeLists(listOne, listTwo) {
  return [...listOne, ...listTwo]
}

function createUniqueList(list) {
  return [...new Set(list)]
}

4. If statements

Câu lệnh if

Problem

if(value === 'duck' || value === 'dog' || value === 'cat') {
  // ...
}

Solution

const options = ['duck', 'dog', 'cat'];
if (options.includes(value)) {
  // ...
}

Nếu các option bao gồm giá trị thì ....

Chúng ta cùng xem ví dụ dưới đây

function handleEvent(event) {
  if (event) {
    const target = event.target;
    if (target) {
      // Your awesome piece of code that uses target
    }
  }
}

Ở đây, đoạn code đang kiểm tra xem đối tượng event có hay không và thuộc tính target có giá trị hay không, chúng ta có thể gộp 2 câu lệnh if này thành một.

function handleEvent(event) {
  if (!event || !event.target) {
    return;
  }
  // Your awesome piece of code that uses target
}

Rõ ràng ngắn gọn và clean hơn đúng không

5. Destructuring assignment

Trong JavaScript, chúng ta có thể Destructuring object và mảng

Theo tài liệu, developer.mozilla.org the descructuring assignment syntax is a JavaScript expression that makes it possible to unpack values from arrays, or properties from objects, into distinct variables. - cú pháp Destructuring assignment có thể giải nén các giá trị từ mảng hoặc thuộc tính từ object thành các biến riêng biệt.

Ví dụ

// Destructuring an object
const numbers = {one: 1, two: 2};
const {one, two} = numbers;
console.log(one); // 1
console.log(two); // 2

// Destructuring an array
const numbers = [1, 2, 3, 4, 5];
const [one, two] = numbers;
console.log(one); // 1
console.log(two); // 2

Vấn đề với việc destructuring là nó đôi khi tạo ra một tên xấu cho thuộc tính. Ví dụ tốt hơn đó là fetch data từ một API và nhận một response có dữ liệu

const url = "http://localhost:8080/api/v1/organizers/1"
const response = await axios.get(url)
const {name} = response.data

Code trên đó là bạn fetch data của 1 organizers có id bằng 1. Đối tượng Organizer có name và bạn destructure nó. Không có gì sai.

Code này vẫn chạy và vẫn ổn . Có phải name này là thuộc tính duy nhất trong toàn bộ code của bạn. Giả sử đối tượng Unit cũng có name thì khi đọc code, name sẽ là của đối tượng nào. Chúng ta sửa lại 1 chút.

const url = "http://localhost:8080/api/v1/organizers/1"
const response = await axios.get(url)
const {name: organizerName} = response.data

Code trở nên dễ đọc hơn rồi đấy, mọi người đều biết rằng đây là name của Organizer

6. The boy scout rule

Quy tắc hướng đạo sinh - nghe hơi lạ nhỉ

Boy Scout Rule là một nguyên lý có nội dung dựa trên quy tắc có thật của hội hướng đạo sinh Mỹ (Boy Scouts of America). Quy tắc đó có nội dung là "Leave the campground cleaner than you found it", tức hãy giữ cho khu cắm trại sạch sẽ hơn lúc bạn đến.

Boy Scout Rule được áp dụng trong thiết kế phần mềm với nội dung dạng như hãy giữ cho code được sạch đẹp hơn lúc bạn chưa chỉnh sửa nó =)) Tức đừng có mà làm cho một đoạn code đã có sẵn trở nên tồi tệ hơn.

Boy Scout Rule được phát biểu dưới nhiều dạng khác nhau như: "always leave the code you're editing a little better than you found it", "always leave the code cleaner/better than you found it", "Always check a module in cleaner than when you checked it out" ...

7. Code style

Cuối cùng, cũng không kém phần quan trọng, đó là xác định style code trong team của bạn.

Trong team có người thích viết code theo kiểu dấu nháy đơn - người thích viết dấu nháy kép, người thích dấu cách - người thích tab, dấu phẩy ở cuối hoặc không có dấu phẩy ở cuối. Cả team phải đưa ra quy định để viết theo 1 kiểu thôi nhé

Với JavaScript có rất nhiều công cụ dể kiểm tra code của bạn trước khi push lên git, ví dụ như eslint, cài đặt pre-commit - kiểm tra trước khi commit.... điều này đảm bảo code của cả team luôn có cùng 1 style và không có code xấu.

Kết luận

Có một số quy tắc là hiển nhiên và có những quy tắc không phải ai hay team nào cũng biết hay quy định. Tầm quan trọng của các rule khi code có lẽ rõ ràng quan trọng trong các dự án lớn - team size lớn. Nhưng không có nghĩa là bạn không áp dụng vào các dự án nhỏ - làm dự án nhỏ ngon thì mới tính đến chuyện làm dự án lớn chứ nhỉ

Như phần đầu của bài viết, việc code theo rule giúp code của bạn dễ đọc và clean hơn - nâng cao skill hơn, tự tin hơn trong việc code. Còn với team giúp những người khác đọc code của bạn không phải vừa đọc code vừa lẩm bẩm "** thằng nào code đoạn này đây nhỉ", dễ maintainable hơn.

Tham khảo : Clean up your code by applying rules