Hacker News 의견

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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