Hacker News 의견

• 이 조언과 기사는 매우 유익함

• 정적으로 타입이 지정된 함수형 언어를 사용하지 않는 사람들에게도 유용함

• 이 아이디어는 패러다임을 초월함

• 80~90년대 객체지향 문헌에서도 유사한 개념을 찾을 수 있음, 예를 들어 Design by Contract

• TypeScript는 런타임에 타입을 세분화하는 방식으로 작성되는 경우가 많음

• Design by Contract는 Clojure의 spec에 영향을 미쳤을 것임 (Clojure는 동적 언어임)

• 기본적으로 이는 가정과 보장에 관한 것임 (요구와 제공)

• 가정이 확인되고 보장이 이루어지면 프로그램의 다른 부분에서 중복된 가정을 다시 확인할 필요가 없음

• 코드에서 이미 보장된 속성이 다시 확인되는 것을 보면 혼란스러울 수 있음, 이는 코드 이해와 개선을 어렵게 만듦

• 이 패턴은 현대 C#에서도 잘 작동하며 공간 절약 효과도 있음

  • 예시 코드:

    if(!Whatever.TryParse<Thingy>(input, out var output)) output = some-sane-default;
    

  • 예시 코드:

    if(!Whatever.TryParse<Thingy>(input, out var output)) throw new ApplicationException($"Not a valid Thingy: {input}");
    

  • 커널 모드 드라이버에서는 후자를 사용하지 말 것을 권장함

• 강력한 타입 시스템을 활용하여 오류 사례를 표현할 수 없게 만드는 것이 좋음, 이는 소프트웨어 버그를 줄이는 데 도움이 됨

• 문제를 생각하고 디자인을 따르는 데 시간이 더 걸리지만, 많은 경우 그 시간이 가치가 있음

• "Parse, don’t validate"라는 슬로건이 타입 기반 설계를 잘 요약함

• 개인적으로는 "항상 단일 생성자에서만 유효성 검사를 수행"하는 것이 좋음, 이렇게 하면 유효하지 않은 객체가 전혀 존재하지 않게 됨

• 객체를 수정하려면 동일한 생성자를 다시 호출하여 새 상태를 구성하는 방식으로 구현해야 함

• qmail의 섹션 5가 떠오름, 여기에는 "파싱하지 말라"와 "좋은 인터페이스와 사용자 인터페이스가 있다"는 내용이 포함됨

• 중간 규모의 프로그래밍 수업을 가르친다면 학생들에게 이 제안을 비교하고 대조하는 에세이를 작성하게 할 것임, 각 제안은 배울 점이 있으며 처음에는 모순처럼 보일 수 있음

• 관련 자료: Richard Feldman의 "Making Impossible States Impossible"

  • YouTube 링크

• 이전 논의:

  • 링크 1
  • 링크 2

• Crowdstrike에 전달됨

• 2000년대 중반 XML 열풍 때 누군가의 댓글이 떠오름, 많은 조직이 XML을 선택한 이유는 XML이 파서를 제공하기 때문임

• 파서를 작성하는 것이 어렵지 않고 재미있음에도 불구하고, 사람들이 파서를 작성하지 않으려는 이유를 이해할 수 없음

• Protocol Buffers의 "required" 키워드가 큰 실수였다는 의견과 반대되는 것인지 궁금함

  • Cap'n Proto FAQ 링크

• 유연하고 검증되지 않은 파싱과 검증된 파싱 기능을 모두 갖추는 것이 최선일 것임