프로그래머가 ISO 표준을 무시하는 이유는 무엇입니까? [닫은]

내가 자주 접하는 것 중 하나는 ISO 표준을 준수하지 않는 프로그램으로 인해 발생하는 문제입니다.

예를 들어 ISO 국가 테이블을 사용하지 않고 미국 (US) 또는 네덜란드 (NL)에는 적합하지만 영국 (영국이 아닌 GB) 또는 스페인에 대해서는 잘못 표시되는 자체 속기를 작성하는 것이 있습니다. (SP가 아닌 ES) 및 다른 많은 국가.

다른 예로서, 내부 날짜 표기법. 왜 누군가가 날짜를 2014 년 1 월 2 일로 저장합니까? 2 월 1 일인지 1 월 2 일인지는 확실하지 않지만 ISO 표준을 사용하는 경우 2014-02-01 * 만 저장하면 2 월 1 일이됩니다.

내 질문 : 사용 가능한 ISO 표준이있을 때 프로그래머가 언제 그리고 왜 자체 구성을 구성해야합니까?

_{* 2014-02-01을 저장하고 최종 사용자에게 표시 할 때 날짜를 적절하게 형식화하십시오.}

어리 석음으로 적절히 설명 된 악의에 귀속되지 마십시오. - 로버트 J Hanlon에 .

그리고 의사 소통의 부족.

따라서 사람들이 "내가 GB 대신 영국을 사용할 것"이라고 생각하게하는 것은 ISO 반대 감정에 대한 음모가 아니며, "그들이 더 잘 알고있다"거나 표준이 좋지 않다는 생각이 들지 않습니다. . 그들은 그것이 존재한다는 것을 모르기 때문에 완전히 사용될 것입니다.

일부 사람들은 Visual Studio에 번들로 제공 되지 않으면 존재하지 않을 수도 있습니다. 다른 일부의 경우 전체 세트를 원하지 않거나 결정적인 목록을 가져 오기가 너무 어려워 즉각적인 상황을 해결하기 위해 자체 하위 세트를 구성하기 만합니다. 다른 사람들에게는 기본값이 사용됩니다. 따라서 날짜 형식은 "ISO 또는 국가 로케일 형식"이 아니고 "나가는 형식으로"형식이 지정되며 그 형식에 맞으면 작업이 완료됩니다 (일반적으로 미국 프로그래머에 대한 비판).

Ruby로 프로그래밍 할 때는 일반적으로 항상 ISO Ruby 표준을 무시합니다. 왜? 엄청나게 제한적이기 때문입니다! ISO Ruby는 Ruby 1.8과 Ruby 1.9의 최소한의 부분 집합입니다. 모든 Ruby 구현에서 지원되는 (또는 최소한 조만간) Ruby의 현재 버전은 Ruby 2.1이며 프로그래밍을보다 쉽게 ​​해주는 많은 기능이 있습니다. ISO로 프로그래밍 Ruby는 PITA입니다.

C #으로 프로그래밍 할 때 C # 2.0의 하위 집합 인 ISO C #도 무시합니다. 더 중요한 것은 ISO 클래스 라이브러리는 .NET BCL의 매우 작은 하위 집합입니다. 대신 C # 5.0에서 프로그래밍하고 나는하지 않습니다. ISO CLI에 지정된 라이브러리 만 사용하도록 제한하지 말고 대신 .NET 4.5.2 및 Mono 3.4.0에서 사용 가능한 라이브러리의 공통 하위 세트를 사용합니다.

그리고 웹 디자인을 할 때 HTML5는 고대 HTML 버전의 제한된 하위 집합보다 훨씬 기능이 풍부하기 때문에 ISO HTML (HTML 4.01 Strict의 작은 하위 집합)보다 HTML5를 다시 사용하는 것이 좋습니다.

따라서 ISO 표준을 무시해야 할 이유가 있습니다.

예를 들어 "GB"는 영국의 국가 코드입니다. 그러나 "UK"는 한때 MARC (미국 의회 도서관) 표준 코드 였지만, 더 이상 사용되지 않습니다. 그리고 IANA는 .uk영국의 최상위 도메인을 사용합니다.

뭔가 ISO 표준을 준수하지 않는 경우에 따라서, 그것은 것을 의미하지 않는다 어떤 표준이 사용중인; 단순히 다른 표준이 사용되고 있음을 의미 할 수 있습니다 . (@ Jörg가 의견에서 언급했듯이 표준에 대한 좋은 점은 선택할 수있는 것이 너무 많다는 것입니다.)이 경우 문제는 주어진 문제 영역, 환경 등에 가장 적합한 표준이됩니다 .

이 질문에 대한 답변은 대부분 의견에 근거한 것이며 "종교적인"토론으로 빠르게 퇴보 될 것입니다. 그러나 ISO 표준 준수가 항상 최선의 대답은 아닙니다. 예를 들어, 소프트웨어가 라이브러리 데이터베이스와 인터페이스해야하는 경우 MARC 표준이 ISO보다 더 적합한 선택 일 수 있습니다. 조직의 소프트웨어 대부분이 특정 방식으로 작업을 수행하는 경우 최소한 단기적으로는이 접근 방식을 고수 할 수 있습니다. 결국 조직의 "표준"입니다.

또한 표준은 발전 / 변경됩니다. 어제 준수했던 것이 오늘이 아닐 수도 있습니다.

그리고 당신이 지적한 문제의 원인으로 무지 및 / 또는 나무 늘보를 배제하고 싶지는 않지만 ... 개발자는 문제를 해결할 충분한 시간이 없었을 수도 있습니다.

ISO 표준을 준수한다고해서 항상 비용이 드는 것은 아닙니다. 사용중인 툴킷에서 특정 표준이 아직 구현되지 않은 경우 프로그래머는 필요한 선택에 직면하게됩니다. 이제이를 올바르게 구현하거나 표준을 구현하지 않고 나중에 변환을 처리하는 것이 더 저렴합니까?

"이봐 요, 항상 표준을 구현해야합니다"라고 말하기는 쉽지만 모든 비용이 있습니다. 프로그래머가 ISO 표준을 구현하고 싶지 않은 몇 가지 이유가 있습니다.

• 고객이 독점 또는 비 ISO 표준을 따르고있을 수 있습니다. 고객이 원하는 표준과 언어가 요구하는 것 외에 추가 구현을 숨겨서 후임자에게 의도 치 않은 두통을 남기는 것보다 고객이 기대하는 표준을 준수하는 것이 좋습니다.
• 많은 양의 기존 데이터가있을 수 있으며 변환 또는 형식 나누기가 아직 실행 가능하지 않을 수 있습니다. 현지 날짜-시간을 기준으로 20 년 간의 고객 연락처 및 계약이있는 경우, 수억 개의 필드를 모두 ISO 표준 날짜로 변경하지 않아도됩니다.
• 표준을 준수하면 혜택이 제공하는 것보다 더 많은 비용이 부과 될 수 있습니다. 예를 들어 미국 내에서 출품작을 처리하는 경우 5 자 ISO-3166-2 코드 (US-NY)는 ​​표준 미국 우편 번호 (NY)보다 3 개의 불필요한 문자입니다.

경험이없는 프로그래머 / 데이터베이스 디자이너의 경우 , 알지 못하기 때문입니다. 그들은 업계에 종사하는 사람들의 그룹을 알지 못하고 이미 문제를 논의했으며 종종 매우 긴 토론, 수정 등을 거친 후에 참여한 모든 사람들이 승인 한 표준을 제시했기 때문에 바퀴를 재발견하는 경향이 있습니다. 최근 동료 내 주에게 주어진 주가 1 년의 마지막 주 또는 다음 해의 첫 번째 주 ( ISO 8601 ) 로 간주되는지에 관한 ISO 표준이 있다고 말했을 때 엄청나게 많은 것을 보여주었습니다 . 그는 특정한 것에 관한 표준이 존재하지 않았다고 믿었습니다. 많은 응용 프로그램의 정확성이 해당 표준에 달려 있다고 그에게 말했습니다.

숙련 된 프로그래머 / 데이터베이스 디자이너의 경우 "알고 있음" , 발명되지 않은 증후군 및 / 또는 위대함으로 인해 무시됩니다 . 그들은 ISO 코드가 "충분히 안정적이지 않다"고 생각하기 때문에 ISO 나 다른 표준기구를 신뢰하지 않습니다 . 따라서 이들은 상호 운용성을 방해하는 자체의 발명 된 또는 자동 증분 코드 / 식별자를 생성하여 무시합니다. 이 비슷한 질문을 참조하십시오 . 그들은 다음과 같은 이유를 제공합니다.

표준이 얼마나 안정적인지에 관계없이 데이터베이스 설계가 여러 타사 (IATA, ISO)에 의존하는 것을 원치 않을 수도 있습니다. 또는 특정 표준에 전혀 의존하고 싶지 않을 수도 있습니다.

이상하게도 표준을 무시하는 사람들은 표준 USB 포트를 사용하고 표준 크기의 DVD 및 BluRay를 구입하고 표준에 맞는 타이어로 자동차를 운전합니다.

사람들은 ISO 표준을 무시하는 경향이 있습니다. 예를 들어

ISO 표준을 사용하는 경우 20140201 * 만 저장하면 분명하게 2 월 1 일입니다.

그러나 완전한 ISO8601 호환 변환은 실제로 2014-02-01 입니다. ( xkcd 1179 도 참조 )

그 이유 중 하나는 응용 프로그램 도메인과 사용자가 이러한 표준을 사용하지 않을 수 있기 때문입니다. 일부 도메인이 일부 표준을 사용하더라도 일부는 종종 역사적인 이유로 ISO 표준과 다르게 선택했을 수 있습니다.

사용자가 기존 절차 ⁽¹⁾ 에서 이미 "영국" 을 사용하여 "영국 및 북 아일랜드"를 언급 한 경우 데이터 구조에서 "GB"를 사용하는 것이 반드시 의미가있는 것은 아닙니다 (특히 국가 별로는 "ISO"국가가 아닙니다 (예 : 영국 국가를 분리하거나 채널 제도와 미묘한 차이가있는 등). 물론 내부 저장소 프레젠테이션 사이에 매핑을 할 수도 있지만 때로는 약간 위에 있습니다. 프로그래밍을 위해 프로그래밍하는 경우는 거의 없으며 종종 환경에 적응해야합니다. ⁽²⁾

또한 이러한 표준은 소프트웨어와 병행하여 발전했음을 기억해야합니다. 종종 다른 소프트웨어의 맥락에서 개발해야하는데, 일부는 완벽하게 설계되지 않았으며, 일부는 여전히 레거시 결정에 영향을받을 수 있습니다.

내부 데이터 스토리지 형식을 보더라도 일부 모호성은 해결하기 어렵습니다. 예를 들어, 내가 아는 한 Excel은 십진수를 사용하여 타임 스탬프를 나타냅니다. 정수는 참조 날짜 이후의 일 수로 정수를 사용한 다음 십진수 뒤의 시간은 24 시간의 일부로 시간을 나타냅니다. .. 이렇게하면 표준 시간대 또는 일광 절약 시간 (하루 23 시간 또는 25 시간)을 고려할 수 없으며 Excel에서는 기본적으로 날짜 / 시간을 해당 내부 형식으로 변환합니다. 작업해야하는 다른 소프트웨어가 선택의 여지가없는 경우 ISO 형식 사용 여부와 관련이 없습니다.

_{(1) 여기서 "프로그래밍 절차"를 의미하지 않습니다.}

_{(2) 사람들 이 왜 일상 생활에서 그러한 표준을 사용 하지 않는지 묻지 마십시오 . 나는 YYYYmmdd가 명확하고 dd / mm / YYYY가 분명하지만 mm / dd / YYYY와 같이 중간, 작고 큰 세분화 된 날짜를 주문하는 것은 의미가 없습니다 :-).}

ISO 3166-1 alpha-2 국가 코드를 사용하지 않는 이유는 무엇 입니까?

STANAG 1059 국가 코드를 사용 하고 영국에서 ISO 3166-1에 따라 GB 대신 영국 코드가 사용되기 때문 입니다.

또는 FIPS 국가 코드를 사용할 수도 있습니다. 다시 영국은 영국의 국가 코드입니다.

많은 표준 (ISO 및 비 ISO)이 있으며 때로는 특정 도메인에서 ISO 표준과 호환되지 않는 표준을 사용 / 요구합니다.

20140201을 저장하는 것은 전혀 모호하지 않습니다. ISO 표준을 따르는 지식을 포함 시켜야만 모호하지 않게됩니다. 2014 년 1 월 2 일에도 마찬가지입니다. 형식이 mm / dd / yyyy라는 지식을 포함하면 완벽하게 모호하지 않습니다.

응용 프로그램이 다른 응용 프로그램과 인터페이스 할 필요가없는 한 잘 문서화 된 표준이 제대로 작동 할 수 있습니다.

인간 (쉽게 1-2-2014를 사용하는 경향이 있음)과 컴퓨터 (ISO 대신 이진 표현으로 더 나은 사람)에게 쉬운 점이 있습니다. 초보자 프로그래머는 쉽게 이해할 수있는 내용을 고수하는 경향이 있으며, 더 많은 경험을 가진 프로그래머는 컴퓨터 지향 스토리지의 장점을보기 시작합니다.

지금까지 제기되지 않은 요점은 국제 표준의 문화적 적합성입니다.

측정에 대한 국제 표준을 고려하십시오. 미국 사용자에게이를 소개하겠습니다. 모든 미국 사용자가 킬로미터, 킬로그램 및 리터에 대해 만족할 것이라고 확신하지 않습니다.

국제 표준은 정부가 작성한다고 생각하십시오. 스페인 정부가 바스크어 언어를 인식하지 않기로 선택하면 ISO 사양을 어떻게 얻습니까? 이것은 소외 계층의 방언과 크리올에서 특히 문제가된다.

국가 코드조차도 문제가 될 수 있습니다. 크림은 이제 자체 국가 코드를 얻습니까? 공식은 결국 발견되지만 (예 : "전 유고 슬라비아 마케도니아 공화국") 외교 또는 전쟁이 끝날 때까지 응용 프로그램에 일부 독립형이 필요할 수 있습니다.

국제 표준은 특정 응용 프로그램을 염두에두고 작성되었습니다. 이들은 귀하의 응용 프로그램에 완전히 맞지 않을 수 있습니다. 예를 들어, 편지를 보낼 목적으로 언어를 저장하는 경우 미국 영어와 같이 말하기에 능숙하더라도 블라인드를 명확하게 코딩 할 수 있습니다. 통계 조직은 인구 조사 동안 가능한 모든 우위 사례를 겪을 때 변수의 정확한 의미 (일명 변수의 "메타 데이터")를 지정해야 할 필요성을 잘 알고 있습니다. 그 중 일부는 데이터베이스 필드에 가치가 있습니다.

마지막 요점은 이런 종류의 선택을 할 때 프로그램이 정치적 진술을 할 수 있다는 것입니다. 이 현실은 가장 좋은 코드를 어지럽 힐 수 있습니다 (예 : 동일한 언어에 대해 여러 언어 이름이 필요할 수 있음).

내 경험상 프로그래머는 다음과 같은 여러 가지 이유로 ISO 표준을 사용하지 못합니다.

• "ISO 표준이 있다는 것을 몰랐습니다"(한 번 말하면 유효한 이유는 아닙니다!)
• "표준에 액세스 할 수 없습니다 (사본을 찾을 수 없음)"(실제 ??)
• "표준이 너무 제한적입니다."(일반적으로 표준에 "하지 마십시오"라고 표시되는 경우에는 정당한 이유가 있습니다. 귀하와 고객의 위험을 무시하십시오!)
• "표준에는 최신 기능 / 라이브러리가 포함되어 있지 않습니다"(표준에는 사용하려는 모든 라이브러리가 포함되어 있지 않으므로 포함 / 커버 할 대상에 대한 표준을 준수하고 사물에 대한 표준과 일관성을 유지하십시오. 그렇지 않습니다)
• "표준이 구현하기에 너무 번거 롭습니다"(사용률이 지나치게 높지만 아래 참조)

불충분 한 변명이 아닌 직원들로부터 내가 받아들이는 유일한 이유는 "표준은 실제로 '적합하지 않다'는 것입니다. 증거로 뒷받침됩니다. 적용 가능한 ISO 표준의 복잡성이 문제 / 해결책에 비례하지 않는 경우가 있습니다. 때로는 솔루션을 구현할 컨텍스트가 표준에서 가정 한 것과 크게 다릅니다. 때로는 표준을 향상시킬 수 있습니다. 이것이 진행 상황입니다.

그러나 종종 ISO 표준을 사용하지 않으면 경험, 게으름 또는 오만으로 인한 것일 수 있습니다. 영어를 사용하는 프로그래머는 국제화와 관련하여 게으름에 특히 죄책감이 있으며 미국 동료들은 ISO를 "관련없는 유럽의 것"(이것이 적용되지 않는 소수 민족에 대한 사과)으로 인식하는 경향이 있다고 유감스럽게 생각합니다.

ISO에는 많은 표준이 있습니다. CCITT / ITU와 마찬가지로. 이러한 표준 중 일부는 "포부"표준이며 다른 표준은 최소 필수 기능입니다. 어느 것이 어느 것인지 명확하지 않습니다.

1980 년대에 일부 장비 벤더가 표준의 한 서브셋을 구현하는 반면 다른 벤더는 다른 서브셋을 구현하는 이유를 묻습니다. 그때는 표준이 종종 작동하기 전에 설정되는 것으로 나타났습니다. 또한 공급 업체는 종종 상호 운용성을 방해 할 수 있도록 표준을 구현하지 않기로 선택하여 이점을 부여합니다.

그래서 IETF RFC를 좋아합니다. 3 개의 독립적 인 RFC 구현이있을 때까지 RFC가되지 않습니다.

Oracle 데이터베이스를 구축하고 날짜를 저장하려면 Oracle DATE 데이터 유형을 사용합니다. 오라클이 ISO 표준을 준수하는지 여부는 알지 못하거나 걱정하지 않습니다. 이것은 실제로 다른 표준 (Oracle 표준)을 준수하고 ISO 표준과 크게 다르지 않은 경우입니다. @David의 답변을 참조하십시오.

어떤 경우에는 내가 디자인 한 것에 대한 ISO 표준이 있다는 것을 깨달았을 때 되돌아 가고 다시 디자인하는 비용이 엄청나거나 적어도 그런 식으로 보였습니다.

단기적으로는 유효한 표준을 사용하거나 현존하는 표준에 대한 신중한 연구보다 새로운 표준을 발명함으로써 더 많은 작업 코드가 생성됩니다. 단점은 대규모 통합에 상호 운용성이 필요할 때 발생합니다. 이것은 거의 항상 이후 프로젝트의 상황에서 발생합니다.