Trong bài viết The Programming Aphorisms of Strunk and White, tác giả James Devlin đã làm một công việc khá xuất sắc trong việc nghiên cứu một số vấn đề mà bản thân tôi đã chú ý trong hơn 5 năm vừa qua:
Đó là mối quan hệ không mong đợi giữa viết code và viết.
Bạn phải viết code rõ ràng để cho các đồng nghiệp có thể hiểu được.
Có lẽ không có một nguồn tham khảo riêng lẻ về chủ đề viết này hơn cuốn sách The Elements of Style của hai tác giả Strunk và White. Nó là một trong những cuốn sách thiết yếu mà bạn có lẽ đã khám phá ra ở trường trung học hoặc đại học, và sau đó dành cả phần đời còn lại của mình để thắc mắc rằng tại sao những cuốn sách khác lại cứ làm lãng phí thời gian của bạn bằng những từ ngữ không cần thiết để trình bày quan điểm của họ. Giống như tất cả những cuốn sách tuyệt vời khác, nó đã thay đổi hoàn toàn cái cách bạn nhìn thế giới này, dù chỉ một chút.
Trang web Wikipedia cung cấp một chút về lịch sử và ngữ cảnh hình thành của cuốn sách sống mãi với thời gian này:
Cuốn sách [The Elements of Style] có nguồn gốc là một bài viết vào năm 1918 và được xuất bản nội bộ bởi giáo sư William Strunk, Jr. thuộc trường đại học Cornell, nó được duyệt lại lần đầu tiên bởi sự giúp đỡ của Edward A. Tenney vào năm 1935. Vào năm 1957, nó gây được sự chú ý của nhà báo E. B. White của tờ The New Yorker. White đã từng là học trò của Strunk vào năm 1919 nhưng đã quên mất “cuốn sách nhỏ” đó cái mà ông gọi là “một bản tổng hợp 43 trang của những trường hợp sử dụng trong tiếng Anh để ngữ nghĩa được rõ ràng, chính xác và súc tích hơn”.
Một ít tuần sau đó, White đã viết một bài trên tờ The New Yorker để tán dương giáo sư Strunk và sự cống hiến của ông đến sự “súc tích” cho văn xuôi tiếng Anh. Tác giả của cuốn sách đó đã mất vào năm 1946, vì vậy nhà xuất bản Macmillan and Company đã ủy quyền cho White viết lại một phiên bản mới của cuốn sách The Elements of Style, và đã được xuất bản vào năm 1959. Trong phiên bản viết lại này, White đã độc lập mở rộng và hiện đại hóa bản gốc năm 1918, tạo ra một cuốn sổ tay nổi tiếng tới hàng triệu người viết bài và các sinh viên, đơn giản với cái tên là “Strunk and White”. Phiên bản đầu tiên của White đã bán được khoảng 2 triệu bản, cùng với tổng số lượng bán của 3 lần tái bản khác đã vượt quá 10 triệu bản trải dài trên 4 thập kỷ.
Tất cả điều này thì rất tốt nếu bạn lên kế hoạch để trở thành một người viết văn, nhưng liệu có mối liên quan nào giữa cuốn sách nhỏ đó và việc viết một chương trình máy tính?
Viết chương trình để cho máy tính có thể hiểu được thì chắc chắn là một thách thức. Đó là lý do tại sao có rất ít người, theo nghĩa rộng nhất, có thể trở thành một lập trình viên giỏi. Nhưng viết các đoạn và câu để những đồng nghiệp của bạn có thể hiểu được — vâng, thì thậm chí còn khó hơn rất nhiều. Bạn càng có thâm niên trong công việc viết phần mềm, thì cuối cùng bạn sẽ nhận ra rằng để có thể thành công thực sự, thì bạn phải viết những chương trình mà có thể được hiểu bởi cả máy tính và những lập trình viên đồng nghiệp của bạn.
Có một điều nghịch lý nhất trong kỹ nghệ phần mềm đó là hầu hết chúng ta tham gia vào lĩnh vực này bởi vì máy móc thì có tính logic hơn là con người. Và vâng, thậm chí khi bạn đang viết code rõ ràng là nhắm đến cho máy tính, thì thực ra bạn vẫn đang viếtcho những người khác. Những con người mà cũng đầy những sai lầm, khuyết điểm và đôi khi cũng khùng khùng giống như bạn. Và đó mới thực sự là điều khó nhất.
Tôi nghĩ rằng đó chính là điều mà nhà khoa học máy tính nổi tiếng Knuth đã đưa ra cùng khái niệm của ông trong tài liệu Literate Programming (pdf).
Chúng ta hãy thay đổi thái độ truyền thống của mình trong việc xây dựng các phần mềm: đó là thay vì tưởng tượng rằng tác vụ chính của chúng ta là hướng dẫn máy tính phải làm gì, thì chúng ta hãy tập trung vào việc giải thích tới những người khác về điều mà chúng ta muốn một chiếc máy tính phải làm.
Những người đang làm công việc viết chương trình có thể được xem như là đang viết bài luận, và mối quan tâm chính là đưa ra một phong cách tuyệt vời nhất. Như là một tác giả, cùng với cuốn từ điển trong tay, hãy lựa chọn tên các biến một cách cẩn thận và giải thích mỗi biến có ý nghĩa gì. Anh ta hoặc cô ta sẽ nỗ lực cho một chương trình mà có thể lĩnh hội được bởi vì những khái niệm của nó đã được giới thiệu theo một cách tốt nhất mà con người có thể hiểu được, sử dụng một sự pha trộn giữa những hình thức trang trọng và bình dân để củng cố lẫn nhau.
Điều này, dĩ nhiên là nói thì dễ hơn làm. Hầu hết chúng ta dành toàn bộ cuộc đời mình để học cách làm thế nào để viết cho hiệu quả. Một cuốn sách như The Elements of Style có thể cung cấp những hướng dẫn rất bổ ích mà có thể ảnh hưởng tới hầu hết toàn bộ quy trình viết code. Tôi muốn nhấn mạnh một quy tắc từ cuốn sách Elements of Style mà mình đã luôn quay lại tham khảo, hết lần này đến lần khác, từ lần đầu tiên khám phá ra cuốn sách đó nhiều năm về trước.
13. Bỏ đi những từ không cần thiết.
Điểm mạnh nhất trong khi viết chính là sự súc tích. Một câu không nên chứa những từ không cần thiết, một đoạn không nên chứa những câu không cần thiết, cũng tương tự như trong một bức họa thì không nên vẽ những nét thừa không cần thiết và một chiếc máy thì không nên có những bộ phận dư thừa. Những yêu cầu này không phải là bắt người viết phải làm cho tất cả các câu của anh ta phải ngắn gọn, hoặc anh ta phải tránh tất cả các chi tiết và nói về chủ đề của mình một cách hời hợt, mà rằng mọi từ trong câu phải nói lên một ý gì đó.
Chúng gợi lên điều gì về cách viết của bạn? Về cách viết code của bạn?
Lập trình, nói cho cùng thì cũng chỉ là viết. Liệu nó có thể trở nên khó đến mức nào?
