Tôi dành rất nhiều thời gian để suy nghĩ về code. Code tốt. Code dễ đọc, dễ hiểu đến mức người đọc không bao giờ phải thốt lên: “Ê, ý đồ của đoạn code này không rõ ràng, giải thích giúp với! Lên Zoom call cái nhỉ!” Thật lòng mà nói, ai cũng ngán ngẩm Zoom rồi.
Vậy nên, tôi tự hỏi: “Điều gì tạo nên code tốt?” 🤔 Có phải là độ thông minh của nó? Hay hiệu quả? Hay chỉ cần viết một dòng lệnh để chạy toàn bộ dự án? Câu hỏi này ám ảnh tôi rất lâu, cho đến một ngày, tôi nhận ra:
Codebase này thật nhàm chán! 💯
Khả năng tìm ra các mẫu chuẩn và có thể tái tạo đã khơi nguồn một trong những cuộc trò chuyện thú vị nhất mà tôi từng có với một đội ngũ kỹ sư: trong một buổi retrospective, một thành viên trong nhóm đã dán một mẩu giấy vào cột Những điều đã diễn ra tốt đẹp với nội dung “Codebase này thật nhàm chán!”
Và bùm! 💥 Ngay lập tức, tôi nhận ra đó chính là câu trả lời mà tôi tìm kiếm: code nhàm chán!
Chúng tôi làm việc với rất nhiều đội ngũ kỹ sư thuộc mọi quy mô: từ các startup giai đoạn đầu đến các tập đoàn lớn, và tư duy của chúng tôi là luôn cung cấp cùng một mức chất lượng, sự chú ý đến chi tiết và khả năng mở rộng cho các đối tác của mình. Chúng tôi hướng đến việc xây dựng các ứng dụng có khả năng mở rộng để chúng có thể phát triển và thay đổi cùng với công ty.
Bạn có thể nói rằng chúng tôi có một mô hình “lặp đi lặp lại”: một thứ mà chúng tôi có thể triển khai hiệu quả nhiều lần. Chúng tôi tập trung vào việc tìm kiếm các giải pháp và mẫu chuẩn mà chúng tôi có thể sao chép: nếu chúng tôi đã giải quyết một vấn đề trong một dự án, chúng tôi có thể mô-đun hóa nó và biến nó thành một gói chung có thể được sử dụng khi các dự án khác đang cố gắng làm điều tương tự.
Bạn điên à!? 🤪 Làm sao code nhàm chán lại có thể là code tốt? 🤓
Hầu hết những việc chúng ta làm trong một ứng dụng di động, nói thật lòng, đều ít nhiều giống nhau: lấy dữ liệu từ đâu đó, áp dụng một số biến đổi, lưu vào bộ nhớ cache và sau đó hiển thị nó trên màn hình. Và nhiều tính năng có trong một ứng dụng cũng giống nhau, bất kể lĩnh vực kinh doanh của chúng là gì: tạo tài khoản, xác thực, hiển thị các điều khoản và điều kiện, đăng xuất người dùng, v.v.
Tạo ra code nhàm chán là lời khen lớn nhất mà một đội ngũ kỹ sư có thể nhận được; xét cho cùng, “những điều bất ngờ” trong một dự án thường có xu hướng là những điều không mấy tốt đẹp. Không ai thích nhận được một cuộc gọi khẩn cấp lúc 2 giờ sáng, hoặc dành 8 giờ để truy tìm một lỗi gần như không thể tái tạo và với tư cách là kỹ sư, chúng ta không thích giải quyết cùng một vấn đề lặp đi lặp lại.
Có một codebase dễ đoán, dễ điều hướng, được kiểm tra kỹ lưỡng và tự động hóa đúng cách khiến nó trở nên nhàm chán. Nhưng nhàm chán một cách dễ chịu! Và điều đó thật tuyệt vời, các nhóm rất thích cảm giác đó! Nó cho phép họ tập trung vào những thách thức thực sự và liên quan đến kinh doanh của họ mà không bị phân tâm bởi các nhiệm vụ khác.
Làm thế nào để codebase của tôi trở nên nhàm chán? 👩💻👨💻
Theo quan điểm của chúng tôi, có hai thành phần chính để làm cho codebase của bạn trở nên tốt… Ý tôi là nhàm chán 😉:
-
API siêu tường minh, rõ ràng như pha lê, không gây bất ngờ: Mỗi thành phần trong dự án của bạn được hiển thị công khai không nên khiến người tiêu dùng nghĩ “Liệu điều này có thực sự hoạt động không?” Thay vào đó, phản hồi bạn muốn họ có là “Tôi không thể tin được điều này lại dễ dàng đến vậy!”
-
Hãy tự hỏi: “Code này có thuộc về đây không?” Câu hỏi này vượt ra ngoài câu hỏi cổ điển “Code này nên được viết ở backend hay ở client?” Trong code client của bạn, bạn nên phân biệt giữa các thành phần thu thập dữ liệu (mạng, cơ sở dữ liệu, GPS, bluetooth, máy ảnh), các quy tắc kinh doanh của bạn (ví dụ: Tôi cần lấy vị trí hiện tại của mình để tìm nạp từ mạng tất cả các nhà hàng đang mở phục vụ món tapas Tây Ban Nha gần tôi) và cách trình bày thông tin đó cho người dùng (trong trường hợp Flutter, đây là cách bạn sử dụng các widget của mình và cách quản lý trạng thái của chúng).
Với hai ràng buộc đó hướng dẫn quy trình phát triển của chúng tôi, chúng tôi có thể dễ dàng hình dung bất kỳ ứng dụng nào trên thế giới được mô hình hóa theo các nguyên tắc đó. Ví dụ: một ứng dụng giao đồ ăn có thể được phân tách thành các thành phần như sau:
Sơ đồ phân tách các thành phần trong codebase nhàm chán của ứng dụng giao đồ ăn
Các phần duy nhất của ứng dụng này nên là duy nhất là các quy tắc kinh doanh và các thành phần trình bày: xét cho cùng, chính trong các quy tắc kinh doanh mà sản phẩm mang lại giá trị, và chính ở phía trình bày mà sản phẩm trở nên dễ chịu khi sử dụng. Tuy nhiên, các thành phần thu thập dữ liệu có thể được sử dụng lại bởi nhiều ứng dụng nhiều lần.
Cách tiếp cận này có thể được áp dụng cho bất kỳ ứng dụng Flutter nào, từ ví dụ đơn giản nhất bạn có thể nghĩ đến đến nền tảng doanh nghiệp với hàng triệu người dùng. Chúng tôi đã lặp lại mẫu này nhiều lần, đến nỗi việc áp dụng nó bây giờ hơi nhàm chán! 🥳 Và chúng tôi rất vui vì đã tìm thấy sự nhàm chán trong phát triển, bởi vì giờ đây các nhóm của chúng tôi có thể thực hiện một cách hiệu quả, dễ đoán và không còn bất ngờ nào nữa!
Chúng tôi muốn giúp bạn trở nên rất nhàm chán!
Một phần trong các giá trị cốt lõi của chúng tôi là chia sẻ với cộng đồng những thách thức mà chúng tôi đã đối mặt và giải quyết để tất cả chúng ta có thể tiếp tục làm việc trên những thách thức thú vị và phức tạp hơn. Chúng tôi đang lên kế hoạch phát hành một loạt các bài viết chi tiết về cách chúng tôi biến code của mình thành code tốt, nhàm chán. Hãy theo dõi!
