SDLC LÀ GÌ? TẠI SAO MỌI ENGINEER PHẢI BIẾT?
SDLC LÀ GÌ? TẠI SAO MỌI ENGINEER PHẢI BIẾT?
Hey các kỹ sư! Hôm nay là một ngày phù hợp để ta cùng nói về SDLC - cái thứ mà hồi xưa mình cứ nghĩ "học làm gì cho mất công" nhưng hóa ra lại là thứ cứu ta khỏi OT đến 2-3h sáng.
Câu chuyện của một dự án "vỡ mồm"
Năm 2018, một trong những dự án đầu tiên của mình: Làm hệ thống detect xe ô tô trên đường cho một công ty Nhật. Mục đích? Đánh giá mức độ tập trung của người lái xe. Ngoài detect xe, còn phải segment đường, nhà, vỉa hè nữa.
Mình tự tin lắm: "MaskRCNN có sẵn, COCO dataset có class Car rồi, accuracy trên paper 90%+. Ez!"
Demo lần đầu, mình khoe:
- "Anh xem, detect xe ngon lành cành đào!"
- "Segment đường, nhà cũng chuẩn luôn!"
Khách hàng Nhật lịch sự: "Sugoi desu ne! Nhưng mà… sao không thấy xe kei car?"
"Xe gì cơ?" - Mình ngơ ngác.
Hóa ra ở Nhật có một loại xe "hộp diêm" (kei car) siêu phổ biến - chiếm 1/3 số xe trên đường. Nhưng COCO dataset của Mỹ làm gì có mấy xe kiểu này!
Kết quả:
- Model detect được Camry, Accord ngon lành
- Nhưng mấy xe hộp vuông vức như Suzuki Wagon R, Honda N-Box? Blind spot hoàn toàn!
- 30% xe trên đường không detect được = Hệ thống vô dụng
Phải làm lại từ đầu: Thu thập data kei car, label lại hàng nghìn ảnh, fine-tune model…
May mắn là khách hàng hiểu chuyện: "Các class khác OK rồi, em cứ tập trung fix xe kei car đi". Nhưng deadline 2 tháng thành 4 tháng, budget x2.
Lúc đó mình mới ngộ ra: Không phải cứ có pre-trained model là xong. Phải hiểu context, phải validate với real data của khách hàng!
Đại khái là nghĩ mình ngon rồi cắm đầu vào "code" là chết!
SDLC là gì?
SDLC (Software Development Life Cycle) nghe thì cao siêu, nhưng thực ra nó chỉ là cách làm việc có đầu có đuôi.
Giống như khi bạn train một model AI vậy:
- Không thể vội train ngay mà chưa biết: Task là gì? Data ở đâu? Metrics nào?
- Phải clean data, chia train/test set
- Chọn architecture, tune hyperparameters
- Evaluate kỹ càng, không phải chỉ nhìn accuracy
- Deploy lên production, monitor performance
- Fix bug, retrain khi data drift
SDLC cũng vậy - nó giúp mình không bị lạc trong rừng code, không bị khách hàng chửi vì làm sai yêu cầu.
Tại sao mọi Engineer phải biết?
1. Vì công ty nào cũng dùng (kể cả startup)
- Interview xong, ngày đầu đi làm: "Em vào daily standup lúc 9h nhé"
- Sếp hỏi: "Story này estimate bao nhiêu story points?"
- PM bảo: "Tuần này mình close sprint, em update Jira chưa?"
Không biết = ngồi ngơ ngác như vịt nghe sấm.
2. Vì nó cứu bạn khỏi làm lại n lần
True story: Có đứa bạn mình làm feature mất 2 tuần. Demo cho khách, khách lắc đầu: "Không phải cái này em ơi". Lý do? Không ai viết requirement rõ ràng, không ai confirm với khách trước khi code.
Còn mình? Dự án detect xe kei car fail vì:
- Không plan: Nghĩ COCO dataset là đủ → Quên mất xe Nhật khác xe Mỹ
- Skip analysis: Không hỏi kỹ "xe nào phổ biến ở Nhật?" → Mất 30% xe trên đường
- Bỏ qua testing với real data: Test với ảnh từ internet → Production là dashcam Nhật Bản
3. Vì nó quyết định career path của bạn
SDLC có những gì?
Nói nôm na, SDLC có 7 bước chính:
Có mấy cách làm?
Có 2 trường phái chính:
Lời khuyên cho Engineers
- Join project open source - Xem người ta làm việc thế nào, PR merge kiểu gì
- Làm side project "nghiêm túc" - Tự ép mình qua đủ 7 bước, từ planning đến deployment
- Đọc postmortem - Google "engineering postmortem", học từ sai lầm của người khác
- Hỏi trong interview - "Anh chị dùng process gì? Agile hay Waterfall?" → Biết ngay công ty có bài bản không
Kết
Nhìn lại 7 năm đi làm, mình nhận ra:
- Những dự án thành công đều có quy trình rõ ràng
- Những dự án fail đều vì "skip" vài bước trong SDLC
- Những đêm OT đều vì không plan, không test kỹ
SDLC không phải thứ gì cao siêu. Nó chỉ là cách để mình làm việc thông minh hơn, không phải cực nhọc hơn.
Bài sau mình sẽ break down từng giai đoạn của SDLC. Trust me, nó practical hơn bạn nghĩ nhiều!
Đi vào chi tiết
Americano Everyday
P/S: Ai đang gặp vấn đề gì với project hiện tại, comment mình tư vấn cho. Been there, done that! 😄
