Này Anh Bạn Lập Trình Viên, Nếu Muốn Lên Trình Thì Hãy Viết Code Cho ...

Chẳng nhớ mình đã nghe câu nói này ở đâu. Cũng có thể đấy là câu mà mình muốn nói với chính bản thân của 1 vài năm về trước. Rằng việc viết ra và giữ cho code luôn sạch có một ý nghĩa cực kỳ to lớn đằng sau nó.

Ngày xưa, chúng ta đều bắt đầu đi lên với lập trình từ con số 0. Tất nhiên ưu tiên hàng đầu là tạo ra 1 sản phẩm có thể chạy được và đáp ứng đủ chức năng yêu cầu đã đề ra. Khi đó việc viết ra một đống code không-sạch-lắm chẳng phải là vấn đề gì to tát. Điều đó dễ hiểu và dễ chấp nhận được. Nhưng khi thời gian trôi qua và kiến thức được tích lũy đã nhiều lên, dường như chúng ta vẫn chưa dành cho việc cải thiện những mớ code không sạch lắm một sự quan tâm cần thiết.

Đã bao giờ bạn gặp trở ngại to lớn do code bẩn?

Nếu bạn là một lập trình viên từng trải, bạn hẳn đã nhận ra sự trở ngại này nhiều lần. Chúng ta lội qua code bẩn, một cách ì ạch qua những bãi lầy, hay như dấn thân vào 1 mê cung đầy cạm bẫy. Bạn đã bao giờ nỗ lực tìm đường, loay hoay để tìm ra một vài gợi ý, một ít đầu mối, về những gì đang xảy ra, nhưng tất cả những gì bạn thấy là nhiều và nhiều hơn nữa những dòng code vô nghĩa.

Qua thời gian, những đội đang triển khai giai đoạn đầu dự án ở tốc độ rất nhanh có thể thấy rằng tốc độ của họ trở nên chậm hơn rất nhiều. Mỗi sự thay đổi làm hỏng hai hay ba phần khác trong mã nguồn. Không sự thay đổi nào là dễ dàng. Mỗi việc thêm mới hay sửa đổi hệ thống đòi hỏi bạn phải hiểu hết những mớ bòng bong và những nút thắt trong code để bạn có thể thêm vào những mớ bòng bong và những nút thắt khác. Càng ngày đống lộn xộn càng to ra, sâu hơn và cao hơn, họ không thể dọn sạch nó được. Không thể nào làm nổi.

Code càng lộn xộn càng làm năng suất làm việc của nhóm liên tục giảm đi. Và vì năng suất giảm, người quản lý làm việc duy nhất họ có thể làm đó là: bổ sung nhân lực cho dự án hòng cải thiện năng suất. Nhưng nhân viên mới lại không thông thạo về thiết kế hệ thống. Họ không hiểu rằng có những thay đổi phù hợp với định hướng thiết kế trong khi một số khác thì không. Hơn nữa, họ cùng những người khác trong nhóm đều phải chịu áp lực khủng khiếp để tăng năng suất. Và tất cả họ càng ngày càng làm ra nhiều lộn xộn hơn.

Tất nhiên bạn đã từng gặp trở ngại với code bẩn. Vậy thì – tại sao bạn lại viết ra chúng?

Có phải bạn đã cố đi nhanh? Lúc đó bạn đang vội? Có lẽ vậy. Có lẽ bạn cảm thấy bạn không có thời gian để làm một việc tốt; rằng sếp có thể sẽ bực mình nếu bạn dành thời gian để làm sạch code của bạn. Có lẽ bạn thật ra rất mệt mỏi với dự án này và chỉ mong cho nó xong sớm. Hoặc cũng có thể bạn nhìn vào backlog và thấy còn rất nhiều hạng mục khác mà mình đã hứa sẽ hoàn thành, và bạn nhận ra rằng phải nhanh chóng “làm cho xong” mô-đun này để có thể chuyển sang việc tiếp theo.

Chúng ta cũng từng làm như vậy. Chúng ta cũng từng nhìn vào mớ bừa bộn mình vừa tạo ra và ngao ngán quyết định sẽ dọn sau. Chúng ta cảm thấy nhẹ nhõm khi chương trình lộn xộn của chúng ta hoạt động được và quyết định rằng “lộn xộn còn hơn là không có gì”. Chúng ta thống nhất rằng sẽ quay lại làm sạch nó sau. Dĩ nhiên là trong những ngày đó chúng ta chưa biết đến “định luật LeBlanc”: Để sau nghĩa là không bao giờ.

Vậy thì thế nào mới là code sạch ?

Sau khi tổng hợp ý kiến của 1 số chuyên gia, có thể rút ra vài đặc điểm của code sạch như sau:

• Phải có logic rõ ràng.
• Phải đat performance tốt, tốt nhất là gần với mức tối đa (so với thuật toán).
• Người khác có thể đọc, cải tiến, bảo trì được dễ dàng.
• Chạy tốt các test.
• Không có các phần trùng lặp về chức năng
• Nội dung code giống với những gì bạn dự kiến
• Giảm bớt số lượng tất cả: class, function, variable,…

Có nhiều định nghĩa nhưng mình tâm đắc nhất 2 câu thế này

“Tôi thích mã của tôi thanh lịch và hiệu quả. Lô-gic nên đơn giản để làm cho nó khó gặp những lỗi ẩn, có tối thiểu những sự phụ thuộc để dễ dàng bảo trì, xử lý lỗi hoàn chỉnh theo những chiến lược thống nhất, và hiệu suất gần như tối ưu để không cám dỗ người ta làm mã lộn xộn với những trò tối ưu hóa lố lăng. Code sạch là code làm tốt một việc”. Bjarne Stroustup, người phát minh ra C++ và là tác giả của cuốn The C++ Programming Language.

Code sạch là code làm tốt một thứ. Không phải ngẫu nhiên mà có rất nhiều nguyên tắc thiết kế phần mềm có thể tóm lược lại thành lời khuyên đơn giản này. Code bẩn cố gắng làm quá nhiều thứ, nó có ý định lộn xộn và mục đích không rõ ràng. Code sạch là sự hội tụ. Mỗi chức năng, mỗi lớp, mỗi môđun cho thấy sự tập trung vào một mục đích, ý đồ duy nhất mà không bị sao nhãng và làm bẩn bởi những chi tiết ngoài lề.

"Code sạch bao giờ cũng trông như được viết bởi những người có tâm". Michael Feathers, tác giả của Working Effectively with Legacy Code.

Code sạch là code được để tâm tới. Một ai đó đã phải mất thời gian để giữ cho nó đơn giản và ngăn nắp. Cái tâm này cũng chính là cái tâm ở trong bức tranh phẳng treo trên tường công ty ấy

Tóm lại, Là một developer “có tâm”, bạn phải có trách nhiệm với code mình viết ra.

Các quản lý và bộ phận sale tìm tới chúng ta cho thông tin họ cần để soạn ra những lời hứa và cam kết. Người dùng thì tìm tới chúng ta để xác nhận liệu những yêu cầu có thích hợp với hệ thống hay không. Quản lý dự án thì nhờ chúng ta hỗ trợ trong việc quyết định lịch trình. Chúng ta can dự sâu sắc vào viện lên kế hoạch cho dự án và chia sẻ phần không nhỏ trách nhiệm với bất kỳ một sự thất bại nào, đặc biệt nếu những thất bại đó một phần là do code bẩn.

Bạn có thể nói “Từ từ đã! Nếu tôi không làm những gì quản lý yêu cầu, tôi sẽ bị sa thải mất.” Không hẳn. Hầu hết quản lý muốn được biết sự thật, ngay cả khi họ không hành động như vậy. Hầu hết các quản lý muốn có code sạch, ngay cả khi họ bị ám ảnh về lịch trình. Họ có thể bảo vệ lịch trình và yêu cầu với sự đam mê, nhưng đó là công việc của họ. Công việc của bạn là bảo vệ mã nguồn với một đam mê tương đương họ. Vậy lần sau PM hay sếp của bạn ra sức ép hay yêu cầu bạn phải hoàn thành một deadline vô lý, hãy mạnh dạn nói "Đ*o !"

Làm sao để viết code sạch hơn

Tin xấu là viết code sạch có rất nhiều điểm giống như vẽ một bức tranh. Phần lớn chúng ta biết như thế nào là tranh được vẽ đẹp hay xấu. Nhưng có thể nhận thức được cái đẹp và cái xấu không có nghĩa là chúng ta biết làm thế nào để vẽ. Việc viết mã nguồn sạch yêu cầu sử dụng một cách kỷ luật vô số kỹ thuật nhỏ được ứng dụng thông qua việc dày công luyện tập cảm giác về sự “sạch”.

Nó không chỉ quan trọng trong việc làm cho chúng ta nhận thấy được mã tốt hay code bẩn, mà còn giúp ta nhìn ra chiến lược để áp dụng kỷ luật mà những chuyên gia kinh nghiệm nhất đề xuất cho việc chuyển đổi code bẩn thành mã sạch. Nói thì đương nhiên là dễ hơn làm. Nhưng cái giá của nỗ lực là sự ưu tú. Để đạt tới trình độ cao siêu hơn, chúng ta phải có 2 thứ: hiểu biết và sự chăm chỉ. Vậy nên hãy cứ luyện tập và luyện tập. Đọc sách rồi luyện tập. Sách thì chắc hẳn các bạn biết phải đọc những sách gì rồi. Một trong những cuốn PHẢI đọc đó là Clean code - cuốn sách lập trình kinh điển "gối đầu giường" của mọi lập trình viên. Lâu lâu hãy đọc lại 1 lần nữa để nghiệm lại những điều mình chưa hiểu.

Có một luật đơn giản để nói về việc làm thế nào để viết code sạch như thế này:

Luật hướng đạo.

Chỉ viết code tốt thôi là không đủ. Code còn phải được giữ sạch cùng thời gian. Tất cả chúng ta đều đã chứng kiến code xấu đi và giảm chất lượng theo thời gian. Do đó chúng ta cần phải chủ động trong việc ngăn ngừa sự suy thoái này. Những cậu bé hướng đạo sinh của nước Mỹ có một luật đơn giản mà chúng ta cũng có thể áp dụng vào nghề của chúng ta. “Rời khỏi khu cắm trại sạch hơn lúc bạn đến”.

Nếu mỗi lần check-in mã (commit) chúng ta đều làm code của mình sạch một chút so với khi ta check-out (update) nó về, code chắc chắn sẽ không bị thối. Việc làm sạch không phải là thứ gì đó quá lớn lao. Đơn giản có thể chỉ là đổi tên một biến nào đó cho tốt hơn, phân tách một chức năng quá lớn, khử một vài đoạn mã lặp, dọn dẹp một câu lệnh if phức tạp v.v..

Bạn có tưởng tượng được việc làm việc trên một dự án mà code đơn giản là cứ mỗi ngày một trông đẹp hơn? Nếu không phải như vậy thì liệu có phải là chuyên nghiệp nữa hay không? Thực sự, chẳng phải “cải tiến liên tục” là một phần bản chất của tính chuyên nghiệp sao? Và từ đó, kỹ năng cũng như giá trị của bạn cũng tăng tiến theo một cách tỉ lệ.

Hãy nhớ rằng Code cho máy đọc thì ai cũng viết được, code cho người đọc thì chỉ có developer giỏi mới viết được.

Nguồn : Clean Code - A Handbook Of Agile Software Craftmanship