Giới Thiệu

Trong phần 4 này của chuỗi bài viết về việc xây dựng menu ngữ cảnh bổ sung, tôi sẽ chia sẻ những trải nghiệm gỡ lỗi lúc 3 giờ sáng mà gần như đã khiến tôi bỏ cuộc. Mỗi lập trình viên đều cần nghe những câu chuyện này.

Tóm Tắt Ngắn Gọn 🎯

Việc phát triển tiện ích mở rộng VS Code này chỉ có 10% là cảm hứng và 90% là gỡ lỗi những trường hợp không ngờ tới. Từ một gói 601KB khiến người dùng khóc, đến việc viết 37 bài kiểm tra để phát hiện lỗi chỉ xảy ra lúc 3 giờ sáng, và cuộc khủng hoảng triết lý giữa AST và Regex. Nhưng những đột phá đó đã làm cho mọi thứ trở nên đáng giá! ⚡

Câu Chuyện Kinh Hoàng Về Kích Thước Gói 💀

Khoảnh Khắc Mọi Thứ Đổ Vỡ

Tưởng tượng cảnh tôi sắp sửa phát hành phiên bản 1.0. Tôi chạy lệnh npm run build và thấy:

✅ Xây dựng hoàn tất: gói 601KB

601KB. Đối với một tiện ích mở rộng menu ngữ cảnh. 😱

Đó là lớn hơn một số trang web hoàn chỉnh! Hướng dẫn của VS Code khuyến nghị rằng các tiện ích mở rộng nên giữ dưới 50KB. Tôi đã xây dựng một con quái vật sẽ mất rất nhiều thời gian để tải xuống, tiêu tốn bộ nhớ khổng lồ và khiến VS Code cảm thấy chậm chạp.

Tôi đã nhìn chằm chằm vào màn hình trong 10 phút không thể tin nổi.

Cuộc Điều Tra Gói Lớn

Tôi đã tiến hành phân tích gói và tìm ra nguyên nhân:

• Hệ sinh thái Babel: 400KB+ thư viện phân tích cú pháp AST
• Chi phí của Webpack: 150KB+ cơ sở hạ tầng gói
• Phụ thuộc không sử dụng: 50KB+ các gói "chỉ phòng khi"

Tiện ích mở rộng đáng lẽ phải giúp lập trình viên làm việc hiệu quả hơn. Thay vào đó, nó trở thành phần mềm thừa thãi. 🤦‍♂️

Giải Pháp Từ esbuild

Sau một cuối tuần tháo gỡ webpack và xây dựng lại bằng esbuild:

Trước: gói 601KB trong 19 giây 😴
Sau: 24.75KB trong 0.8 giây ⚡

Cải thiện: nhỏ hơn 95.9%, nhanh hơn 20 lần

Thay đổi duy nhất này đã biến mọi thứ. Người dùng từ "tại sao lại chậm thế này?" thành "wow, cảm giác như có sẵn!"

Cơn Ác Mộng Kiểm Tra Đã Tốn Rất Nhiều Năng Lượng Của Tôi 🧪

Khi "Nó Chạy Trên Máy Tôi" Không Đủ

Tôi bắt đầu với 19 bài kiểm tra cơ bản. Tất cả đều vượt qua. Tôi rất tự tin. Sau đó, người dùng bắt đầu báo cáo những trường hợp kỳ lạ:

• Tiện ích mở rộng bị treo trên các tệp có emoji trong tên hàm 🎉
• Kết hợp import thất bại với các tệp 1000 dòng
• Menu ngữ cảnh tự nhiên biến mất trong các không gian làm việc
• Chức năng sao chép gặp lỗi trong mã lồng nhau sâu (20+ cấp độ)

Mỗi báo cáo lỗi đều như một cuộc tấn công cá nhân vào năng lực của tôi như một lập trình viên.

Hố Thỏ Các Trường Hợp Ngoại Lệ

Tôi đã dành hai tuần viết thêm 18 bài kiểm tra cho các trường hợp ngoại lệ mà tôi không bao giờ tưởng tượng nổi:

// Ai viết mã như thế này? Hóa ra là mọi người.
const 🚀rocket = () => {
  const nested = () => {
    const deeper = () => {
      const evenDeeper = /* 15 cấp độ nữa */ "hỗn loạn";
    };
  };
};

Bài kiểm tra yêu thích của tôi: "Phải xử lý các hàm có ký tự đặc biệt trong đường dẫn trên hệ thống Windows có tên thư mục chứa khoảng trắng trong khi người dùng đang gõ."

Đúng, đó là một bài kiểm tra thực sự. Vâng, nó đã thất bại.

Khoảnh Khắc Đột Phá

Sau bài kiểm tra số 37, một điều gì đó đã sáng tỏ. Tôi không chỉ sửa lỗi - tôi đang xây dựng độ tin cậy không thể phá vỡ. Mỗi trường hợp ngoại lệ làm cho tiện ích mở rộng mạnh mẽ hơn.

Kết quả cuối cùng: 37/37 bài kiểm tra đều vượt qua ✅

Người dùng ngừng báo cáo lỗi. Tiện ích mở rộng trở nên vững chắc. Đáng giá cho mọi phiên gỡ lỗi lúc 3 giờ sáng!

Cuộc Chiến Triết Học Lớn: AST So Với Regex 🥊

Cách "Đúng" Gần Như Đã Giết Tôi

"Bạn PHẢI sử dụng Cây Cú Pháp Trừu Tượng để phân tích! Regex chỉ dành cho những người nghiệp dư!" - Mọi giáo sư khoa máy tính từng có

Tôi đã xây dựng một trình phân tích cú pháp AST đẹp đẽ và hoàn hảo về mặt học thuật với Babel:

// Cách "đúng" (đã thêm 400KB vào gói)
import { parse } from '@babel/parser';
import traverse from '@babel/traverse';

const ast = parse(code, {
  sourceType: 'module',
  plugins: ['typescript', 'jsx', 'decorators', 'classProperties']
});

Nó thật thanh lịch. Nó xử lý mọi trường hợp ngoại lệ. Nhưng cũng khổng lồ, chậm chạp và quá mức cần thiết để tìm ranh giới hàm.

Giải Pháp Regex Bất Hợp Pháp

Lúc 2 giờ sáng, kiệt sức và thất vọng, tôi đã có một suy nghĩ cấm kỵ:

"Liệu tôi có thể... sử dụng regex không?" 😈

// Cách "sai" nhưng thực sự hoạt động hoàn hảo
const functionPattern = /^(\s*)(?:export\s+)?(async\s+)?function\s+(\w+)/gm;

Kết quả thật bất ngờ:

• ✅ Tiết kiệm hơn 400KB cho gói
• ✅ Thực thi nhanh hơn 10 lần
• ✅ Độ chính xác 95% (hoàn hảo cho mã trong thực tế)
• ✅ Không có sự thừa thãi về phụ thuộc

Đôi khi giải pháp "sai" lại chính xác là điều đúng đắn. 🎯

Cú Đảo Ngược Phản Hồi Từ Người Dùng Đã Thay Đổi Mọi Thứ 🔄

Bình Luận Đã Phá Vỡ Những Giả Định Của Tôi

Tôi đã quá mải mê với các tính năng nâng cao khi bình luận này xuất hiện:

"Yêu thích tiện ích mở rộng! Nhưng thực sự, tôi chỉ muốn 'Lưu Tất Cả' hoạt động một cách đáng tin cậy. Những thứ fancy thì tốt, nhưng tôi cần những cơ bản phải chắc chắn." - Sarah, Lập Trình Viên React

Tâm trí tôi bị chấn động. 🤯

Tôi đã xây dựng một chiếc Ferrari khi người dùng cần một chiếc Honda Civic đáng tin cậy.

Thay Đổi Ưu Tiên

Bình luận này đã kích hoạt một sự thay đổi hoàn toàn trong chiến lược:

• Trước: Thêm nhiều tính năng, gây ấn tượng với độ phức tạp
• Sau: Hoàn thiện các tính năng cốt lõi, tập trung vào độ tin cậy

Tôi đã dành tháng tiếp theo:

• Làm cho chức năng Lưu Tất Cả xử lý các trường hợp ngoại lệ một cách khéo léo
• Thêm phản hồi tiến trình cho các thao tác dài
• Cải thiện thông báo lỗi và khôi phục
• Kiểm tra trên các mã nguồn lớn

Kết quả: Người dùng bắt đầu nói rằng nó "cảm giác như VS Code nên được trang bị sẵn tính năng này."

Đó là lúc bạn biết bạn đã làm đúng. ✨

Những Khoảnh Khắc Chiến Thắng Khiến Mọi Thứ Đáng Giá 🏆

Khi Tối Ưu Hiệu Suất Được Thực Hiện

Nhìn thấy thời gian xây dựng giảm từ 19 giây xuống dưới 1 giây giống như phát hiện ra lửa. Sự chuyển mình trong trải nghiệm phát triển là không thể tin được - tôi có thể lặp lại nhanh gấp 20 lần!

Khi Tất Cả Các Bài Kiểm Tra Cuối Cùng Đều Vượt Qua

Sau nhiều tuần thất bại, thấy rằng "37/37 vượt qua" là một niềm vui thuần khiết. Mỗi trường hợp ngoại lệ đã bị chinh phục, mọi lỗi đã được loại bỏ.

Khi Người Dùng Bắt Đầu Nói "Ma Thuật"

Lần đầu tiên có người bình luận "Tiện ích mở rộng này đọc suy nghĩ của tôi" - đó là khoảnh khắc mà tất cả những phiên gỡ lỗi lúc 3 giờ sáng đều trở nên đáng giá.

Những Bài Học Đáng Nhớ 🧠

Hiệu suất quan trọng hơn tính năng. Người dùng có thể tha thứ cho việc thiếu tính năng. Họ không thể tha thứ cho phần mềm chậm và không đáng tin cậy.

Các trường hợp ngoại lệ có mặt ở khắp mọi nơi. Trường hợp ngoại lệ kỳ lạ mà bạn nghĩ rằng không ai sẽ gặp phải? Có người đang gặp phải ngay bây giờ.

Phản hồi từ người dùng quan trọng hơn giả định cá nhân. Lắng nghe những gì người dùng thực sự cần, chứ không phải những gì bạn nghĩ họ muốn.

Giải pháp đơn giản thường tốt hơn giải pháp phức tạp. Đôi khi regex THỰC SỰ tốt hơn phân tích cú pháp AST. Đánh tôi đi. 😄

Kiên trì quan trọng hơn hoàn hảo. Những phiên gỡ lỗi lúc 3 giờ sáng đã dạy tôi nhiều hơn bất kỳ khóa học nào.

Điều Gì Đang Đến Tiếp Theo 🚀

Trong Phần 5, tôi sẽ chia sẻ lời khuyên dành cho chính mình trong quá khứ (và bạn!) về việc xây dựng các công cụ cho lập trình viên không tệ. Ngoài ra, một cái nhìn thoáng qua về những tính năng thú vị dự kiến cho phiên bản 2.0!

Hành trình này thật khắc nghiệt, giáo dục và cuối cùng là đáng giá. Mọi lần xây dựng bị treo, mọi bài kiểm tra thất bại, mọi báo cáo nhầm lẫn từ người dùng đều đã làm cho tiện ích mở rộng tốt hơn.

Hãy thử ngay! Cài đặt menu ngữ cảnh bổ sung và xem những cải tiến mà bạn đã phải trải qua.

Sắp tới: Phần 5 - Những Gì Tôi Sẽ Nói Với Chính Mình Về Việc Xây Dựng Các Tiện Ích Thực Sự Giúp Đỡ Lập Trình Viên 🎯

*Bạn có câu chuyện gỡ lỗi tệ nhất nào không? Hãy để lại trong phần bình luận - tôi cần cảm thấy tốt hơn về cuộc đi săn dấu chấm phẩy 6 giờ của mình! 😅