Những điều khó đỡ trong ngành phần mềm #1

Gửi email bị sai thông tin

Hôm nọ mình bất lực trong việc tạo tài khoản thanh toán của TPBank và BIDV (quy trình onboarding rất lằng nhằng và phức tạp), nên mình chuyển sang tạo mới một tài khoản thanh toán của VCB.

Sau khi đăng kí xong thì ngay ngày hôm sau bên VCB gửi email thông báo đã cập nhật thông tin và hạn mức tài khoản thanh toán cho mình ở cái email trên, kiểu là tài khoản của bạn đã sẵn sàng rồi, sử dụng thôi.

Xong mình thấy buồn cười ở nội dung email, đăng lên linkedin chơi chơi thì thấy tự nhiên viral ghê. À mà mình cũng không check được là họ đã sửa lỗi này chưa, bạn nào mà đăng kí mới tài khoản VCB thì gửi ảnh mình xem với nhé.

Code trên nhánh phát triển quá rác so với master

Đây là điển hình của việc không làm sạch code trên nhánh develop (sai khác nhiều so với master), khiến việc tạo merge request từ các nhánh feature vào nhánh develop gặp rất nhiều thay đổi.

Thời gian resolve conflict cũng sẽ lâu hơn, tự nhiên mình thấy lười resolve conflict ngang luôn.

Trả message lỗi không thân thiện tới người dùng

Query 1 căn cước công dân mà đang bị trả duplicate hai bản ghi rồi nè, không ai trả lỗi hệ thống thế này về cho người dùng cả, handle lại exception đi nha.

Chưa kiểm tra dữ liệu null trước khi lấy ra update nên dẫn tới bị NullpointerException.

Không log stack trace error khi gặp exception

Không log full stack trace của error ra thì làm sao mà trace chính xác được là gặp lỗi gì đây? các bạn muốn xem log để biết rõ lỗi nó như thế nào hay là muốn ngồi đoán?

Làm IT không có stress tí nào đâu, hihi.

Đùa chứ, phải khi các bạn tự mình tối ưu từng dòng code, tối ưu connection pool db, http connection, thread, transaction, monitor statistic,… thì các bạn mới hiểu được rằng nó thực sự giúp ích rất rất nhiều trên con đường sự nghiệp của mình.

Gemini, Claude, ChatGPT,… các loại AI tạo ra code, và lại chính chúng nó review code của chúng nó.

Thứ 6 thì đừng có deploy gì cả

Đây là một rule làm việc khá tốt với team mình, việc golive vào thứ 6 đi kèm khá nhiều rủi ro về lỗi và nguồn lực.

Phàm những cái gì kiểu hotfix, incident gấp, hoặc những phần golive mới không bị ảnh hưởng đến những hệ thống hiện tại thì mình sẽ xử lý ngay, còn lại những change golive thông thường thì sẽ chỉ golive từ thứ 2 đến thứ 5 thôi.

Golive trong giờ hành chính thì còn xử lý nhanh được, chứ để cuối tuần hoặc tối muộn thì nên hạn chế, thời gian đó nên ở bên gia đình và nghỉ ngơi thì hơn.

Xem thêm các bài viết nổi bật bên dưới:

• Xác thực giao dịch trong hệ thống tài chính
• Đồng nghiệp tôi vừa mới Golive và bùm, race condition
• Tổng hợp dữ liệu cho 1 triệu tài khoản trong 4 phút
• Xử lý lỗi lệch múi giờ khi dùng Mapstruct
• Có CodeRabbit làm tôi review code cũng nhàn hơn
• Lỗi trên môi trường Staging mà không ai chịu sửa đến cùng
• Filter Spring và pha xử lý bug nhớ đời
• Những thói quen tốt trong ngành phát triển phần mềm
• Rest API: Cách Ngăn Chặn Duplicate Request Hiệu Quả
• Sức mạnh của AI CLI – trợ thủ đắc lực cho dân lập trình