Code của bạn một chút lộn xộn (trừ khi bạn là một nhà khoa học máy tính)

Tại sao mỗi nhà phát triển đều nghĩ rằng họ đang viết code hoàn toàn dễ hiểu? Tại sao nhà phát triển đó không thể giải mã code của người khác, chưa nói đến việc duy trì nó?

Vì họ đều viết code một cách lộn xộn nhưng vẫn hoạt động. Nghĩa là, code hoạt động ngay bây giờ nhưng không linh hoạt hoặc đa dạng do sự lộn xộn của nó. Ngoại trừ những nhà khoa học máy tính - họ viết code tuyệt vời nhưng không hoạt động.

Lý do 1: Với nhà khoa học máy tính, viết code là một nghệ thuật. Với tất cả mọi người khác, đó chỉ là một công cụ

Những nhà khoa học máy tính viết code vì họ muốn viết code. Mọi người khác viết code vì họ muốn hoàn thành một công việc gì đó.

Một nhà phát triển bình thường sẽ xây dựng một chương trình dựa trên ý tưởng đầu tiên xuất hiện trong đầu họ. Sau đó, họ sẽ xây dựng lên ý tưởng đó cho đến khi có một cái gì đó giống như một MVP. Thường thì, họ thậm chí không nghĩ đến các phương pháp tiếp cận khác.

Ngược lại, một nhà khoa học máy tính sẽ xem xét mọi lựa chọn cài đặt và cân nhắc về ưu và nhược điểm của mỗi lựa chọn. Một vài tuần sau, họ sẽ có một đoạn code tuyệt vời nhưng vẫn chưa hoàn toàn hoạt động vì nhà khoa học máy tính vẫn chưa quyết định định dạng của đầu ra.

Nhiều đoạn code lộn xộn được tạo ra vì các nhà phát triển bắt đầu với một công cụ dễ sử dụng và phát triển mã nguồn một cách tự nhiên. Ngược lại, nhà khoa học máy tính thường bắt đầu thiết lập một cấu trúc và sau đó làm việc trong đó.

Phương pháp tự nhiên là tốt nhất để tránh Coder’s Block và giao hàng đúng hạn. Tuy nhiên, nếu bạn muốn viết code bền vững, bạn có thể muốn đặt cấu trúc lên đầu.

Lý do 2: Nhà phát triển không luôn viết với người đọc trong tâm trí

Ngay cả trong các dự án cộng tác, nhà phát triển thường viết code chỉ với chức năng của nó trong tâm trí. Trong khi làm như vậy, họ quên rằng code cũng cần được duy trì.

Vấn đề là tư duy này phản tác dụng. Khi nhà phát triển muốn thêm một tính năng ba tháng sau đó, họ có thể không hiểu được chính code của mình. Điều này xảy ra thường xuyên hơn bạn nghĩ!

Và nó trở nên phức tạp hơn khi một nhà phát triển khác được yêu cầu triển khai một tính năng mới. Tùy thuộc vào kích thước của dự án, việc hiểu code của người khác có thể mất từ vài ngày đến vài tuần.

Lý do 3: Phong cách là một điều quan trọng

Mỗi người viết code theo cách khác nhau. Một số người ghét comment trong code, những người khác thì yêu thích chúng. Một số người comment cho hàm của họ ở trên dòng đầu tiên, một số thì ở dưới. Một số người yêu thích switch cases, những người khác ghét chúng.

Đó là lý do tại sao một đoạn code có thể dường như kinh khủng đối với một người, nhưng hoàn toàn ổn đối với người khác.

Điều này không phải là vấn đề khi bạn làm việc một mình. Nhưng ngày nay, rất nhiều phần mềm được xây dựng thông qua sự cộng tác. Vì vậy, quan trọng là đặt một hướng dẫn phong cách từ giai đoạn đầu của dự án.

Và tất nhiên, bạn sẽ cần đảm bảo rằng tất cả các nhà phát triển đều tuân thủ nó. Nếu không, bạn sẽ kết thúc với một đoạn code lộn xộn vì nó là một sự kết hợp của nhiều quy ước khác nhau.

Lý do 4: Sai lầm của những phần thưởng ngay lập tức

Bạn đã bao giờ cảm thấy hứng thú khi bạn bị mắc kẹt với một vấn đề trong vài ngày cho đến khi cuối cùng bạn tìm ra một giải pháp để giải quyết nó chưa? Đó là một khoảnh khắc rất động viên.

Vấn đề là, khi một nhà phát triển theo đuổi các sửa lỗi nhanh, họ thường bỏ qua các vấn đề dài hạn. Ví dụ, họ có thể sửa một lỗi hoặc thêm một tính năng, nhưng không nhận ra rằng cấu trúc của code đã lỗi thời.

Điều này có nghĩa là mỗi khi họ thêm một tính năng mới, họ sẽ phải làm việc nhiều hơn. Ngược lại, tái cấu trúc chương trình một lần sẽ làm cho việc thêm tính năng dễ dàng hơn trong tương lai.

Nếu bạn ưa chuộng việc sửa lỗi nhanh chóng hơn là giải quyết vấn đề cơ bản, bạn không đơn độc. Hệ thống thưởng của con người dễ bị tác động hơn bởi những sửa lỗi ngắn hạn hơn là những thay đổi dài hạn. Nhưng theo cách này, bạn đang chồng chất nợ kỹ thuật. Và điều đó có thể tốn kém bạn rất nhiều trong tương lai.

Nguy hiểm của sự sạch sẽ so với sự lộn xộn

Những nhà phát triển khẳng định rằng họ luôn viết code sạch sẽ đều đang nói dối hoặc đánh giá cao về bản thân mình. Dù vậy, có một vài lý do tại sao bạn không nên viết code quá sạch sẽ:

• Nếu mục tiêu của bạn là viết code sạch sẽ từ đầu, bạn đang tăng cơ hội bị Coder's Block. Để tránh tình trạng tắc nghẽn lớn xảy ra, tốt nhất là phát triển code một cách tự nhiên từ đầu. Điều này đặc biệt áp dụng nếu bạn là người mới bắt đầu.
• Một số nhà phát triển dành cả ngày để làm sạch code của họ chỉ vì mục đẹp. Tất nhiên, điều này có thể hữu ích nếu có nhiều người cộng tác khác hoặc nếu code sẽ được trình bày bằng bất kỳ cách nào. Nhưng thường thì làm cho code của bạn sạch sẽ tương tự như phẫu thuật thẩm mỹ cho sức khỏe tổng thể - có thể trông đẹp nhưng nó không giải quyết bất kỳ vấn đề sâu sắc nào.

Ngược lại, bạn cũng không muốn code của bạn quá lộn xộn. Quá nhiều lộn xộn khiến code của bạn khó bảo trì. Thiếu bảo trì dẫn đến sự mục nát của code, và trong tương lai dự án sẽ bị loại bỏ vì chúng gây hại hơn là ích.

Vì vậy, điều cần thiết là một sự cân bằc khỏe mạnh giữa kết quả nhanh chóng và code có thể bảo trì được. Hầu hết những nhà phát triển nghiêm túc hơn về phía lộn xộn, vì vậy tăng tính sạch sẽ là con đường đi đúng đắn. Tin tốt là một số thói quen tốt có thể ảnh hưởng lớn đến sự sạch sẽ và năng suất của một nhà phát triển.

Mẹo 1: Kiểm thử sớm và thường xuyên

Một số nhà phát triển tin tưởng quá mạnh vào nghệ thuật của họ đến mức xây dựng một dự án toàn bộ mà không chạy kiểm thử. Nhưng trừ khi nhiệm vụ đang hoàn toàn trivial, điều này sẽ gặp phải nguy hiểm.

Ngay khi họ thử biên dịch hoặc thực thi chương trình, màn hình tràn ngập các thông báo lỗi. Hoặc, tệ hơn nữa, lỗi không được phát hiện cho đến vài tháng sau, khi người dùng nhận ra rằng chương trình không hoạt động như mong đợi.

Đây là những thói quen xấu. Nếu làm việc trong ngành công nghiệp công nghệ đã dạy bạn điều gì đó, đó là:

Không bao giờ giả định rằng mọi thứ đều hoạt động như mong đợi nếu bạn chưa kiểm thử qua tất cả các tình huống.

Hãy cố gắng xây dựng một cái gì đó có thể chạy được càng sớm càng tốt. Ngay cả nếu đó là một điều rất, rất đơn giản. Và hãy kiểm thử nó ngay khi bạn có cơ hội. Như vậy, bạn có thể sửa lỗi ngay khi chúng được tạo ra.

Mẹo 2: Xây dựng cấu trúc tốt và định dạng một cách lộn xộn

Chasing quick fixes là hoàn toàn chấp nhận được miễn là cấu trúc cơ bản của code là tốt. Trong thực tế, những nhà phát triển thường cố gắng triển khai các sửa lỗi nhanh chóng trong một code có cấu trúc lộn xộn hoặc lạc hậu.

Trong trường hợp đó, nên đầu tư thời gian để cấu trúc lại code. Nếu sửa lỗi không được chú thích đúng cách hoặc có một số tên biến khó hiểu, điều đó cũng không phải là điều tồi tệ nhất. Nhưng cố gắng xây dựng một tính năng sạch sẽ trong một code lỗi là lãng phí thời gian và nguồn lực — có lẽ bạn sẽ phải viết lại nhiều nó đâu đó.

Do đó, một sự nhất quán tốt giữa sự sạch sẽ và tốc độ sẽ là giữ cho cấu trúc cơ bản sạch sẽ và cập nhật và làm một cách lộn xộn cần thiết trong chi tiết.

Mẹo 3: Dành thời gian cho việc tái cấu trúc

Mỗi khi bạn làm lộn xộn, bạn đang tạo ra nợ kỹ thuật. Giống như nợ tiền tệ, càng để lâu, nó càng trở nên đắt đỏ.

Ngược lại, việc dành ngày hoặc thậm chí cả tuần để làm sạch code không nghe có vẻ rất đầy cảm hứng đối với nhà phát triển thông thường. Đó là lý do tại sao nó có thể hữu ích để thiết lập một lịch trình để trả nợ mỗi ngày.

Một cách tốt để bắt đầu là sử dụng 15% thời gian của bạn mỗi ngày để tái cấu trúc. Tôi gọi đây là quy tắc thời gian. Bạn sẽ ngạc nhiên với mức độ cải thiện code mà bạn có thể đạt được!

Mẹo 4: Để lại code sạch sẽ hơn khi bạn tìm thấy nó

Tôi gọi đây là quy tắc nhà vệ sinh. Nếu mọi người để lại nhà vệ sinh công cộng ít nhất là sạch sẽ như họ tìm thấy, chúng sẽ ở trong tình trạng tuyệt vời.

Nhìn vào tình trạng của hầu hết các nhà vệ sinh công cộng, thực tế không hoạt động theo cách này. Việc giữ một quy tắc như vậy đòi hỏi sự kỷ luật từ mỗi nhà phát triển — điều này lại đòi hỏi một quản lý xuất sắc.
Nhưng sự kỷ luật đáng giá, vì những phần thưởng theo thời gian có thể là khổng lồ. Bạn không đạt được điều không thể bằng cách thực hiện những điều không thể — bạn đạt được nó bằng cách đưa ra một số quyết định tốt và thực hiện những bước nhỏ hướng về phía chúng mỗi ngày.

Mẹo 5: Yêu cầu xem xét!

Đôi khi, một đoạn code bẩn bởi vì nhà phát triển không biết cách làm cho nó tốt hơn. Ví dụ, một đoạn code có thể sử dụng câu lệnh chuyển đổi trong khi một bản đồ sẽ dễ dàng hơn nhiều. Trong trường hợp này, lời khuyên của nhà phát triển cấp cao là quan trọng.

Thiết lập một lịch trình xem xét code có thể giúp tạo ra một vòng phản hồi. Điều này dẫn đến một đường học tốt hơn cho những nhà phát triển trẻ và tạo ra một văn hóa thảo luận lành mạnh.

Như với quy tắc nhà vệ sinh và quy tắc thời gian, thói quen là chìa khóa. Yêu cầu xem xét nên là một thói quen đối với nhà phát triển mới, và việc đưa ra lời khuyên nên là một phần quan trọng của công việc của nhà phát triển cấp cao.
Lý tưởng nhất, thời gian xem xét nên là một phần của quy trình cốt lõi của nhóm phát triển, và bản tóm tắt của những lời khuyên quan trọng nên là một phần của mỗi cuộc họp.

Cân bằng giữa cấu trúc và hỗn loạn

Quá nhiều việc làm sạch có thể là một lãng phí thời gian và nguồn lực. Và việc viết code lộn xộn còn tốt hơn là phải đối mặt với Coder’s Block và không giao hàng.

Ngược lại, code lộn xộn là không linh hoạt và khó bảo trì. Năm quy tắc sẽ giúp code của bạn sạch sẽ hơn mà không làm lãng phí thời gian. Như trong mọi lĩnh vực của cuộc sống, những điều tốt đẹp được tạo ra với sự cân bằng lành mạnh giữa cấu trúc và hỗn loạn.

Bài viết này được viết bởi Ari Joury và ban đầu được xuất bản trên Towards Data Science. Bạn có thể đọc nó ở đây.