Viết code cũng như viết một câu chuyện
May 1, 2022Khi bạn nảy ra một ý tưởng nào đó, bạn muốn kể cho cả mọi người và bạn sẽ sử dụng ngôn ngữ để làm nó. Ngôn ngữ có thể giúp bạn truyền đạt một thông tin hay một điều gì đó cho người khác, có thể là những kinh nghiệm hay giải thích một thứ gì, nó chính là điều mà chính nội tại nó được sinh ra.
Bài viết này không phải nói về ngôn ngữ, mình chỉ muốn hướng suy nghĩ khác nếu chúng ta coi thiết kế một hệ thống phần mềm như đang kể một câu chuyện thì sao. Phải chăng câu chuyện đó sẽ được viết bởi một ngôn ngữ nào đó mà bạn có thể.
Một câu chuyện thì có lẽ điều đầu tiên đòi hỏi phải có độc giả chứ nhỉ?
Vậy ai là người sẽ đọc code của bạn?
Người đầu tiên đọc không ai khác chính là bản thân bạn, có mấy ông lập trình viên nào nhăn nhó khi tự đọc code của chính mình sau 1 tuần, một tháng rồi tự chửi thề thì đừng có nhột nhột nhé.
Mỗi đoạn code bạn viết ra để thực hiện một chức năng nào đó, và sau đó có thể chính bạn sẽ phải sửa nó vì yêu cầu bị thay đổi, đó là chuyện bình thường hằng ngày rồi.
Tuy nhiên nếu bạn làm việc với một dự án lớn hơn một chút, bạn sẽ có những người đồng nghiệp đẹp trai xinh gái làm cùng. Khi này câu chuyện kể của bạn chắc hẳn sẽ có những độc giả khác ngoài chính bạn. Nếu bạn thực sự chỉ muốn làm việc một mình hay muốn bị mắng sml thì bạn cứ viết bừa cũng được, miễn sao chương trình nó chạy. Vậy chẳng có gì để nói với bạn ở đây. Còn nếu bạn muốn người khác đọc hiểu được thì có lẽ bạn nên chia đoạn, chia dòng, chú thích, chia chương, đánh mục lục để người khác có thể hiểu được code của bạn viết.
Điều này sẽ giúp cho chính bạn và nhóm phát triển của bạn tiết kiệm được rất nhiều thời gian và có thể đảm báo được chất lượng sản phẩm khi đắp thêm những phần mới vào.
Không phải tự nhiên “Clean Code” được coi là kinh thánh của anh em lập trình viên, và để tổ chức dự án được tốt cũng không phải là chuyện dễ dàng gì.
Chất lượng phần mềm cũng như sự hấp dẫn của câu chuyện!
Một câu chuyện hay có lẽ sẽ có những quy chuẩn riêng của riêng nó. Bạn nghĩ sao khi một câu chuyện phá cách chẳng có mở bài thân bài kết luận hay các ý các chương đảo lộn hết cả. Tất nhiên nó vẫn diễn đạt một điều gì đó nhưng có lẽ sẽ chẳng ai muốn đọc nó.
Bạn mở một vài đoạn code và bạn có thể thay đổi một chức năng nào đó của hệ thống, bạn hiểu đoạn code đó trong vòng 3 giây để có thể tiếp tục thêm tính năng mới liệu có khó không.
Theo mình để có thể làm được việc đó thì code của bạn phải có cấu trúc xác định từ đầu. Đoạn nào, file nào để xử lý nhiệm vụ gì, chức năng gì, khi này việc của bạn là tìm đúng khúc cần thêm và thay đổi nó thì chẳng phải đơn giản lắm sao.
Đối với câu chuyện về phần mềm này có lẽ sẽ có 3 tiêu chuẩn mà mình nghĩ bạn sẽ phải để ý khi viết ra. Đó là sự đơn giản, dễ bảo trì và dễ dàng mở rộng. Có thể ở đâu đó sẽ cho nó vào danh sách non-functional thứ mà luôn đi song song với đầu ra của sản phẩm nhưng mà lại không được khách hàng nói ra và bạn phải mặc định hiểu để thực hiện nó.
Tất nhiên functional vẫn phải là cốt chuyện chính của bạn. Một câu chuyện hay trong phần mềm có thể là những tính năng mượt, logic, giao diện đẹp, trải nghiệm người dùng tốt là điều hiển nhiên cho chất lượng phần mềm.
Có thể đọc hiểu không có nghĩa là lan man
Câu chuyện hay thật đó, có dụng ý thật đó nhưng mà bạn hãy cố gắng cô đọng ý nhất có thể nhằm tiết kiệm thời gian đọc cho độc giả. Có lẽ khi viết code cũng vậy, chẳng ai muốn đọc từng chữ trong code, rồi cả comment nữa. Bạn có thể giúp người ta đọc lướt mà vẫn hiểu được nội dung mà đúng không?
“Bài vếit cuẩ tôi sai chíh tả mất rùi“, đọc lướt chắc bạn vẫn hiểu nhỉ =)))
Nói đùa thế thôi chứ làm sao khi viết code thì cố gắng đặt tiên biến tên hàm ngắn gọn mà vẫn mang đủ ý nghĩa đỡ phải viết chú thích giải thích các kiểu lại mệt thêm và ngồi sửa khi thay đổi chức năng hàm thì đến mệt.
Bạn có thể lược bỏ giới từ, trạng từ, mạo từ và ngắn ngắn nhỏ hơn 4,5 từ nếu bạn đặt tên biến bằng tiếng anh, anh em coder có lẽ vẫn hiểu cả thôi.
Giới hạn của bộ não khi đọc
Anh em cứ cậy logic mình siêu cứ viết các điều kiện ràng buộc, trộn các câu lệnh rõ dài vào để thể hiện gì chứ. Tăng độ phức tạp của đoạn code không khiến bạn trở nên thông minh hơn đâu. Với mình mà review code kiểu hại não vậy là reject chứ tự mình làm khổ mình chi vậy. Kể chuyện cũng vậy, ừ thì logic là tốt, câu ghép, câu dài so sánh ẩn dụ các kiểu là tốt. Nhưng quá hoa mỹ có khi lại phản tác dụng đó. Nhất là thời đại con người ai cũng muốn nắm thông tin nhanh chóng thì cố gắng chau chuốt hơn thay vì dùng quá nhiều các thể loại biện pháp văn học để vẽ rồng vẽ phượng =))))
Bài viết hướng dẫn cách viết bài như thế nào
Có bao giờ bạn gặp được những bài viết kiểu như Câu chuyện kể về cách kể một câu chuyện chưa. Có lẽ sẽ khá nhiều đối với những người thích chia sẻ “How to” như mình.
Viết code cũng vậy, sẽ có những đoạn code dành cho mục đích tái sử dụng hay những vấn đề lặp đi lặp lại mình sẽ viết hướng dẫn cách làm hay viết sẵn đoạn code mẫu và khi cần thì chỉ việc bê vào thôi. Đó cũng là mục đích của các thư viện hay nền tảng xây dựng sẵn để triển khai nhanh hơn. Để làm được điều đó thì bạn càng phải tuân theo những quy chuẩn của cộng đồng.
Ngôn ngữ liệu có quyết định câu chuyện của bạn
Đằng sau những câu chuyện không thể thiếu ngôn ngữ diễn đạt. Đằng sau những hệ thống không thể thiếu những ngôn ngữ tạo nên nó. Nó có thể là một ngôn ngữ phổ biến nào đó, cũng có thể là sự kết hợp của nhiều ngôn ngữ khác nhau. Miễn sao nó có thể kết hợp và diễn đạt được đúng những thứ mà tác giả hướng tới.
Ngôn ngữ lập trình cũng vậy, có thể ngôn ngữ đó phổ biến và hót nhất thị trường nhưng suy cho cùng thì nó cũng để xây dựng ra phần mềm mà thôi. Viết dài hay viết ngắn, khó học hay dễ học thì đừng quên mục đích cuối cùng bạn sử dụng nó nhé!
Bài viết là một sự ví von đôi chút, nếu có sự so sánh khập khiễng quá thì mong rằng anh em trong ngành đừng quá gạch đá mình nhé.
