11 Nguyên tắc cho mọi lập trình viên bạn không thể bỏ qua
Trong cuộc sống, việc tự đặt ra cho mình những nguyên tắc sẽ làm cho chúng ta sống và làm việc tốt hơn vì đó là cách để chúng ta đảm bảo các công việc được tiến hành theo kế hoạch và theo một chuẩn mực nhất định. Đối với nghề nghiệp nào cũng vậy, mỗi người nên tự xây dựng cho mình một bộ quy tắc để lấy đó làm chuẩn mực cho cuộc sống và công việc. Dưới đây là 11 nguyên tắc cho mọi lập trình viên:
1. Công nghệ là cách bạn tìm ra giải pháp, không phải là giải pháp
Bạn thực sự có được framework JavaScript, Angular IoC container, ngôn ngữ lập trình và thậm chí là cả hệ điều hành mới nhất, nhưng tất cả những thứ này không thực sự là giải pháp cho các vấn đề mà bạn đang gặp phải, đó chỉ là công cụ để bạn giải quyết vấn đề.
Bạn phải rất cẩn thận để không quá phụ thuộc vào một công nghệ cụ thể nào đó, nếu không bạn sẽ có nguy cơ nhìn nhận mọi vấn đề một cách phiến diện mà quên mất mọi thứ đều cần cái nhìn toàn diện. (lời gốc của tác giả: “lest we run the risk of thinking about every problem as a nail, just because we happen to be holding a shiny hammer we just learned about”)
2. Thông minh là kẻ thù của sự rõ ràng
Khi viết code, bạn nên viết sao cho rõ ràng và dễ hiểu. Code rõ ràng và truyền đạt đúng mục đích của nó sẽ có giá trị hơn những code tối nghĩa – không quan trọng việc code đó thông minh đến thế nào.
Điều này không phải lúc nào cũng đúng, nhưng nhìn chung, thông minh là kẻ thù của sự rõ ràng. Nhiều khi bạn viết code trông có vẻ “thông minh” nhưng nó lại không thực sự rõ ràng. Điều quan trọng là chúng ta phải nhớ đến nguyên tắc này bất cứ khi nào bạn nghĩ bạn đang làm một việc gì đó đặc biệt thông minh.
Đôi khi bạn có thể viết được code vừa thông minh vừa rõ ràng, nhưng điều đó rất hiếm khi xảy ra. Nếu bạn quan tâm đến việc viết một code sạch, bạn nên đọc cuốn sách The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin).
3. Chỉ viết code nếu bạn buộc phải viết
Điều này có vẻ hơi mâu thuẫn, không phải công việc của lập trình viên là viết code hay sao?
Đúng vậy, công việc của lập trình viên liên quan đến việc viết code. Nhưng bạn hãy cố gắng viết ít code nhất có thể để giải quyết những vấn đề mà bạn đang gặp phải.
Điều này không có nghĩa là bạn phải làm cho code của mình nhỏ gọn nhất có thể và đặt tên cho các biến của mình bằng các chữ cái trong bảng chữ cái. Sẽ là ý nghĩ hơn nếu bạn chỉ viết code khi thực sự cần để thực hiện chức năng được yêu cầu.
Thường thì bạn hay bị cám dỗ để thêm tất cả các loại tính năng vào code của mình hoặc làm cho code của bạn “mạnh mẽ” và “linh hoạt” hơn để có thể xử lý các tình huống khác nhau. Nhưng đa phần chúng ta đều sai khi tiên đoán về những tính năng hữu ích hoặc sai khi lường trước những vấn đề chúng ta nghĩ sẽ gặp phải trong tương lai.
Phần code mà chúng ta viết thêm để lường trước những tình huống tương lai có thể không bổ sung thêm chút giá trị nào, nhưng nó vẫn có thể gây ra rất nhiều tác hại. Viết càng nhiều code thì càng nhiều rủi ro dính phải lỗi và phần code đó cũng phải mất công duy trì theo thời gian.
Các kỹ sư phần mềm giỏi không viết code trừ khi điều đó là hoàn toàn cần thiết. Các kỹ sư phần mềm vĩ đại thường xóa nhiều code nhất có thể.
4. Comment trong code đa phần là không tốt
Bob Martin từng nói: “Mỗi khi bạn viết một comment trong code, bạn nên nhăn mặt và cảm thấy sự thất bại trong khả năng diễn đạt của mình”.
Điều này không có nghĩa là bạn không bao giờ nên viết comment trong code, nhưng với hầu hết các trường hợp việc comment có thể tránh được bằng cách đặt tên biến và hàm của mình sao cho chúng có ý nghĩa diễn đạt tốt hơn.
Nhìn chung, comment không phải là có hại vì trong nhiều trường hợp chúng rất cần thiết, nhưng nhiều khi chúng lại không miêu tả đúng chức năng của dòng code. Thậm chí, các comment này còn có thể lái bạn đi theo một hướng hoàn toàn sai lệch.
5. Luôn biết code của bạn thực hiện chức năng gì trước khi bạn bắt đầu viết chúng
Đã bao lần bạn ngồi xuống viết code mà không hiểu thấu đáo code của bạn sẽ thực hiện chức năng gì?
Phương pháp Test Driven Development (TDD) có thể hữu ích trong trường hợp này, bởi vì bạn phải biết phần code đó sẽ làm gì trước khi bạn viết ra đó, nhưng phương pháp này cũng không thể ngăn cản bạn tạo ra những lỗi sai. Do đó, điều quan trọng là bạn phải hiểu 100% các yêu cầu về tính năng và chức năng mà bạn đang xây dựng trước khi bắt tay vào viết code.
6. Kiểm tra lại code trước khi bàn giao
Đừng đưa code của bạn cho nhóm Tester ngay khi bạn vừa viết xong, bởi vì người ta sẽ trả lại cho bạn hàng đống những lỗi, và bạn sẽ làm mất thời gian của chính mình cũng như của tất cả mọi người trong việc tạo ra các bug report và resolution không cần thiết. Thay vào đó, dành ra vài phút để test thử code của mình trước khi đưa chúng cho nhóm Tester. Chắc chắn bạn không thể bắt được tất cả các lỗi, nhưng ít ra bạn cũng bắt được những lỗi ngớ ngẩn cứ lặp đi lặp lại hết lần này đến lần khác.
Quá nhiều lập trình viên nghĩ rằng đó là trách nhiệm của nhóm Tester. Nhưng điều đó hoàn toàn không đúng. Việc đảm bảo chất lượng là trách nhiệm của tất cả mọi người!
7. Học kiến thức mới mỗi ngày
Nếu bạn không học được những kiến thức mới mỗi ngày thì bạn đang bị thụt lùi lại phía sau bởi vì chắc chắn bạn sẽ quên một số kiến thức trong khi công nghệ thay đổi mỗi ngày.
Sẽ không mất quá nhiều thời gian để tìm hiểu kiến thức mới mỗi ngày. Hãy cố gắng dành ra 15 phút hoặc lâu hơn để đọc một cuốn sách. Những tiến bộ ít ỏi mà bạn tích lũy mỗi ngày theo thời gian sẽ tạo cho bạn nhiều cơ hội trong tương lai. Tuy nhiên, bạn phải bắt đầu ngay từ bây giờ nếu muốn gặt hái những phần thưởng xứng đáng.
Bên cạnh đó, công nghệ đang thay đổi chóng mặt, nếu bạn không ngừng nâng cao kĩ năng của mình và học hỏi kiến thức mới thì bạn sẽ bị bỏ lại phía sau.
8. Lập trình là niềm vui
Đúng thế! Bạn có thể đã không quyết định đi theo ngành này chỉ bởi vì nó có mức lương rất tốt. Tất nhiên là, không có gì sai trong việc lựa chọn những công việc được trả lương cao cả. Nhiều khả năng bạn trở thành một nhà phát triển phần mềm, bởi vì bạn thích viết code. Vì vậy, đừng quên rằng bạn đang được làm những thứ mình yêu thích. Viết code mang lại rất nhiều niềm vui.
Nếu bạn quên mất việc viết code vui như thế nào thì đây là lúc bạn nên nhớ lại niềm vui bạn đã từng có, bằng cách bắt đầu với một dự án phụ, hoặc chỉ cần thay đổi tư duy và nhận ra rằng bạn có thể viết code tốt hơn và được trả tiền cho công việc đó. Động lực là tự quản, bạn hãy tự mình tạo ra động lực cho chính mình.
9. Bạn không thể biết tất cả mọi thứ
Một điều thú vị là, bạn càng học nhiều thì bạn sẽ phát hiện ra rằng vẫn còn có rất nhiều thứ mà mình không biết. Quan trọng là phải nhận ra điều này bởi vì bạn có thể đang cố gắng để biết tất cả mọi thứ.
Cũng là OK thôi nếu bạn không có được tất cả những câu trả lời. Cũng là chuyện bình thường khi yêu cầu giúp đỡ hoặc hỏi người khác khi bạn không hiểu điều gì đó. Hãy đừng cố gắng để tìm hiểu tất cả mọi thứ, đó là một nhiệm vụ bất khả thi. Thay vào đó, hãy tập trung vào học cái bạn cần biết và xây dựng các kỹ năng giúp bạn có thể tìm hiểu mọi thứ một cách nhanh chóng.
10. Phương pháp thực hiện tốt nhất (best practice) còn phụ thuộc vào từng tình huống
Liệu Test-Driven Development (TDD) có phải là phương pháp tốt nhất để viết code? Liệu chúng ta có nên luôn luôn áp dụng lập trình cặp (pair programming)? Bạn có cảm thấy mình kém cỏi nếu không sử dụng IoC containers?
Câu trả lời cho tất cả những câu hỏi này là “còn tùy”. Nó tùy thuộc vào ngữ cảnh.
Người ta sẽ cố gắng áp đặt best practices vào bạn và nói với bạn rằng họ luôn áp dụng chúng – rằng bạn cũng nên làm theo như họ – nhưng, điều đó chỉ đơn giản là không đúng sự thật. Nguyên tắc là mãi mãi, còn best practices sẽ tùy thuộc vào tình huống cụ thể
11. Luôn hướng đến sự đơn giản
Tất cả các vấn đề đều có thể được chia nhỏ để giải quyết. Các giải pháp tuyệt vời nhất thường là những cái đơn giản nhất. Nhưng đơn giản không đến một cách dễ dàng. Bạn phải làm việc cật lực mới khiến mọi thứ trở nên đơn giản. Hãy dành thời gian, nỗ lực thật nhiều và phấn đấu cho sự đơn giản.
Trên đây là 11 nguyên tắc khá thiết thực và gần gũi với công việc lập trình, cũng như giải quyết những vấn đề cơ bản mà một lập trình viên hay gặp phải trong công việc của họ.
