2coffee.dev

Khoảng thời gian sau đi làm 1-2 năm là thời điểm sung sức nhất với việc lập trình, tôi có thể tưởng tượng ra trong đầu nhiều cách để giải quyết một vấn đề, thậm chí nghĩ xem nên làm theo cách nào mới "đẳng cấp" nhất. Suy nghĩ thật đơn giản: Cách nào được nhiều người khuyên, nhiều người áp dụng... hẳn là cách tốt nhất. Một logic ban đầu trông không có gì nhưng sau khi đi qua vài lớp suy nghĩ đã dày cộp như chiếc bánh burger, bởi một hàm phải đi qua vài lớp bọc để sẵn sàng "cover" nhiều trường hợp sau này.

Viết code có thể nói là một công việc thú vị, giải quyết được một bài toán có thể khiến tâm trạng vui lên cả ngày, mang đến nhiều câu chuyện để chém gió với đồng nghiệp, phân tích, mổ xẻ vấn đề ngỡ chưa ai biết. Nhưng hầu hết câu chốt đều đặt nghi vấn: "Thế còn hiệu năng thì sao?". Mã viết ra chạy được là một chuyện, nhưng đã bao giờ bạn đặt câu hỏi làm thế nào để biết mã mình viết ra đủ tốt hay chưa? Nhiều người nghĩ rằng chỉ cần tuân theo thực hành tốt nhất (Best Practices) thì ắt hẳn nó sẽ chạy nhanh nhất. Điều đó đúng nhưng chưa đủ, nếu ai cũng chắc chắn mã mình viết ra là tốt thì đâu đâu cũng có những hệ thống hoàn hảo. Mã chạy nhanh hay không phụ thuộc vào rất nhiều yếu tố chứ không chỉ riêng cách viết. Người ta thường không dựa vào cảm tính để đánh giá một logic là nhanh hay chậm, mà muốn chứng minh được phải dựa trên số liệu, hay ít nhất là cần phải biết đoạn mã nào đang tốn thời gian xử lý. Sau khi mọi thứ bày ra trước mắt từ đó mới tìm ra cách tối ưu.

Profiling là phương pháp được

Mấy hôm nay chuyển từ VSCode sang sử dụng Zed vì một số lý do. Zed là một trình soạn thảo mã viết bằng Rust rất nhẹ và có giao diện tương đồng với VSCode ở nhiều chỗ. Tuy vậy Zed vẫn có những điểm khác biệt và đi theo triết lý riêng của họ. Cá nhân mình đã sử dụng Zed từ những ngày đầu ra mắt, ấn tượng ban đầu là rất nhanh và mượt. Tuy nhiên rất nhiều tính năng quen dùng trên VSCode lại không có trên Zed nên chỉ dừng lại ở mức trải nghiệm.

Một trong những tính năng mình thường xuyên sử dụng là debug bằng breakpoint, chọn vị trí rồi quan sát luồng dữ liệu trong hệ thống. VSCode là trình soạn thảo phổ biến cho nên bật debug dễ dàng hơn nhiều. Thường chỉ mất vài thao tác, đặc biệt nếu sử dụng framework thì bạn còn dễ dàng tìm thấy hướng dẫn trên mạng. Nói chung là VSCode làm rất tốt việc tối giản cho người sử dụng.

Vì vậy sau khi chuyển

Đây có thể là bài viết cuối cùng của chuỗi MCP cơ bản trong chuyên mục Posts của blog. Đúng ra dự định không viết thêm nữa do Prompts & Resources trong MCP có tài liệu rất hạn chế, nhưng vì đây là hai phần thú vị nên giới thiệu chúng đến bạn đọc.

Mình đã đọc và nghiên cứu tài liệu về hai mục này trên trang chủ của MCP, sau khi hiểu được nguyên tắc và trường hợp sử dụng thì sau đó có đi tìm một số dự án đã tích hợp với dự định bổ sung thêm ví dụ trong bài viết, nhưng xem ra rất ít dự án triển khai hai thành phần này. Tại sao?

Theo quan điểm cá nhân