Tôi là một người có xu hướng sống theo những nguyên tắc. Hiện giờ vẫn vậy, 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à quy tắc, ít nhất là của riêng tôi.
Tôi nhận thấy việc tự mình tạo ra những nguyên tắc cho bản thân giúp tôi sống và làm việc tốt hơn bởi trước khi quyết định một điều gì đó tôi đều dành thời gian suy nghĩ việc mình cần phải làm thay vì cứ đến đâu hay đến đó.
Chẳng hạn như sáng nay tôi có nên đi đến phòng tập Gym 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 và ngày 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ố nguyên tắc đặt ra 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ấ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.
Tôi thừa nhận rằng, hầu hết các nguyên tắc lập trình 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, chứ không phải giải pháp
Chúng ta có thể thực sự có được framework JavaScript hot nhất như 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 đề; bởi chúng ta đang cố gắng giải quyết với tư cách là một 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 đề mà chúng ta đang gặp phải mà thôi.
Chúng ta phải thật cẩn thận để không quá cực đoan về một công nghệ cụ thể nào đó 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ả mọi vấn đề giống như một cái đinh, chỉ bởi 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
Có bao giờ bạn từng gặp trường hợp thế này: Có một chức năng cần sửa, hoặc một con bug khủng. Bạn nghĩ ra cách giải vô cùng thông minh, ngắn gọn và tự vỗ đùi khen mình thông minh. Nhưng rồi một tháng sau vào xem lại code (của chính mình) không biết cái đống code “thông minh” của mình chạy như thế nào và làm sao sửa không?
Khi viết code, chúng ta nên cố gắng viết sao cho rõ ràng và dễ hiểu. Code rõ ràng truyền đạt mục đích 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.
Tất nhiên đ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 chúng ta viết code trông có vẻ “thông minh”, nhưng phần code đó lại không đặ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 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 điều đó hiếm khi xảy ra. Chúng ta là lập trình viên, chất lượng của code được đo bằng tính rõ ràng và tính dễ bảo trì; chứ không phải code càng ít dòng là càng giỏi như thời còn đi thi hay đi học.
Nếu bạn quan tâm đến việc viết code rõ ràng, tôi khuyên bạn nên đọc cuốn “The Clean Coder: A Code of Conduct for Professional Programmers” (tạm dịch: Coder rõ ràng: Quy tắc ứng xử dành cho các lập trình viên chuyên nghiệp) của Robert C. Martin.
3. Đừng viết code thừa, hãy viết đúng những gì cần viết
Mới đọc thì điều này có vẻ hơi mâu thuẫn với điều số 2 nhỉ? Nhưng chẳng phải sau tất cả công việc của lập trình viên chúng ta là viết code hay sao?
Thực ra câu trả lời cho câu hỏi trên là vừa “có”, vừa “không”.
Công việc lập trình 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.
Tất nhiên điều này cũng không có nghĩa là chúng ta nên làm cho code của mình ngắn gọn 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à hãy 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ường thì bạn hay 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 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. Ngược lại, nhiều code còn sinh ra nhiều bug hơn và việc bảo trì khó khăn hơn.
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. Lạm dụng 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 để diễn đạt ý nghĩa tốt hơn.
Comment chỉ nên 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 trong nhiều trường hợp chúng là 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ì các comment này trở nên thực sự nguy hiểm, bởi 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 xuyên 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 không? 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 đó đang nói đúng sự thật?
Đó chính là con dao hai lưỡi, vì vậy tốt nhất bạn nên tránh sử dụng comment càng nhiều càng tốt.
Nếu không đồng tình với quan điểm của tôi, 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 – tác giả bài viết, 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ắt đầu viết nó
Tình huống này khá quen thuộc, chắc không ít các bạn đọc đều gặp phải. Đôi khi, chúng ta cắm đầu vào code trước khi làm rõ vấn đề. Quả thật có nhiều lúc ta phải code mới biết cần giải quyết chuyện gì và code thế nào. Tuy nhiên, lời khuyên ở đây là: Hãy xác định mục đích code sẽ thực hiện trước khi code.
Đ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 thực sự hiểu rõ về những gì code mà 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 – Phát triển hướng kiểm thử) 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 viết ra, 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 bạn đang xây dựng trước khi bắt tay vào thực hiện.
6. Kiểm tra lại code trước khi bàn giao nó
Hãy tự test code của mình trước khi quăng nó cho tester! Dĩ nhiên, test là trách nhiệm của tester nhưng một lập trình viên “có đạo đức”, hãy tự test những case cơ bản, fix những lỗi ngớ ngẩn, không cần thiết để tránh lãng phí thời gian của mọi người.
Đừng ném code của bạn cho nhóm Tester ngay khi vừa viết xong, bởi 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 bản test của mình, trước khi cho rằng mình đã hoàn thành công việc.
Chắc chắn 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. 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
Tôi chắc rằng bạn sẽ quên một số kiến thức trong khi công nghệ luôn 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ố dành ra 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ộ công nghệ 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.
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. Viết code là chuyện rất thú vị
Đúng thế. Bạn có thể đã không quyết định theo ngành này chỉ bởi vì nó có mức lương tốt. Thật lòng mà nói, nghề lập trình viên là một nghề có mức lương khá ổn, công việc cũng dễ kiếm so với các ngành khá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. Tôi ước 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 phải không? 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, thậm chí còn được trả tiền cho công việc đó.
9. Chấp nhận rằng không phải thứ gì mình cũng biết
Đừng cố gắng học hết tất cả mọi thứ, đừng cố gắng tỏ ra mình biết mọi thứ. Bạn có thể nói “em không biết”, cũng có thể hỏi người khác khi có vấn đề không rõ.
Điều thú vị là càng học nhiều, 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 OK nếu bạn không có được tất cả những câu trả lời. Hãy yêu cầu sự 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ó – hãy 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. Cách giải quyết tốt nhất còn tùy vào từng tình huống
Không phải lúc nào cũng nên áp dụng 3 lớp, áp dụng IoC, áp dụng Test Driven Development. Mặc dù chúng được gọi là “best practice – những cách giải quyết tốt nhất”, nhưng chúng ta cũng phải áp dụng tùy theo hoàn cảnh, chứ không phải cứ mù quáng áp dụng là được.
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 á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 không?
Câu trả lời cho tất cả những câu hỏi này là “còn tùy”, tùy thuộc vào tình huống gặp phải.
Người ta sẽ cố gắng đẩy “best practice” 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 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ách giải quyết tốt nhất khi viết code, nhưng bên cạnh đó, 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 những cách giải quyết tốt nhất sẽ tùy thuộc vào tình huống cụ thể.
11. Luôn hướng đến sự đơn giản
Cách giải quyết hay nhất cho một vấn đề thường là cách đơn giản nhất (Đừng làm với cách giải “thông minh” được nhắc ở trên). Tuy nhiên, cách “đơn giản” này đôi khi rất tốn công sức mới tìm ra được. Trước khi đưa ra một cách giải quyết phức tạp cho một vấn đề nào đó, hãy tự hỏi bản thân: “Có cách nào giải quyết một cách đơn giản hơn không?”.
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.
Đây hiển nhiên 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.
Nếu phải thêm một nguyên tắc thứ 12, đó là: Hãy làm cho mình công lý. Các lập trình viên vĩ đại không phải lúc nào cũng chỉ huy người khác và yêu cầu được trả lương tốt nhất. Tại sao ư? Họ không “thị trường” mình.
Bạn đang sống với những nguyên tắc nào? 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 không?
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é!
Tác giả: John Sonmez
(theo QuanTriMang)
| FPT Aptech trực thuộc Tổ chức Giáo dục FPT có hơn 25 năm kinh nghiệm đào tạo lập trình viên quốc tế tại Việt Nam, và luôn là sự lựa chọn ưu tiên của các sinh viên và nhà tuyển dụng. |
