▲

GN⁺: 고품질 소프트웨어 개발 방법을 배우지 못하는 현실

 (florianbellmann.com)
3P by neo 7달전 | favorite | 댓글 1개

소프트웨어 품질 구축 방법에 대한 교육 부재

  • 대학에서 컴퓨터 과학을 공부할 때 소프트웨어 품질 보증(QA)에 대한 교육이 누락됨.
  • 대부분의 시간이 알고리즘, 컴퓨터 작동 방식, 언어 및 개념의 역사 등에 할애됨.
  • 프로젝트 관리 접근법과 스크럼에 대한 학기가 있지만 QA는 전혀 다루지 않음.

기업들의 시간 내 제품 출시 방식

  • 기업들은 예산 문제로 QA 표준과 조치를 가장 먼저 프로젝트에서 제외함.
  • 개발이 지연되거나 범위가 확대되면 QA에 충분한 시간이 남지 않음.
  • 최소한의 비구조화된 테스팅을 거쳐 불안정한 소프트웨어를 출시함.

햄스터 휠에서 벗어나는 방법

  • 프로젝트에서 누락된 QA 조치에 대해 말하기 위해 경험과 자신감을 쌓는 데 몇 년이 걸림.
  • 누락된 모니터링을 찾고, 생산 시스템이 실패하는 등의 문제를 겪음.
  • QA 조치를 구현하지 않으면 제대로 배우지 못하는 문제가 발생함.

돈에 대해 이야기하기

  • 소프트웨어가 '더 안정적'이거나 '유지 관리가 훨씬 쉬워질 것'이라고 설명하는 것은 비개발자에게 구체적이지 않음.
  • QA를 하지 않는 비용에 대해 이야기해야 함.
  • QA 조치를 예시와 함께 비용 측면에서 설명하는 것이 효과적임.

최소 효과량

  • QA 조치를 과도하게 설계하지 않고 프로젝트의 진행을 막지 않아야 함.
  • 애플리케이션의 핵심 기능을 테스트하고 항상 예상대로 작동하는지 확인하는 것이 중요함.
  • '최소 효과량'(MED) 개념을 사용하여 가장 중요한 부분부터 시작함.

주의 깊게 살펴보는 것들

  • 새 프로젝트를 시작하거나 참여할 때 QA 개념을 찾음.
  • 팀이 QA에 대해 생각했는지를 보여주는 문서나 테스팅 계획이 중요함.
  • 새로운 코드를 작성할 때 테스트를 함께 작성하는 것이 코드가 실제로 테스트 가능하도록 구조화되도록 함.

프로젝트 이점

  • 품질에 대해 이야기하고 가능한 해결책을 제안함으로써 개발자로서의 영향력을 확장함.
  • QA 조치를 통해 프로젝트가 건강한 속도로 성장할 수 있음.

프로젝트를 개선하는 방법

  • QA 조치를 사용하여 프로젝트에서 품질 소프트웨어를 작성하는 사람으로 알려질 수 있음.
  • 프로젝트에서 MED를 고려하고 팀 내에서 변화를 위한 목소리가 되어야 함.

GN⁺의 의견

이 글에서 가장 중요한 것은 소프트웨어 개발 과정에서 품질 보증(QA)의 중요성과 이를 구현하는 방법에 대한 인식 부족이다. QA는 종종 간과되지만, 장기적으로 프로젝트의 성공과 안정성을 위해 필수적이다. 이 글은 초급 소프트웨어 엔지니어들에게 QA의 중요성을 인식시키고, 실제 프로젝트에서 QA를 통합하는 구체적인 방법을 제시함으로써 흥미롭고 유익하다.

▲
neo 7달전  [-]
Hacker News 의견

  • 소프트웨어 엔지니어링은 컴퓨터 과학(CS)의 핵심 주제가 아니라 다른 영역에서 가르치는 경우가 많으며, 선택 과목이나 소프트웨어 엔지니어링 과정에서 다루어짐.

    CMU에서는 소프트웨어 엔지니어링 석사 및 박사 프로그램을 운영하며, 블로그 포스트에서 언급된 내용을 포함하여 다양한 주제를 가르침.

  • 컴퓨터 과학 학위를 가진 사람들과 협업하는 것이 더 쉬움을 경험함. 이들은 좋은 알고리즘의 중요성을 이해하고 있으며, 파서나 암호화를 직접 구현하려 하지 않음.

    소프트웨어 엔지니어링 분야에서는 팀워크와 품질에 대한 순진한 생각을 교정하는 과정이 부족함을 지적함.

  • 고품질의 소프트웨어 개발은 경험 많은 회사에서 배울 수 있음.

    과거에는 FAANG 회사들이었지만, 현재는 TailScale과 같은 회사들에서 배울 수 있음. 무의미한 마이크로서비스, 도커, JSON 처리 등을 남발하지 않고, 퀵체크, 가설 검증, 퍼징 등을 활용하여 품질을 높일 수 있음.

  • 버그 없는 소프트웨어를 시간 내에 배포해야 한다는 주장은 품질 소프트웨어에 대한 기사를 시작하기에 부적절한 전제임.

    버그 없는 코드를 배포할 수 있다고 믿는 것은 현실과 동떨어진 생각임.

  • 컴퓨터 엔지니어링 프로그램과 인턴십 및 실습을 강조하는 대학들이 있음.

    많은 대학의 CS 학과는 수학 학과에서 분화되어 이론에 중점을 둠. 대학은 단순한 직업 학교가 아니라 복잡한 자료를 마스터하는 능력을 훈련하는 곳임.

  • 대학에서 산업용 소프트웨어 빌딩을 가르친다는 주장은 과장된 것임.

    지속적인 배포 파이프라인이 일반화된 현재, 품질 보증 부서가 수동으로 버그를 확인하는 것은 구식 방법으로 여겨짐.

  • 소프트웨어가 '더 안정적'이거나 '유지 보수가 쉬워질 것'이라는 논리는 코드베이스에 직접 작업하지 않는 사람들에게 설득력이 없음.

    개발자는 품질 보증(QA)을 하지 않는 비용에 대해 말하며, 이것이 비즈니스와 관리자에게 이해되는 언어임.

  • 품질, 시간, 의사소통 복잡성, 비용 중 세 가지를 선택할 수 있음.

    소프트웨어 엔지니어링은 공장 프로세스를 적용하기 어려운 팀 스포츠이며, 팀워크와 개인의 성장을 중시해야 함.

  • 소프트웨어 개발자는 품질 높은 소프트웨어를 만드는 방법을 배웠지만, 회사를 운영하는 MBA나 이사회가 이를 이해하지 못해 실제로 적용하기 어려움을 겪음.

    대부분의 직장에서 소프트웨어 개발자의 의견은 대체로 무시됨.

  • 품질은 실제로 연습을 통해서만 습득할 수 있는 속성임.

    품질 높은 결과물을 만들어내는 능력은 반복적인 실습을 통해 얻어짐.

답변달기