Thực tế là chúng ta không được học cách phát triển phần mềm chất lượng cao

 (florianbellmann.com)
3 điểm bởi GN⁺ 2023-12-09 | 1 bình luận | Chia sẻ qua WhatsApp

Sự thiếu hụt đào tạo về cách xây dựng chất lượng phần mềm

  • Khi học khoa học máy tính ở đại học, việc đào tạo về đảm bảo chất lượng phần mềm (QA) thường bị bỏ sót.
  • Phần lớn thời gian được dành cho thuật toán, cách máy tính hoạt động, lịch sử của ngôn ngữ và các khái niệm.
  • Có học kỳ nói về phương pháp quản lý dự án và Scrum, nhưng hoàn toàn không đề cập đến QA.

Cách các công ty phát hành sản phẩm đúng hạn

  • Vì vấn đề ngân sách, các công ty thường loại bỏ tiêu chuẩn và biện pháp QA khỏi dự án đầu tiên.
  • Khi quá trình phát triển bị chậm hoặc phạm vi mở rộng, sẽ không còn đủ thời gian cho QA.
  • Họ phát hành phần mềm không ổn định sau khi chỉ trải qua mức kiểm thử tối thiểu và thiếu cấu trúc.

Cách thoát khỏi vòng quay bất tận

  • Phải mất nhiều năm để tích lũy kinh nghiệm và sự tự tin nhằm lên tiếng về những biện pháp QA còn thiếu trong dự án.
  • Người ta phát hiện ra phần giám sát còn thiếu và gặp các vấn đề như hệ thống production bị lỗi.
  • Nếu không triển khai các biện pháp QA, sẽ nảy sinh vấn đề là không thể học đúng cách.

Nói về tiền bạc

  • Việc giải thích rằng phần mềm sẽ “ổn định hơn” hoặc “dễ bảo trì hơn rất nhiều” không đủ cụ thể với những người không phải nhà phát triển.
  • Cần nói về cái giá của việc không làm QA.
  • Giải thích các biện pháp QA dưới góc độ chi phí kèm ví dụ là cách hiệu quả.

Liều lượng hiệu quả tối thiểu

  • Không nên thiết kế các biện pháp QA quá mức và cũng không nên cản trở tiến độ dự án.
  • Điều quan trọng là kiểm thử các chức năng cốt lõi của ứng dụng và xác nhận rằng chúng luôn hoạt động như mong đợi.
  • Sử dụng khái niệm “liều lượng hiệu quả tối thiểu” (MED) để bắt đầu từ những phần quan trọng nhất.

Những điều cần xem xét kỹ

  • Khi bắt đầu hoặc tham gia một dự án mới, hãy tìm các khái niệm QA.
  • Tài liệu hoặc kế hoạch kiểm thử cho thấy đội ngũ đã suy nghĩ về QA hay chưa là điều quan trọng.
  • Việc viết test cùng lúc khi viết mã mới giúp cấu trúc mã theo cách thực sự có thể kiểm thử được.

Lợi ích cho dự án

  • Bằng cách nói về chất lượng và đề xuất các giải pháp khả thi, bạn có thể mở rộng tầm ảnh hưởng của mình với tư cách là một nhà phát triển.
  • Các biện pháp QA giúp dự án phát triển với tốc độ lành mạnh.

Cách cải thiện dự án

  • Bằng cách sử dụng các biện pháp QA, bạn có thể được biết đến là người viết phần mềm chất lượng trong dự án.
  • Cần cân nhắc MED trong dự án và trở thành tiếng nói thúc đẩy thay đổi trong nhóm.

Ý kiến của GN⁺

Điều quan trọng nhất trong bài viết này là sự thiếu nhận thức về tầm quan trọng của đảm bảo chất lượng phần mềm (QA) trong quá trình phát triển phần mềm và về cách triển khai nó. QA thường bị bỏ qua, nhưng về lâu dài lại là yếu tố thiết yếu đối với thành công và sự ổn định của dự án. Bài viết này thú vị và hữu ích vì giúp các kỹ sư phần mềm mới vào nghề nhận ra tầm quan trọng của QA, đồng thời đưa ra những cách cụ thể để tích hợp QA vào các dự án thực tế.

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-12-09
Ý kiến trên Hacker News

  • Kỹ nghệ phần mềm thường không phải là chủ đề cốt lõi của khoa học máy tính (CS), mà thường được giảng dạy ở các mảng khác, dưới dạng môn tự chọn hoặc trong các khóa học về kỹ nghệ phần mềm.

    Tại CMU có các chương trình thạc sĩ và tiến sĩ về kỹ nghệ phần mềm, giảng dạy nhiều chủ đề khác nhau, bao gồm cả những nội dung được đề cập trong bài đăng blog.

  • Nhiều người cho biết việc cộng tác với những người có bằng khoa học máy tính dễ dàng hơn. Họ hiểu tầm quan trọng của thuật toán tốt và không cố tự triển khai parser hay mã hóa.

    Có ý kiến chỉ ra rằng trong lĩnh vực kỹ nghệ phần mềm còn thiếu quá trình sửa lại những nhận thức ngây thơ về làm việc nhóm và chất lượng.

  • Phát triển phần mềm chất lượng cao có thể học được ở các công ty giàu kinh nghiệm.

    Trước đây đó là các công ty FAANG, nhưng hiện nay có thể học từ những công ty như TailScale. Thay vì lạm dụng microservices vô nghĩa, Docker hay xử lý JSON, họ có thể nâng cao chất lượng bằng QuickCheck, kiểm định giả thuyết và fuzzing.

  • Khẳng định rằng phải triển khai phần mềm không có lỗi đúng thời hạn là một tiền đề không phù hợp để mở đầu bài viết về phần mềm chất lượng.

    Việc tin rằng có thể phát hành mã không lỗi là một suy nghĩ xa rời thực tế.

  • Có những chương trình kỹ thuật máy tính và các trường đại học nhấn mạnh thực tập cùng đào tạo thực hành.

    Khoa CS ở nhiều trường đại học tách ra từ khoa toán nên tập trung vào lý thuyết. Đại học không chỉ là trường dạy nghề, mà là nơi rèn luyện khả năng làm chủ những tài liệu phức tạp.

  • Nhận định rằng đại học dạy cách xây dựng phần mềm cho môi trường công nghiệp là một sự cường điệu.

    Trong bối cảnh pipeline triển khai liên tục đã trở nên phổ biến, việc bộ phận đảm bảo chất lượng kiểm tra lỗi thủ công bị xem là cách làm lỗi thời.

  • Lập luận rằng phần mềm sẽ "ổn định hơn" hoặc "dễ bảo trì hơn" không có sức thuyết phục với những người không trực tiếp làm việc trên codebase.

    Các nhà phát triển nói về cái giá của việc không làm đảm bảo chất lượng (QA), vì đó là ngôn ngữ mà doanh nghiệp và quản lý có thể hiểu.

  • Có thể chọn ba trong bốn yếu tố: chất lượng, thời gian, độ phức tạp giao tiếp và chi phí.

    Kỹ nghệ phần mềm là một môn thể thao đồng đội khó áp dụng quy trình kiểu nhà máy, vì vậy cần coi trọng làm việc nhóm và sự phát triển của từng cá nhân.

  • Các nhà phát triển phần mềm đã học cách tạo ra phần mềm chất lượng cao, nhưng MBA hoặc hội đồng quản trị điều hành công ty lại không hiểu điều đó, nên rất khó áp dụng vào thực tế.

    Ở hầu hết nơi làm việc, ý kiến của các nhà phát triển phần mềm phần lớn đều bị phớt lờ.

  • Chất lượng thực chất là một thuộc tính chỉ có thể lĩnh hội thông qua rèn luyện thực tế.

    Khả năng tạo ra sản phẩm chất lượng cao đến từ quá trình thực hành lặp đi lặp lại.