Mã nội bộ có nên được chia sẻ với những người không phải là nhà phát triển trong một tổ chức?


14

Nơi tôi làm việc, chúng tôi có rất nhiều nhà phát triển và rất nhiều mã chạy các ứng dụng độc quyền của chúng tôi được sử dụng bởi cả nhân viên và khách hàng.

Chúng tôi cũng có rất nhiều nhân viên hỗ trợ thông minh muốn tìm hiểu hoạt động bên trong của hệ thống của chúng tôi để hỗ trợ khách hàng tốt hơn và thậm chí có thể thỉnh thoảng gửi một bản vá.

Chúng ta có nên mở mã cho nhân viên không phát triển của mình để có thể đọc không? Những yếu tố nào chúng ta nên tính đến khi đưa ra quyết định này? Tôi đã bắt gặp một loạt các lập luận và phản biện mỗi cách & muốn đưa ra quyết định dựa trên kinh nghiệm của những người khác cũng như các rủi ro được hiểu rõ.

Một số đối số cho đến nay:

  • Mật khẩu trong VCS bị lộ (giải pháp: loại bỏ mật khẩu - chúng không nên ở đó để bắt đầu)
  • Mã được mở cho các cuộc tấn công bảo mật hộp trắng (đối số: điều này chỉ ngăn chặn những kẻ tấn công trung thực / lười biếng)
  • Nhân viên hỗ trợ có thể hỏi các nhà phát triển "cách" mọi thứ hoạt động (bộ đếm: dạy một người đàn ông câu cá, v.v.)

Có ai mở mã của họ cho nhân viên tại tổ chức của họ không? Nó có gây ra vấn đề gì không?


4
Tại sao bạn muốn giữ nó từ họ?
Marjan Venema

1
Bạn có thể trích dẫn luật để sao lưu điều đó?
Blrfl

3
@ S.Lott: Đó là một "tài sản vốn" và như vậy công ty có quyền kiểm soát những nhân viên nào có thể và không thể truy cập nó. Thông thường công ty sẽ muốn giới hạn số lượng nhân viên có quyền truy cập để giới hạn số người có thể bị mua chuộc hoặc buộc phải đưa tài sản đi hoặc lạm dụng tài sản khi họ bất đồng với công ty. Vì vậy, trong hầu hết các trường hợp, nó không được tiết lộ nội bộ (cho mọi người; nó phải được tiết lộ cho ban quản lý).
Jan Hudec

1
@JanHudec: "phải được tiết lộ cho ban quản lý"; "công ty có quyền kiểm soát những nhân viên nào có thể và không thể truy cập nó." Hoàn hảo. Các nhà phát triển không quyết định những quyết định này. Do đó yêu cầu của tôi để làm rõ. Làm thế nào câu hỏi này có thể đi lên? Tại sao các nhà phát triển đưa ra quyết định này?
S.Lott

1
@ S.Lott: Tôi không thấy câu hỏi ngụ ý rằng các nhà phát triển đang đưa ra quyết định này. Quản lý có từ cuối cùng, nhưng ai đó phải thu thập các lập luận cho họ.
Jan Hudec

Câu trả lời:


8

Tôi không nghĩ rằng có một câu trả lời chung cho vấn đề này. Các tổ chức khác nhau về quy mô, sự lan truyền địa lý, văn hóa công ty, chính sách bản quyền, loại phần mềm đang được phát triển, v.v.

Ví dụ, đối với một công ty đang phát triển loại phần mềm / cơ sở hạ tầng, có thể dễ dàng mở mã nguồn, thậm chí để mở mã nguồn, như Cisco đã làm cách đây vài năm với phần mềm trình điều khiển máy in của họ (IIRC).

Đối với một công ty đang phát triển một số phần mềm độc quyền hiếm có, có khả năng bao gồm các thuật toán đặc biệt hoặc công cụ mang lại lợi thế cạnh tranh cho họ, tôi có thể hiểu rất rõ nếu họ đang cố gắng giữ bí mật mã của họ. Ví dụ: AFAIK Google giới hạn rất nghiêm ngặt số người được cấp quyền truy cập triển khai thuật toán tìm kiếm cốt lõi của họ.

Ngoài ra, một tổ chức đa quốc gia hiện đang lan rộng trên nhiều quốc gia, múi giờ và văn hóa, và vì lý do bảo mật, họ có thể phân đoạn mạng nội bộ của mình và sử dụng tường lửa để kiểm soát lưu lượng giữa các phân khúc / miền khác nhau. Vì vậy, việc tạo ra một repo SCM có thể được cung cấp cho "toàn bộ công ty" trên thực tế có thể đòi hỏi rất nhiều công việc phụ cho sysadins và rủi ro bảo mật thêm. Mặc dù nó thường không mang lại bất kỳ lợi ích nào nói chung, vì các nhà tuyển dụng làm việc ở một lục địa khác trên các công cụ hoàn toàn khác nhau thậm chí có thể không biết về dự án của chúng tôi ở đây, ít đóng góp tích cực cho nó.

Vì vậy, nếu nó có ý nghĩa trong bộ phận của bạn , và / hoặc cho những người liên quan đến dự án theo một cách nào đó, tại sao không. Nhưng nói chung, chỉ vì "sự cởi mở", tôi không chắc chắn nó có giá trị hay không.

Một lưu ý cuối cùng: ngay cả khi những người hỗ trợ thông minh và mong muốn đóng góp các bản vá, tôi sẽ nói rằng những đóng góp của họ phải luôn được nhà phát triển xem xét trước khi tích hợp vào hệ thống.


5

Trong hầu hết các tổ chức tôi đã làm việc, kho lưu trữ mã được mở cho tất cả các nhà phát triển.

Trong một số, nó cũng được sử dụng để lưu trữ các tài liệu (như thông số kỹ thuật và yêu cầu) để phiên bản chúng cùng với phần mềm. Trong trường hợp đó, hầu hết các nhân viên khác cũng có quyền truy cập. Trường hợp repo chỉ được sử dụng cho mã, những người không phải là nhà phát triển thường không có quyền truy cập - nhưng tôi chưa bao giờ nghe ai phàn nàn, vì vậy có lẽ đó cũng không phải là vấn đề lớn.

Tôi muốn giới thiệu càng nhiều sự cởi mở càng tốt - vì vậy nếu mọi người muốn truy cập, hãy cung cấp cho họ trừ khi có vấn đề rõ ràng. Nhưng đó thực sự là một câu hỏi về văn hóa của tổ chức ...


4

Tôi chia sẻ một quan điểm chung / thực dụng về điều này và cũng có thể phụ thuộc vào bản chất của công việc / tổ chức là tốt. Nhưng tôi tin rằng cơ sở mã phải được mở cho tất cả mọi người (cũng sẽ thể hiện sự cởi mở và tin tưởng trong tổ chức).

Tôi cũng làm việc trong một thiết lập tương tự như bạn đã đề cập, nơi chúng tôi có một nhóm hỗ trợ / trợ giúp liên quan đến các yêu cầu của khách hàng. Tuy nhiên, một số khu vực phức tạp nhất định của hệ thống họ yêu cầu trợ giúp bổ sung. Trong trường hợp của tôi, cơ sở mã được mở cho tất cả chúng ta không gặp phải bất kỳ vấn đề nào.

  • Tôi nghĩ bằng cách mở cơ sở mã, các thành viên nhóm hỗ trợ khác, những người quan tâm cũng có thể kiểm tra cơ sở mã và làm quen với các quy tắc / lĩnh vực kinh doanh mà họ quan tâm hoặc cần tìm câu trả lời (và có thể cải thiện hiểu biết kỹ thuật của họ và xem xét một cái gì đó khác với thói quen đơn điệu nếu thời gian cho phép;)). Điều này cũng có thể hữu ích khi các thành viên nhóm hỗ trợ nhận được các vấn đề và nhật ký của khách hàng và có thể chỉ ra / hỗ trợ trên các khu vực có thể có của mã nơi điều này xảy ra bằng cách xem stacktrace, ví dụ (rõ ràng sẽ phụ thuộc vào vấn đề, v.v.). Điều này cũng sẽ tiết kiệm thời gian với nhà phát triển nhưng tùy thuộc vào vấn đề của khóa học.

Ngoài ra, có một tài liệu / wiki cập nhật của sản phẩm có chứa tất cả các quy tắc / quyết định kinh doanh cũng sẽ giúp ích. Nhưng tất nhiên bạn cần đảm bảo rằng wiki được cập nhật liên tục để cung cấp các cải tiến mới và / hoặc sửa lỗi (nơi thay đổi hành vi). Suy nghĩ trung thực của tôi


3

Nói chung, từ quan điểm tổ chức - mọi người đến và đi; dự án (hoặc sản phẩm) cần tiếp tục phát triển. Do đó, trong hầu hết các tổ chức, thường có một Open cho tất cả các kho lưu trữ để duy trì mã.

Thông thường có quyền truy cập, vv để ngăn chặn truy cập trái phép không được chú ý (để ngăn chặn hành vi trộm cắp mã, v.v.) nhưng hầu hết các cấp cao hơn không thực sự bị cấm trong việc này. Trong một tổ chức, người ta phải tin tưởng mọi người (đủ) rằng bạn có thể tin tưởng họ bằng mã. Ẩn mã từ nhân viên (hoặc đồng nghiệp) là một yếu tố giảm động lực tuyệt vời.

Trong tổ chức của chúng tôi, ngay cả khi mọi người không thực sự đóng góp cho mã - họ có quyền truy cập trực tiếp vào mã giúp vì họ cố gắng chiến đấu / khắc phục các sự cố tại hiện trường (có quyền sở hữu) thay vì bỏ lại mọi thứ cho nhà phát triển và đi ngủ!


3
"trong hầu hết các tổ chức, thường có một Open cho tất cả các kho lưu trữ để duy trì mã." - Tôi có nghi ngờ của tôi về nó. Bạn có thể trích dẫn bất kỳ dữ liệu để ủng hộ yêu cầu này? Ngoài ra, làm thế nào để không thể truy cập vào repo của dự án Foo để giải phóng tôi?
Péter Török

@ PéterTörök - Tôi nghi ngờ rằng ý nghĩa của Dipan là hầu hết các tổ chức mà anh ấy / cô ấy có kinh nghiệm, mã được mở cho tất cả mọi người. Điều đó sẽ đồng tình với kinh nghiệm của chính tôi trong hơn 20 năm trong các quy mô tổ chức khác nhau. Ngay cả khi làm việc trong ngành công nghiệp quốc phòng, có rất ít mã chỉ có trên mạng an toàn.
Đánh dấu gian hàng

@Mark, theo nghĩa đó tôi đồng ý. Trong hầu hết các nơi làm việc của tôi cho đến nay, tôi chưa thấy nhiều nỗ lực để đưa ra chính sách truy cập cho các repos SCM, vì vậy, thường thì chúng có thể truy cập được trên thực tế cho bất kỳ ai tình cờ đến. Nhưng đây là kết quả của sự bỏ bê, không phải là quyết định có ý thức của bất kỳ ai.
Péter Török
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.