Làm thế nào để truyền bá nhận thức cho lập trình chung giữa các thành viên trong nhóm?

Tôi đang ở trong một môi trường, nơi mọi người tin rằng:

1. Java generic là tính năng được sử dụng riêng cho việc viết thư viện và không phải cho mã hóa thực sự.
2. C ++ là ngôn ngữ lập trình OO; templatelà một tính năng tùy chọn và có thể tránh được

Mặc dù vậy, những người này phụ thuộc rất nhiều vào các thư viện được viết bằng lập trình chung (ví dụ: STL, các thùng chứa Java). Nếu tôi viết mã bằng templates hoặc generics, người đánh giá mã rất có thể sẽ từ chối nó và sẽ bình luận để viết mã theo cách "phù hợp / dễ hiểu / thanh lịch" .

Tâm lý như vậy được áp dụng từ lập trình viên bình thường đến quản lý cao cấp nhất. Không có lối thoát, vì 90% thời gian, những người này có hành lang của họ.

Cách tốt nhất ( không bị cắt cổ họng ) để giải thích chúng, cách tiếp cận thực tế của việc viết mã tạo thành OO và lập trình chung cả hai cùng một lúc là gì?

Vẫn có những người trên thế giới không sử dụng thuốc generic trong "mã hóa thông thường". Tôi có thể tin nó với các mẫu C ++, nhưng thuốc generic? Chúng thậm chí không khó học / sử dụng. Nghiêm túc, các tính năng tốt nhất của Java và C ++ tương ứng là các mẫu và mẫu.

Cách tốt nhất để thuyết phục mọi người về mọi thứ là đưa ra một lập luận thuyết phục, không đe dọa và đúng đắn.

Vì vậy, miễn là bạn không làm điều gì đó như sử dụng các mẫu làm ngôn ngữ lập trình của mình, thì đa hình tham số (khái quát / mẫu) gần như chắc chắn là tốt.

1. Tránh sao chép mã.

Điều này là hiển nhiên, nhưng mã đa hình là mã chung. Đó là lý do tại sao nó được gọi là thuốc generic.

2. Hỗ trợ kiểm tra tĩnh tốt hơn.

Nếu không có đa hình tham số, cuối cùng bạn sẽ viết những thứ như public Object clone()hoặc public boolean equals(object b)không chỉ là gớm ghiếc, chúng có những loại không cung cấp thông tin về những gì chúng làm, và cuối cùng luôn ném ngoại lệ ra khắp nơi. Sự thay thế cho đa hình tham số là diễn viên ở khắp mọi nơi

3. Mã OOP không đa hình tham số về cơ bản không thể xử lý "phương thức nhị phân" một cách chính xác.

Bạn sử dụng thường xuyên.

4. Đó là thực hành tốt nhất

Trong Java, việc sử dụng thuốc generic được coi là cách thực hành tốt nhất (xem Java hiệu quả của Josh Bloch). Các nhà tư tưởng chính của C ++ như Sutter và Alexandrescu cũng khuyến khích sử dụng các mẫu để giải quyết nhiều vấn đề khác nhau.

5. Nó phù hợp với mô hình OO.

Mọi người thường không nhận thấy điều này, nhưng sự kết hợp giữa gõ phụ và khái quát tạo ra một hệ thống RẤT NHIỀU biểu cảm và hướng đối tượng hơn bất kỳ hệ thống nào chỉ có một trong số chúng.

Hãy xem xét các mixin của Scala. Đây là một tính năng hay cho phép bạn kéo các đối tượng của mình lại với nhau từ các bộ phận cấu thành. Generics và mẫu có thể mô phỏng một số lợi ích này. Ví dụ, giả sử một trong các đối tượng của bạn sử dụng cơ sở dữ liệu. Thiết kế tốt sẽ giúp bạn trừu tượng hóa việc truy cập cơ sở dữ liệu vào một lớp riêng biệt. Nếu được thực hiện đúng, điều này không chỉ cho phép bạn mô phỏng kho lưu trữ dữ liệu của bạn (chìa khóa để kiểm tra) mà còn có nghĩa là bạn có thể thêm các triển khai thay thế như cơ sở dữ liệu không có sql mới đó. Tuy nhiên, ở đây, bạn có thể gặp sự cố, cho dù bạn sử dụng triển khai nào, bạn sẽ nhận được các khả năng khác nhau của đối tượng kinh doanh của mình.

Generics để giải cứu!

   public class Business<S extends Datastore>{
      private S store; ...
   }

Bây giờ bạn có thể bắt đầu phân biệt tĩnh các Businessđối tượng của mình dựa trên khả năng sử dụng các tính năng cụ thể của cơ sở dữ liệu. Bạn vẫn cần một số kiểm tra thời gian chạy và truyền, nhưng bạn có thể bắt đầu xây dựng mã NHIỀU tốt hơn.

và

6. Mã bình thường không tồn tại.

Chỉ có ba điều trong vũ trụ lập trình:

1. thư viện,
2. cấu hình và
3. mã xấu.

Nếu bạn không nghĩ về mã của mình giống như đó là một thư viện, bạn sẽ gặp rắc rối nghiêm trọng khi các yêu cầu cho dự án của bạn thay đổi. Kiến trúc (được cho là) ​​nghệ thuật thiết kế các API tốt.

Tôi thấy thái độ này tuyệt đẹp. Sau khi bạn quen với việc lập trình với các loại tham số, không sử dụng chúng chỉ khiến mọi thứ trở nên khó khăn. Và, Java và C ++ có một loạt các điểm thô mà chúng giúp khắc phục.

Đây là một hình thức chuyên biệt của câu hỏi chung chung hơn "làm thế nào để bạn thuyết phục cấp trên của mình bắt đầu sử dụng một công nghệ / cách thức mới hơn và tốt hơn để tạo ra mọi thứ?"

Thật không may, tôi không nghĩ bạn có thể, và tôi không chắc bạn nên làm thế. Theo định nghĩa, đó là sự lựa chọn của họ, vì họ trả tiền cho bạn để làm mọi thứ theo một cách nhất định mà họ đã chọn, không phải theo bất kỳ cách nào bạn muốn. Điều tốt nhất bạn có thể làm là đề xuất rằng công nghệ này hiện có, rất nhiều người đang sử dụng nó và nó dường như là con đường của tương lai. Bạn thậm chí có thể muốn đề cập đến thực tế mà tất nhiên họ phải biết: đó là cách tốt nhất để mọi người không để bộ kỹ năng của họ bị đình trệ. Nhưng đó là: nếu họ không mua nó, bạn không thể làm gì được.

Họ có thể có những cân nhắc khác mà bạn không có, bởi vì bạn không nghĩ ở cấp độ của họ. Bạn đang suy nghĩ như một kỹ sư, họ có thể đang suy nghĩ nhiều hơn về các điều khoản kinh doanh hoặc thậm chí là các nguồn nhân lực.

• Thuốc generic (hoặc bất cứ thứ gì) sẽ cải thiện giá trị của sản phẩm của họ? Chắc là không.

• Liệu thuốc generic (hoặc bất cứ thứ gì) sẽ gây khó khăn hơn cho những người mà họ đã thuê để thực hiện công việc của họ? Vâng.

• Thuốc generic sẽ cải thiện thời gian tiếp thị? Nếu kỹ sư duy nhất là bạn, có lẽ. Nhưng nếu cả một nhóm kỹ sư cần được giáo dục về thuốc generic trước khi một dòng mã khác được viết trong nhà, Không.

Vì vậy, bạn có thể muốn xem xét chỉ thay đổi công việc. Trong công việc cuối cùng của tôi, tôi là người đầu tiên sử dụng thuốc generic với Java và may mắn là họ không gặp vấn đề gì với nó; họ bày tỏ mối quan tâm rằng thuốc generic làm cho mã 'khó đọc hơn', nhưng họ để tôi có cách của tôi. Tìm một công việc như thế.

Tôi sẽ phát đi giá trị của thuốc generic cho người đánh giá mã và các đồng nghiệp khác trước bất kỳ đánh giá nào:

1) Bằng cách cho phép bạn chỉ định các loại được tác động bởi một lớp hoặc phương thức chung, tính năng tổng quát sẽ chuyển gánh nặng về an toàn loại từ bạn sang trình biên dịch. Không cần phải viết mã để kiểm tra loại dữ liệu chính xác vì nó được thi hành tại thời điểm biên dịch. Sự cần thiết phải đúc kiểu và khả năng lỗi thời gian chạy được giảm.

2) Generics cung cấp loại an toàn mà không cần nhiều chi phí triển khai.

Vì vậy, [1] và [2] giảm nguy cơ lỗi trong mã. Điều này tiết kiệm thời gian của nhà phát triển và do đó tiền của công ty.

Nếu khả năng đọc là một vấn đề thì sự lúng túng khi sử dụng các loại chung có thể bị tổn hại. Đây là một lý do bạn có thể muốn mở rộng hướng dẫn mã hóa. Điều này có thể được thực hiện trong bối cảnh ngày làm việc và không chỉ để mở rộng thư viện (tuy nhiên, đó là ý tưởng để cấu trúc lại khi bạn đi và đánh dấu các phương thức ứng cử viên có thể cho các thư viện trong mã để dễ dàng nhận ra sau này). Do đó, sẽ không có lý do gì để không sử dụng chúng trong bối cảnh công việc.

Tôi sẽ thêm một vài tuyên bố về cách các lập trình viên khác không gặp vấn đề với khái quát: Generics được sử dụng rộng rãi trong Java và nhiều ngôn ngữ khác như C #. Bất kỳ lập trình viên nghiêm túc nào cũng sẽ thấy cuộc sống khó khăn nếu không có các khối xây dựng an toàn như vậy.

Tuy nhiên, bạn có thể muốn xem xét rằng một số nhà phát triển có thể không bắt đầu. Ban quản lý có thể đã đưa ra một quyết định có ý thức để bảo vệ các dự án trong quá khứ, do đó giữ cho các lỗ hổng này ra khỏi khu vực nguy hiểm. Ở đây, cả người vô tội và người có tội thường nhận lỗi khi phân tích đầy đủ hoặc quản lý vi mô hiếm khi được tiến hành.

Nếu bạn đưa ra một trường hợp tốt về phía trước và bạn không nhận được phản hồi hợp lý để đáp lại thì bí mật bắt đầu tìm kiếm một công ty khác nghiêm túc lập trình.

Trừ khi bạn là kiến ​​trúc sư / lãnh đạo công nghệ, sẽ khó có thể bắt buộc rằng bạn nên sử dụng thuốc generic / mẫu. Bạn thực sự nên đề xuất giải pháp chung / mẫu từ lâu trước khi xem xét mã, tốt nhất là trước khi bạn bắt đầu triển khai nó.

Những gì bạn có thể làm, là để chứng minh tại sao bạn nên sử dụng chung chung trong một số trường hợp. Nếu bạn có thể chứng minh lợi ích, thì đồng nghiệp của bạn có thể đồng ý. Những lý do có thể khiến bạn nên sử dụng thuốc generic / mẫu nên như sau:

• Nó sẽ cho phép bạn viết ít mã hơn cho các nhiệm vụ lặp đi lặp lại
• Nó làm cho các lập trình viên làm việc dễ dàng hơn
• Nó thi hành một mẫu được thiết kế bởi kiến ​​trúc sư giải pháp
• Nó gói gọn các tính năng phổ biến, điều đó sẽ buộc các lập trình viên không sao chép-dán mã (tức là tránh vấn đề bảo trì kép)
• Nó hợp lý trong tương lai chứng minh mã của bạn (mặc dù con đường này rất khó để lý do)

Trong một dự án Java gần đây, tôi đã thêm thành công một số lớp trừu tượng chung vì nó thỏa mãn một số điều cơ bản: nó làm cho mọi thứ trong nhóm dễ dàng hơn, thực thi mẫu mà kiến ​​trúc sư đã đề xuất và có một số mã chung mà các lập trình viên không cần sao chép và dán. Đó là một mô hình đơn giản mà kiến ​​trúc sư đã viết về những người có năng lực hợp lý vẫn mắc sai lầm (vì sự phức tạp của hệ thống thực tế trong trò chơi), nhưng các khái quát đánh dấu lớp nào đi đâu.

Rõ ràng tôi không thể thể hiện ví dụ thực tế mà không vi phạm thỏa thuận không tiết lộ. Nhưng như một ví dụ về những gì tôi đã làm sẽ là thực hiện mô hình chiến lược và thực thi nó bằng thuốc generic. Vì vậy, đây là mô hình chiến lược:

Và để các lập trình viên thực thi mẫu này, bạn có thể thêm loại chung vào Contextđó nên sử dụng Strategyloại có loại. Thông thái mã, nó sẽ trông giống như thế này trong Java:

// declare the generic Context class that has a type "S" 
// that is an upper bound class of Strategy
public class Context <S extends Strategy> {
    S strategy;

    // Constructor with an initial strategy
    public Context(S initialStrategy) {
        this.strategy = initialStrategy;
    }

    public void doSomething() {
      strategy.execute(); // assumes that Strategy has an execute() method.
    }

    public void setStrategy(S strategy) {
        this.strategy = strategy;
    }
}

Bạn có thể làm điều này khá nhiều với bất kỳ mô hình nào theo như tôi biết. Hãy chắc chắn rằng bạn có thể kiểm tra thiết kế chung / mẫu của mình bằng các thử nghiệm đơn vị để thấy rằng nó hoạt động, để có sự tự tin trong thiết kế mã.

Nếu các đồng nghiệp của bạn không thích ý tưởng đó thì đừng tự mình thực hiện nó, nó có thể không phải là một giải pháp dễ dàng để họ xử lý như bạn nghĩ. Đó là lý do tại sao bạn nên đề xuất một giải pháp chung / mẫu trước khi bạn bắt đầu thực hiện nó. Bạn vẫn phải làm việc cùng với các đồng nghiệp của mình để giải quyết vấn đề thực tế theo một cách khác.

Luôn luôn có một số cách để làm điều tương tự. Nếu việc sử dụng các mẫu của bạn là sử dụng sai các mẫu thì nó sẽ thất bại trong việc xem lại mã.

Tuy nhiên, nếu mã của bạn không xem xét, vì họ không hiểu các mẫu, thì vấn đề thuộc loại khác. Trong trường hợp đó, khuyên họ (một cách tốt đẹp) để tìm hiểu các mẫu.

Những gì bạn đang giải quyết ở đây là một tập hợp các thành kiến. Mọi người thích hiện trạng, một nhóm đã phát triển và cuộc tranh luận đã được tiến hành một vài lần để mọi người trở nên cố thủ trong niềm tin của họ.

Một trong những chiến lược hiệu quả nhất ở đây là tập trung vào một chiến thắng nhỏ. Tôi đọc ví dụ sau trong một cuốn sách : tác giả là một người dùng không trung thành của Apple. Cô không thích họ, và cô không muốn làm gì với họ. Cô đã có nhiều cuộc thảo luận với những người có lập trường ủng hộ Apple, và mỗi người chỉ đẩy gót chân sâu hơn xuống đất. Sau đó, một người nào đó đã mua cho cô một chiếc iPod shuffle và như thế, những thành kiến ​​của cô biến mất. Nó không khiến cô chỉ muốn mua các sản phẩm của Apple, nhưng lập trường chống Apple cứng rắn, cố thủ đã được thay thế bằng một quan điểm cân bằng hơn. Có chỗ cho sự thỏa hiệp và cuối cùng cô ấy đã dần dần chuyển đổi hoàn toàn sang Apple.

Vì vậy, đừng cố gắng thuyết phục tất cả mọi người cùng một lúc: nó sẽ có tác dụng ngược lại. Tập trung vào một điều nhỏ, và phần còn lại sẽ tự xảy ra. Chỉ cần loại bỏ tính chất hai mặt của tranh luận để mọi người có thể vượt qua từng chút một, thay vì tất cả cùng một lúc.

Điểm cụ thể để tập trung vào tùy thuộc vào tình huống của bạn, nhưng đây là một ý tưởng: Sự phân chia bạn phác thảo giữa các thư viện và 'mã thực' có vẻ rất không tự nhiên. Theo quan điểm của tôi, một lập trình viên làm một ứng dụng nên dành 80% thời gian của mình cho một thư viện cho loại ứng dụng mà anh ta tạo ra và 20% sử dụng thư viện đó để xây dựng ứng dụng. Tất cả các mã đáng giữ nên được coi là một thư viện. Tôi sẽ đề nghị với cấp trên của bạn rằng bạn khái quát một số mã của mình vào một thư viện nội bộ (nếu bạn chưa có). Theo logic riêng của họ, họ nên sử dụng thuốc generic cho việc này và theo ước tính ở trên, 80% mã của bạn có thể nằm trong thư viện. Khi bạn nhận được tất cả mọi người bằng cách sử dụng thuốc generic từ phía bên kia, họ sẽ quen với nó và các thành kiến ​​sẽ mờ dần.

Lưu ý "dễ hiểu". Nếu người xem xét mã không thấy được lợi ích của thuốc generic, thì tất cả các công cụ <<<>>>chỉ là tiếng ồn không thể hiểu được là không cần thiết.

Tôi sẽ đề nghị xem xét có bao nhiêu lỗi thực sự, hiện tại (đã mở hoặc đã sửa gần đây) mà cơ sở dữ liệu lỗi của bạn có thể tránh được bằng cách sử dụng thuốc generic. Tìm ClassCastExceptions.

Cũng lưu ý rằng nếu bạn không có bất kỳ lỗi nào có thể tránh được bằng cách sử dụng thuốc generic thì đồng nghiệp của bạn có một điểm là bạn không cần đến chúng.

Tôi sẽ dễ dàng trong việc này. Tôi đã chuyển từ Java 1.4 sang 1.6 một vài năm trước và thuốc generic đã là một cú hích thực sự. Thật đơn giản và rất hữu ích nếu bạn đang cố gắng tung hứng một vài Bộ sưu tập, Bản đồ và các cấu trúc khác. Tuy nhiên, việc viết các lớp lấy dữ liệu chung làm tham số, thao tác chúng và chuyển chúng sang các lớp khác nhanh chóng trở nên khó hiểu. Tôi nhận được sự hài lòng lớn từ việc làm cho tất cả hoạt động, nhưng tự hỏi liệu thời gian và công sức bỏ ra có xứng đáng không. Tôi cũng sợ một số lượng lớn các lập trình viên Java có thể không bao giờ thực sự hiểu được nó.

Một vài suy nghĩ ngẫu nhiên từ hành trình chung của tôi cho đến nay:

• ClassCastExceptions xảy ra vào thời gian chạy, nhưng chúng thường xuất hiện trong một vài lần chạy đầu tiên và rất dễ sửa.
• Mỗi bài viết tôi đã đọc trên generic đều nói rằng đôi khi chúng không hoạt động và bạn cần sử dụng @SuppressWarnings(value="unchecked") thỉnh thoảng . Làm thế nào để bạn biết nếu bạn vượt quá giới hạn của thuốc generic, hoặc nếu bạn chỉ ngu ngốc và cần phải suy nghĩ nhiều hơn?
• Nó có thể khó áp dụng @SuppressWarnings(value="unchecked") cho chỉ một dòng.
• Tôi đã thêm một số khái quát ưa thích vào một trong các lớp học của tôi. Tôi đã biết một số lập trình viên, những người có thể đã nâng cao lớp trước khi tôi quảng cáo nó, người không bao giờ có thể chạm vào nó và đã nhận được một biên dịch sạch sau đó.

Generics đã dọn sạch mã của tôi và cảnh báo tôi về sự cố quá nhiều lần để tôi từ chối nó, nhưng tôi cũng thấy thời gian phát triển tăng lên, dành thêm thời gian cho đào tạo và các lập trình viên Java buộc phải làm việc trong C #, C và Visual Basic. .. hoặc Java 1.4. Tôi tập trung vào viết mã đồng nghiệp của bạn có thể hiểu. Nếu bạn có thể trượt trong một số khái quát dễ hiểu, tuyệt vời. Tôi thấy Java generic là một cơ hội / vấn đề chưa được tìm ra.