Có việc hay không cũng đừng tối ưu hiệu suất một cách bừa bãi 😂 Mới thấy một bình luận: > Một khi đã quy mô hóa, ngay cả những lỗi mà bạn viết ra cũng sẽ có người dùng. Công việc đầu tiên của tôi sau khi tốt nghiệp đại học là ở một công ty, khi vào làm có một buổi hội thảo đào tạo nhân viên mới rất hoành tráng. Một ngày nọ, họ kể cho chúng tôi một câu chuyện: đó là vào giữa những năm 90, đội ngũ kỹ thuật đã tối ưu thời gian tải phần mềm từ 5 phút xuống còn 30 giây. Kết quả là, phản hồi tiêu cực từ khách hàng bùng nổ ngay lập tức. Việc tối ưu thời gian tải này đã phá hủy văn hóa doanh nghiệp của công ty đó. Hóa ra, trước khi tối ưu, mọi người đến văn phòng, mở máy tính, tận dụng 5 phút thời gian tải để trò chuyện, uống cà phê, bắt đầu một ngày làm việc thoải mái. Còn bây giờ, chưa kịp đứng dậy khỏi bàn làm việc, phần mềm đã sẵn sàng, thúc giục họ làm việc! Ý nghĩa của câu chuyện này — và câu trích dẫn ở trên — không phải là bảo bạn đừng cải tiến mọi thứ. Ngược lại, đó là một lời nhắc nhở: phần mềm bạn xây dựng không chỉ tồn tại trong PRD (Tài liệu yêu cầu sản phẩm) hoặc bộ kiểm thử. Nó là một hệ thống tương tác với con người trong thế giới thực. Mọi người sẽ hình thành thói quen xung quanh nó, phát triển các phương pháp thay thế (Workarounds), thậm chí phụ thuộc vào một số lỗi vì các tình huống sử dụng thực tế. Điều này rất quan trọng đối với bạn với tư cách là một kỹ sư phần mềm: bạn phải hiểu mục đích thực sự của phần mềm và cách sử dụng của nó trong thế giới thực. Công việc của bạn không phải là hoàn thành một đống công việc (Tickets) mà quản lý sản phẩm giao cho, công việc của bạn là xây dựng phần mềm có thể giải quyết vấn đề của người dùng. Liên kết: