Tôi là một người có xu hướng sống theo nguyên tắc. Thực ra chúng chủ yếu là những nguyên tắc mà tôi đặt ra cho bản thân mình, nhưng đó vẫn là những nguyên tắc. Tôi thấy rằng việc tạo ra các nguyên tắc cho bản thân mình giúp tôi sống và làm việc tốt hơn, bởi vì tôi đã quyết định trước được những việc mình cần phải làm thay vì cứ đến đâu hay đó.
Ví dụ, sáng nay tôi có nên đến phòng tập gym (thể dục) hay không ư? Vâng, nguyên tắc của tôi nói rằng vào Thứ Tư tôi phải đi đến phòng tập gym và hôm nay là Thứ Tư, vì vậy tôi sẽ đến phòng tập gym, đó là điều chắc chắn.
Tuần này, tôi đang suy nghĩ về một số loại nguyên tắc mà tôi áp đặt cho bản thân mình, tôi nghĩ rằng nó có thể là một ý tưởng tốt để tạo ra một bộ quy tắc mà tôi nghĩ rằng tất cả các nhà phát triển phần mềm nên áp dụng trong công việc và cuộc sống.
Bây giờ, tôi sẽ phải thừa nhận rằng, hầu hết các nguyên tắc này là các hướng dẫn, và tôi sẽ liệt kê ra dưới đây:
1. Công nghệ là cách bạn tìm ra giải pháp, nó không phải là giải pháp
Chúng ta có thể thực sự có được framework JavaScript mới nhất – a hèm, Angular – IoC container, ngôn ngữ lập trình hay thậm chí là hệ điều hành, 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 đề chúng ta đang cố gắng giải quyết với tư cách là lập trình viên, thay vào đó chúng chỉ đơn giản là các công cụ giúp chúng ta giải quyết các vấn đề.
Chúng ta phải rất cẩn thận để không quá cực đoan về một công nghệ cụ thể mà chúng ta thích hoặc nó đang phổ biến hiện nay, nếu không chúng ta sẽ có nguy cơ suy nghĩ tất cả các vấn đề giống như một cái đinh, chỉ bởi vì chúng ta đang nắm một cái búa sáng bóng mà chúng ta cũng chỉ vừa mới tìm hiểu về nó.
2. Thông minh là kẻ thù của sự rõ ràng
Khi viết code, chúng ta nên cố gắng viết code sao cho rõ ràng và dễ hiểu. Code rõ ràng truyền đạt mục đích của nó giá trị hơn nhiều so với code tối nghĩa – không quan trọng về việc nó có thông minh như thế nào.
Điều này không phải lúc nào cũng đúng, nhưng nói chung, thông minh là kẻ thù của sự rõ ràng. Nhiều khi chúng ta viết code trông có vẻ “thông minh”, nhưng phần code đó lại không phải là đặc biệt rõ ràng. Điều quan trọng là chúng ta phải nhớ đến quy tắc này bất cứ khi nào chúng ta nghĩ rằng mình đang làm một cái gì đó đặc biệt thông minh.
Đôi khi chúng ta viết code vừa thông minh mà cũng rõ ràng, nhưng thường thì điều đó hiếm khi xảy ra. Nếu bạn quan tâm đến việc viết code sạch thì tôi khuyên 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 bắt buộc phải viết
Điều này mới đọc lên có vẻ hơi mâu thuẫn, sau tất cả, không phải công việc của các lập trình viên chúng ta là viết code ư?
Vâng, thực ra câu trả lời cho câu hỏi trên là vừa “có” và “không”.
Công việc của chúng ta có thể liên quan đến việc viết code, nhưng chúng ta vẫn cần phải cố gắng viết ít code nhất có thể để giải quyết vấn đề mà chúng ta đang gặp phải.
Điều này không có nghĩa là chúng ta nên làm cho code của mình nhỏ gọn nhiều nhất có thể và đặt tên cho tất cả các biến của mình bằng cách sử dụng các chữ trong bảng chữ cái. Mà nó có nghĩa là chúng ta nên cố gắng chỉ viết code khi thực sự cần thiết để 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 chúng ta “mạnh mẽ” và “linh hoạt” để nó có thể xử lý tất cả các tình huống khác nhau. Nhưng đa phần chúng ta đều sai khi cố gắng đoán về những tính năng hữu ích hoặc lường trước những vấn đề mà chúng ta nghĩ sẽ có thể 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
Tôi không phải là một fan hâm mộ lớn của việc viết comment trong code. Tôi cũng đồng tình với Bob Martin, khi ô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 về khả năng diễn đạt của mình.”
– Clean Code: A Handbook of Agile Software Craftmanship
Đ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 đối với hầu hết các trường hợp chúng đều có thể tránh được và thay vào đó bạn có thể tập trung cải thiện việc đặt tên các biến và hàm của mình để nó có thể diễn đạt ý nghĩa tốt hơn.
Comment nên chỉ thực sự được viết khi bạn không thể truyền đạt rõ ràng ý định của một biến hoặc phương thức qua tên của chúng. Các comment phục vụ cho những phần code không dễ dàng để tự biểu đạt mục đích của nó.
Ví dụ, một comment có thể cho bạn biết về một vài hoạt động kỳ lạ diễn ra trong code nhưng không phải là một lỗi, mà đó là chủ ý của người viết code.
Nhìn chung, comment không chỉ là có hại bởi vì trong nhiều trường hợp chúng là rất cần thiết, nhưng nhiều khi chúng lại không miêu tả đúng những gì phần code đi kèm với nó đang thực hiện.
Comment mà không được cập nhật với phần code đi kèm thì kết quả là các comment này trở nên thực sự nguy hiểm, bởi vì chúng rất có thể sẽ lái bạn đi theo một hướng hoàn toàn sai.
Bạn có thường kiểm tra tất cả các comment so với phần code để đảm bảo phần code đó đang thực sự làm những gì các comment nói? Nếu vậy, mục đích của việc có những comment đó là gì? Nếu không, làm thế nào bạn có thể tin tưởng rằng những comment đó là đang nói đúng sự thật?
Đó là con dao hai lưỡi, vì vậy tốt nhất bạn nên tránh sử dụng nó càng nhiều càng tốt.
Nếu bạn không đồng tình với quan điểm của tôi, thì hãy để lại “comment” của bạn trong phần bình luận phía dưới bài viết, nhưng tôi sẽ không thay đổi lập trường của mình đâu.
5. Luôn biết code của bạn phải làm gì trước khi bạn bắt đầu viết nó
Điều này trông có vẻ hiển nhiên, nhưng thực ra nó không phải như vậy.
Đã bao nhiêu lần bạn ngồi xuống viết code mà không có sự hiểu biết thấu đáo về những gì mà code bạn đang viết thực sự phải làm?
Tôi phải thừa nhận rằng bản thân mình cũng đã rơi vào tình huống này rất nhiều lần, vì vậy đây là một nguyên tắc mà tôi cần phải đọc lại thường xuyên.
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 nó, nhưng nó vẫn không ngăn cản bạn tạo ra những điều sai, do đó điều quan trọng là bạn phải hoàn toàn hiểu được 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 thực hiện nó.
6. Kiểm tra lại code của bạn trước khi bàn giao nó
Đừng ném 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ẽ gửi lại cho bạn hàng mớ lỗi, và bạn sẽ làm mất thời gian của chính mình lẫn 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 đó, hãy dành ra vài phút để chạy thử các kịch bản test của mình, trước khi bạn cho rằng mình đã hoàn thành công việc.
Chắc chắn là bạn sẽ không bắt được tất cả các lỗi trước khi chuyển công việc của mình tới nhóm Tester, nhưng ít ra thì bạn cũng bắt được một số những sai lầm ngớ ngẩn và đáng xấu hổ 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 đó chỉ là công việc của nhóm Tester với những công cụ của họ. Nhưng điều đó hoàn toàn không đúng. Việc đảm bảo chất lượng sản phẩm 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ì thực ra bạn đang bị thụt lùi lại phía sau, bởi vì tôi chắc rằng bạn sẽ quên một số kiến thức trong khi công nghệ thì 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 chỉ là 15 phút hoặc lâu hơn để đọc một cuốn sách, tôi đã đọc rất nhiều sách vào năm ngoái, trung bình mỗi ngày tôi dành ra 45 phút để đọc.
Những tiến bộ dù ít ỏi mà bạn thực hiện mỗi ngày theo thời gian sẽ tạo ra cho bạn rất nhiều cơ hội tuyệt vờ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ệ ngày nay đang thay đổi như vũ bão, nếu bạn không ngừng nâng cao kỹ năng của mình và học hỏi những điều mới thì bạn sẽ bị bỏ lại phía sau rất nhanh chóng.
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ôi 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ả, nghề bác sĩ hay luật sư sẽ có thể là một lựa chọn tốt hơn.
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. Tôi ước gì mình có thật nhiều thời gian để ngồi viết code.
Tôi thường quá bận rộn để duy trì công việc kinh doanh của mình mà bớt đi khoảng thời gian dành cho việc viết code mỗi ngày, đó là một trong những lý do tại sao tôi nhớ rất rõ về những niềm vui bất tận mà công việc viết code mang lại.
Có lẽ bạn đã quên mất rằng việc viết code vui như thế nào. Có lẽ đây là lúc bạn nên nhớ lại những niềm vui mà bạn đã có được, bằng cách bắt đầu một dự án phụ (side project) 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à thậm chí được trả tiền cho công việc đó.
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 để yêu cầu giúp đỡ hoặc hỏi người khác khi bạn không hiểu điều gì đó.
Trong nhiều trường hợp, bạn có thể tìm hiểu về những gì bạn cần biết vào thời điểm khi bạn cần phải biết về nó – tin tôi đi, tôi đã làm điều đó rất nhiều lần rồi.
Quan điểm của tôi là, 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 đẩy best practices xuống cổ họng của 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.
Tôi đã làm theo rất nhiều các best practice khi viết code, nhưng tôi cũng đặt ra những điều kiện để biết lúc nào thì nên áp dụng và lúc nào thì không. 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.
Mục đích của blog này là biến những vấn đề phức tạp trong phát triển phần mềm và cuộc sống nói chung trở nên đơn giản hơn.
Tin tôi đi, đây không phải là một nhiệm vụ dễ dàng. Bất kỳ thằng ngốc nào cũng có thể tạo ra một giải pháp phức tạp cho một vấn đề nào đó. Phải cần có thêm nhiều nỗ lực và quyết tâm tinh chỉnh giải pháp để làm cho nó đơn giản hơn. Hãy dành thời gian, nỗ lực thật nhiều và phấn đấu cho sự đơn giản.
Bạn đang sống với những nguyên tắc nào?
Vâng, ở trên đây là những nguyên tắc của tôi, thế còn nguyên tắc của bạn là gì?
Những nguyên tắc nào mà cá nhân bạn luôn sống với nó? Bạn có nghĩ là nó quan trọng để ghi nhớ mỗi ngày và luyện tập thành thói quen?
Hãy chia sẻ những nguyên tắc của bạn trong phần bình luận phía dưới nhé!
