Tại sao các lập trình viên sẽ bỏ qua các tiêu chuẩn ISO? [đóng cửa]

Một trong những điều tôi gặp phải thường xuyên là các vấn đề gây ra bởi các chương trình không tuân thủ các tiêu chuẩn ISO.

Một ví dụ sẽ không sử dụng các bảng quốc gia ISO mà tạo ra các tốc ký riêng của họ, điều này phù hợp với Hoa Kỳ (Hoa Kỳ) hoặc Hà Lan (NL) nhưng lại sai lầm một cách ngoạn mục đối với Vương quốc Anh (GB, không phải Vương quốc Anh) hoặc Tây Ban Nha (ES, không phải SP) và rất nhiều quốc gia khác.

Một ví dụ khác, ký hiệu ngày nội bộ. Tại sao mọi người sẽ lưu trữ một ngày là 01/02/2014? Hoàn toàn không rõ đó là ngày 1 tháng 2 hay ngày 2 tháng 1, trong khi nếu bạn sử dụng tiêu chuẩn ISO, bạn chỉ cần lưu trữ 2014 / 02-01 * và rõ ràng là ngày 1 tháng 2.

Câu hỏi của tôi: Khi nào và tại sao một lập trình viên nên tạo ra các cấu trúc của riêng họ khi có sẵn một tiêu chuẩn ISO?

_{* Lưu trữ 2014 / 02-01 và định dạng ngày phù hợp khi hiển thị cho người dùng cuối.}

Không bao giờ gán cho ác ý được giải thích thỏa đáng bởi sự ngu ngốc. - Robert J Hanlon .

Điều đó, và thiếu giao tiếp.

Vì vậy, đó không phải là một âm mưu của tình cảm chống ISO khiến mọi người nghĩ rằng "Tôi biết, tôi sẽ sử dụng Vương quốc Anh thay vì GB", cũng không phải là một xu hướng "họ biết rõ hơn", hoặc thậm chí có ý nghĩa rằng tiêu chuẩn này không tốt . Nó sẽ hoàn toàn bởi vì họ không biết nó ở đó và họ nên sử dụng nó.

Ý tôi là, đối với một số người, nếu nó không được đưa vào Visual Studio , thì nó cũng có thể không tồn tại. Đối với một số người khác, có thể họ chỉ không muốn toàn bộ hoặc quá khó để lấy danh sách dứt khoát, vì vậy họ chỉ tạo ra tập hợp con của riêng họ để giải quyết tình huống trước mắt của họ. Đối với những người khác, mặc định là những gì được sử dụng - vì vậy định dạng ngày không "được định dạng theo ISO hoặc thậm chí là ngôn ngữ quốc gia", đó là "được định dạng trong bất cứ điều gì xuất hiện" và nếu phù hợp với họ, thì đó là công việc được thực hiện (đây thường là một chỉ trích các lập trình viên Mỹ).

Khi tôi lập trình trong Ruby, tôi thường luôn bỏ qua tiêu chuẩn ISO Ruby. Tại sao? Bởi vì nó vô cùng hạn chế! ISO Ruby là tập hợp con tối thiểu của giao điểm của Ruby 1.8 và Ruby 1.9. Phiên bản hiện tại của Ruby, được hỗ trợ bởi tất cả các triển khai Ruby (hoặc ít nhất là sẽ sớm ra mắt) là Ruby 2.1, và nó có nhiều tính năng giúp lập trình dễ dàng hơn. Lập trình trong ISO Ruby là một PITA.

Khi tôi lập trình trong C #, tôi cũng bỏ qua ISO C #, là một tập hợp con của C # 2.0 (và quan trọng hơn, Thư viện lớp ISO là một tập hợp con cực kỳ nhỏ của .NET BCL), và thay vào đó tôi lập trình trong C # 5.0 và tôi không Tôi hạn chế chỉ sử dụng các thư viện được chỉ định trong ISO CLI, thay vào đó tôi sử dụng tập hợp con phổ biến của các thư viện có sẵn trong .NET 4.5.2 và Mono 3.4.0.

Và khi thực hiện thiết kế web, tôi rất thích sử dụng HTML5 hơn ISO HTML (là một tập hợp con nhỏ của HTML 4.01 Strict), bởi vì HTML5 có nhiều tính năng hơn một tập hợp con bị hạn chế của một phiên bản HTML cổ.

Vì vậy, có những lý do chính đáng để bỏ qua các tiêu chuẩn ISO.

Theo ví dụ của bạn, "GB" là mã quốc gia của Vương quốc Anh. Tuy nhiên, "Vương quốc Anh" đã có lúc là mã tiêu chuẩn MARC (Thư viện Quốc hội Hoa Kỳ), mặc dù tôi tin rằng điều đó không được chấp nhận. Và IANA sử dụng .ukcho tên miền cấp cao nhất cho Vương quốc Anh.

Vì vậy, nếu một cái gì đó không phù hợp với tiêu chuẩn ISO, điều đó không có nghĩa là không có tiêu chuẩn nào được sử dụng; nó có thể đơn giản có nghĩa là một tiêu chuẩn khác đang được sử dụng. (Như @ Jörg ghi nhận trong một chú thích, những điều tốt đẹp về tiêu chuẩn là có rất nhiều để lựa chọn.) Trong trường hợp này, câu hỏi thực sự trở thành mà tiêu chuẩn sẽ là nhất thích hợp cho miền vấn đề nhất định, môi trường, vv ?

Những câu trả lời cho câu hỏi đó có lẽ phần lớn dựa trên ý kiến ​​và nhanh chóng suy thoái thành một cuộc tranh luận "tôn giáo". Nhưng sự phù hợp tiêu chuẩn ISO không nhất thiết luôn là câu trả lời tốt nhất. Ví dụ: nếu một phần mềm cần giao tiếp với cơ sở dữ liệu thư viện, các tiêu chuẩn MARC có thể là lựa chọn phù hợp hơn ISO. Nếu hầu hết các phần mềm của tổ chức của bạn thực hiện mọi thứ theo một cách nhất định, thì bạn có thể muốn gắn bó với phương pháp đó, ít nhất là trong ngắn hạn - rốt cuộc đó là "tiêu chuẩn" của tổ chức bạn.

Ngoài ra, các tiêu chuẩn làm phát triển / thay đổi. Những gì đã phù hợp ngày hôm qua có thể không phải là ngày hôm nay.

Và, trong khi tôi không muốn loại trừ sự thiếu hiểu biết và / hoặc lười biếng là nguyên nhân của các vấn đề bạn chỉ ra ... nhà phát triển có thể đơn giản là không có đủ thời gian để giải quyết chúng.

Tuân thủ tiêu chuẩn ISO không phải lúc nào cũng là một hoạt động miễn phí. Nếu một tiêu chuẩn cụ thể chưa được triển khai trong bộ công cụ mà cô ấy đang sử dụng, một lập trình viên phải đối mặt với một lựa chọn cần thiết: Có rẻ hơn khi thực hiện đúng cách này ngay bây giờ hay không thực hiện tiêu chuẩn và xử lý các chuyển đổi sau này?

Thật dễ dàng để nói "hey, bạn nên luôn luôn thực hiện tiêu chuẩn", nhưng mọi thứ đều có chi phí. Và có một số lý do chính đáng tại sao một lập trình viên có thể không muốn thực hiện một tiêu chuẩn ISO.

• Khách hàng có thể tuân theo tiêu chuẩn độc quyền hoặc không phải ISO. Tốt hơn là nên tuân theo tiêu chuẩn mà khách hàng đang mong đợi hơn là để lại những cơn đau đầu ngoài ý muốn cho người kế nhiệm của bạn bằng cách ẩn một triển khai bổ sung bên cạnh những gì khách hàng muốn và ngôn ngữ của bạn yêu cầu.
• Có thể có rất nhiều dữ liệu hiện có và việc chuyển đổi hoặc phá vỡ định dạng có thể chưa khả thi. Nếu bạn có hai mươi năm liên hệ với khách hàng và hợp đồng được khóa với thời gian ngày địa phương, bạn không nhất thiết muốn thay đổi tất cả hàng trăm triệu trường đó thành ngày theo tiêu chuẩn ISO cho đến khi bạn có thể thực hiện đúng.
• Tuân thủ tiêu chuẩn có thể áp đặt chi phí lớn hơn lợi ích mang lại. Ví dụ: nếu bạn đang xử lý các mục nhập hoàn toàn ở Hoa Kỳ, mã ISO-3166-2 gồm năm ký tự (US-NY) là ba ký tự không cần thiết so với mã bưu chính tiêu chuẩn của Hoa Kỳ (NY).

Trong trường hợp lập trình viên / nhà thiết kế cơ sở dữ liệu thiếu kinh nghiệm , đó là vì không biết. Họ có xu hướng phát minh lại bánh xe vì họ không biết một nhóm người bao trùm các ngành công nghiệp, đã thảo luận về vấn đề này và đưa ra một tiêu chuẩn được chấp thuận bởi tất cả những người tham gia, thường sau các cuộc thảo luận, sửa đổi rất lâu, v.v. Của tôi cho thấy sự hoài nghi khi tôi nói với anh ta rằng có một tiêu chuẩn ISO liên quan đến việc một tuần nhất định được coi là tuần cuối cùng của năm hay là tuần đầu tiên của năm tiếp theo ( ISO 8601 ). Anh không tin một tiêu chuẩn tồn tại liên quan đến thứ gì đó quá cụ thể. Tôi nói với anh ta rằng tính đúng đắn của nhiều ứng dụng phụ thuộc vào tiêu chuẩn đó.

Trong trường hợp các lập trình viên / nhà thiết kế cơ sở dữ liệu có kinh nghiệm , nó không quan tâm đến việc "hiểu rõ hơn" , hội chứng không được phát minh ở đây và / hoặc sự tò mò. Họ không tin tưởng ISO hoặc bất kỳ cơ quan tiêu chuẩn nào khác vì họ coi mã ISO là "không đủ ổn định" , có nghĩa là nó sẽ thay đổi vào một ngày nào đó. Vì vậy, họ tạo mã / số nhận dạng tự động, được phát minh ở đây hoặc tự động tăng lên gây cản trở khả năng tương tác, mà họ cũng không quan tâm. Xem câu hỏi tương tự này , mặc dù cơ sở dữ liệu - thiết kế nghiêng. Họ đưa ra những lý do như:

Tôi có thể không nhất thiết muốn thiết kế cơ sở dữ liệu của mình phụ thuộc vào một nhóm các bên thứ ba (IATA, ISO), bất kể tiêu chuẩn của họ ổn định đến mức nào. Hoặc, tôi có thể không muốn phụ thuộc vào một tiêu chuẩn cụ thể nào cả.

Thật kỳ lạ, những người coi thường các tiêu chuẩn sử dụng cổng USB tiêu chuẩn, mua DVD và BluRays có kích thước tiêu chuẩn và lái xe ô tô có lốp phù hợp với tiêu chuẩn.

Chà, mọi người có xu hướng bỏ qua các tiêu chuẩn ISO: ví dụ, bạn đã viết

nếu bạn sử dụng tiêu chuẩn ISO, bạn chỉ cần lưu trữ 20140201 * và rõ ràng là ngày 1 tháng 2.

nhưng rendition đầy đủ ISO8601 tuân thủ là trong thực tế 2014/02/01 . (xem thêm xkcd 1179 )

Một trong những lý do là miền ứng dụng và người dùng có thể không sử dụng các tiêu chuẩn này. Ngay cả khi một số tên miền sử dụng một số tiêu chuẩn, một số trong số chúng có thể có các lựa chọn khác với tiêu chuẩn ISO, thường là vì lý do lịch sử.

Nếu người dùng của bạn đã sử dụng "UK" trong các quy trình hiện có của họ ⁽¹⁾ để chỉ "Vương quốc Liên hiệp Anh và Bắc Ireland", thì không nhất thiết phải sử dụng "GB" trong cấu trúc dữ liệu của họ (đặc biệt là nếu bạn có nghĩa là quốc gia không hoàn toàn là một quốc gia "ISO", ví dụ như tách các quốc gia Anh hoặc có sự khác biệt tinh tế với Quần đảo Channel, v.v.). Tất nhiên, bạn có thể có một ánh xạ giữa lưu trữ nội bộ một bản trình bày, nhưng đôi khi, nó hơi vượt trội. Bạn hiếm khi lập trình vì mục đích lập trình, bạn thường phải thích nghi với môi trường của mình. ⁽²⁾

Bạn cũng phải nhớ rằng các tiêu chuẩn này đã phát triển song song với phần mềm. Bạn thường phải phát triển trong bối cảnh của các phần mềm khác, một số phần mềm có thể được thiết kế không hoàn hảo, một số phần mềm vẫn có thể bị ảnh hưởng bởi các quyết định cũ.

Ngay cả khi bạn nhìn vào các định dạng lưu trữ dữ liệu nội bộ, một số sự mơ hồ khó giải quyết. Ví dụ, theo như tôi biết, Excel sử dụng số thập phân để biểu thị dấu thời gian: nó sử dụng một số nguyên làm số ngày kể từ ngày tham chiếu, sau đó số thập phân biểu thị phân số của 24 giờ để cung cấp cho bạn số giờ. Vấn đề là điều này ngăn bạn tham gia vào các múi giờ tài khoản hoặc thời gian tiết kiệm ánh sáng ban ngày (23h hoặc 25h một ngày) và Excel sẽ chuyển đổi bất kỳ ngày / giờ nào sang định dạng nội bộ theo mặc định. Việc bạn có muốn sử dụng định dạng ISO hay không trở nên không liên quan nếu một phần mềm khác mà bạn phải làm việc không để lại cho bạn lựa chọn.

_{(1) Tôi không có nghĩa là "thủ tục lập trình" ở đây.}

_{(2) Đừng hỏi tôi tại sao mọi người không sử dụng những tiêu chuẩn đó trong cuộc sống hàng ngày của họ. Ý tôi là YYYYmmdd rõ ràng, dd / mm / YYYY rõ ràng, nhưng sắp xếp một ngày với thứ tự độ trung bình, nhỏ, lớn như mm / dd / YYYY, điều đó không có nghĩa gì cả :-).}

Tại sao tôi không sử dụng mã quốc gia ISO 3166-1 alpha-2 ?

Bởi vì tôi sử dụng mã quốc gia STANAG 1059 ... và ở Vương quốc Anh đó là mã của Vương quốc Anh (thay vì GB theo ISO 3166-1).

Ngoài ra, tôi có thể sử dụng mã quốc gia Trin - một lần nữa Vương quốc Anh là mã quốc gia của Vương quốc Anh.

Có nhiều tiêu chuẩn (ISO và không phải ISO) và đôi khi một miền cụ thể sử dụng / yêu cầu một tiêu chuẩn không tương thích với tiêu chuẩn ISO.

Lưu trữ 20140201 không hề mơ hồ chút nào. Chỉ khi bạn bao gồm kiến ​​thức tuân theo tiêu chuẩn ISO thì nó mới trở nên rõ ràng. Điều tương tự cũng diễn ra vào ngày 01/02/2014: khi bạn bao gồm kiến ​​thức rằng định dạng là mm / dd / yyyy, nó cũng hoàn toàn không rõ ràng.

Miễn là ứng dụng không phải giao tiếp với ứng dụng khác, bất kỳ tiêu chuẩn tài liệu tốt nào cũng có thể hoạt động tốt như vậy.

Có một sự đánh đổi giữa những gì dễ dàng cho con người (tôi có xu hướng sử dụng 1-2-2014) và máy tính (những người thậm chí sẽ tốt hơn với biểu diễn nhị phân thay vì ISO). Các lập trình viên Novice có xu hướng gắn bó với những gì họ có thể dễ dàng hiểu được, nhiều kinh nghiệm hơn các lập trình viên bắt đầu thấy những lợi thế của lưu trữ theo định hướng máy tính.

Một điểm không được nêu ra cho đến nay là sự phù hợp về văn hóa của các tiêu chuẩn quốc tế.

Xem xét các tiêu chuẩn quốc tế cho các phép đo. Hãy giới thiệu những thứ đó cho người dùng ở Hoa Kỳ. Tôi không chắc chắn tất cả người dùng ở Mỹ của bạn sẽ hài lòng về số km, kilôgam và lít.

Hãy xem xét rằng các tiêu chuẩn quốc tế được viết bởi chính phủ. Nếu chính phủ Tây Ban Nha chọn không công nhận ngôn ngữ Basque thì làm thế nào để có được thông số kỹ thuật ISO? Điều này đặc biệt là một vấn đề với các phương ngữ và creoles của các nhóm bên lề.

Ngay cả mã quốc gia cũng có thể có vấn đề: bây giờ Crimea có nhận được mã quốc gia của riêng mình không? Các công thức cuối cùng đã được tìm thấy (ví dụ: "Cộng hòa Macedonia thuộc Nam Tư cũ") nhưng đơn đăng ký của bạn có thể cần một số thay thế cho đến khi chính sách ngoại giao hoặc chiến tranh kết thúc.

Hãy xem xét rằng các tiêu chuẩn quốc tế được viết với các ứng dụng cụ thể trong tâm trí. Đây có thể không hoàn toàn phù hợp với ứng dụng của bạn. Ví dụ, nếu bạn đang lưu trữ ngôn ngữ với mục đích gửi thư thì bạn có thể muốn mã hóa một cách rõ ràng, ngay cả khi họ thành thạo nói, nói tiếng Anh Mỹ. Các tổ chức thống kê nhận thức rõ về sự cần thiết phải chỉ định ý nghĩa chính xác của một biến (hay còn gọi là "dữ liệu meta" của biến) khi họ gặp phải mọi trường hợp cạnh có thể xảy ra trong cuộc điều tra dân số. Một số sự nghiêm ngặt đó rất đáng giá cho các trường cơ sở dữ liệu.

Điểm cuối cùng là khi đưa ra những lựa chọn này, chương trình của bạn có thể đưa ra tuyên bố chính trị. Thực tế này có thể gây rối với mã đẹp nhất (ví dụ: bạn có thể cần nhiều tên ngôn ngữ cho cùng một ngôn ngữ).

Theo kinh nghiệm của tôi, các lập trình viên không sử dụng các tiêu chuẩn ISO vì nhiều lý do đã nêu, ví dụ:

• "Tôi không biết rằng có một tiêu chuẩn ISO" (không còn là lý do hợp lệ khi bạn được thông báo!)
• "Tiêu chuẩn không thể truy cập (không thể tìm / mua một bản sao)" (thực sự ??)
• "Tiêu chuẩn quá hạn chế" (thông thường nếu tiêu chuẩn nói "không" thì đó là một lý do chính đáng. Bỏ qua nó tại bạn và khách hàng của bạn, nguy hiểm!)
• "Tiêu chuẩn không bao gồm chức năng / thư viện mới nhất" (không có tiêu chuẩn nào bao gồm MỌI thư viện mà bạn muốn sử dụng để tuân thủ tiêu chuẩn cho những thứ mà nó bao gồm / bao gồm và phù hợp với tiêu chuẩn cho mọi thứ mà nó không)
• "Tiêu chuẩn này quá cồng kềnh để thực hiện" (lý do được sử dụng quá mức nhưng xem bên dưới)

Lý do duy nhất mà tôi chấp nhận từ nhân viên của mình, vì không phải là một lý do khập khiễng, là "tiêu chuẩn thực sự không phải là 'phù hợp'" - được hỗ trợ bởi bằng chứng. Đôi khi sự phức tạp của tiêu chuẩn ISO áp dụng nằm ngoài tỷ lệ của vấn đề / giải pháp. Đôi khi bối cảnh bạn sẽ thực hiện giải pháp của mình khác biệt đáng kể so với bối cảnh được giả định bởi tiêu chuẩn. Và đôi khi tiêu chuẩn có thể được cải thiện - đó là cách tiến trình xảy ra.

Thường xuyên hơn không, việc không sử dụng tiêu chuẩn ISO có thể được quy cho sự thiếu kinh nghiệm, lười biếng hoặc kiêu ngạo. Tôi rất tiếc phải nói rằng các lập trình viên nói tiếng Anh đặc biệt có lỗi về sự lười biếng liên quan đến quốc tế hóa và các đồng nghiệp Hoa Kỳ của chúng tôi có xu hướng coi ISO là "một điều không liên quan ở châu Âu" (xin lỗi người thiểu số mà điều này không áp dụng).

ISO có rất nhiều tiêu chuẩn. CCITT / ITU cũng vậy. Một số trong những tiêu chuẩn này là tiêu chuẩn "khao khát", trong khi những tiêu chuẩn khác là chức năng bắt buộc tối thiểu. Nó không thường xuyên rõ ràng đó là cái gì.

Tôi nhớ vào những năm 1980, tại sao một số nhà cung cấp thiết bị thực hiện một tập hợp con của tiêu chuẩn trong khi các nhà cung cấp khác thực hiện một tập hợp con khác. Đó là khi nó xuất hiện rằng các tiêu chuẩn thường được đặt ra trước khi một cái gì đó hoạt động. Và các nhà cung cấp thường cố tình chọn không thực hiện các tiêu chuẩn để họ có thể cản trở khả năng tương tác, sau đó mang lại cho họ một lợi thế.

Đó là lý do tại sao tôi thích RFC của IETF. Họ thậm chí không trở thành RFC cho đến khi có 3 triển khai RFC độc lập.

Nếu tôi đang xây dựng cơ sở dữ liệu Oracle và tôi muốn lưu trữ ngày, tôi sẽ sử dụng kiểu dữ liệu Oracle DATE. Tôi sẽ không biết, hoặc quan tâm, liệu Oracle có tuân thủ tiêu chuẩn ISO hay không. Đây thực sự là một trường hợp tôi tuân thủ một tiêu chuẩn khác (tiêu chuẩn của Oracle) và không quá khác biệt so với tiêu chuẩn ISO. Xem phản hồi của David.

Trong một số trường hợp, vào thời điểm tôi nhận ra có một tiêu chuẩn ISO cho một thứ tôi đã thiết kế, chi phí quay trở lại và thiết kế lại sẽ bị cấm, hoặc ít nhất là được nhìn theo cách đó.

Trong ngắn hạn, nhiều mã làm việc được tạo ra bằng cách sử dụng các tiêu chuẩn có sẵn hoặc bằng cách phát minh ra các mã mới hơn là nghiên cứu cẩn thận về các tiêu chuẩn còn tồn tại. Nhược điểm xảy ra khi tích hợp quy mô lớn đòi hỏi khả năng tương tác. Điều này hầu như luôn xảy ra trong bối cảnh của một dự án sau này.