Xấu hổ quá, tôi đã giới thiệu một thư viện "chung", được đặt tên như vậy, trong môi trường nhóm cách đây vài thập kỷ. Tôi đã không thực sự hiểu động lực hồi đó về những gì có thể xảy ra trong một nhóm phối hợp lỏng lẻo chỉ trong vài tháng.
Khi tôi giới thiệu, tôi nghĩ rằng tôi đã nói rõ và cũng ghi lại rằng đó là những điều mà tất cả chúng ta đều đồng ý, chúng tôi thấy hữu ích trên cơ sở hàng ngày, rằng nó dự định là một thư viện tối giản và thư viện không phụ thuộc vào điều gì khác ngoài thư viện chuẩn để dễ triển khai nhất có thể trong các dự án mới. Suy nghĩ của tôi lúc đó là việc chúng tôi mở rộng ra thư viện tiêu chuẩn cho những thứ mà trong miền cụ thể của chúng tôi, chúng tôi thấy hữu ích hàng ngày.
Và nó bắt đầu đủ tốt. Chúng tôi bắt đầu với một thư viện toán học ( common/math*) các thói quen mà tất cả chúng tôi sử dụng hàng ngày, vì chúng tôi làm việc trong đồ họa máy tính thường nặng về đại số tuyến tính. Và vì chúng tôi thường xen kẽ với mã C, chúng tôi đã đồng ý về một số chức năng tiện ích hữu ích như thế find_index, không giống nhưstd::findtrong C ++, sẽ trả về một chỉ mục cho một phần tử được tìm thấy trong một chuỗi thay vì một trình vòng lặp bắt chước cách các hàm C của chúng ta hoạt động - những thứ thuộc loại này - một chút chiết trung nhưng tối giản và được sử dụng rộng rãi đủ để vẫn quen thuộc và thiết thực với mọi người và sự quen thuộc ngay lập tức là một tiêu chí cực kỳ quan trọng như tôi thấy khi cố gắng tạo ra bất cứ thứ gì "phổ biến" hoặc "tiêu chuẩn" vì nếu nó thực sự là "phổ biến", thì nó phải có chất lượng quen thuộc về nó như là kết quả của nó áp dụng và sử dụng hàng ngày.
Nhưng theo thời gian, ý định thiết kế của thư viện tuột khỏi ngón tay tôi khi mọi người bắt đầu thêm những thứ họ sử dụng mà họ nghĩ rằng họ chỉ có thể sử dụng cho người khác, chỉ để không tìm thấy ai khác sử dụng nó. Và sau đó, một người nào đó bắt đầu thêm các chức năng phụ thuộc vào OpenGL cho các thói quen phổ biến liên quan đến GL. Hơn nữa, chúng tôi đã thông qua Qt và mọi người bắt đầu thêm mã phụ thuộc vào Qt, vì vậy thư viện chung đã phụ thuộc vào hai thư viện bên ngoài. Tại một số thời điểm, ai đó đã thêm các thói quen đổ bóng phổ biến phụ thuộc vào thư viện trình đổ bóng dành riêng cho ứng dụng của chúng tôi và tại thời điểm đó, bạn thậm chí không thể triển khai nó trong một dự án mới mà không đưa vào Qt, OGL, và thư viện trình đổ bóng dành riêng cho ứng dụng của chúng tôi một kịch bản xây dựng không tầm thường cho dự án của bạn. Vì vậy, nó biến thành mớ hỗn độn, phụ thuộc lẫn nhau.
Nhưng tôi cũng đã tìm thấy bằng cách tranh luận những gì nên và không nên vào thư viện này rằng những gì được coi là "phổ biến" có thể dễ dàng biến thành một ý tưởng rất chủ quan nếu bạn không đặt ra một quy tắc rất khó hiểu rằng "phổ biến" là gì những gì mọi người có xu hướng tìm thấy hữu ích trên cơ sở hàng ngày. Bất kỳ sự nới lỏng nào của các tiêu chuẩn và nó nhanh chóng suy giảm từ những thứ mà mọi người đều thấy hữu ích hàng ngày thành một thứ mà một nhà phát triển thấy hữu ích có thể có lợi cho người khác, và tại thời điểm đó, thư viện biến thành một mớ hỗn độn rất nhanh .
Nhưng hơn nữa khi bạn đạt đến điểm đó, một số nhà phát triển có thể bắt đầu thêm mọi thứ vì lý do đơn giản là họ không thích ngôn ngữ lập trình. Họ có thể không thích cú pháp của vòng lặp for hoặc lệnh gọi hàm, tại thời điểm đó, thư viện bắt đầu chứa đầy những thứ chỉ chống lại cú pháp cơ bản của ngôn ngữ, thay thế một vài dòng mã đơn giản không thực sự sao chép bất kỳ logic nào xuống một dòng mã kỳ lạ duy nhất chỉ quen thuộc với nhà phát triển đã giới thiệu một tốc ký như vậy. Sau đó, một nhà phát triển như vậy có thể bắt đầu thêm nhiều chức năng hơn vào thư viện chung được triển khai bằng cách sử dụng các tốc ký như vậy, tại thời điểm đó, các phần quan trọng của thư viện chung trở nên đan xen với những tốc ký kỳ lạ này có vẻ đẹp và trực quan đối với nhà phát triển đã giới thiệu nó nhưng xấu và xa lạ và khó hiểu đối với mọi người khác. Và tại thời điểm đó tôi nghĩ bạn biết rằng mọi hy vọng tạo ra một cái gì đó thực sự "chung" đều bị mất, vì "chung" và "không quen thuộc" là những ý tưởng trái ngược nhau.
Vì vậy, có tất cả các loại giun ở đó, ít nhất là trong môi trường nhóm phối hợp lỏng lẻo, với một thư viện với tham vọng rộng lớn và khái quát như "những thứ thường được sử dụng". Và trong khi vấn đề tiềm ẩn có thể là sự phối hợp lỏng lẻo trên tất cả các vấn đề khác, thì ít nhất nhiều thư viện nhằm phục vụ mục đích khác thường hơn, như một thư viện nhằm cung cấp các thói quen toán học và không có gì khác, có lẽ sẽ không suy giảm đáng kể về mặt thiết kế tinh khiết và phụ thuộc như một thư viện "chung". Vì vậy, khi nhìn lại tôi nghĩ sẽ tốt hơn nhiều nếu nhầm lẫn về phía các thư viện có ý định thiết kế rõ ràng hơn nhiều. Trong những năm qua, tôi cũng thấy rằng mục đích hẹp và khả năng áp dụng là những ý tưởng hoàn toàn khác nhau.
Ngoài ra, tôi thừa nhận ít nhất một chút không thực tế và quan tâm có thể hơi quá về tính thẩm mỹ, nhưng cách tôi có xu hướng nhận thức ý tưởng của tôi về chất lượng của thư viện (và thậm chí là "vẻ đẹp") được đánh giá nhiều hơn bởi liên kết yếu nhất của nó mạnh nhất, theo cách tương tự như nếu bạn đưa cho tôi loại thực phẩm ngon miệng nhất thế giới, nhưng trên cùng một đĩa, đặt thứ gì đó thối rữa lên đó có mùi rất tệ, tôi có xu hướng muốn từ chối toàn bộ đĩa. Và nếu bạn giống tôi về vấn đề đó và tạo ra thứ gì đó mời tất cả các loại bổ sung như một thứ gọi là "chung", bạn có thể thấy mình đang nhìn vào tấm tương tự đó với một thứ gì đó mục nát ở bên cạnh. Vì vậy, tôi cũng nghĩ rằng thật tốt nếu một thư viện được tổ chức và đặt tên và ghi lại theo cách mà nó không ' mời ngày càng nhiều hơn và nhiều bổ sung theo thời gian. Và điều đó thậm chí có thể áp dụng cho các sáng tạo cá nhân của bạn, vì tôi chắc chắn đã tạo ra một số thứ mục nát ở đây và ở đó, và nó "làm mờ" đi rất nhiều nếu nó không được thêm vào đĩa lớn nhất. Việc tách các thứ ra thành các thư viện nhỏ, rất đơn lẻ cũng có xu hướng tách mã tốt hơn, nếu chỉ nhờ vào đức tính tuyệt đối mà nó trở nên ít thuận tiện hơn để bắt đầu ghép mọi thứ.
Sự trùng lặp mã đã được rèn vào tôi trong những năm qua nhưng tôi cảm thấy như tôi nên thử nó lần này.
Những gì tôi có thể đề nghị trong trường hợp của bạn là bắt đầu làm cho nó dễ dàng trong việc sao chép mã. Tôi không nói sẽ sao chép và dán các đoạn mã lớn được kiểm tra kém, dễ bị lỗi xung quanh hoặc bất cứ thứ gì thuộc loại này, hoặc sao chép một lượng lớn mã không tầm thường có xác suất yêu cầu thay đổi trong tương lai.
Nhưng đặc biệt nếu bạn có ý định tạo ra một thư viện "chung", mà tôi cho rằng mong muốn của bạn là tạo ra thứ gì đó có thể áp dụng rộng rãi, có khả năng tái sử dụng cao và có lẽ lý tưởng là thứ gì đó bạn thấy hữu ích như bạn làm trong một thập kỷ kể từ bây giờ , sau đó đôi khi bạn thậm chí có thể cần hoặc muốn một số sao chép để đạt được chất lượng khó nắm bắt này. Bởi vì sự trùng lặp thực sự có thể phục vụ như một cơ chế tách rời. Giống như nếu bạn muốn tách một trình phát video khỏi trình phát MP3, thì ít nhất bạn phải sao chép một số thứ như pin và ổ cứng. Họ không thể chia sẻ những thứ này nếu không chúng được ghép nối một cách không thể tách rời và không thể được sử dụng độc lập với nhau và tại thời điểm đó, mọi người có thể không quan tâm đến thiết bị nữa nếu tất cả những gì họ muốn làm là phát MP3. Nhưng một thời gian sau khi bạn tách hai thiết bị này ra, bạn có thể thấy rằng trình phát MP3 có thể được hưởng lợi từ một thiết kế pin khác hoặc ổ cứng nhỏ hơn trình phát video, tại thời điểm đó bạn không còn sao chép bất cứ thứ gì; những gì ban đầu bắt đầu là sự trùng lặp để cho phép thiết bị phụ thuộc lẫn nhau này tách thành hai thiết bị độc lập, riêng biệt sau đó có thể tạo ra các thiết kế và triển khai không còn dư thừa.
Thật đáng để xem xét mọi thứ từ quan điểm của một người sử dụng thư viện. Bạn có thực sự muốn sử dụngmột thư viện giảm thiểu sao chép mã? Rất có thể là bạn sẽ không vì một thứ sẽ tự nhiên phụ thuộc vào các thư viện khác. Và các thư viện khác đó có thể phụ thuộc vào các thư viện khác để tránh sao chép mã của họ, v.v., cho đến khi bạn có thể cần nhập / liên kết 50 thư viện khác nhau để có được một số chức năng cơ bản như tải và phát tệp âm thanh, và điều đó trở nên rất khó sử dụng . Trong khi đó, nếu một thư viện âm thanh như vậy cố tình chọn sao chép một số thứ ở đây và ở đó để đạt được sự độc lập, nó sẽ trở nên dễ sử dụng hơn trong các dự án mới, và rất có thể nó sẽ không cần được cập nhật gần như thường xuyên vì nó đã thắng ' Không cần thay đổi do một thư viện bên ngoài phụ thuộc của nó thay đổi, có thể đang cố gắng thực hiện mục đích tổng quát hơn nhiều so với những gì thư viện âm thanh cần.
Vì vậy, đôi khi đáng để cố tình chọn sao chép một chút (một cách có ý thức, không bao giờ hết lười biếng - thực sự không cần thiết) để tách rời một thư viện và làm cho nó độc lập bởi vì thông qua sự độc lập đó, nó đạt được phạm vi ứng dụng thực tế rộng hơn và thậm chí ổn định (không có khớp nối hướng tâm hơn). Nếu bạn muốn thiết kế các thư viện có thể tái sử dụng nhiều nhất có thể sẽ kéo dài bạn từ dự án này sang dự án tiếp theo và sau nhiều năm, thì trên hết thu hẹp phạm vi của nó đến mức tối thiểu, tôi thực sự khuyên bạn nên xem xét sao chép một chút ở đây. Và tự nhiên viết các bài kiểm tra đơn vị và đảm bảo rằng nó thực sự được kiểm tra kỹ lưỡng và đáng tin cậy về những gì nó đang làm. Điều này chỉ dành cho các thư viện mà bạn thực sự muốn dành thời gian để khái quát hóa đến một điểm vượt xa một dự án duy nhất.