Le code interne doit-il être partagé avec des non-développeurs dans une organisation?

Là où je travaille, nous avons beaucoup de développeurs et énormément de code exécutant nos applications propriétaires utilisées par le personnel et les clients.

Nous avons également beaucoup de personnel de support intelligent qui aime comprendre le fonctionnement interne de nos systèmes pour mieux soutenir nos clients, et peut-être même soumettre un patch de temps en temps.

Devrions-nous ouvrir notre code pour que notre personnel non développeur puisse lire? Quels facteurs devons-nous prendre en compte pour prendre cette décision? J'ai rencontré un tas d'arguments et de contre-arguments dans chaque sens et je voudrais prendre une décision basée sur l'expérience des autres ainsi que sur des risques bien compris.

Quelques arguments jusqu'à présent:

• Les mots de passe dans VCS sont exposés (solution: se débarrasser des mots de passe - ils ne devraient pas être là pour commencer)
• Le code est ouvert aux attaques de sécurité en boîte blanche (contre-argument: cela ne retient que les attaquants honnêtes / paresseux)
• Le personnel de support peut demander aux développeurs "comment" les choses fonctionnent (contre: apprendre à un homme à pêcher, etc.)

Quelqu'un ouvre-t-il son code au personnel de son organisation? Cela a-t-il causé des problèmes?

Je ne pense pas qu'il y ait de réponse générale à cela. Les organisations diffèrent énormément par leur taille, leur répartition géographique, leur culture d'entreprise, leurs politiques en matière de droit d'auteur, le type de logiciel en cours de développement, etc. etc. etc.

Par exemple, pour une entreprise développant des logiciels de type commodité / infrastructure, il peut être facile d'ouvrir le code source, voire de l'ouvrir, comme Cisco l'a fait il y a quelques années avec son logiciel de pilote d'imprimante (IIRC).

Pour une entreprise développant des logiciels propriétaires rares, incluant potentiellement des algorithmes spéciaux ou des trucs qui leur donnent un avantage concurrentiel sur leurs concurrents, je peux très bien comprendre s'ils s'efforcent de garder leur code secret. Par exemple, AFAIK Google limite très strictement le nombre de personnes autorisées à accéder à l'implémentation de leur algorithme de recherche principal.

De plus, une organisation multinationale est aujourd'hui répartie sur de nombreux pays, fuseaux horaires et cultures, et pour des raisons de sécurité, elle segmente probablement son intranet et utilise des pare-feu pour contrôler le trafic entre différents segments / domaines. Donc, rendre un référentiel SCM accessible à «toute l'entreprise» peut en fait nécessiter beaucoup de travail supplémentaire pour les administrateurs système et un risque de sécurité supplémentaire. Bien que cela n'apporte généralement aucun avantage en général, comme les employeurs travaillant sur un autre continent sur des choses totalement différentes ne connaissent probablement même pas notre projet ici, encore moins pour y contribuer positivement.

Donc, si cela a du sens au sein de votre département et / ou pour les personnes associées au projet d'une manière ou d'une autre, pourquoi pas. Mais en général, juste pour "l'ouverture", je ne suis pas sûr que cela en vaille la peine.

Une dernière remarque: même lorsque les personnes de support sont intelligentes et désireuses de contribuer des correctifs, je dirais que leurs contributions doivent toujours être examinées par un développeur avant de s'intégrer dans le système.

Dans la plupart des organisations dans lesquelles j'ai travaillé, le référentiel de code était ouvert à tous les développeurs.

Dans certains, il a également été utilisé pour stocker des documents (tels que les spécifications et les exigences) pour les versionner avec le logiciel. Dans ce cas, la plupart des autres employés y avaient également accès. Là où le dépôt n'était utilisé que pour le code, les non-développeurs n'avaient généralement pas accès - mais je n'ai jamais entendu personne se plaindre, donc ce n'était probablement pas un gros problème de toute façon.

Je recommanderais autant d'ouverture que possible - donc si les gens veulent avoir accès, donnez-leur-leur sauf s'il y a un problème évident. Mais c'est vraiment une question de culture de l'organisation ...

Je partage une vision générale / pragmatique à ce sujet et peut également dépendre de la nature du travail / de l'organisation. Mais je crois que la base de code devrait être ouverte à tous (montrera également l'ouverture et la confiance au sein de l'organisation également).

Je travaille également dans une configuration similaire à celle que vous avez mentionnée, où nous avons une équipe de support / helpdesk qui traite les demandes des clients. Cependant, certaines zones complexes du système nécessitent une aide supplémentaire. Dans mon cas, la base de code est ouverte à tous, nous n'avons rencontré aucun problème.

• Je pense qu'en ouvrant la base de code, d'autres membres de l'équipe de support qui sont désireux peuvent également consulter la base de code et se familiariser avec les règles / domaines commerciaux qui les intéressent ou doivent trouver des réponses (et éventuellement améliorer leur compréhension technique et regarder quelque chose différent de la routine monotone si le temps le permet;)). Cela pourrait également s'avérer utile lorsque les membres de l'équipe de support obtiennent des problèmes et des journaux de clients et pourraient pointer / aider sur les zones possibles du code où cela se produit en regardant la pile de traces, par exemple (cela dépendra évidemment du problème, etc.). Cela permettra également de gagner du temps avec le développeur mais en fonction du problème bien sûr.

Il sera également utile d'avoir une documentation / wiki à jour du produit qui contient toutes les règles / décisions commerciales. Mais bien sûr, vous devez vous assurer que le wiki est constamment mis à jour pour remettre à niveau les nouvelles améliorations et / ou corrections de bugs (où le comportement change). Mes pensées honnêtes

En général, du point de vue de l'organisation - les gens vont et viennent; le projet (ou le produit) doit continuer d'évoluer. Par conséquent, dans la plupart des organisations, il existe généralement un ouvert à tous les référentiels pour maintenir le code.

Habituellement, il existe des droits d'accès, etc. pour empêcher tout accès non autorisé inaperçu (pour empêcher le vol de code, etc.), mais la plupart des niveaux supérieurs ne sont pas vraiment interdits. Au sein d'une organisation, il faut faire suffisamment confiance aux gens pour pouvoir leur faire confiance avec du code. Cacher du code aux employés (ou à un collègue) est un excellent facteur de démotivation.

Dans notre organisation, même lorsque les gens ne contribuent pas vraiment au code - ils ont un accès direct au code qui les aide car ils tentent de combattre / résoudre les problèmes sur le terrain (avec propriété) plutôt que de renvoyer les choses au développeur et de s'endormir!