O código interno deve ser compartilhado com não desenvolvedores em uma organização?

Onde trabalho, temos muitos desenvolvedores e muito código executando nossos aplicativos proprietários usados ​​tanto pela equipe quanto pelos clientes.

Também temos uma equipe de suporte inteligente que gosta de entender o funcionamento interno de nossos sistemas para melhor atender nossos clientes e talvez até enviar um patch de tempos em tempos.

Devemos abrir nosso código para que nossa equipe que não seja de desenvolvimento possa ler? Que fatores devemos levar em consideração ao tomar essa decisão? Eu me deparei com vários argumentos e contra-argumentos em cada sentido e gostaria de tomar uma decisão com base na experiência de outras pessoas e em riscos bem compreendidos.

Alguns argumentos até agora:

• As senhas no VCS são expostas (solução: livre-se das senhas - elas não deveriam estar lá para começar)
• O código está aberto a ataques de segurança de caixa branca (contra-argumento: isso mantém apenas os invasores honestos / preguiçosos)
• A equipe de suporte pode perguntar aos desenvolvedores "como" as coisas funcionam (contador: ensinar um homem a pescar etc.)

Alguém abre seu código para a equipe de sua organização? Causou algum problema?

Eu não acho que haja uma resposta geral para isso. As organizações diferem bastante em tamanho, distribuição geográfica, cultura da empresa, políticas de direitos autorais, tipo de software em desenvolvimento, etc. etc. etc.

Por exemplo, para uma empresa que desenvolve software de tipo commodity / infraestrutura, pode ser fácil abrir o código-fonte, mesmo para código-fonte aberto, como a Cisco fez alguns anos atrás com seu software de driver de impressora (IIRC).

Para uma empresa que desenvolve algum software proprietário raro, incluindo potencialmente algoritmos especiais ou outras coisas que lhes dão vantagem competitiva sobre a concorrência, posso entender muito bem se eles estão tentando manter seu código secreto. Por exemplo, o AFAIK Google limita estritamente o número de pessoas que têm acesso a sua implementação de algoritmo de pesquisa principal.

Atualmente, uma organização multinacional está hoje espalhada por muitos países, fusos horários e culturas e, por razões de segurança, provavelmente segmenta sua intranet e usa firewalls para controlar o tráfego entre diferentes segmentos / domínios. Portanto, tornar um repositório SCM acessível a "toda a empresa" pode, de fato, exigir muito trabalho extra para administradores de sistemas e riscos extras à segurança. Embora geralmente não traga nenhum benefício em geral, como os empregadores que trabalham em um continente diferente em coisas totalmente diferentes provavelmente nem sabem sobre o nosso projeto aqui, muito menos para contribuir positivamente.

Portanto, se faz sentido dentro do seu departamento e / ou para as pessoas associadas ao projeto de alguma forma, por que não? Mas, em geral, apenas por uma questão de "abertura", não tenho certeza de que vale a pena.

Uma observação final: mesmo quando as pessoas de suporte são espertas e desejam contribuir com patches, eu diria que suas contribuições devem sempre ser revisadas por um desenvolvedor antes de serem integradas ao sistema.

Na maioria das organizações em que trabalhei, o repositório de código estava aberto a todos os desenvolvedores.

Em alguns, também foi usado para armazenar documentos (como especificações e requisitos) para a versão deles juntamente com o software. Nesse caso, a maioria dos outros funcionários também teve acesso. Onde o repositório era usado apenas para código, os não-desenvolvedores geralmente não tinham acesso - mas eu nunca ouvi alguém reclamar, então provavelmente não era grande coisa de qualquer maneira.

Eu recomendaria o máximo de abertura possível - portanto, se as pessoas quiserem, dê a elas, a menos que haja um problema óbvio. Mas isso realmente é uma questão de cultura da organização ...

Eu compartilho uma visão geral / pragmática sobre isso e também pode depender da natureza do trabalho / organização. Mas acredito que a base de código deve ser aberta a todos (também mostrará abertura e confiança dentro da organização).

Também trabalho em uma configuração semelhante à mencionada, onde temos uma equipe de suporte / suporte técnico que lida com solicitações de clientes. No entanto, certas áreas complexas do sistema precisam de ajuda adicional. No meu caso, a base de código está aberta a todos que não encontramos nenhum problema.

• Acho que, ao abrir a base de código, outros membros da equipe de suporte interessados ​​também podem verificar a base de código e se familiarizar com as regras / áreas de negócios em que estão interessados ​​ou precisam encontrar respostas (e possivelmente melhorar seu entendimento técnico e procurar algo diferente da rotina monótona, se o tempo permitir;)). Isso também pode ser útil quando os membros da equipe de suporte obtêm problemas e registros do cliente e podem apontar / auxiliar em possíveis áreas do código onde isso acontece, observando o rastreamento de pilha, por exemplo (obviamente, isso depende do problema, etc.). Isso também economizará tempo com o desenvolvedor, mas dependendo do problema, é claro.

Ter também uma documentação / wiki atualizada do produto que contém todas as regras / decisões de negócios também ajudará. Mas é claro que você precisa ter certeza de que o wiki é atualizado constantemente para refletir novos aprimoramentos e / ou correções de bugs (quando o comportamento muda). Meus pensamentos honestos

Em geral, do ponto de vista da organização - as pessoas vêm e vão; o projeto (ou produto) precisa continuar evoluindo. Portanto, na maioria das organizações, geralmente existe um Aberto a todos os repositórios para manutenção do código.

Geralmente, existem direitos de acesso, etc., para impedir o acesso não autorizado despercebido (para impedir o roubo de código etc.), mas a maioria dos altos não é realmente proibida. Dentro de uma organização, é preciso confiar nas pessoas (o suficiente) para que você possa confiar nelas com código. Ocultar o código dos funcionários (ou colegas) é um ótimo fator desmotivador.

Em nossa organização, mesmo quando as pessoas realmente não contribuem para o código - elas têm acesso direto ao código que ajuda, porque tentam combater / corrigir os problemas no campo (com propriedade), em vez de enviar as coisas de volta ao desenvolvedor e dormir!