Các nhà phát triển có nên dự kiến ​​biên dịch một thư viện nội bộ trước chương trình thực tế không?

Gần đây, một nhà phát triển cấp cao mà tôi làm việc đã đưa ra một trường hợp yêu cầu các nhà phát triển có được phiên bản mới nhất và biên dịch như một phần của dự án của họ một thư viện nội bộ lớn. Điều này trái ngược với lập luận phản đối rằng các nhóm dự án nên tạo ra một phiên bản ổn định mà họ nhận được từ kho lưu trữ Maven nội bộ mà nhà phát triển lập luận rằng việc có sẵn mã nguồn trên các máy của nhà phát triển giúp họ có thể đọc được nguồn thư viện mã để xác định nếu chức năng cần thiết có sẵn.

Liệu các nhà phát triển cao cấp có một đối số hợp lệ? Hoặc là yêu cầu các nhà phát triển đọc mã nguồn của thư viện chạy ngược lại triết lý đóng gói cơ bản và thậm chí có thư viện ngay từ đầu?

Lập luận của nhà phát triển cấp cao này không có ý nghĩa với tôi.

Họ muốn thêm chi phí liên tục truy xuất & biên dịch thư viện nội bộ để các nhà phát triển thỉnh thoảng có thể đọc mã nguồn? Điều đó sẽ lãng phí nhiều thời gian hơn nhiều so với việc các nhà phát triển chỉ nhìn vào mã nguồn khi họ cần kiểm tra xem một tính năng có khả dụng hay không.

Đây là một ý tưởng đặc biệt tồi tệ nếu thư viện và khách hàng đang được phát triển bởi các nhóm phát triển khác nhau và thư viện đang được tích cực phát triển. Các nhà phát triển khách hàng sẽ không có bất kỳ sự cách nhiệt nào từ sự bất ổn trong thư viện.

Tôi không thấy lý do tại sao mã nguồn không thể được cung cấp cho các nhà phát triển mà không buộc họ phải là một phần của bản dựng thông thường.

Gợi ý là

Chúng tôi có thể tiết kiệm thời gian bởi các nhà phát triển phía khách hàng đọc mã nguồn của thư viện để xác định xem có sẵn chức năng cần thiết không

Bạn có thể đưa ra một đề nghị thay thế

Chúng ta có thể tiết kiệm thời gian bằng cách ai đó ghi lại thư viện để cho biết chức năng nào khả dụng.

Tôi sẽ không mua lập luận rằng có khả năng kiểm tra nguồn cục bộ là một lợi ích, nhưng nếu thư viện đang phát triển tích cực (có thể để hỗ trợ cho nhu cầu dự án của bạn) thì tôi không nghĩ rằng việc yêu cầu các nhà phát triển phải vô lý tải về cập nhật thường xuyên (có thể vài lần một ngày). Tôi nghĩ rằng nó có ý nghĩa kinh doanh tốt hơn để làm cho một nhị phân được biên dịch (và thử nghiệm đơn vị) có sẵn thay vì yêu cầu các nhà phát triển biên dịch từ nguồn, mặc dù.

Bạn có khả năng trong dự án của mình để thiết lập một số loại kho lưu trữ được chia sẻ trong đó phiên bản được biên dịch mới nhất sẽ có sẵn không? Lý tưởng nhất là bạn muốn một máy chủ CI thực hiện tìm nạp theo lịch, nhưng ngay cả khi đó chỉ là tài nguyên mạng mà một trong những người lãnh đạo nhóm chịu trách nhiệm cập nhật định kỳ, nó có thể giúp ích. Tất nhiên, cái này nên có trên đĩa của nhóm thư viện, nhưng rõ ràng là họ không quan tâm, vì vậy bạn sẽ phải chọn lấy đồ của họ.

Tôi đã từng làm việc cho một công ty phần mềm lớn, người liên tục "làm thức ăn" phần mềm của riêng họ với các hệ thống kinh doanh nội bộ.

Họ thấy đây là một cấp độ thử nghiệm khác.

Điều đó tôi đồng ý, đối với một công ty, là một điều tốt.

Tôi nghĩ việc buộc bạn tải xuống và biên dịch phiên bản mới nhất là một bước quá xa, trừ khi bước biên dịch là một phần quan trọng trong các công ty của bạn cung cấp bán, hoặc thậm chí thuê ngoài, một thư viện.

Mặc dù có sẵn mã nguồn có thể là một lợi ích, nhưng nếu bạn có một tác nhân xây dựng CI giám sát kho lưu trữ, điều đó có ý nghĩa hơn khi để tác nhân đó biên dịch thư viện này và sao chép nó vào các dự án phụ thuộc như bên ngoài, hơn là yêu cầu các nhà phát triển phải chạy hai bước biên dịch khác nhau khi xây dựng bản sao của chúng.

Tôi hiện đang làm việc trên một dự án không liên kết với một đại lý xây dựng, yêu cầu xây dựng một ứng dụng phụ trước khi xây dựng ứng dụng chính. Đó là một nỗi đau nghiêm trọng ở hậu thế của tôi; để thay đổi ứng dụng phụ, trước tiên tôi phải xây dựng toàn bộ dự án, sau đó chuyển đến thư mục xây dựng phụ, lấy sản phẩm đã biên dịch ra khỏi đó và sao chép nó vào một thư mục con khác, trước khi xây dựng toàn bộ dự án LẠI để đảm bảo phiên bản mới nhất của ứng dụng phụ được bao gồm trong bản dựng của ứng dụng chính. Đây KHÔNG phải là cách nó nên được thực hiện; ít nhất nên có một tập lệnh MSBuild sẽ tự động hóa quá trình này và tôi muốn tác nhân xây dựng cập nhật các phần bên ngoài bất cứ khi nào mã mới được cam kết vào trung kế.

Vì rất nhiều người trả lời rằng thật vô nghĩa khi mọi người xây dựng một thư viện nội bộ, tôi sẽ trình bày quan điểm ngược lại có thể biện minh cho lý do:

1. Bạn sử dụng thư viện rất nhiều và không có tài liệu. Vì vậy mọi người nên có nguồn để tham khảo. Nếu đây là một thư viện được sử dụng rất thường xuyên, có sẵn tài liệu tham khảo có thể hữu ích

   • Chắc chắn, người ta sẽ nói rằng họ nên làm việc trên tài liệu và nhiều khả năng nhà phát triển cấp cao của bạn nhận thức được thực tế này. Nhưng hãy đối mặt với thực tế, rất nhiều lần các nhóm phát triển kết thúc với một tấn mã không có giấy tờ, vì vậy khi bạn cần biết nó hoạt động như thế nào, bạn hãy tìm đến nguồn. Bạn không cần phải làm điều đó, nhưng trong ngắn hạn, đây là cách thay thế tốt nhất.
   • Thông thường những người giỏi nhất để đặt tài liệu vào vị trí là những người biết thư viện tốt nhất. Thật không may, đó là những người thường bận rộn nhất, vì vậy thường không dễ để họ bỏ mọi thứ và bắt đầu ghi chép.

2. Khi mọi người bắt đầu viết mã của riêng họ phụ thuộc vào thư viện và một cái gì đó trong thư viện không hoạt động, thay vì giơ tay lên không, nếu thư viện được xây dựng cục bộ, sẽ rất dễ dàng để bước ngay vào mã thư viện

   • Điều này có thể xảy ra vì nhiều thư viện không hoàn hảo và trong khi tất cả chúng ta muốn làm việc với một bản phát hành "ổn định", vẫn có thể có vấn đề.
   • Có thể bạn đang nhận được kết quả xấu vì hiểu sai về cách sử dụng API. Ngay cả với tài liệu, mọi người thường đưa ra các giả định sai
   • Anh chàng cao cấp của bạn có lẽ đã mệt mỏi với những người mới (và đôi khi có nhiều người mới hơn những người biết dự án bên trong và bên ngoài) ném tay lên không trung mỗi khi gặp sự cố / một số lỗi khác dường như đến từ mã thư viện. Vì vậy, thay vì phải ghé qua máy của bạn và sau đó đến anh chàng ngồi cạnh bạn, họ muốn có tùy chọn trả lời với những câu hỏi sau: 1) chính xác thì sự cố ở đâu? mô-đun / tập tin / dòng nào? 2) bạn đã gỡ lỗi chưa? BẠN đã tìm thấy gì?
   • Những người cấp cao của bạn đã làm việc với cơ sở mã này (ứng dụng và thư viện lớn của bạn) đủ lâu và có khả năng anh ta có thể nhận thấy rằng khi mã đã có trên máy và sẵn sàng để gỡ lỗi và bước qua, nó giúp cuộc sống của anh ta dễ dàng hơn và có được mọi người để tìm hiểu cơ sở mã nhanh hơn. Vì vậy, vì lý do đó, anh ta buộc bạn phải trả chi phí trả trước khi xây dựng thư viện trên máy của bạn.

Tôi không nói rằng quyết định của anh ấy là hợp lý, chỉ nêu ra rằng a) câu hỏi được trình bày một mặt của câu chuyện và b) có thể có những động cơ chính đáng.

Thử nghiệm loại này tốt hơn sẽ được thực hiện. Mặc dù vậy, nó nên được thực hiện bởi những người thử nghiệm chứ không phải bởi các nhà phát triển . Theo nghĩa đó, đó không phải là công việc của nhà phát triển thư viện cũng như của bạn.

_{Từ những gì bạn mô tả có vẻ như không có người thử nghiệm trong dự án - nếu đây là trường hợp, đó là một vấn đề quản lý và khá nghiêm trọng.}

... Tiết kiệm thời gian vì họ có thể đọc mã nguồn của thư viện để xác định xem có sẵn chức năng cần thiết không

Lý luận khá khập khiễng. Khi thư viện phiên bản gần đây nhất không biên dịch được với dự án phiên bản gần đây nhất, có thể có nhiều lý do khác nhau cho việc đó - chỉ cần khoan vào mã nguồn lib có thể lãng phí thời gian.

• Điều gì xảy ra nếu thư viện ổn và lỗi xây dựng là do lỗi trong mã dự án? Hoặc, điều gì xảy ra nếu lỗi xây dựng là do thay đổi không tương thích tạm thời được cho là sẽ được sửa chữa một hoặc hai ngày sau đó? Điều gì xảy ra nếu một lỗi xây dựng chỉ ra một vấn đề tích hợp phức tạp sẽ mất một tuần hoặc một tháng để giải quyết? Đối với một vấn đề tích hợp, việc sử dụng một thư viện phiên bản trước có làm cho một cách giải quyết hay không?
   
  Dù lý do có thể là gì, thực hiện phân tích sơ bộ về sự thất bại có nghĩa là lãng phí thời gian của nhà phát triển vào một công việc được cho là do người thử nghiệm thực hiện.

Một điều nữa ở trên lý do bỏ lỡ là không thể tránh khỏi (và khá đau đớn theo kinh nghiệm của tôi) mất năng suất theo sau khi người ta phải phá vỡ dòng chảy bằng cách chuyển đổi giữa các hoạt động phát triển và QA.

Khi có người kiểm tra trong nhóm, những việc như vậy thực sự đơn giản và có thể được xử lý dễ dàng hơn nhiều. Những gì nhà phát triển "cấp cao" của bạn đưa ra cho bạn về cơ bản là một yêu cầu thử nghiệm dự thảo.

Theo mỗi thay đổi được thực hiện cho dự án hoặc thư viện, hãy đảm bảo rằng quá trình xây dựng thành công.

Các bước để tiến hành từ đó là các hoạt động QA điển hình: làm rõ chi tiết yêu cầu, thiết kế một kịch bản thử nghiệm chính thức, đàm phán về cách xử lý các lỗi thử nghiệm.

• Từ quan điểm của SQA , đây là một công việc thường xuyên là thiết kế, thiết lập và duy trì một quy trình kiểm tra hồi quy khá đơn giản có thể được tự động hóa cao - có lẽ đến mức chỉ có hoạt động thủ công mới tạo và duy trì vé trong trình theo dõi vấn đề và xác minh sửa lỗi.

Những gì Sr Dev đang gợi ý có ý nghĩa rất nhỏ đối với tôi. Thật tuyệt khi có thể duyệt các nguồn, nhưng có nhiều cách tốt hơn để làm như vậy.

Bạn đang sử dụng Kho lưu trữ nào? Bạn sẽ có thể triển khai một jar nguồn cho mỗi phiên bản để sống bên cạnh thư viện được biên dịch. Hầu hết các IDE sau đó sẽ cho phép bạn đính kèm thư viện này vào thư viện đã biên dịch để duyệt nguồn. Eclipse với Plugin Maven sẽ tự động làm điều này.

Nếu bạn cần mã mới nhất, bạn chỉ có thể triển khai ảnh chụp nhanh phiên bản.

Điều này chỉ đơn giản sẽ xảy ra trong tập lệnh xây dựng của bạn:

1. kiểm tra xem có phiên bản mới không bỏ qua 2 nếu không
2. tải xuống và biên dịch nó và chạy bất kỳ công cụ nào bạn có để tạo tham chiếu API từ mã nguồn cục bộ. hiển thị một bản ghi thay đổi.
3. xây dựng ứng dụng của bạn

Tôi không thấy lý do tại sao hoặc đây là một vấn đề. Ngoài ra khi thiếu một cái gì đó trong tài liệu tham khảo, bạn có thể thêm nó vào các nguồn và đẩy các thay đổi. Tất nhiên có vẻ hơi đáng sợ khi thư viện có thể thay đổi ngay dưới chân bạn, nhưng nếu những người bảo trì thư viện thực hiện đúng công việc của họ thì đây là một điều tốt.