Có phải người Do Thái không phát minh lại bánh xe mà bỏ qua giới hạn của bộ nhớ con người?

Một điều làm việc tại Haskell và F # đã dạy tôi là ai đó trong một trường đại học thông minh hơn tôi có lẽ đã tìm thấy một sự trừu tượng cho những gì tôi đang làm. Tương tự như vậy trong C # và lập trình hướng đối tượng, có lẽ có một thư viện cho "nó", bất cứ điều gì tôi đang làm.

Có một sự nhấn mạnh vào việc tái sử dụng các khái niệm trừu tượng trong lập trình mà tôi thường cảm thấy khó xử giữa: 1) chỉ viết mã một cái gì đó ngắn và bẩn hoặc 2) dành cùng thời gian để tìm thư viện / giải pháp mạnh mẽ hơn của người khác và chỉ sử dụng nó.

Giống như gần đây, một trong những lập trình viên ở đây đã viết (de) serializer cho các tệp CSV và tôi không thể không nghĩ rằng một cái gì đó như thế có lẽ rất dễ tìm thấy trên mạng, nếu nó không đi kèm với tiêu chuẩn .NET API.

Mặc dù vậy, tôi không trách anh ấy, nhiều lần làm việc trong .NET Tôi đã vá một giải pháp dựa trên những gì tôi biết, chỉ để nhận ra rằng có một số phương thức gọi hoặc đối tượng hoặc một cái gì đó , thường trong cùng một thư viện, đã làm những gì Tôi muốn và tôi không biết về nó.

Đây chỉ là một dấu hiệu của sự thiếu kinh nghiệm, hay luôn luôn có một yếu tố đánh đổi giữa việc viết mới và tái sử dụng cũ? Điều tôi ghét nhất là khi tôi chạy qua một giải pháp mà tôi đã biết và quên đi. Tôi cảm thấy như một người không có khả năng tiêu hóa số lượng mã tuyệt đối được đóng gói sẵn với hầu hết các ngôn ngữ hiện nay.

Trước tiên, bạn cần học cách xác định "các thành phần" chung chung / có thể tái sử dụng đủ để thư viện hoặc giải pháp của bên thứ 3 có khả năng tồn tại. Khi bạn làm điều đó, hãy nhận ra rằng, ngay cả khi bạn là một nhà phát triển giỏi, kinh nghiệm tập thể của vô số nhà phát triển dành vô số thời gian cho cùng một vấn đề có thể đã tạo ra một giải pháp tốt hơn bạn có thể làm. Điều đó không có nghĩa là bạn không bao giờ nên "phát minh lại bánh xe", nhưng nếu bạn chọn làm như vậy, tốt hơn hết bạn nên có một lý do chính đáng để DAMN làm điều đó.

Có một sự nhấn mạnh vào việc tái sử dụng các khái niệm trừu tượng trong lập trình mà tôi thường cảm thấy khó xử giữa: 1) chỉ viết mã một cái gì đó ngắn và bẩn hoặc 2) dành cùng thời gian để tìm thư viện / giải pháp mạnh mẽ hơn của người khác và chỉ sử dụng nó.

Điều đáng nói là ngay cả khi bạn mất cùng thời gian để tìm một thư viện / giải pháp hiện có giống như tự viết, hãy nhớ rằng tự mình làm điều đó cũng có nghĩa là bạn sẽ phải duy trì nó mãi mãi . Bạn không chỉ phát minh lại bánh xe, mà còn toàn bộ phi hành đoàn để giữ cho nó chạy. Tất nhiên, một số thư viện bị lỗi hoặc bảo trì kém, nhưng đây là những điều bạn nên ghi nhớ khi chọn giải pháp của bên thứ 3.

Đôi khi đây là một dấu hiệu của sự thiếu kinh nghiệm, cho dù với ngôn ngữ cụ thể hoặc với lập trình nói chung. Tuy nhiên, đôi khi, nếu sự phù hợp không rõ ràng, tốt hơn là bạn nên cuộn mã của riêng bạn, chính xác những gì bạn muốn và không có gì hơn . Các thư viện chung, mặc dù thường hữu ích, có thể được xây dựng cho các yêu cầu mà bạn đơn giản không có, và trong một số trường hợp, mức độ hào phóng này có thể khiến chúng gặp nhiều rắc rối hơn giá trị của chúng.

Ví dụ: Đối với các dự án một người đàn ông nhỏ của tôi, tôi không bao giờ sử dụng thư viện ghi nhật ký "thực". Tôi sử dụng printbáo cáo cộng với một ít cấu hình ad-hoc. Tôi không muốn bị làm phiền với việc thiết lập và định cấu hình thư viện ghi nhật ký có nhiều tính năng hơn tôi từng sử dụng, khi các printcâu lệnh hoạt động tốt cho mục đích của tôi. Tôi cũng không muốn một phụ thuộc khác có thể không tương thích với phiên bản trình biên dịch / trình thông dịch tôi muốn sử dụng, sẽ phải được phân phối, v.v.

Chào mừng đến với thế giới lập trình. Vấn đề này sẽ là chủ đề của nhiều bất đồng giữa bạn và các đồng nghiệp tương lai. Bạn có hai lựa chọn:

1. Cuộn của riêng bạn.
2. Xây dựng một cái gì đó trên đầu giải pháp của người khác.

Tôi nghĩ rằng có những lúc cả hai giải pháp đều phù hợp. Chẳng hạn, tôi muốn tránh sử dụng trình phân tích cú pháp CSV của riêng mình nếu tôi có thể tránh được phần lớn vì công việc này khá tẻ nhạt. Mặt khác, các thư viện thường bị hạn chế. Tôi sẽ nói rằng đối với mọi dự án tôi từng làm, tôi đã gặp các thư viện sẽ giải quyết vấn đề của tôi một cách hoàn hảo nếu không vì sự thiếu sót này. Hoặc đôi khi một thư viện chính xác là những gì bạn cần khi bạn mới bắt đầu làm một việc gì đó, nhưng có hại hơn là giúp đỡ một khi bạn cần thay đổi.

Nói chung, tôi khuyên bạn không nên cố gắng tìm câu trả lời "chính xác" vì chúng không tồn tại. Khi nghi ngờ, chỉ cần đi với ruột của bạn. Tôi đã từng nghe ai đó nói rằng kinh nghiệm được xác định bởi bạn có bao nhiêu sai lầm ngu ngốc. Vì vậy, thông thường, bạn sẽ học một cái gì đó hoặc làm một cái gì đó hoạt động. Dù bằng cách nào, nó không phải là tất cả xấu.

Điều này (hoặc một điều tương tự) thường xảy ra với tôi trong một công việc trước đây, nơi khuôn khổ đang chịu ảnh hưởng nghiêm trọng của Nền tảng bên trong.

Về cơ bản, cơ sở mã của họ đã phát triển từ những ngày đầu Windows C / C ++, sau đó bắt đầu được biên dịch theo MFC - và do đó, các nhà bảo trì bắt đầu trộn MFC và các cấu trúc dữ liệu cũ trong nhà và các thành phần cửa sổ. Nền tảng bên trong không được ghi chép rõ ràng, nhưng nó được cho là "Cách thức" để thực hiện mọi thứ trên sản phẩm đó, do một số phương tiện nội bộ mà nó cung cấp. Tôi thường thấy việc viết nội dung của mình từ đầu trở nên dễ dàng và nhanh chóng hơn (từ các nguyên tắc cơ bản của MFC), thay vì tìm ra cách thực hiện với khung bên trong của công ty.

(Được rồi, vì vậy điều này dường như trái ngược với quan điểm ban đầu của bạn - nhưng nguyên tắc là như vậy, hehe! Vâng, đôi khi thực sự làm việc của bạn nhanh hơn là dành thời gian và nỗ lực để tìm kiếm một thứ có thể sử dụng lại hiện có giải pháp.)