Những quy tắc gây sốc trong phát triển phần mềm

Khi tham gia một dự án, chắc chắn ai cũng muốn tạo ra những sản phẩm chất lượng tốt, giá thánh rẻ, tạo được sự tin tưởng của khách hàng. Để làm được điều đó, bạn phải “quán triệt, thấm nhuần những quy tắc trong phát triển phần mềm sau”

Phát triển phần mềm “Đúng Quy Trình”

Quy trình phát triển phần mềm là một tập hợp các hoạt động tổ chức mà mục đính là xây dựng và phát triển phần mềm, đảm bảo cho sản phẩm đạt chất lượng.

Ở Fsoft quá trình phát triển phần mềm cũng nhiều thay đổi, các dự án cũng lớn dần, từ “dự án có hàng trăm member” đến những “hàng trăm member một dự án”, nên việc follow đúng process thực sự quan trọng.

Có một số quy trình phát triển phần mềm đã được các nhà khoa học nghiên cứu và được áp dụng như một “hệ tư tưởng” như waterFall, V-Shaped, mô hình phát triển phần mềm tuần tự từ Architecture Design, Detail Design đến Code, Test. Đặc biệt là Scrum Agile. Mô hình cho phép chia quá trình phát triển thành nhiều giai đoạn nhỏ (Sprint) để đảm bảo detect sớm được issues.

Tuy nhiên thực tế dự án, do những lý do như tight schedule, change requirement, PM vẫn “vi phạm vào đường lối, chủ trương” của các mô hình phát triển trên, hiện tượng code trước design sau, code không có design, project không có plan, schedule là có, nên cần có đội ngũ QA để review process.

Ngoài ra, các công ty phần mềm còn áp dụng mô hình CMMI (Capability Marturity Model Integration) với 5 level để phục vụ cho cải tiến quy trình phần mềm

Đảm bảo tỉ lệ bug “Ổn định”

Bất kì giai đoạn nào trong phát triển phần mềm, từ Architecture design, detail design đến coding đều có thể sinh ra bug. Chính vì thế, các dự án đều cần đến đội ngũ QA, TQA và tester, những người phụ trách kiểm thử phần mềm.

Coder và Tester, PM và QA là những người kiểu “chúng ta không thuộc về nhau”, “quyết tâm tìm lỗi của nhau”. Những tình huống thường gặp phải là

Chúng tôi đã kiểm tra kĩ lưỡng từng dòng code “Kết luận coding đúng convention, suốt dự án không tìm thấy bug nào”

Source code có đến mấy trăm K line of code, bị vài chục bug là tốt rồi

Đây không phải là lần đầu tiên gặp bug này, đề nghị nên định hướng cho QA và Tester chuẩn bị tâm lý để “đỡ sốc”

App phải bị crash lăn ra chết mới gọi là bug, app vẫn chạy(như rùa bò) không thể nói là bug

Thực tế, khi bắt đầu một dự án, PM luôn đặt ra các target cho QCD (Quality, Cost, Delivery) của mình, quy định rõ tỉ lệ bug là bao nhiêu (norm value). Nếu số bug quá cao hoặc quá thấp so với con số này thì đó là điều không bình thường cần phải “giải trình trước quốc hội”.(QA, PMO). Việc test mà không có bug nào là việc khiến KH “hết sức quan ngại” vì đó có thể là chất lượng testing quá thấp, tóm lại tỉ lệ bug phải tăng theo “lộ trình để đỡ sốc”

“Nghiêm khắc kiểm điểm và rút kinh nghiệm sâu sắc” sau mỗi dự án

Mỗi khi dự án kết thúc, đội QA sẽ thực hiện “KPI” để đánh giá dự án.

K (Keep) : Đánh giá những mặt tốt cần phát huy

P (Problem): Những điểm chưa được, khiếm khuyết của dự án cần rút ra

I (Improvement): Biện pháp cải thiện cho sau này

Thường các dự án, “sợi dây kinh nghiệm” sẽ dài như vạn lý trường thành, “rút mãi không hết”. Những sai sót xảy ra trong dự án có thể là “phạm lỗi lần đầu” hơn nữa đội dự án “đã hết sức hợp tác với QA, tích cực khắc phục hậu quả” nên cơ bản là huề cả làng

“Cực lực phản đối và quan ngại sâu sắc” các sai lầm trong coding

Thực tế, coder vẫn giữ tư duy coding theo kiểu sinh viên nên ít để ý đến Coding convention, nguyên tắc SOLID trong coding, code không comments dẫn tới code viết phức tạp, khó hiểu, không maintain sau này, và đặc biệt là có “tư duy nhiệm kỳ”. “Em làm hết tháng rồi nghỉ dự án, không làm gì được, thôi nhường cho bạn đến sau”.

Thực tế một bộ source code có rất nhiều members cùng phát triển, nên quan trọng nhất là code phải dễ hiểu, có comment đầy đủ thì người sau mới hiểu được

Việc code tùy tiện hay dẫn tới những bug như stack overflow, memory leak, exception….

“Nguyên nhân dẫn tới các sai lầm trên còn liên quan đến thủ phạm gây ra nguyên nhân đó” có lẽ là do… “lỗi đánh máy” của coder, kiểu như “gạt ngón tay trúng nút delete nên xóa mất dòng code”

Source code trước khi test phải qua phase Review code để loại bỏ hết những lỗi trên trước khi test

Đảm bảo chất lượng dự án là “trách nhiệm của toàn developer, toàn tester, toàn…” tóm lại là trách nhiệm của tập thể. Quán triệt, thấm nhuần các quy trình quản lý phần mềm sẽ giúp project manager dẫn dắt project team “đi hết thắng lợi này đến thắng lợi khác”

Techtalk via giaosucan