Tại sao chúng ta cần document (ghi chép lại) cẩn thận về chương trình mình đã viết?
Truyền cảm hứng từ bài viết này trong blog Coding Horror của Jeff Antwood.
Bởi vì chính chúng ta, người viết ra chương trình, sẽ quên ý nghĩa của những dòng lệnh, thuật toán hay một mẹo nhỏ mình đã sử dụng cho chương trình đó. Và điều đó sẽ trở thành một nỗi đáng sợ kinh hoàng khi bạn phải sửa đổi (maintain) lại chương trình đó. Và điều này là rất thường xuyên trong vòng đời của sản phẩm phần mềm.
Bản thân mình đang làm việc với hệ thống SAP, phần mềm doanh nghiệp ổn định nhất hiện nay. Nhưng có thể là không thể nào tránh khỏi lỗi hay phải maintain lại code cũ. Và nhờ có thể document cũng như Note (dạng document ghi lại thay đổi trong code của SAP), và quy cách (policy) thay đổi code cực kì chặt chẽ của SAP, mà việc đọc lại code đã dễ dàng hơn. Tuy nhiên nó vẫn là một công việc rất đau đầu với hầu hết developer.
Vậy là thế nào để viết một đoạn code sạch (clean code)? Một đoạn không những đáp ứng yêu cầu, mà phải đảm bảo ít lỗi và dễ sửa đổi sau này.
Đó là một khoa học mà chắc hẳn bộ môn khoa học máy tính và nhiều lập trình viên đã nghiên cứu trong vòng mấy chục năm qua. Chúng ta may mắn khi là hậu bối và có thể học hỏi từ tiền bối đi trước. Tuy nhiên việc học hỏi là không dễ dàng và đòi hỏi nỗ lực của mỗi người rất nhiều. Đó là bạn vài dành nhiều thời gian nghiên cứu về cách lập trình, và mở rộng ra là cách làm việc; đầu tư nhiên hơn để rèn luyện kĩ năng và mua sách để gia tăng kiến thức (tốn cũng kha khá tiền đấy). Kết quả sẽ đến từ từ chứ không chỉ ngày một ngày hai mà có thể khá lên ngay được. Tuy nhiên, tương lai bạn sẽ tự tin hơn với giá trị của mình và có thể đứng vững mà ít phụ thuộc vào sếp của mình, không phải răm rắp nghe theo sếp vì sợ đuổi việc.
Luôn ghi nhớ một điều, kĩ năng bạn có càng khó thì bạn càng có giá trị; còn ngược lại thì bạn hoàn toàn có thể bị thay thế bởi một người khác với giá rẻ hơn:
---V---
p/s: Sau khi đọc nhiều comment trong blog của Jeff ở đâu bài, có một comment khiến mình đồng ý đó là: dường như các kĩ sư phần mềm quá phân biệt rõ ràng giữa "lập trình viên dở" (mort) và "lập trình viên tốt" (Einstein). Và sự phân biệt được đôi khi trở nên rất cực đoan đối với một số người (như chủ blog - Jeff), khi cho rằng 80% lập trình viên là Mort, chỉ có thể dùng tool có sẵn để viết những chương trình ẩn chứa nhiều lỗi.
Với mình và nhiều người thuộc ngành khác, đây rõ ràng là một thái độ không "tích cực" lắm. Vì không phải ai cũng giỏi, nên sẽ có cấp bậc trong công việc. Không thể đòi hỏi một người IQ thấp lại có thể viết một chương trình tối ưu, gọn gàng như một chuyên gia được.
Đó là thực tế mà xét về mặt nhân sự ta phải chấp nhận, và tìm công việc phù hợp với sở trường của từng người, vì mỗi người sẽ có điểm mạnh riêng.
Có lẽ Jeff, và nhiều lập trình viên khác, nên ra ngoài, tiếp xúc nhiều hơn để hiểu rõ hơn về con người và những cách giải quyết thực tế phù hợp; thay vì phán xét trình độ người khác và ra kết luận trên những nhận định đó.
Bởi vì chính chúng ta, người viết ra chương trình, sẽ quên ý nghĩa của những dòng lệnh, thuật toán hay một mẹo nhỏ mình đã sử dụng cho chương trình đó. Và điều đó sẽ trở thành một nỗi đáng sợ kinh hoàng khi bạn phải sửa đổi (maintain) lại chương trình đó. Và điều này là rất thường xuyên trong vòng đời của sản phẩm phần mềm.
Vậy là thế nào để viết một đoạn code sạch (clean code)? Một đoạn không những đáp ứng yêu cầu, mà phải đảm bảo ít lỗi và dễ sửa đổi sau này.
Đó là một khoa học mà chắc hẳn bộ môn khoa học máy tính và nhiều lập trình viên đã nghiên cứu trong vòng mấy chục năm qua. Chúng ta may mắn khi là hậu bối và có thể học hỏi từ tiền bối đi trước. Tuy nhiên việc học hỏi là không dễ dàng và đòi hỏi nỗ lực của mỗi người rất nhiều. Đó là bạn vài dành nhiều thời gian nghiên cứu về cách lập trình, và mở rộng ra là cách làm việc; đầu tư nhiên hơn để rèn luyện kĩ năng và mua sách để gia tăng kiến thức (tốn cũng kha khá tiền đấy). Kết quả sẽ đến từ từ chứ không chỉ ngày một ngày hai mà có thể khá lên ngay được. Tuy nhiên, tương lai bạn sẽ tự tin hơn với giá trị của mình và có thể đứng vững mà ít phụ thuộc vào sếp của mình, không phải răm rắp nghe theo sếp vì sợ đuổi việc.
Luôn ghi nhớ một điều, kĩ năng bạn có càng khó thì bạn càng có giá trị; còn ngược lại thì bạn hoàn toàn có thể bị thay thế bởi một người khác với giá rẻ hơn:
---V---
p/s: Sau khi đọc nhiều comment trong blog của Jeff ở đâu bài, có một comment khiến mình đồng ý đó là: dường như các kĩ sư phần mềm quá phân biệt rõ ràng giữa "lập trình viên dở" (mort) và "lập trình viên tốt" (Einstein). Và sự phân biệt được đôi khi trở nên rất cực đoan đối với một số người (như chủ blog - Jeff), khi cho rằng 80% lập trình viên là Mort, chỉ có thể dùng tool có sẵn để viết những chương trình ẩn chứa nhiều lỗi.
Với mình và nhiều người thuộc ngành khác, đây rõ ràng là một thái độ không "tích cực" lắm. Vì không phải ai cũng giỏi, nên sẽ có cấp bậc trong công việc. Không thể đòi hỏi một người IQ thấp lại có thể viết một chương trình tối ưu, gọn gàng như một chuyên gia được.
Đó là thực tế mà xét về mặt nhân sự ta phải chấp nhận, và tìm công việc phù hợp với sở trường của từng người, vì mỗi người sẽ có điểm mạnh riêng.
Có lẽ Jeff, và nhiều lập trình viên khác, nên ra ngoài, tiếp xúc nhiều hơn để hiểu rõ hơn về con người và những cách giải quyết thực tế phù hợp; thay vì phán xét trình độ người khác và ra kết luận trên những nhận định đó.
Nhận xét
Đăng nhận xét