Kiểu mã hóa khi sử dụng một số thư viện khác nhau

Tôi đang làm việc trên một số mã C ++ sử dụng một số thư viện, bao gồm một số thư viện C, tất cả đều có các kiểu mã hóa khác nhau. Nó sẽ được mở nguồn một khi nó đạt đến một giai đoạn có thể sử dụng. Điều nào sẽ gây ra sự nhầm lẫn ít nhất cho một người đóng góp ngắn hạn, người kiểm tra mã để sửa một lỗi hoặc thêm một tính năng?

• Có một kiểu mã hóa nhất quán trong toàn bộ ứng dụng, ngay cả khi đôi khi nó không khớp với kiểu mã hóa điển hình của các thư viện được sử dụng.
• Khi một thư viện được sử dụng nhiều trong một mô-đun nhất định, phù hợp với kiểu mã hóa điển hình của thư viện đó (tức là kiểu mã hóa được sử dụng trong mã và tài liệu riêng của thư viện) trong mô-đun đó.

Tôi nghĩ rằng cái sau sẽ giúp các chuyên gia trong thư viện cụ thể đó dễ dàng đóng góp một lần hơn và giúp kết hợp mã hướng dẫn / ví dụ trong quá trình phát triển dễ dàng hơn. Tuy nhiên, nó cũng làm cho phong cách mã hóa không nhất quán trong toàn bộ ứng dụng. Những ưu và nhược điểm của từng phương pháp là gì?

Tôi nghĩ rằng nó phụ thuộc vào mức độ lớn của dự án sẽ kết thúc.

Ở một thái cực, giả sử bạn có dự án 1 Mloc. Đối với dự án lớn đó, không chắc một cá nhân nào sẽ là "chuyên gia" trong tất cả các lĩnh vực liên quan. Vì vậy, trong trường hợp này, tôi sẽ gắn bó với các kiểu mã hiện có cho từng thành phần chính. Các nhà phát triển mới sẽ chọn một khu vực, tìm hiểu điều đó và không chắc họ sẽ thấy nhiều thành phần khác có thể có các kiểu mã khác nhau.

Nếu dự án là nhỏ hơn rất nhiều, mà nó là khả năng có cá nhân hiểu được toàn bộ cơ sở mã, sau đó tôi sẽ chọn một phong cách đang chiếm ưu thế và dính với điều đó. Trong trường hợp này, tôi nghĩ tính nhất quán trong toàn bộ dự án có ý nghĩa hơn bởi vì các nhà phát triển mới sẽ có khả năng làm việc trong tất cả các lĩnh vực của dự án.

Các dự án cỡ trung bình có lẽ là khó nhất để đưa ra quyết định này. Trong trường hợp này, bạn phải cân nhắc chi phí cho mỗi phương pháp và quyết định phương pháp bạn nghĩ sẽ ít tốn kém nhất về lâu dài. Thách thức là các dự án có quy mô trung bình thường phát triển vừa đủ để tái cấu trúc kiểu hoàn chỉnh trông đắt đỏ. Bạn có thể muốn có cái nhìn thứ hai về cấu trúc cây mã để xem liệu mọi thứ có thể được sắp xếp để nhóm các kiểu mã cụ thể lại với nhau không.

Dù bằng cách nào, quyết định cuối cùng sẽ thuộc về đội bạn đang đặt gói này cùng nhau.

Một số ngoại lệ có thể thay đổi lý luận của tôi từ phía trên:

• Nếu một hoặc nhiều mô-đun có phong cách tàn bạo, thì sẽ không có ý nghĩa gì trong việc giữ nó xung quanh, ngay cả trong một dự án lớn hơn. Đúng, phong cách là chủ quan, nhưng nếu bạn và những người tham gia dự án của bạn thực sự, thực sự không thích cách các khu vực cụ thể chảy qua thì hãy biến phong cách cũ và cho nó một phong cách tốt hơn.

• Nếu tất cả các kiểu gần nhau một cách hợp lý, có thể dễ dàng khai báo "đây là cách mới" và sử dụng kiểu đó cho tất cả các mã mới và các phép tái cấu trúc quan trọng. Điều này có thể làm cho các đánh giá hơi đau một chút, nhưng theo kinh nghiệm của tôi, hầu hết dân gian đều có khả năng thích nghi với phương pháp này. Nó cũng cung cấp một dấu hiệu nhận biết nơi mã cũ.

• Đôi khi phong cách được thay đổi dựa trên chức năng mới được thêm vào ngôn ngữ. C ++ đã chọn một số tính năng trong những năm qua. Nó có thể có ý nghĩa để tái cấu trúc khi cần kiểu cũ hơn sang kiểu mới hơn để tận dụng các tính năng đó.

• Một số thư viện có thể có một cách tiếp cận đặc biệt hoặc phong cách. Nếu vậy, tôi sẽ gắn bó với phong cách đó cho thư viện đó ngay cả khi nó có thể xung đột với phần còn lại của dự án. Mục đích ở đây là để tăng tỷ lệ cược rằng ai đó làm việc frobnosticatorstrên các dự án khác cũng sẽ làm việc trong dự án của bạn.

Một số ý kiến ​​đề cập đến phong cách bắt buộc và hướng đối tượng là một điều cần xem xét.

Các mô-đun "nặng" theo một kiểu cụ thể có lẽ phải giữ nguyên như vậy nếu mô-đun có kích thước trung bình hoặc lớn hơn. Tôi đã làm việc với ba phong cách chính (bắt buộc, khách quan và chức năng), và tôi đã tái cấu trúc các phong cách mệnh lệnh nặng nề thành một phong cách OO. Với số lượng mã trung bình hoặc lớn hơn, việc tái cấu trúc có thể (đặc biệt) khó khăn. Kinh nghiệm của tôi đã bị xáo trộn vì tôi không có bất kỳ công cụ hỗ trợ nào để hỗ trợ tái cấu trúc.

Tôi sẽ tưởng tượng có một mối tương quan cao giữa các mô-đun có kiểu dáng rất cấp thiết và các mô-đun đó là thành ngữ cho các hốc phát triển cụ thể, quay trở lại điểm cuối cùng tôi nêu ra với các ngoại lệ. Vì vậy, bất kỳ mô-đun nào bạn sẽ tìm thấy cho chức năng đó sẽ trông giống như vậy và bạn muốn các chuyên gia của miền đó cũng có thể dễ dàng làm việc với dự án của bạn. Nhưng nếu có các tùy chọn và nhóm của bạn không thích kiểu của mô-đun đó, thì tôi sẽ điều tra các tùy chọn.

Tương tự như vậy, tôi đã làm việc với một mô-đun kiểu OO nặng, trong đó các nguyên tắc OO đã được đưa quá xa và sử dụng không chính xác. Ví dụ, các giao diện đã được sử dụng để thay thế cho nhiều kế thừa. Và như bạn có thể mong đợi, đó là một triển khai thô thiển. Tôi đã có thể đạt được tiến bộ hợp lý trong việc tái cấu trúc mô-đun đó, nhưng cuối cùng tôi đã từ bỏ cách tiếp cận đó khi tôi tìm thấy các gói tốt hơn để sử dụng thay thế.

Âm thanh như có nhiều lớp để xem xét, ít nhất là:

1. Các thư viện hiện có và bất kỳ sửa đổi cho họ.
2. Mã kiểm tra đơn vị mới cho các thư viện.
3. Lớp trừu tượng.
4. API được trình bày bởi lớp trừu tượng.
5. Ví dụ và mã kiểm tra bằng cách sử dụng lớp trừu tượng.

Tôi sẽ giả định rằng sẽ không có ý nghĩa gì khi chỉ cấu trúc lại tất cả mã thành một kiểu chung trước - nếu bạn không đặt câu hỏi.

Lần lượt tham gia:

1. Đối với cơ sở mã hiện có, sau đó bạn có thể muốn theo phong cách đó.
2. Mã kiểm tra đơn vị mới cho mã hiện tại nằm trong một vùng màu xám, đặc biệt tùy thuộc vào mức độ được tích hợp với mã cũ. Nhưng rất có thể, tôi sẽ cố gắng làm cho nó theo 'phong cách ưa thích'.
3. Mã mới trong lớp trừu tượng. Bằng cách đảm bảo rằng đây thực sự là một lớp mã riêng biệt, không có khó khăn gì trong việc sử dụng một kiểu ưa thích ngay cả khi mã đang thực hiện nhiều giao thoa với kiểu hoặc kiểu kế thừa. Hầu hết các mã cần phải giao tiếp với các kiểu khác và tôi chưa bao giờ thấy đây là một vấn đề.
4. Rõ ràng bản thân API cần nhiều suy nghĩ nhất và đáp ứng nhu cầu sử dụng tối đa.
5. Bất kỳ ví dụ hoặc mã kiểm tra nào cũng có thể được viết theo kiểu ưa thích. Tùy thuộc vào tính đầy đủ của sự trừu tượng (tức là liệu hoàn toàn che giấu các lớp thấp hơn), điều này có thể dễ hoặc khó. Tất nhiên, đảm bảo rằng mã khách hàng trong tương lai có thể đọc được sẽ là một trong những mục tiêu chính của bạn.

Một số điều tôi đã tìm thấy cá nhân là với một cơ sở mã di sản lớn:

• Đặt kiểu ưa thích và thực thi thay đổi mã, điều đó không dẫn đến kết quả là tất cả mã cũ sẽ chuyển sang kiểu mới.

• Hầu hết các kỹ sư có xu hướng thích mã hóa (nhiều hơn hoặc ít hơn) kiểu hiện có trong một thư viện nhất định. Yêu cầu kết quả khác trong rất nhiều thực thi.

• Yêu cầu một phong cách ưa thích trong một thư viện cũ có xu hướng dẫn đến rất nhiều sự không nhất quán trong phong cách trong thư viện đó. Vì vậy, đối với các tiêu chuẩn hoàn toàn xoay quanh việc trình bày, trái ngược với sự mạnh mẽ của mã, thật khó để thấy được nhiều lợi ích trong việc yêu cầu chúng.

Là một vấn đề cuối cùng (hơi lạc đề nhưng tôi nghĩ có liên quan), sự thật là một số kỹ sư đấu tranh để tuân theo bất kỳ tiêu chuẩn phong cách nào khác ngoài những gì họ biết rõ nhất. Tôi thực sự khuyên bạn nên tham gia vào nhóm trong các quyết định về phong cách và đảm bảo có mua. Đã thực hiện để bạn ở vị trí tốt hơn nhiều để thực sự áp dụng một tiêu chuẩn trong mã hỗn hợp.

Tôi sẽ đồng ý với @MetaFight ở đây trong trường hợp bạn đang phát triển một dự án quy mô lớn với nhiều mô-đun của bên thứ ba.

Hãy lập bản đồ vấn đề của bạn bằng một vấn đề thực sự: " Giả sử bạn có lối sống yên tĩnh trong nhà. Bạn thích nơi yên tĩnh, bạn không bao giờ nói to hơn và không bao giờ thích bất kỳ thành viên nào trong gia đình làm như vậy. Nhưng bạn tương tác với rất nhiều Những người khác nhau bên ngoài hàng ngày để mang lại một cái gì đó cho ngôi nhà của bạn. Không nhất thiết họ cũng sẽ nói với giọng nói thấp hơn, trong trường hợp đó bạn tự uốn nắn mình trong khi giao tiếp với những người như vậy. Do đó, giao diện hoặc trình bao bọc cho những người này rất linh hoạt chỉ vì lợi ích của công việc của bạn phải hoàn thành. "Ví dụ ngu ngốc ... lol

Nhưng quan điểm của tôi là tạo trình bao bọc cho các thư viện như vậy theo tiêu chuẩn mã hóa của chúng theo cách bạn sử dụng các thư viện này thông qua các trình bao bọc này duy trì phong cách mã hóa ban đầu của bạn bên trong.

+1 cho MetaFight.

Nó rõ ràng sẽ gây ra sự nhầm lẫn ít nhất để sử dụng một kiểu mã hóa duy nhất trong suốt dự án của bạn. Điểm chính của việc sử dụng một phong cách mã hóa ở nơi đầu tiên là làm cho mã dễ đọc và sửa đổi hơn.

Đối với kiểu mã được sử dụng nội bộ trong thư viện, tôi không nghĩ nó có liên quan. Nếu thư viện quá bắt buộc, thì việc viết một trình bao bọc OO xung quanh là tốt, nhưng điều đó không yêu cầu bạn sử dụng cùng một kiểu mã như trong các ví dụ hoặc nội bộ của thư viện.