Reinvent The Wheel Là Gì

  -  

Kiến thức phổ biến của nó trong lập trình rằng phát minh lại bánh xe là xấu hoặc ác .Bạn đang xem: Reinvent the wheel là gì

Nhưng tại sao vậy?

Tôi không cho rằng nó tốt. Tôi tin rằng nó là sai. Tuy nhiên, tôi đã từng đọc một bài báo nói rằng, nếu ai đó đang làm gì đó sai (lập trình khôn ngoan) giải thích cho họ tại sao nó sai, nếu bạn không thể, thì có lẽ bạn nên tự hỏi liệu điều đó có thực sự sai không.

Bạn đang xem: Reinvent the wheel là gì

Điều đó dẫn tôi đến câu hỏi này :

Nếu tôi thấy ai đó rõ ràng đang phát minh lại bánh xe bằng cách xây dựng phương pháp riêng của họ về một thứ đã được tích hợp vào ngôn ngữ/khung. Đầu tiên, đối với các đối số, hãy giả sử rằng phương thức của họ hiệu quả như phương thức được xây dựng. Cũng là nhà phát triển, nhận thức được phương thức tích hợp sẵn, thích phương thức của riêng mình.

Tại sao anh ta nên sử dụng cái tích hợp trên một cái của mình?

reinventing-the-wheel 104 23 thg 12, 2010JD IsaacksNhư tôi đã từng đăng trên StackOverflow, phát minh lại bánh xe là thường là một lựa chọn rất tốt, trái với niềm tin phổ biến. Ưu điểm chính là bạn đã có toàn quyền kiểm soát trên phần mềm, thường là cần thiết. Để thảo luận đầy đủ, xem bài viết gốc của tôi .

73 23 thg 12, 2010Dimitri C.

Phụ thuộc ..

Như với tất cả mọi thứ, đó là về bối cảnh:

Thật tốt khi :

Khung hoặc thư viện quá nặng và bạn chỉ yêu cầu chức năng giới hạn. Cán phiên bản cực kỳ nhẹ của riêng bạn mà yêu cầu của bạn là một cách tiếp cận tốt hơn.Khi bạn muốn hiểu và học một cái gì đó phức tạp, bạn sẽ có ý nghĩa.Bạn có một cái gì đó khác biệt để cung cấp, những thứ mà người khác không có. Có thể là một bước ngoặt mới, tính năng mới, vv.

Thật tệ khi :

Chức năng đã tồn tại và được biết là ổn định và nổi tiếng (phổ biến).Phiên bản của bạn không có gì mới.Phiên bản của bạn giới thiệu các lỗi hoặc ràng buộc (ví dụ: phiên bản của bạn không an toàn cho chuỗi).Phiên bản của bạn thiếu tính năng.Phiên bản của bạn có tài liệu tồi tệ hơn.Phiên bản của bạn đang thiếu các bài kiểm tra đơn vị so với những gì nó đang thay thế.

83 23 thg 12, 2010DarknightTôi nghĩ trường hợp của một nhà phát triển cố tình phát minh lại bánh xe "bởi vì anh ta thích phương pháp của riêng mình" là khá hiếm. Hầu hết nó được thực hiện từ sự thiếu hiểu biết, và đôi khi vì sự bướng bỉnh.

Có phải tất cả đều xấu? Đúng. Tại sao? Bởi vì bánh xe hiện tại rất có thể đã được chế tạo theo thời gian và đã được thử nghiệm trong nhiều trường hợp và chống lại nhiều loại dữ liệu khác nhau. (Các) nhà phát triển của bánh xe hiện tại đã gặp phải các trường hợp Edge và những khó khăn mà người sáng chế thậm chí không thể tưởng tượng được.

56 23 thg 12, 2010Dan RayBánh xe vuông phải được phát minh lại. Nỗ lực mà hút phải được nhân đôi. Có thể thiếu tài liệu cho phương pháp và lập trình viên khác cảm thấy việc viết riêng của họ dễ dàng hơn thay vì cố gắng tìm ra nó. Có lẽ cách mà phương thức đang được gọi là khó xử và không phù hợp với thành ngữ của ngôn ngữ lập trình.

Chỉ cần hỏi anh ấy những gì thiếu hụt.

22 23 thg 12, 2010user8865Nói chung, tôi tránh phát minh lại bánh xe nếu chức năng tôi mong muốn hoặc thứ gì đó gần đúng với nó, tồn tại trong thư viện chuẩn của ngôn ngữ tôi sử dụng.

Tuy nhiên, nếu tôi phải kết hợp các thư viện của bên thứ ba, đó là một cuộc gọi phán xét tùy thuộc vào mức độ sử dụng và đánh giá cao của thư viện. Ý tôi là, chúng ta đang nói về Boost hoặc Bob"s Kick-ass String-Parsing Tools 1.0?

Ngay cả khi thư viện nói chung là nổi tiếng và được đánh giá cao trong toàn ngành, nó vẫn là một phụ thuộc của bên thứ ba . Các lập trình viên thường chú trọng đáng kể vào các ưu điểm của việc tái sử dụng mã, trong khi thường che giấu sự nguy hiểm của các phụ thuộc. Một dự án có quá nhiều sự phụ thuộc của bên thứ ba có thể sẽ sụp đổ trong thời gian dài khi nó dần dần phá hủy thành một cơn ác mộng bảo trì.

Vì vậy, tận dụng mã hiện có là tốt - nhưng phụ thuộc là xấu . Thật không may, hai tuyên bố này là bất hòa với nhau, vì vậy mẹo là cố gắng tìm sự cân bằng phù hợp. Đó là lý do tại sao bạn cần xác định các phụ thuộc có thể chấp nhận . Như tôi đã nói, bất cứ điều gì trong Thư viện tiêu chuẩn của ngôn ngữ rất có thể là một sự phụ thuộc chấp nhận được. Chuyển từ đó, các thư viện được đánh giá cao trong toàn ngành cũng thường được chấp nhận (như Boost cho C++ hoặc jQuery cho Javascript) - nhưng chúng vẫn còn ít hơn mong muốn hơn Thư viện chuẩn vì chúng làm có xu hướng kém ổn định hơn so với thư viện được tiêu chuẩn hóa.

Đối với các thư viện tương đối không rõ, (ví dụ: tải lên mới nhất trên SourceForge) đây là những phụ thuộc cực kỳ rủi ro và tôi thường khuyên bạn nên tránh những điều này trong mã sản xuất, trừ khi bạn đủ quen thuộc với mã nguồn để tự duy trì chúng.

Vì vậy, nó thực sự là một hành động cân bằng. Nhưng vấn đề là chỉ cần mù quáng nói "Mã sử ​​dụng lại tốt! Phát minh lại bánh xe xấu!" là một thái độ nguy hiểm. Lợi ích của việc tận dụng mã của bên thứ ba phải được cân nhắc với những bất lợi của việc đưa ra các phụ thuộc.

17 Nếu mọi người không phát minh lại bánh xe, thế giới sẽ tràn ngập những thứ này .. 

*

Đây là một cuộc đối thoại từ nơi làm việc của tôi:

- I would like to add some colors to the output of this program.- Oh, there is this library called Colorama ..Có hai tùy chọn: hoặc phát minh lại bánh xe OR sử dụng Colorama. Đây là những gì mỗi tùy chọn sẽ dẫn đến:

Sử dụng Colorama

Có thể nhanh hơn một chút để chạyThêm một phụ thuộc của bên thứ ba cho một cái gì đó tầm thườngBạn tiếp tục ngu ngốc như trước khi sử dụng Colorama

Phát minh lại bánh xe

Bạn hiểu làm thế nào một số chương trình có thể hiển thị màu sắcBạn biết rằng các ký tự đặc biệt có thể được sử dụng để tô màu trên bất kỳ thiết bị đầu cuối nàoBạn có thể tô màu bằng bất kỳ ngôn ngữ lập trình nào bạn có thể sử dụng trong tương laiDự án của bạn ít có khả năng phá vỡ

Như bạn thấy, tất cả tùy thuộc vào bối cảnh. Phát minh lại bánh xe là điều tôi làm rất thường xuyên vì tôi muốn có thể và nghĩ cho bản thân mình và không dựa vào người khác nghĩ cho tôi. Tuy nhiên, nếu bạn đang chạy theo thời hạn hoặc những gì bạn cố gắng thực hiện là rất lớn và đã tồn tại, thì tốt hơn hết bạn nên sử dụng những gì đang có.

Một lý do hữu ích để phát minh lại bánh xe là vì mục đích học tập - nhưng tôi khuyên bạn nên thực hiện nó vào thời gian của riêng bạn. Khi có nhiều giải pháp đóng hộp sẵn có và mức độ trừu tượng được cung cấp nhiều hơn, chúng tôi trở nên năng suất hơn rất nhiều. Chúng ta có thể tập trung vào vấn đề kinh doanh hơn là những thứ chung chung đã được điều chỉnh nhiều lần. NHƯNG, vì lý do đó, bạn có thể mài giũa kỹ năng của mình và học hỏi được nhiều thứ bằng cách tự mình thực hiện lại một giải pháp. Chỉ không nhất thiết cho sử dụng sản xuất.

Một điều khác - nếu mối quan tâm là sự phụ thuộc vào thư viện bên thứ ba từ một công ty có thể biến mất, hãy đảm bảo có một tùy chọn để lấy mã nguồn, hoặc ít nhất là một vài lựa chọn khác ngoài đó để quay trở lại.

Nhân tiện, nếu bạn chọn tự thực hiện, hãy tránh làm điều này cho mật mã hoặc các chức năng liên quan đến bảo mật khác. Các công cụ đã được thiết lập (và đã được kiểm tra đầy đủ) có sẵn cho điều đó, và trong thời đại ngày nay, thật là quá mạo hiểm khi bạn tự lăn lộn. Điều đó không bao giờ có giá trị, và thật đáng sợ khi tôi vẫn nghe về các đội làm điều này.

Có hai loại hiệu quả - xử lý/tốc độ (đó là tốc độ thực thi nhanh) mà nó có thể phù hợp và tốc độ phát triển mà gần như chắc chắn sẽ không xảy ra. Đó là lý do đầu tiên - đối với bất kỳ vấn đề phức tạp hợp lý nào có sẵn các giải pháp hiện có, gần như chắc chắn sẽ nhanh hơn để nghiên cứu và triển khai một thư viện hiện có hơn là viết mã của riêng bạn.

Lý do thứ hai là thư viện hiện tại (giả sử đã trưởng thành) đã được thử nghiệm và được chứng minh là có hiệu quả - có thể trong phạm vi rộng hơn nhiều so với nhà phát triển và nhóm thử nghiệm sẽ có thể đặt mới thói quen bằng văn bản thông qua và điều này đến ở nỗ lực không.

Thứ ba, đó là cách dễ dàng hơn để hỗ trợ. Không chỉ người khác hỗ trợ và cải thiện nó (bất cứ ai đã viết thư viện/thành phần), nhưng nhiều khả năng các nhà phát triển khác sẽ quen thuộc với nó và có thể hiểu và duy trì mã đi về phía trước, tất cả đều giảm thiểu chi phí đang diễn ra.

Và tất cả những gì giả định tương đương chức năng, thường không phải là trường hợp. Các thư viện thường xuyên sẽ cung cấp chức năng mà bạn sẽ thấy hữu ích nhưng không bao giờ có thể biện minh cho việc xây dựng, tất cả đều có sẵn miễn phí.

Có nhiều lý do để tự mình thực hiện - phần lớn là nơi bạn muốn làm điều gì đó mà chức năng tích hợp không thể làm và nơi nào có lợi thế thực sự để đạt được điều đó hoặc khi các tùy chọn có sẵn không thành thục - nhưng chúng Bạn sẽ ít phổ biến hơn nhiều nhà phát triển sẽ tin bạn.

Bên cạnh đó, tại sao bạn muốn dành thời gian giải quyết các vấn đề đã được giải quyết? Vâng, đó là một cách tuyệt vời để học nhưng bạn không nên làm điều đó với chi phí cho giải pháp phù hợp cho mã sản xuất, đó là điều mà tôi cho rằng chúng ta đang nói đến.

Xem thêm: Vòng Quay Vốn Lưu Đông Cách Tính ? Ý Nghĩa Và Cách Tính

Tất nhiên phát minh lại bánh xe một cách bất chợt, vì sự thiếu hiểu biết và kiêu ngạo có thể là một điều xấu, nhưng IMHO con lắc đã vung quá xa. Có một lợi thế rất lớn khi có một bánh xe thực hiện chính xác những gì bạn muốn và không có gì nữa .

Thông thường khi tôi nhìn vào một bánh xe hiện có, nó sẽ hoạt động nhiều hơn tôi cần, chịu đựng hiệu ứng nền tảng bên trong, và do đó phức tạp không cần thiết, hoặc nó thiếu một số tính năng chính mà tôi làm cần và điều đó sẽ khó thực hiện trên đầu trang của những gì đã có.

Hơn nữa, sử dụng các bánh xe hiện có thường thêm các ràng buộc cho dự án của tôi mà tôi không muốn. Ví dụ:

Bánh xe hiện tại yêu cầu một ngôn ngữ và/hoặc phong cách lập trình khác với cách tôi muốn sử dụng.Bánh xe hiện tại chỉ hoạt động với phiên bản kế thừa của một ngôn ngữ (ví dụ: Python 2 thay vì Python 3).Trong trường hợp có sự đánh đổi giữa hiệu quả, tính linh hoạt và sự đơn giản, bánh xe hiện tại sẽ đưa ra các lựa chọn không tối ưu cho trường hợp sử dụng của tôi. (Tôi được biết là đã phát minh lại ngay cả chức năng từ các thư viện mà ban đầu tôi đã tự viết trong những trường hợp này. Thông thường là do tôi đã viết phiên bản thư viện của hàm là chung chung và hiệu quả một cách hợp lý, khi tôi hiện cần một thứ gì đó rất nhanh trong cụ thể của tôi trường hợp.)Bánh xe hiện tại có vô số hành trình kế thừa hoàn toàn vô dụng trong trường hợp mã mới nhưng dù sao cũng khiến cuộc sống trở nên khó khăn (ví dụ, thư viện a Java tôi sử dụng buộc tôi phải sử dụng các lớp container nhảm nhí của nó vì nó đã được viết trước khi khái quát, vv).Cách mô hình bánh xe hiện tại vấn đề hoàn toàn khác so với những gì thuận tiện cho trường hợp sử dụng của tôi. (Ví dụ: có thể thuận tiện cho tôi khi có một biểu đồ được định hướng được biểu thị bởi các đối tượng và tham chiếu nút nhưng bánh xe hiện tại sử dụng ma trận kề hoặc ngược lại. Có thể tôi thuận tiện để sắp xếp dữ liệu của mình theo thứ tự chính của cột, nhưng bánh xe hiện tại nhấn mạnh vào hàng chính hoặc ngược lại.)Thư viện thêm một sự phụ thuộc lớn, dễ vỡ sẽ là một rắc rối lớn để bắt đầu và chạy ở mọi nơi tôi muốn triển khai mã của mình, khi tất cả những gì tôi cần là một tập hợp nhỏ các tính năng của nó. Mặt khác, trong trường hợp này đôi khi tôi chỉ trích xuất tính năng tôi muốn vào một thư viện mới, nhỏ hơn hoặc chỉ sao chép/dán nếu thư viện là nguồn mở và cơ sở mã hóa làm cho việc đó đủ đơn giản. (Tôi thậm chí đã làm điều này với các thư viện tương đối lớn Tôi đã tự viết, không chỉ cho người khác.)Các bánh xe hiện tại cố gắng tuân thủ theo phương pháp giáo dục với một số tiêu chuẩn vừa bất tiện vừa không liên quan đến trường hợp sử dụng của tôi.Thường thì tôi sử dụng của riêng mình vì tôi đã xây dựng nó trước khi tôi phát hiện ra cái đã có từ trước và tôi quá lười để đi tìm và thay thế mọi trường hợp. Ngoài ra, tôi hoàn toàn hiểu phương pháp của riêng mình trong khi tôi có thể không hiểu phương pháp tồn tại từ trước. Và cuối cùng, vì tôi không hiểu đầy đủ về cái đã tồn tại trước đó, tôi không thể xác minh rằng nó hoàn toàn làm mọi thứ mà cái hiện tại của tôi làm.

Có rất nhiều mã để viết mã và tôi không có nhiều thời gian để quay lại và mã hóa lại một cái gì đó trừ khi nó ảnh hưởng đến sản xuất.

Trên thực tế, một ứng dụng web asp vẫn được sử dụng ngày nay có biểu đồ đầy đủ chức năng hiển thị dữ liệu theo định dạng bảng và cho phép sắp xếp/chỉnh sửa, tuy nhiên nó không phải là một biểu dữ liệu. Nó được xây dựng vài năm trước khi tôi mới học asp.net và không biết về datagrids. Tôi hơi sợ mã vì tôi không biết tôi đang làm gì lúc đó, nhưng nó hoạt động, chính xác, dễ sửa đổi, không bị sập và người dùng thích nó

Có hay không phát minh lại bánh xe là một điều chi phí/lợi ích. Chi phí khá rõ ràng ...Phải mất rất nhiều thời gian để làm lại.Nó thậm chí còn mất nhiều thời gian hơn để ghi lại những gì bạn đã phát minh ra.Bạn không thể thuê những người đã hiểu những gì bạn đã phát minh ra.Tất cả đều quá dễ dàng để phát minh lại một cái gì đó tồi tệ, gây ra chi phí liên tục cho các vấn đề gây ra bởi thiết kế xấu.Mã mới có nghĩa là lỗi mới. Mã cũ thường đã loại bỏ hầu hết các lỗi và có thể có cách giải quyết tinh tế cho các vấn đề bạn không biết và do đó không thể khắc phục trong thiết kế mới.

Điều cuối cùng rất quan trọng - có một bài đăng trên blog ở đâu đó cảnh báo về xu hướng "vứt mã cũ đi và bắt đầu lại từ đầu" trên cơ sở rất nhiều hành trình cũ mà bạn không hiểu là lỗi thực sự cần thiết. Có một câu chuyện cảnh báo về Netscape, IIRC.

Những lợi thế có thể là ...

Khả năng thêm các tính năng mà các thư viện hiện có không có. Ví dụ, tôi có các thùng chứa "duy trì" các trường hợp lặp/con trỏ của chúng. Chèn và xóa không làm mất hiệu lực các vòng lặp. Một trình vòng lặp trỏ vào một vectơ sẽ tiếp tục trỏ đến cùng một mục (không phải cùng chỉ mục) bất kể các phần chèn và xóa trước đó trong vectơ. Bạn chỉ đơn giản là không thể làm điều đó với các thùng chứa C++ tiêu chuẩn.Một thiết kế chuyên biệt hơn nhắm vào các yêu cầu cụ thể của bạn và tôn trọng các ưu tiên của bạn (nhưng hãy cẩn thận với xu hướng về hiệu ứng nền tảng bên trong).Kiểm soát hoàn toàn - một số bên thứ ba không thể quyết định thiết kế lại API theo cách có nghĩa là bạn phải viết lại một nửa ứng dụng của mình.Hiểu đầy đủ - bạn đã thiết kế nó theo cách đó, vì vậy bạn hy vọng hoàn toàn hiểu cách thức và lý do tại sao bạn làm như vậy. CHỈNH SỬA Bạn có thể học các bài học từ các thư viện khác mà không bị mắc vào cùng một bẫy bằng cách chọn lọc về cách bạn bắt chước chúng.

Một điều - sử dụng thư viện của bên thứ ba có thể được tính là phát minh lại bánh xe. Nếu bạn đã có thư viện cổ xưa, được sử dụng tốt, được kiểm tra tốt, hãy suy nghĩ cẩn thận trước khi loại bỏ nó để sử dụng thư viện của bên thứ ba thay thế. Nó có thể là một ý tưởng tốt trong thời gian dài - nhưng có thể có một lượng lớn công việc và rất nhiều bất ngờ khó chịu (từ sự khác biệt ngữ nghĩa tinh tế giữa các thư viện) trước khi bạn đến đó. Ví dụ, hãy xem xét ảnh hưởng của việc tôi chuyển từ các thùng chứa của riêng mình sang các thư viện tiêu chuẩn. Một bản dịch ngây thơ của mã gọi sẽ không cho phép thực tế là các bộ chứa thư viện tiêu chuẩn không duy trì các trình lặp của chúng. Các trường hợp sau đó tôi lưu một trình lặp để làm "dấu trang" không thể được thực hiện bằng cách sử dụng một bản dịch đơn giản - Tôi cần một số phương tiện thay thế không tầm thường để chỉ ra các vị trí dấu trang.

Tôi hiện đang làm việc cho một loạt các cheapskates.

Khi quyết định được đưa ra giữa "xây dựng hoặc mua", thay vì đưa ra quyết định hợp lý dựa trên kinh tế, các nhà quản lý đã chọn "xây dựng". Điều này có nghĩa là thay vì trả vài nghìn đô la cho một thành phần hoặc công cụ, chúng tôi dành nhiều tháng để xây dựng công trình của riêng mình. Mua một bánh xe từ một công ty khác sẽ tiêu tốn tiền từ ngân sách - vốn được tính vào các khoản thưởng cuối năm không chính đáng. Thời gian của lập trình viên là miễn phí và do đó không được tính vào tiền thưởng cuối năm (với lợi ích bổ sung là khiến các lập trình viên không hoàn thành mọi thứ "đúng hạn"), do đó một bánh xe được phát minh lại là một bánh xe miễn phí .

Trong một công ty hợp lý, chi phí so với lợi ích của việc mua bánh xe do người khác tạo ra so với việc phát minh lại bánh xe của chính mình sẽ dựa trên chi phí ngắn hạn và dài hạn, cũng như chi phí cơ hội bị mất vì người ta không thể tạo ra các vật dụng mới trong khi một phát minh lại bánh xe. Mỗi ngày bạn dành để phát minh lại bánh xe là một ngày khác bạn không thể viết một cái gì đó mới.

Trình bày về xây dựng so với mua . Bài viết về xây dựng so với mua .

Nếu tôi thấy ai đó rõ ràng đang phát minh lại bánh xe bằng cách xây dựng phương pháp riêng của họ về một thứ đã được tích hợp vào ngôn ngữ/khung. Đầu tiên, đối với các đối số, hãy giả sử rằng phương thức của họ hiệu quả như phương thức được xây dựng. Ngoài ra, nhà phát triển, nhận thức được phương thức tích hợp sẵn, thích phương thức riêng của mình.

Tại sao anh ta nên sử dụng cái được tích hợp trên cái của mình?

Phiên bản tích hợp sẽ có rất nhiều người đập vào nó - do đó, việc tìm và sửa nhiều lỗi hơn mã homebrew của bạn có thể có.

Cuối cùng, khi nhà phát triển địa phương của bạn rời đi và người khác phải duy trì mã mà anh ta đã viết, nó sẽ được tái cấu trúc hoàn toàn và thay thế bằng mã trong khuôn khổ Tôi biết điều này sẽ xảy ra bởi vì chủ nhân hiện tại của tôi có mã đã được chuyển sang các phiên bản mới hơn của VB trong những năm qua (sản phẩm lâu đời nhất đã có mặt trên thị trường khoảng 20 năm) và đây là những gì Nhà phát triển có việc làm lâu nhất trong văn phòng của tôi đã ở đây 17 năm.

Vấn đề của việc phát minh lại bánh xe là đôi khi không có bánh xe tiêu chuẩn, sẵn có sẽ làm những gì bạn cần. Có rất nhiều bánh xe tốt ngoài kia, với rất nhiều kích cỡ, màu sắc, vật liệu và phương thức xây dựng. Nhưng một số ngày bạn chỉ cần có một bánh xe thực sự nhẹ, đó là nhôm anot hóa màu xanh lá cây, và không ai làm được. Trong trường hợp đó, bạn phải làm cho riêng mình.

Bây giờ không phải nói rằng bạn nên tự làm bánh xe cho mọi dự án - hầu hết mọi thứ đều có thể sử dụng các bộ phận tiêu chuẩn và tốt hơn cho nó. Nhưng thỉnh thoảng, bạn thấy rằng các bộ phận tiêu chuẩn không hoạt động, vì vậy bạn làm cho riêng mình.

Điều quan trọng nhất là biết KHI NÀO để làm cho riêng bạn. Bạn phải có một ý tưởng tốt về những gì các bộ phận tiêu chuẩn có thể làm, và những gì họ không thể, trước khi bạn bắt đầu thiết kế của riêng bạn.

Trở nên "xấu" hay thậm chí là "xấu xa" là những từ khá mạnh mẽ.

Như mọi khi, có những lý do để chọn triển khai cá nhân so với tích hợp sẵn. Vào thời xưa, một chương trình C có thể gặp phải lỗi trong thư viện thời gian chạy, và do đó, đơn giản phải cung cấp triển khai riêng.

Điều này không áp dụng cho Java chương trình vì JVM được xác định rất nghiêm ngặt, nhưng một số thuật toán vẫn rất khó để hiểu đúng. Ví dụ Joshua Bloch mô tả cách thuật toán tìm kiếm nhị phân đơn giản lừa dối trong Java thư viện thời gian chạy có lỗi, phải mất chín năm để xuất hiện:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-gầnly.html

Nó đã được tìm thấy, cố định và phân phối trong tương lai Java phân phối.

Nếu bạn sử dụng tìm kiếm nhị phân dựng sẵn, bạn vừa tiết kiệm thời gian và tiền bạc bằng cách nhờ Sun thực hiện công việc tìm kiếm, sửa chữa và phân phối lỗi này. Bạn có thể tận dụng công việc của họ chỉ bằng cách nói "bạn cần ít nhất Java 6 cập nhật 10".

Nếu bạn sử dụng triển khai của riêng mình - rất có thể cũng có lỗi này - trước tiên bạn cần có lỗi để tự thể hiện. Vì điều này đặc biệt chỉ hiển thị trên các bộ dữ liệu LARGE, điều này chắc chắn sẽ xảy ra trong sản xuất ở đâu đó, có nghĩa là ít nhất một khách hàng của bạn sẽ bị ảnh hưởng và rất có thể mất tiền thật trong khi bạn tìm, sửa và phân phối lỗi.

Xem thêm: Nước Hoa Eau De Toilette Là Gì, Eau De Toilette Là Gì

Vì vậy, nó hoàn toàn hợp lệ để thích thực hiện của riêng bạn, nhưng lý do tốt hơn là thực sự tốt, vì nó chắc chắn sẽ đắt hơn so với tận dụng công việc của người khác.