![복잡한 솔루션과 실패에 대한 이야기 [닫기]](https://linux55.com/image/199110/%EB%B3%B5%EC%9E%A1%ED%95%9C%20%EC%86%94%EB%A3%A8%EC%85%98%EA%B3%BC%20%EC%8B%A4%ED%8C%A8%EC%97%90%20%EB%8C%80%ED%95%9C%20%EC%9D%B4%EC%95%BC%EA%B8%B0%20%E2%80%8B%E2%80%8B%5B%EB%8B%AB%EA%B8%B0%5D.png)
참고 자료를 찾고 있습니다. 클라이언트가 충돌(또는 이와 유사한 것)하고 문제 없이 다시 시작하는 대신 한 팀은 다소 복잡한 방법으로 문제를 해결하고 다른 팀은 실패하는 이야기입니다.
분명 책 어딘가에서 읽었던 것 같은데유닉스 프로그래밍의 예술, 하지만 찾을 수 없습니다.
답변1
드디어 찾았네요 원작은Richard P. Gabriel의 "더 나쁜 것이 더 좋습니다"나도 그 책을 읽었다유닉스 프로그래밍의 예술. 간단히 이야기하면 이렇습니다.
MIT 출신과 버클리 출신(그러나 Unix에서 일하고 있음)이라는 두 명의 저명한 사람들이 한때 만나 운영 체제 문제를 논의했습니다. MIT의 사람들은 Unix가 PC 오류 문제를 어떻게 해결했는지에 관심이 있었습니다. 이는 기본적으로 긴 작업을 수행하는 시스템 호출이 보유하거나 마스크할 수 없는 인터럽트를 처리하는 방법에 관한 것이었습니다. MIT에 있는 사람은 이 사건을 처리하는 코드를 보지 못했고 뉴저지에 있는 사람에게 문제를 처리하는 방법을 물었습니다. 뉴저지 직원은 Unix 사람들이 문제를 알고 있지만 해결책은 시스템 루틴을 항상 완료하도록 하는 것이었지만 때로는 시스템 루틴이 작업을 완료하지 못했음을 나타내는 오류 코드를 반환하는 것이라고 말했습니다. 그런 다음 올바른 사용자 프로그램은 오류 코드를 확인하여 시스템 루틴을 다시 시도할지 여부를 결정해야 합니다. MIT 사람들은 이 솔루션이 "올바른" 일이 아니기 때문에 좋아하지 않았습니다. 뉴저지 사람들은 Unix 솔루션이 올바른 솔루션이라고 말합니다. 왜냐하면 Unix는 단순하도록 설계되었고 옳은 일은 너무 복잡하기 때문입니다. 또한 프로그래머는 이러한 추가 테스트와 루프를 쉽게 삽입할 수 있습니다. MIT 사람들은 구현이 간단하지만 기능에 대한 인터페이스가 복잡하다고 지적했습니다. 뉴저지 출신인 그는 Unix에서는 올바른 절충안이 선택되었다고 말했습니다. 즉, 구현 단순성이 인터페이스 단순성보다 더 중요하다고 말했습니다.