Quy tắc và Nghệ thuật Bảo dưỡng Xe máy: Những Lỗi Thường gặp của Người mới bắt đầu

Họ nói rằng lập trình dễ, giống như đi xe đạp vậy. Thực ra, lập trình là một chiếc xe máy, rất mạnh mẽ và nhanh. Với lập trình, cũng giống như đi xe đạp, bạn cần phải có trách nhiệm và tỉnh táo để giữ vững lập trường và tăng gấp đôi tốc độ để trở thành người chiến thắng. Thật vậy, người đi xe đạp và người viết mã đều có chung những sai lầm của người mới vào nghề: người mới thường có xu hướng tập trung vào các công cụ nhanh, mạnh mẽ và các thủ thuật sáng tạo, tin rằng chỉ riêng điều này đã định nghĩa nên một bậc thầy thực sự. Tư duy này một phần là do "hiệu ứng Dunning-Kruger", khi những người mới vào nghề không nắm bắt được sự phức tạp và tầm quan trọng của nghề nghiệp của họ. May mắn thay, với kinh nghiệm, ngay cả người mới bắt đầu nhiệt thành nhất cũng nhận ra rằng nghệ thuật lập trình không chỉ đơn thuần là lựa chọn thuật toán tối ưu. Trong bài viết này, tôi muốn chia sẻ suy nghĩ của mình về những điều thực sự quan trọng đối với một lập trình viên và những điều mà cả nhà phát triển mới và dày dạn kinh nghiệm đều nên nhớ khi tạo phần mềm và viết mã.

Khả năng đọc hơn hiệu suất, nhưng không phải lúc nào cũng vậy

Những người mới lái xe máy thường bắt đầu với điều gì? Số lượng và tiện ích. Công suất, mô-men xoắn, các bộ phận hiệu suất để cắn những mili giây lý thuyết trên một phần tư dặm… Giống như thể họ sắp vào vạch xuất phát MotoGP. Trong khi đó, nhiệm vụ chính của họ chỉ là học cách lái xe an toàn. Tương tự như vậy, các nhà phát triển mới vào nghề thường bị ám ảnh về hiệu suất mã khi không cần thiết. Các bài viết tranh luận về việc `dict()` hay `{}` hiệu quả hơn trong Python hay ưu và nhược điểm của việc sử dụng các khuôn khổ mặc dù chúng có khả năng làm giảm hiệu suất, đã thúc đẩy nỗi ám ảnh này. Mặc dù việc hiểu được sự phức tạp của ngôn ngữ lập trình của bạn là có lợi và đôi khi rất quan trọng - chẳng hạn như trong phần mềm cho máy bay, rô bốt giao dịch chứng khoán hoặc thiết bị y tế - nhưng không phải lúc nào cũng quan trọng đối với phần lớn các chương trình mà chúng ta tạo ra hàng ngày. Ngay cả khi bạn đang làm việc trên phần mềm quan trọng về hiệu suất, điều cần thiết là phải biết phần nào của mã yêu cầu hiệu suất cao và phần nào không.

Tuy nhiên, điều luôn quan trọng là khả năng đọc mã. Nhiều nghiên cứu và khảo sát xác nhận rằng các nhà phát triển dành nhiều thời gian để đọc và hiểu mã hơn là viết mã. Ví dụ, nghiên cứu "Tôi biết bạn đã làm gì vào mùa hè năm ngoái – Một cuộc điều tra về cách các nhà phát triển dành thời gian của họ" phát hiện ra rằng chỉ có 4% thời gian dành cho IDE được sử dụng để chỉnh sửa mã. Báo cáo thời gian mã toàn cầu , dựa trên khảo sát hơn 250.000 nhà phát triển, cho thấy những người trả lời chỉ dành khoảng 52 phút mỗi ngày để viết mã tích cực. Thời gian còn lại dành cho việc thảo luận và lập kế hoạch cho dự án, với khoảng 41 phút dành cho việc đọc mã trong IDE và tài liệu dự án.

Trong hầu hết các trường hợp, mục tiêu của chúng tôi là tạo ra một sản phẩm có thể bảo trì được mà không cần hỗ trợ phức tạp và sẽ phát triển mạnh trong môi trường cạnh tranh. Điều này không có nghĩa là chúng tôi có thể hoàn toàn bỏ qua hiệu suất; chúng tôi phải tìm ra sự cân bằng khi khả năng bảo trì và hiệu suất cùng tồn tại. Nếu cần mã hiệu suất cao, chúng tôi có thể tối ưu hóa các phần chậm sau khi dự án ra mắt.

Ngoài ra, hãy nhớ rằng trình biên dịch và trình thông dịch sẽ phát triển, nhưng mã của bạn vẫn giữ nguyên. Một đoạn mã ma thuật được tối ưu hóa siêu cao được viết cho một phiên bản trình biên dịch có thể trở thành một sự thất bại không liên quan đối với phiên bản khác. Thêm vào đó, các nhà phát triển trong tương lai – hoặc thậm chí là bạn – sẽ cần phải làm việc với mã đó. Vậy, khi nào chúng ta nên hy sinh khả năng đọc để đổi lấy hiệu suất?

Việc xác định thời điểm ưu tiên hiệu suất hơn khả năng đọc liên quan đến việc xác định chính xác các điểm nghẽn trong ứng dụng của bạn:

• Phân tích ứng dụng : Nếu phân tích cho thấy các phần mã quan trọng cụ thể ảnh hưởng đáng kể đến hiệu suất, việc tối ưu hóa các đoạn mã này có thể biện minh cho việc giảm khả năng đọc.

• Kiểm tra tải : Mô phỏng tải cao có thể giúp xác định các điểm nghẽn về hiệu suất trước khi chúng trở thành vấn đề thực tế.

• Phân tích phản hồi của người dùng : Thu thập phản hồi từ người dùng có thể làm nổi bật những lĩnh vực có hiệu suất kém.

• Ghi nhật ký và giám sát : Phân tích nhật ký thực thi và số liệu có thể xác định các khu vực có vấn đề trong quá trình vận hành thực tế của ứng dụng. Giai đoạn này có thể phát hiện ra các vấn đề bất ngờ, chẳng hạn như sử dụng API không đúng cách gây ra sự cố về hiệu suất.

• Công cụ phân tích mã tĩnh : Một số công cụ có thể gợi ý cải thiện hiệu suất trong quá trình đánh giá mã. Tự động chạy các công cụ này trong quá trình đánh giá tác vụ là một biện pháp tốt.

  
  

Những mẹo này có thể giúp xác định điểm yếu của ứng dụng, cho phép bạn tập trung vào các tối ưu hóa cần thiết. Dựa trên kinh nghiệm cá nhân của tôi, các tối ưu hóa này ít có khả năng liên quan đến các cấu trúc ngôn ngữ lạ và có nhiều khả năng liên quan đến việc tối ưu hóa tương tác cơ sở dữ liệu hoặc sử dụng API bên ngoài.

Việc ghi chép giúp hiểu được công việc đã thực hiện

Khi ra ngoài đường, một trong những kỹ năng an toàn quan trọng là có thể dự đoán được và cũng như vậy, đọc được ý định của người khác. Trong lập trình, giống như khi lái xe, bạn không thể trực tiếp đọc được suy nghĩ của người khác. Trên hai bánh xe, bạn phải chú ý đến những chuyển động tinh tế và dự đoán những gì người khác sẽ làm vào giây tiếp theo. Các lập trình viên sở hữu (nhưng không phải lúc nào cũng sử dụng) một công cụ mạnh mẽ để thay thế thần giao cách cảm: giấy tờ. Hầu hết các nhà phát triển đều đồng ý rằng tài liệu là rất quan trọng đối với một dự án, bằng chứng là các cuộc khảo sát như Khảo sát nhà phát triển Stack Overflow 2023 , nơi 90,36% người trả lời sử dụng tài liệu kỹ thuật thường xuyên. Tuy nhiên, họ thường không thể tìm thấy tất cả các câu trả lời ở đó, thay vào đó chuyển sang Stack Overflow (82,56%) và nhiều blog khác nhau (76,69%). Một nghiên cứu khác, Microsoft Research: Cuộc sống hàng ngày của các nhà phát triển phần mềm cho thấy các nhà phát triển dành 1-2% thời gian trong ngày cho công việc lập tài liệu, trong đó 10,3% số người được hỏi mất nhiều thời gian do giấy tờ kém chất lượng hoặc lỗi thời.

Tài liệu có thể có nhiều dạng, từ mô tả chi tiết về dự án trong các hệ thống như Confluence đến các bình luận về mã và các trang web mô tả dự án được tạo tự động hoặc bán tự động. Nó thậm chí có thể đơn giản như một tệp README trong thư mục gốc của dự án. Bất kể định dạng nào, quá trình tạo tài liệu không chỉ đơn thuần là truyền đạt thông tin về cách sản phẩm hoạt động. Quá trình này khiến chúng ta phải suy nghĩ lại về những gì mình đã làm , điều này thường có thể dẫn đến những cải tiến trong API và kiến trúc tổng thể. Tôi thường nhận ra rằng, trong khi ghi lại tài liệu về chức năng mà tôi đã tạo, có thể khó để làm việc với nó và tôi đã tìm ra cách để khắc phục điều đó.

Điều quan trọng cần nhớ là việc duy trì tài liệu luôn đòi hỏi nỗ lực đáng kể, đặc biệt là nếu dự án đang trong giai đoạn thường xuyên thay đổi. Trong những trường hợp như vậy, bạn nên cân nhắc mọi rủi ro và cân nhắc cẩn thận logic nào cần ghi lại. Nếu dự án của bạn đã đạt đến trạng thái trưởng thành, tài liệu tốt sẽ mang lại nhiều lợi ích hơn là thách thức: các nhà phát triển mới có thể tham gia và đạt được động lực nhanh hơn, trong khi những nhân viên lâu năm có thể nhanh chóng tìm ra cách thức hoạt động của một số tính năng nhất định. Ngoài ra, tài liệu có chức năng tìm kiếm tốt trong một dự án lớn với nhiều nhóm có thể ngăn ngừa việc trùng lặp tính năng.

Nói với người khác những gì bạn đang làm không phải là điều đáng xấu hổ

Sử dụng đèn báo rẽ là hình thức cơ bản nhất để trở thành một người lái xe có thể đoán trước. Tương tự như vậy, chú thích mã có lẽ là cách dễ nhất và trực tiếp nhất để cho người khác biết bạn đang làm gì. Và, giống như khi sử dụng đèn báo rẽ, nó không khiến bạn kém ngầu hơn. Tôi biết, có một niềm tin phổ biến rằng chú thích là không cần thiết vì mã phải tự giải thích. Nhưng, không, tôi không hoàn toàn đồng ý với điều đó. Mã chất lượng thường có thể được hiểu một cách trực quan nhờ tên biến và hàm tốt, cấu trúc rõ ràng và tuân thủ các nguyên tắc mã sạch. Tuy nhiên, ngay cả trong những trường hợp như vậy, các chú thích được cân nhắc kỹ lưỡng có thể cung cấp thông tin vô giá.

Bình luận đóng vai trò quan trọng khi nói đến các thuật toán hoặc giải pháp phức tạp đòi hỏi bối cảnh bổ sung để hiểu. Chúng có thể giải thích "lý do" đằng sau một cách tiếp cận, điều này không phải lúc nào cũng dễ thấy từ chính mã. Điều này đặc biệt quan trọng khi mã được tối ưu hóa cho hiệu suất, nhưng ý định và logic của nó không rõ ràng ngay lập tức. Bình luận cũng có thể giúp xem xét lại liệu thuật toán đã chọn có đang đi đúng hướng hay không.

Bình luận là cứu cánh trong logic kinh doanh phức tạp hoặc các yêu cầu cụ thể của dự án, có thể không rõ ràng đối với các thành viên nhóm mới hoặc trong trường hợp hỗ trợ dự án dài hạn. Chúng giúp duy trì kiến thức trong nhóm và giúp chuyển giao dự án giữa các nhà phát triển dễ dàng hơn.

Tất nhiên, điều quan trọng là tránh bình luận quá mức khi bình luận nêu rõ điều hiển nhiên hoặc trở nên lỗi thời và gây hiểu lầm. Mục đích của chúng là đảm bảo tính rõ ràng và hỗ trợ việc hiểu mã, không phải là làm lộn xộn mã bằng thông tin không cần thiết.

Kiểm thử: một công cụ để hiểu và xác minh mã

Được rồi, giờ hãy tưởng tượng chúng ta cuối cùng đã học được cách lái xe và giờ chúng ta muốn thử vận may trên đường đua thực sự. Vâng, chúng ta sẽ sớm nhận ra rằng đua xe thực sự không chỉ là khả năng "đạp hết ga". Nó bao gồm việc luyện tập, thử nghiệm và tinh chỉnh máy của bạn để phù hợp với thói quen và điều kiện đua xe của bạn. Tương tự như vậy đối với mã: nó phải được thử nghiệm, kiểm tra và sửa lỗi kỹ lưỡng nếu cần trước khi có thể chạy thử thực sự. Vì vậy, việc tiếp cận thử nghiệm mã với trách nhiệm tối đa là rất quan trọng. Các thử nghiệm thường chỉ được coi là một công cụ tìm lỗi, nhưng vai trò của chúng rộng hơn:

• Phát hiện lỗi và khuyết điểm : Kiểm thử xác định lỗi và hành vi không lường trước trước khi sản phẩm đến tay người dùng, nâng cao chất lượng và giảm các vấn đề của người dùng.
• Hiểu biết về mã : Việc tạo các tình huống thử nghiệm đòi hỏi phải hiểu biết sâu sắc về cấu trúc và chức năng của mã, giúp hiểu rõ hơn về logic và tương tác của chương trình.
• Phụ lục tài liệu : Các bài kiểm tra có thể đóng vai trò là ví dụ sử dụng cho các hàm và phương pháp, giúp tìm thông tin về chức năng của dự án và hỗ trợ các chuyên gia mới bằng cách cung cấp các trường hợp sử dụng thực tế.

Kiểm thử hiệu quả là rất quan trọng để tạo ra mã chất lượng cao, đáng tin cậy và dễ hiểu. Tuy nhiên, giống như tài liệu, kiểm thử có thể tốn nhiều tài nguyên, đặc biệt là trong giai đoạn đầu của dự án. Cân bằng giữa tính cần thiết của việc kiểm thử với các hạn chế về thời gian và tài nguyên là điều cần thiết.

Rõ ràng là phạm vi kiểm thử tuyệt đối cho mã phức tạp là không thể đạt được. Do đó, các nhà phát triển phải ưu tiên kiểm thử các chức năng chính và các phần mã quan trọng, biết khi nào nên dừng lại để tránh chu kỳ kiểm thử vô tận.

Yêu mã của bạn như bạn yêu bạn bè của mình và chăm sóc nó

Cuối cùng, không có xe máy nào có thể đáng tin cậy nếu không được bảo dưỡng đúng cách. Có khá nhiều người bỏ qua khía cạnh này của việc lái xe, nhưng họ lại tạo ra những câu chuyện (từ buồn cười đến đáng sợ đến buồn) mà chúng ta chắc chắn không muốn tham gia. Trong thế giới lập trình, giống như trong xe máy, bảo trì mã không chỉ là một khuyến nghị mà là một điều cần thiết, đặc biệt là đối với các dự án dài hạn. Việc thiếu bảo trì và cập nhật dẫn đến lỗi thời sản phẩm và lỗ hổng bảo mật.

Khi mã không được cập nhật để tương thích với trình biên dịch và trình thông dịch mới nhất, việc cập nhật có thể (và thực tế sẽ) trở nên ngày càng khó khăn. Sản phẩm của bạn có thể ngừng hoạt động với các phiên bản hệ điều hành mới nếu bạn đang phát triển ứng dụng dành cho máy tính để bàn hoặc thiết bị di động. Đối với trang web, nó có thể ngừng hoạt động do các công cụ và công nghệ lỗi thời. Vấn đề đơn giản nhất có thể là chứng chỉ bảo mật đã hết hạn hoặc phần mềm lỗi thời để gia hạn.

Các bản cập nhật và tái cấu trúc thường xuyên cũng rất quan trọng để duy trì khả năng đọc mã. Điều này giúp dự án dễ quản lý, đơn giản hóa các thay đổi trong tương lai và bổ sung tính năng.

Tóm lại, hãy yêu code của bạn và dành thời gian cho nó – nhưng đừng quá mức, nếu không bạn sẽ có kết cục giống như nhân vật chính trong "Định lý số 0". Chúc may mắn!