Quá mức quan tâm về tốc độ thực thi của code, của ngôn ngữ lập trình. Đây là một thói quen nên bỏ!
Trong bài viết hôm nay, mình sẽ giải thích về việc tối ưu code: Optimize code một cách pro nhất! Khi nào cần optimize, khi nào không nên optimize code?
Optimize code (Tối ưu code) là việc chỉnh sửa/viết lại code nhằm giảm dung lượng, hạn chế input/output, tăng tốc độ thực thi, giảm lượng phần cứng cần sử dụng.
Thuở đi học, ta được học về Big O Notation, thuật toán được tối ưu sẽ chạy nhanh hơn, hoặc ít tốn bộ nhớ hơn. Đa phần các trường đại học dạy C, C++, làm việc trực tiếp với bộ nhớ, các thầy lúc nào cũng tâm niệm: Code viết ra phải càng tối ưu càng tốt.
Đi thi tin học, code viết ra chạy nhanh hơn, ít tốn bộ nhớ hơn thì sẽ được điểm cao hơn. Phỏng vấn của một số công ty lớn cũng đòi hỏi code viết ra phải tối ưu hơn. Điều này dẫn đến nhiều bạn có suy nghĩ: Phải ưu tiên tối đa việc optimize code!
Trong ngành phần mềm, điều này không hề đúng! Tại sao vậy? Hãy đọc phần dưới nhé.
Nguyên văn câu này như sau:
Chúng ta nên bỏ qua những optimize vụn vặt, trong khoảng 97% mọi trường hợp: Optimize code sớm là nguồn gốc của mọi tội ác. Tuy vậy, chúng ta không nên bỏ qua việc optimize trong 3% còn lại.
Trong môi trường làm việc, performance chỉ là một khía cạnh của code. Như mình đã nói nhiều lần, code của bạn sẽ được đọc, được nâng cấp và bảo trì bởi nhiều người khác. Do đó, code cần phải rõ ràng, dễ đọc dễ hiểu rồi mới tính đến performance. Theo kinh nghiệm, nếu quá chú tâm vào tối ưu code, code của bạn có thể trở nên vòng vèo khó đọc.
Trong đa phần các trường hợp, sự đơn giản, tường minh của code quan trong hơn performance nhiều lần. Code tốt thật sự là code dễ đọc, dễ hiểu, dễ bảo trì.Ngoài ra, trong đa phần các trường hợp, ta sẽ không biết những chức năng nào cần optimize, đoạn code nào cần optimize. Nếu không xác định được việc này, optimize code một cách mù quáng sẽ giống như “thầy bói xem voi”, tốn thời gian mà chả được gì cả.
Mình từng gặp một case như sau. Có bạn hỏi mình “Dapper performance nhanh hơn Entity Framework, web chạy chậm em có nên thay bằng EF bằng Dapper ko?”. Mình đề nghị họ dùng tool để đo performance trước.
Thời gian đọc dữ liệu từ DB chỉ là 50ms, có nhanh hơn gấp đôi cũng chỉ tiết kiệm được 25ms. Hóa ra web chậm là do gọi nhiều Ajax, load CSS/JS và hình ảnh lâu. Chỉ cần thêm cache, minify và bundle lại CSS/JS, chỉnh chất lượng ảnh là tốc độ đã tăng 2/3 lần mà ko cần sửa đụng chạm nhiều đến code.
Như đã nói trong câu danh ngôn, chúng ta không nên optimize code sớm, chứ không phải là không nên optimize code. Trước khi quyết định optimize code, hãy thử áp dụng các qui tắc sau nhé.
Khi quyết định optimize, làm theo những bước sau:
Một lời khuyên khác của các chuyên gia về việc optimize:
Một điều quan trọng nữa cần nhớ là: Hãy tự hỏi có thật sự cần optimize hay không? Lấy ví dụ, trang web bán hàng nọ có chức năng xuất report. Chức năng này chạy mất 1 tiếng đồng hồ. Chậm quá nhỉ, có lẽ bạn phải optimize? Khoan, hãy xem xét các trường hợp sau. Giả sử bạn mất 10 tiếng để optimize chức năng này, thời gian chạy xuống còn khoảng 30 phút.
Nếu chức năng này được admin sử dụng mỗi ngày, sau 1 tháng họ sẽ tiết kiệm được 15 tiếng. Việc bỏ công sức ra optimize là chính xác.
Tuy nhiên, nếu như chức năng cả tháng hoặc nửa năm mới chạy một lần, thì phải mất vài năm thì công sức bạn bỏ ra optimize mới … hoàn vốn. Thay vì optimize nó, bạn nên bỏ thời gian đó để optimize các chức năng khác có ích hơn, được dùng nhiều hơn.
Như mình đã nói, trong 97% các trường hợp các bạn không cần quan tâm đến việc optimize code. Tuy nhiên, vẫn có một số ngoại lệ (3% còn lại) mà việc optimize code khá quan trọng:
Điều mình muốn nhắn nhủ sau bài viết là:
Performance của code cũng khá quan trọng, nhưng nó không phải là điều quan trọng nhất
Lập trình viên giỏi sẽ biết cách viết code chạy nhanh, biết cách optimize code
Lập trình viên xuất sắc sẽ biết khi nào cần phải optimize code, khi nào khôngYou need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
SUBSCRIBE TO OUR NEWSLETTER
