Là phát minh lại bánh xe thực sự là tất cả xấu?

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 xấu .

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.

Đ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 một trong những hơn một mình?

Như tôi đã từng đăng trên StackOverflow, phát minh lại bánh xe 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 phần mềm, điều này thường rất cần thiết. Đối với một cuộc thảo luận đầy đủ, xem bài viết gốc của tôi .

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ế.

Tô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 cạnh và những khó khăn mà người sáng chế thậm chí không thể tưởng tượng được.

Bánh xe vuông phải được phát minh lại. Nỗ lực mà phải được nhân đôi. Có lẽ 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.

Nó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 một cái gì đó gần đúng với nó, tồn tại trong thư viện tiêu 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, thì đó 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 hay 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 sự 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ó khả năng 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 chấp nhận được . 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ừ đó, thư viện được đánh giá cao trên toàn ngành công nghiệp cũng thường được chấp nhận (như Boost cho C ++, hoặc jQuery cho Javascript) - nhưng họ vẫn còn ít mong muốn hơn so với thư viện chuẩn vì họ làm có xu hướng ít ổn định hơn so với các thư viện chuẩn .

Đố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ã tái sử dụng 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.

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 lựa chọn: hoặc phát minh lại bánh xe HOẶC 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ạy
• Thêm một phụ thuộc của bên thứ ba cho một cái gì đó tầm thường
• Bạ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ắc
• Bạ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ào
• Bạ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 lai
• Dự á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 hết lần này đến lần khác. 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ỉ cần 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 của 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ờ đáng, và thật đáng sợ khi tôi vẫn nghe về các đội làm việc 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ể đưa ra một thói quen mới được viết và điều này xuất hiện không nỗ lực.

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), mà nhiều khả năng các nhà phát triển khác sẽ quen 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 việc tiếp tục chi phí.

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 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í là 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.

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ế to lớn để 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ì hơn thế .

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 hiệu ứng nền tảng bên trong và do đó phức tạp không cần thiết hoặc thiếu một số tính năng chính mà tôi cần và điều đó rất 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).
• Khi 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ụ, một thư viện Java mà 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ó bởi vì nó được viết trước khi khái quát, v.v.) .
• 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. 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à codebase 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ó

Phát minh lại bánh xe là một cách tuyệt vời để tìm hiểu cách bánh xe hoạt động, nhưng nó không phải là một cách tốt để chế tạo một chiếc xe hơi.

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 giờ"), do đó, bánh xe được phát minh lại là 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 vs mua .
Bài viết về xây dựng vs 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. 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 một trong những hơn một 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 những gì trong khung. 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 VB mới hơn 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à điều đã xảy ra. 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 tự làm.

Đ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.

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.
• EDIT 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 tôi lưu một trình lặp lại sau này dưới dạng "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 '

Nếu có một thành phần làm việc làm những gì bạn cần thì tại sao lại dành thời gian viết và gỡ lỗi phiên bản của riêng bạn? Tương tự, nếu bạn đã viết mã để thực hiện một chức năng tương tự trước đây, tại sao lại viết lại nó?

Joel đã viết một bài báo về Không được phát minh - ở đây nói nhiều về việc khi viết lại mã và phần mềm không và không hữu ích.

Phát minh lại bánh xe có thể là một cách tuyệt vời để tìm hiểu cách thức hoạt động của một cái gì đó - và tôi khuyên bạn nên phát minh lại cho mục đích đó vào thời gian của riêng bạn - nhưng khi viết một ứng dụng tại sao lại phát minh ra nếu có các giải pháp được thiết lập tốt đã làm điều tương tự?

Ví dụ, tôi sẽ không bao giờ viết mã JavaScript từ đầu; thay vào đó tôi sẽ bắt đầu với jQuery và xây dựng các ứng dụng của mình trên khung đó.

Quy tắc cá nhân của tôi:

Phát minh lại bánh xe là tốt khi bạn chỉ đang học. Nếu bạn có thời hạn, bạn có thể muốn sử dụng các bánh xe hiện có.

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. Ngày xưa, một chương trình C có thể gặp lỗi trong thư viện thời gian chạy, và do đó đơn giản là phải cung cấp việc thực hiện riêng.

Điều này không áp dụng cho các chương trình Java 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ó để có được đúng. Chẳng hạn, 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 thư viện thời gian chạy Java có một 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 các bản phân phối Java trong tương lai.

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 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 trong số các 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.

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.

Gần đây tôi đã viết những suy nghĩ của tôi về chủ đề này. Để tóm tắt:

1. Đó là hầu như luôn luôn ác để xây dựng riêng của bạn, đặc biệt đúng nếu nó là một chức năng thats được xây dựng vào ngôn ngữ. Nhưng nếu bạn đang đánh giá một khuôn khổ chưa trưởng thành / được duy trì một cách nghi ngờ / tài liệu tồi mà bạn tìm thấy trên Internet chống lại khả năng tự viết, thì đó có thể là một việc không có trí tuệ.

2. Tôi nghĩ rằng việc phát minh lại bánh xe là một sự tương tự khá khủng khiếp đối với một mô hình chống phần mềm. Nó ngụ ý rằng giải pháp ban đầu không bao giờ có thể được cải thiện. Điều đó là vô nghĩa. Cái gọi là bánh xe có thể trở nên lỗi thời chỉ sau một đêm, hoặc chủ sở hữu của nó có thể ngừng duy trì nó. Bánh xe có một giá trị khác nhau ở mỗi hệ thống được sử dụng. Vì vậy, thường hoàn toàn có thể phát minh ra một bánh xe tốt hơn.

3. Một lợi ích lớn của việc tạo khung riêng của bạn là bạn sẽ không phải chịu trách nhiệm về lỗi của người khác. (Đây là triết lý của Amazon .) Hãy nghĩ về nó theo cách này: cách nào tốt hơn để nói với khách hàng? -

   "Trang web của chúng tôi đã bị hỏng. Đó là lỗi của người khác và chúng tôi đã đăng nhập một lỗi với người tạo ra nó. Chúng tôi không thể làm gì khác ngoài việc chờ đợi. Chúng tôi sẽ cập nhật cho bạn."

   "Trang web của chúng tôi đã bị hỏng và chúng tôi đã có thể khắc phục ngay lập tức."

Có lẽ nó chỉ hiệu quả, nhưng nó có mạnh mẽ không? Tôi nghĩ lý do hấp dẫn nhất để sử dụng một thư viện thay vì sử dụng thư viện của bạn là khung công tác có rất nhiều người sử dụng nó để họ có thể tìm và sửa lỗi nhanh chóng. Thư viện phát triển nội bộ, trong khi chúng có thể cung cấp nhiều chức năng (hoặc hơn), không thể cạnh tranh với thư viện có hàng triệu người dùng để cung cấp thử nghiệm trong hầu hết mọi trường hợp sử dụng. Bạn không thể đánh bại loại thử nghiệm nội bộ đó.

Chà, phương pháp riêng của anh ta hiệu quả như khung sẽ khá hiếm vì hầu hết các khung vẫn có lỗi và không có khung nào có thể cung cấp cho bạn một giải pháp vượt trội. Hầu hết các lập trình viên không thể nghĩ sẽ không bao giờ cố gắng viết bất cứ điều gì ở cấp độ khung; họ sẽ chỉ tìm kiếm Google cho một giải pháp làm sẵn. Bất kỳ lập trình viên thông thái nào trước tiên sẽ thấy nếu có một khung công tác miễn phí có chức năng anh ta cần, sau đó tự viết giải pháp nếu không có. Đôi khi thật khó để giải thích các dự án hiện tại và nhà phát triển là người đánh giá tốt nhất.

Phát minh lại bánh xe không phải là xấu, đó là một tuyên bố của những người lười biếng để tránh làm việc chăm chỉ. Ngay cả các nhà văn khung làm lại phát minh; toàn bộ khung .Net đã được phát minh lại để thực hiện những gì COM đang cung cấp.

Khó chịu như một số người, tôi luôn thấy thuật ngữ này là không rõ ràng khi được sử dụng bởi bất kỳ hình thức kỹ sư nào hoặc liên quan đến một chủ đề tạo ra hoặc thiết kế mọi thứ. Trên thực tế, tôi không thể không coi đó là sự thiếu tôn trọng khi xem xét những áp lực phải đổi mới trong thế giới nhịp độ nhanh ngày nay. Lặp đi lặp lại chính mình (hoặc bỏ qua các giải pháp đầy đủ, có sẵn) không bao giờ là khôn ngoan, nhưng thực sự, có một lý do tại sao tất cả chúng ta vẫn không nhìn chằm chằm vào màn hình đen đầy chữ màu xanh lá cây.

Tôi hiểu "Nếu nó không bị hỏng thì đừng sửa nó", mặc dù tôi đoán một cụm từ như vậy nghe có vẻ không biết gì với một số người. Tuy nhiên, với nỗ lực hiện tại để phát minh lại bánh xe cho các nhu cầu du hành không gian, đua xe, vận chuyển, v.v., "đừng tái tạo lại bánh xe" cũng khá ngu dốt và không có gì thông minh như âm thanh.

Nền tảng của tôi bao gồm nhiều dự án hàng đầu và tôi đã phải làm việc với nhiều thực tập sinh và các hình thức phát triển xanh khác, và tôi đã phải xử lý nhiều câu hỏi ngây thơ mà một số người sẽ gọi là 'ngu ngốc', và cũng phải chuyển hướng mọi người khỏi đuổi theo thỏ wholes ngoài phạm vi của nhiệm vụ của họ. Tuy nhiên, tôi sẽ không bao giờ ngăn cản sự đổi mới hoặc sáng tạo, và đã thấy những điều tuyệt vời đến từ 'tái tạo bánh xe'.

Câu trả lời thực tế của tôi cho câu hỏi: Chỉ có hai tình huống khiến việc phát minh lại bánh xe là một điều tồi tệ:

1. Nếu nó không thực sự cần thiết
2. Nếu đó là người đàn ông khác làm điều đó khi bạn có thể có

Chỉnh sửa: Tôi có thể nhìn thấy bằng cách bỏ phiếu xuống mà tôi phải xúc phạm một số. Một điều mà tôi muốn nói thêm là cụm từ này luôn là một thú cưng lớn của tôi. Tôi hiểu rằng hai xu của tôi nghe có vẻ khá troll, nhưng tôi không có ý định troll, gây ra hỏa hoạn hoặc xúc phạm.

Các lập luận về "phát minh lại một bánh xe" thường được sử dụng trong bối cảnh sai lầm khi chọn sử dụng thư viện nhưng nó hầu như không giống nhau.

Giả sử tôi đang đánh giá một thư viện 'biểu mẫu cộng', gần đây đã trở nên phổ biến và giúp xử lý các biểu mẫu. Nó có một trang đích đẹp, đồ họa hiện đại, và một cộng đồng - (rất tiếc, ý tôi là cộng đồng) xung quanh nó, người thề rằng làm thế nào để nó làm cho các hình thức trở nên tuyệt vời trở lại. Nhưng "hình thức cộng" là một sự trừu tượng hóa trên đầu "hình thức". "Các hình thức" là có thể nhưng khó xử lý, vì vậy sự trừu tượng làm cho nó dễ dàng hơn đang trở nên phổ biến.

Trừu tượng mới đang diễn ra tất cả các thời gian. Thật khó để so sánh chúng với bánh xe. Nó giống như một thiết bị điều khiển mới và hướng dẫn mới cho bất kỳ thiết bị nào đã rất phức tạp mà bạn cần chạy.

Định giá của thiết bị mới này "hình thức cộng" sẽ trông khác nhau tùy thuộc vào kinh nghiệm cá nhân. Nếu tôi chưa bao giờ xây dựng các biểu mẫu trước đó thì "biểu mẫu cộng" sẽ rất hấp dẫn bởi vì nó dễ dàng hơn để bắt đầu. Nhược điểm là nếu "form-plus" hóa ra là sự trừu tượng bị rò rỉ thì tôi vẫn sẽ cần phải học "biểu mẫu". Nếu tôi đang xây dựng các biểu mẫu mà không có "biểu mẫu cộng" thì tôi sẽ cần tính đến thời gian mà tôi cần để học công cụ mới. Ưu điểm là tôi đã biết "các hình thức" vì vậy tôi không sợ sự trừu tượng trên nó. Lợi ích ngắn hạn thường sẽ lớn hơn cho những người mới bắt đầu bởi vì có lẽ sẽ không có thư viện mới nếu nó không cải thiện điều gì. Lợi ích dài hạn sẽ thay đổi lớn về chất lượng trừu tượng, tỷ lệ chấp nhận,

Sau khi đánh giá cẩn thận lợi ích và tiêu cực của việc sử dụng một hình thức trừu tượng mới "cộng với" so với sử dụng xương trần ", tôi đưa ra quyết định. Quyết định dựa trên kinh nghiệm cá nhân của tôi và những người khác nhau sẽ đưa ra quyết định khác nhau. Tôi có thể đã chọn sử dụng "hình thức" xương trần. Có lẽ sau này trong các hình thức thời gian cộng với đã có thêm chuyển động đằng sau nó và trở thành một tiêu chuẩn defacto. Và có lẽ việc thực hiện của riêng tôi theo thời gian đã có lông và bắt đầu bao gồm rất nhiều những gì hình thức - cộng với hiện đang làm. Những người đến vào thời điểm này sẽ bị lôi kéo chỉ trích rằng tôi rất muốn sáng tạo lại bánh xe và thay vào đó tôi nên sử dụng thư viện hiện có. Nhưng cũng có thể vào thời điểm tôi phải đưa ra quyết định về "biểu mẫu cộng" cũng có nhiều lựa chọn thay thế khác cho "biểu mẫu cộng",

Cuối cùng, lựa chọn công cụ phù hợp là một quyết định phức tạp để thực hiện và "phát minh lại bánh xe" không phải là một quan điểm rất hữu ích.

Tôi đã viết một bài viết nhỏ về điều này - http://samueldeleque.tumblr.com/post/77811984752/what-re-inventing-the-wheel-can-teach-you

Theo kinh nghiệm của tôi, phát minh lại thực sự rất tuyệt - mặc dù rất dài và tẻ nhạt. Tôi sẽ nói, nếu bạn không biết chính xác các mô hình lập trình bạn sẽ sử dụng, thì hãy tự viết chúng (nếu bạn có thời gian và sức lực). Điều này sẽ dạy cho bạn biết chính xác những mô hình lập trình đó có ý nghĩa gì và cuối cùng bạn sẽ trở thành một lập trình viên tốt hơn. Tất nhiên, nếu bạn đang làm việc cho một khách hàng và chỉ cần nhanh chóng nhận được một cái gì đó, có lẽ bạn sẽ chỉ muốn thực hiện một số nghiên cứu và tìm ra phần mềm phù hợp với bạn.