Điều gì được tính là phát minh lại bánh xe?

Các tình huống sau có được tính là "phát minh lại bánh xe" trong cuốn sách của bạn không?

• Một giải pháp tồn tại, nhưng không phải bằng ngôn ngữ bạn muốn sử dụng và các giải pháp hiện có không thể được giao tiếp với ngôn ngữ bạn muốn sử dụng theo cách sạch sẽ, thành ngữ.

• Về nguyên tắc, bạn có thể có được một thư viện hiện có để làm những gì bạn muốn với sửa đổi nặng, nhưng bạn nghĩ có lẽ sẽ dễ dàng hơn để bắt đầu lại từ đầu.

• Những gì bạn đang viết có mô tả một dòng giống như những gì đã được thực hiện, nhưng bạn đang nhắm mục tiêu vào một phân khúc khác. Ví dụ: có thể vấn đề của bạn đã được giải quyết hàng trăm lần trước đây, nhưng theo cách đó không hiệu quả đối với các bộ dữ liệu lớn và mã của bạn hoạt động tốt cho các bộ dữ liệu lớn.

Nếu có một giải pháp hiện có mà trong mắt bạn sẽ là một giải pháp thiết thực , thì không sử dụng giải pháp đó mà tạo ra giải pháp của riêng bạn sẽ là phát minh lại bánh xe. Khác hơn thế, nó rất chủ quan.

Về các kịch bản cụ thể của bạn:

1. Bạn luôn muốn mã sạch, dễ bảo trì và dễ hiểu. Điều đó đi trên phát minh lại bánh xe, IMHO. Hạn chế thời gian có thể khiến bạn muốn phá vỡ điều này mặc dù.
2. Nếu dễ dàng hơn để bắt đầu từ đầu, hãy làm điều đó. Bạn cũng có thể sẽ nhận được kết quả tốt hơn nếu mã được điều chỉnh cho nhu cầu cụ thể.
3. Nếu một giải pháp là một giải pháp tồi cho vấn đề của bạn, thì đó không phải là phát minh lại bánh xe để tạo ra một giải pháp mới, đó là tạo ra một bánh xe tốt hơn .

Phát minh lại bánh xe là những gì người khác buộc tội bạn khi phân tích của bạn cho thấy bạn nên tự viết một cái gì đó và của họ thì không.

Tôi nghĩ rằng việc phát minh lại bánh xe có thể được định nghĩa khá đơn giản: khi về lâu dài, bạn tự làm nhiều việc hơn để viết nó thay vì sử dụng thư viện. Lưu ý rằng không phải lúc nào cũng rõ ràng công việc có thể xảy ra trong bao lâu . Bạn có thể tự mình hack một nguyên mẫu nhanh hơn bạn có thể cấu trúc lại mã hiện có của mình để bao gồm thư viện, nhưng về lâu dài, khi bạn thêm nhiều khả năng hoặc phải hỗ trợ mã, thư viện sẽ hoạt động tốt hơn.

Điểm mấu chốt là, bạn cần suy nghĩ cẩn thận về tình huống của mình khi quyết định có sử dụng thư viện hay không. Bạn cần phải quyết định xem thư viện có dễ dàng hơn cho những gì bạn muốn làm bây giờ và dễ dàng hơn cho những gì bạn sẽ làm trong tương lai . Biết những gì bạn sẽ làm trong tương lai không phải lúc nào cũng thẳng tiến, nhưng nếu bạn có một kế hoạch tốt, bạn nên có một ý tưởng sơ bộ. Điều đó nói rằng, đôi khi dự báo là không chính xác - bạn thường không nhận ra rằng bạn đã phát minh lại bánh xe cho đến khi bạn thực hiện nó.

Nó quá rộng và chủ quan để có thể trả lời với bất kỳ độ chính xác nào đơn giản chỉ vì mỗi trường hợp là khác nhau.

Hoàn toàn có thể chấp nhận để phát minh lại bánh xe khi cần thiết, điều quan trọng là sử dụng phán đoán của bạn để quyết định khi nào bánh xe trước là một giải pháp chấp nhận được và khi nó không đủ tròn để mang lại một chuyến đi suôn sẻ.

Đó là một câu hỏi cần phải được hỏi gần như hùng biện đôi khi để đảm bảo rằng phương pháp tốt nhất đang được sử dụng. Bạn thường có thể tìm thấy một thuật toán tốt hơn trong một cuốn sách hơn hầu hết các lập trình viên có thể viết trong thời gian cần thiết để tìm thấy nó.

Vấn đề càng lớn và càng phức tạp, bánh xe càng ít có khả năng phù hợp với chính xác nhu cầu của bạn và bạn càng hợp pháp để xây dựng lại nó.

Tôi nghĩ rằng chúng ta chỉ nên áp dụng "không phát minh lại bánh xe" cho các yếu tố cơ bản (các chức năng đã được xây dựng trong nền tảng, các mẫu thiết kế nổi tiếng ...) hoặc nếu có sẵn giải pháp chính xác cho vấn đề của bạn - nhưng đó là hiếm khi xảy ra trường hợp

3 điểm của bạn không được tính là phát minh lại bánh xe cho tôi.

Nó phụ thuộc ...

Đối với hai người đầu tiên:

• Một giải pháp tồn tại, nhưng không phải bằng ngôn ngữ bạn muốn sử dụng ...
• Về nguyên tắc, bạn có thể có được một thư viện hiện có để làm những gì bạn muốn với sửa đổi nặng ...

Trong cả hai trường hợp, việc viết mã của riêng bạn là điều hợp lý. Nhưng hãy xem xét điều này: giải pháp hiện có có chứa bất kỳ kỹ thuật, thuật toán hoặc thói quen nào mà bạn có thể học hỏi không? Bỏ qua những điều này sẽ được phát minh lại bánh xe.

• Những gì bạn đang viết có mô tả một dòng giống như những gì đã được thực hiện ... có thể vấn đề của bạn đã được giải quyết hàng trăm lần trước đây, nhưng theo cách đó không hiệu quả đối với các bộ dữ liệu lớn ...

Ba câu hỏi:

1. Một triệu là rất nhiều. Bạn đã thực sự xem xét tất cả các triển khai hiện có?
2. Là hiệu quả vấn đề chính của bạn?
3. Bạn có cần mã hóa giải pháp tối ưu bây giờ (và viết lại sau)?

Nếu câu trả lời cho bất kỳ câu nào trong số này là "Không", thì bạn đang phát minh lại bánh xe.

Điều đó nói rằng, tôi không tin rằng phát minh lại bánh xe luôn luôn là một điều xấu:

1. Đó là một cách tuyệt vời để học , và là cách duy nhất để thực sự hiểu các giải pháp hiện có.
2. Bánh xe của người khác có thể không tốt . Đó là cách duy nhất để làm cho bánh xe tốt hơn.
3. Ngay cả khi bánh xe của người khác là tuyệt vời, đôi khi bạn có thể kinh doanh tốt từ việc tạo ra bánh xe thậm chí còn tốt hơn .

Kịch bản đầu tiên của bạn, không áp dụng để phát minh lại bánh xe, nó tự giải thích.

Kịch bản thứ hai, KHÔNG áp dụng nếu mã hiện tại yêu cầu sửa đổi ít, nhưng nếu có, bạn nên thử sử dụng các thuộc tính, phương thức và cách sử dụng tương tự so với mã hiện có, vì vậy các nhà phát triển khác không gặp khó khăn khi sử dụng "Bánh xe".

Hãy cẩn thận bởi phương pháp "luôn luôn tốt hơn để bắt đầu từ sự thấu hiểu", nó có thể mất nhiều thời gian hơn bạn mong đợi.

Kịch bản thứ ba mà bạn đề cập, đó là cách tiếp cận "thực tế". "Bánh xe đã cho" có thể thực hiện công việc, nhưng, trong thực tế, tiêu tốn quá nhiều tài nguyên, bộ nhớ, tốc độ, v.v.

Tôi đã làm việc một lần trong một ứng dụng yêu cầu hiển thị dữ liệu phân cấp trong điều khiển treeview từ một bảng. Chúng tôi đã có một điều khiển có thể làm điều đó, nhưng hỗ trợ một số bảng cho mỗi mục.

Để sử dụng nó, tôi đã phải học quá nhiều thứ, gán quá nhiều thuộc tính, thực thi quá nhiều phương thức và CNTT ĐƯỢC CHẬM. Một đồng nghiệp khăng khăng sử dụng nó, để "không phát minh lại bánh xe".

Tôi đã thực hiện một điều khiển mới, từ đầu, đọc một bảng duy nhất, chỉ lập trình một vài thuộc tính dễ học. Và trước khi tôi biết điều đó, đã có một đồng nghiệp khác lấy nó từ kho lưu trữ mã được chia sẻ và thay thế điều khiển trước đó.

Tặng kem:

Khi bánh xe bạn đã có là "bình phương". Theo "bình phương", ý tôi là ở bề mặt, có vẻ như nó giống như một giải pháp cho vấn đề của bạn, nhưng sau khi nhìn tốt, bạn sẽ đi đến kết luận, không phải vậy.

Nó phụ thuộc vào việc bạn có kỹ năng và thời gian, (và ủy quyền công ty của bạn), để phát minh lại bánh xe.

Lần đầu tiên đọc bài viết xuất sắc này của Joel Spolsky: Bảo vệ Hội chứng không được phát minh ở đây

Sau đó, tất cả các lý do kỹ thuật trở thành sắc thái thực sự nhỏ. Nếu bạn cảm thấy phần mềm này rất quan trọng cho công việc của bạn, thì hãy viết lại nó. Vâng, đó là "phát minh lại bánh xe" nhưng có lẽ đáng để dành thời gian cho việc viết và duy trì. Nếu nó không quan trọng, thì chỉ cần sử dụng những gì có sẵn.

... Nếu bạn đã từng phải thuê ngoài một chức năng kinh doanh quan trọng, bạn sẽ nhận ra rằng thuê ngoài là địa ngục. Nếu không có sự kiểm soát trực tiếp đối với dịch vụ khách hàng, bạn sẽ nhận được dịch vụ khách hàng tồi tệ về đêm - những người tử tế viết về nhật ký web của họ khi họ cố gắng nhờ ai đó, bất cứ ai , từ một công ty điện thoại nào đó làm những việc cơ bản nhất. Nếu bạn thuê ngoài thực hiện và đối tác thực hiện của bạn có ý tưởng khác về việc tạo thành giao hàng nhanh chóng, khách hàng của bạn sẽ không hài lòng và bạn không thể làm gì về điều đó, vì trước tiên phải mất 3 tháng để tìm được đối tác thực hiện và trên thực tế, bạn thậm chí sẽ không biếtrằng khách hàng của bạn không hài lòng, vì họ không thể nói chuyện với bạn, vì bạn đã thiết lập một trung tâm dịch vụ khách hàng thuê ngoài với mục đích rõ ràng là không lắng nghe khách hàng của chính bạn. Đó là công cụ thương mại điện tử mà bạn đã mua? Không có cách nào nó sẽ linh hoạt như những gì Amazon làm với obidos, mà họ tự viết. (Và nếu có, thì Amazon không có lợi thế so với các đối thủ cạnh tranh đã mua cùng một thứ). Và không có máy chủ web nào sẵn có nhanh như những gì Google làm với máy chủ được tối ưu hóa bằng tay, được mã hóa bằng tay của họ.

Thật không may, nguyên tắc này dường như trực tiếp mâu thuẫn với lý tưởng "tái sử dụng mã tốt - phát minh lại bánh xe xấu".

Lời khuyên tốt nhất tôi có thể cung cấp:

    Nếu đó là một chức năng kinh doanh cốt lõi - hãy tự làm, không có vấn đề gì.

Chọn những năng lực và mục tiêu kinh doanh cốt lõi của bạn, và thực hiện những điều đó ...

Nếu bạn đang phát triển một trò chơi trên máy tính trong đó cốt truyện là lợi thế cạnh tranh của bạn, bạn có thể sử dụng thư viện 3D của bên thứ ba. Nhưng nếu các hiệu ứng 3D thú vị sẽ là đặc điểm nổi bật của bạn, bạn nên tự mình cuộn ...