Gần đây trong bắt đầu tham gia vài dự án có liên quan đến nhu cầu đọc và viết ngày càng thường hơn, đặc biệt là các bài viết kỹ thuật. Bản thân mình hay tự đặt ra câu hỏi: Làm thế nào để phân biệt một bài viết kỹ thuật là hay, là chưa hay?
Sau khi dành vài ngày đọc tham khảo vài nguồn, mình nhận thấy vài điều:
Một bài viết hay, hay dở phụ thuộc nhiều vào cảm nhận chủ quan của người đọc. Bài viết có thể trình bày chưa tốt, hoặc thiếu ý, hoặc lang mang nhưng đánh đúng tâm lý người đọc thì sẽ được người đọc cho là hay. Đồng thời, việc cảm nhận hay hay dở cũng tùy người. Cùng một bài viết, có người cho là hay, có người bảo là chưa hay.
Nhưng mình cũng đồng thời nhận thấy, việc hay hay dở cũng chịu tác động bởi một vài yếu tố khách quan bởi chính bản thân bài viết.
1- Ý tưởng, chủ đề mang tính mới
Có rất nhiều vấn đề, vốn đã được nói đi nói lại rất nhiều lần. Ví dụ như coding styles. Mặc dù bài viết của tác giả cũng nêu bật được quan điểm riêng của mình. Nhưng nếu không có một yếu tố đặc sắc nào, mình sẽ cảm thấy bài viết vậy có ý tưởng chưa “mới”.
2- Tác giả hiểu rõ mục đích viết (giới thiệu, bình luận, nêu quan điểm, bày tỏ cảm xúc) và xác định được mục tiêu viết (giúp người đọc hiểu khái niệm, đồng tình với quan điểm, …)
Dựa theo các cách phân loại ở trên, ứng với mỗi thể loại, thường người viết phải tự đề ra những mục tiêu khác nhau để từ đó chọn một cách diễn đạt / trình bày phù hợp.
Việc không xác định rõ mục tiêu, hoặc mục tiêu lệch với thể loại, hoặc cách diễn đạt không thể hiện được mục tiêu đề ra sẽ khiến bài viết không hay, đôi lúc trở nên lang mang.
3- Kết cấu chặt chẽ, logic
Kết cấu bài viết được xem là logic khi các ý liên kết và bổ trợ cho nhau, ý sau mô tả dựa vào ý trước. Ngoài ra, bài viết cần giải quyết được vấn đề được đặt ra. Ví dụ, nếu bài viết nhằm mục tiêu giới thiệu cách dùng một loại công cụ, công nghệ nào đó thì khi kết thúc bài viết, người đọc phải hiểu cách dùng công cụ đó.
Ví dụ: một bài viết có tiêu đề như thế này “Packfiles – Người hùng thầm lặng của Git”. Qua cách đọc tiêu đề, mình nhận thấy tác giả nhắm tới hai nhóm mục tiêu chính: giới thiệu, hoặc giải thích về Packfiles.
Kết cấu bài viết gồm các phần:
- Giải thích về Git
- Giải thích cách Git version project như thế nào
- Giới thiệu về Packfile
- Giải thích cách dùng Packfile trong một trường hợp cụ thể
Sau khi mình đọc bài viết này, mình cảm nhận bài viết có kết cấu chặt chẽ vì:
Thứ nhất, mục tiêu của bài viết nêu ra là giới thiệu về pack-file đã đạt được. Sau khi đọc xong bài viết, mình có thể hình dung được packfile là gì, tại sao nó tồn tại, mối liên quan của nó với Git.
Thứ hai, kết cấu của bài viết logic và hợp lý. Để hiểu về packfiles, tác giả đã giới thiệu về kiến thức nền cần thiết về Git objects và cách Git quản lý version cho mình. Việc cung cấp kiến thức nền như thế này giúp mình hiểu về khái niệm packfiles đưa ra phía sau.
4- Cách diễn đạt trơn tru, mạch lạc
Khi ta đánh giá một bài viết, trước tiên ta phải xác định: đây là văn viết. Diễn đạt dưới hình thức văn viết, “bài viết” thì yêu cầu cơ bản là diễn đạt cần đúng ngữ pháp và chính tả. Ngôn từ được sử dụng trong văn viết cũng phải khác biệt với văn nói.
Đối với bài viết kỹ thuật, thường yếu tố diễn thường bị xem nhẹ. Một phần là do thói quen diễn đạt vắn tắt, ngắn gọn qua các nền tảng chat. Một phần khác là do người viết chỉ chú trọng đến yếu tố kiến thức, yếu tố kỹ thuật có trong bài viết mà không hoặc ít quan tâm đến phần diễn đạt.
Quan điểm cá nhân, mình tin là các bài viết về công nghệ cũng nên chú ý đến yếu tố diễn đạt. Bản thân mình cũng thấy đây là điểm yếu mình cần khắc phục nhiều.
5- Minh họa dễ hiểu và cần thiết
“Một tấm ảnh trị giá bằng ngàn vạn lời nói” – Mình rất tâm đắc với câu nói này, dù quên mất bắt nguồn từ đâu rồi.
Việc đặt những hình ảnh minh họa đúng chỗ, đặc biệt là trong các bài viết về kỹ thuật, sẽ giúp người đọc hiểu nhanh và hiểu rõ hơn vấn đề bạn muốn diễn đạt. Tuy nhiên, nhiều bạn quá lạm dụng hình ảnh minh họa, chỉ cần thấy thích là để vào, sẽ làm cho nội dung rối rắm và khó hiểu hơn.
Một số trường hợp khác, việc chỉ đưa hình ảnh, code minh họa, mà không giải thích, cũng khiến cho nội dung được truyền tải trở nên thiếu rõ ràng, mạch lạc.
6- Có chiều sâu về công nghệ
Sự khác biệt giữa bài viết hay và bài viết kỹ thuật hay, khác nhau ở hàm lượng kỹ thuật được đề cập đến trong bài viết.
Để trả lời về độ sâu của bài viết, mình nghĩ có thể dựa vào hai yếu tố:
- Bản thân người viết hiểu về chủ đề mình viết sâu tới mức nào. Cái hiểu ở đây nên là cái hiểu thông qua làm thật, thông qua thực hành, rèn luyện.
- Nội dung được đề cập đến đòi hỏi người đọc phải trang bị những gì để thực sự hiểu bài viết một cách trọn vẹn.
- Nội dung bài viết đề cập đến một chủ đề đòi hỏi nhiều trải nghiệm trong ngành.
- Nội dung mang tính trừu tượng, khái quát hóa cao, đòi hỏi người đọc cũng phải có mức độ nhận thức về chủ đề ở mức tương đương.
Từ những điều ghi chú trên, mình đề nghị các bước để review một bài viết kỹ thuật, đồng thời cũng giúp bản thân tự đánh giá các bài viết của mình, của team khi cần:
- Xác định chủ đề của bài viết là gì.
- Xác định mục tiêu của bài viết
- Xem kết cấu, các ý chính của bài viết có phục vụ cho mục tiêu hay không, hay lạc đề.
- Văn phong và cách diễn đạt có rõ ràng, rành mạch, trơn tru hay không. Hay ngắt quãng kiểu nói sao viết vậy.
- Có ví dụ, hình ảnh minh họa hay không, có phù hợp không.
- Độ sâu về công nghệ của bài viết.
Ghi chú: Theo mình, xét một cách riêng lẻ, từng yếu tố trên đây không làm nên một bài viết kỹ thuật hay. Một bài viết hay, nên là sự tổng hòa các yếu tố này cùng cảm nhận của bản thân người đọc.
Con Mọt Sách 