組織内の開発者以外と内部コードを共有する必要がありますか？

私が働いている場所には、多くの開発者と、スタッフや顧客が使用する独自のアプリケーションを実行する非常に多くのコードがあります。

また、システムの内部動作を理解してお客様をよりよくサポートし、場合によってはパッチを提出することを希望する多くのスマートサポートスタッフもいます。

開発者以外のスタッフが読めるようにコードを開く必要がありますか？この決定を行う際に考慮すべき要因は何ですか？私はそれぞれの方法で多くの議論と反論に出くわし、他者の経験とよく理解されたリスクに基づいて決定をしたいと思います。

これまでのいくつかの議論：

• VCSのパスワードが公開されています（解決策：パスワードを取り除いてください-最初からそこにあるべきではありません）
• コードはホワイトボックスセキュリティ攻撃に対して無防備です（反論：これは正直/怠yな攻撃者のみを排除します）
• サポートスタッフは、開発者に「仕組み」の仕組みを尋ねることができます（カウンター：男性に魚を教えるなど）

組織のスタッフにコードを公開している人はいますか？それは問題を引き起こしましたか？

これに対する一般的な答えはないと思います。組織の規模、地理的広がり、企業文化、著作権ポリシー、開発中のソフトウェアの種類などは大きく異なります。

たとえば、コモディティ/インフラストラクチャタイプのソフトウェアを開発している企業の場合、Ciscoが数年前にプリンタードライバーソフトウェア（IIRC）で行ったように、ソースコードを開くことも、ソースコードを開くことも簡単です。

競合他社よりも競争上の優位性を提供する特別なアルゴリズムやものを含む可能性のある、いくつかの珍しいプロプライエタリなソフトウェアを開発している会社にとって、コードを秘密にしようと努力しているかどうかは非常によく理解できます。たとえば、Googleはコア検索アルゴリズムの実装へのアクセスを許可されるユーザーの数を非常に厳しく制限しています。

また、多国籍企業は現在、多くの国、タイムゾーン、文化に広がっており、セキュリティ上の理由から、おそらくイントラネットをセグメント化し、ファイアウォールを使用して異なるセグメント/ドメイン間のトラフィックを制御しています。そのため、SCMリポジトリを「会社全体」にアクセス可能にするには、実際にはシステム管理者のために多くの追加作業が必要になり、追加のセキュリティリスクが発生する場合があります。通常、一般的には何の利益ももたらされませんが、異なる大陸でまったく異なるものに取り組んでいる雇用主は、おそらくここでのプロジェクトについても知らず、積極的に貢献することはあまりありません。

それがあなたの部門内で、そして/または何らかの形でプロジェクトに関係する人々のためにそれが理にかなっているのであれば、なぜだろうか。しかし、一般に、「オープン性」のためだけに、それが価値があるかどうかはよくわかりません。

最後に、サポート担当者がパッチを提供することに熱心であり、システムに統合される前に、開発者が彼らの貢献を常に確認する必要があると思います。

私が働いたほとんどの組織では、コードリポジトリはすべての開発者に公開されていました。

一部では、ソフトウェア（仕様や要件など）を保存してソフトウェアと一緒にバージョン管理するためにも使用されていました。その場合、他のほとんどの従業員もアクセスできました。リポジトリがコードのみに使用された場合、通常、開発者以外はアクセスできませんでしたが、不満を言う人はいなかったので、おそらく大したことではなかったでしょう。

できるだけオープンであることをお勧めします。したがって、アクセスが必要な場合は、明らかな問題がない限り、アクセスできるようにしてください。しかし、それは本当に組織の文化の問題です...

私はこれについて一般的/実用的な見方を共有しており、仕事/組織の性質にも依存するかもしれません。しかし、コードベースはすべての人に開かれているべきだと考えています（組織内での公開と信頼も示します）。

また、お客様のリクエストを処理するサポート/ヘルプデスクチームがいる場合と同様の設定で作業します。ただし、システムの特定の複雑な領域では、追加のヘルプが必要です。私の場合、コードベースは問題に遭遇していないすべての人に開かれています。

• コードベースを開くことで、熱心な他のサポートチームメンバーもコードベースをチェックアウトし、興味のある、または答えを見つける必要があるビジネスルール/エリアに精通することができます時間が許せば単調なルーチンとは異なります;））。これは、サポートチームのメンバーが顧客の問題とログを取得し、スタックトレースを調べることでコードの可能な領域をポイント/アシストできる場合にも役立ちます（明らかに問題などに依存します）。これは開発者との時間を節約しますが、もちろん問題にもよります。

また、すべてのビジネスルール/決定を含む製品の最新のドキュメント/ wikiがあれば役立ちます。ただし、もちろん、新しい機能強化やバグ修正（動作が変更される場合）に影響を与えるために、Wikiが常に更新されていることを確認する必要があります。私の正直な考え

一般に、組織の観点からは、人々は行き来します。プロジェクト（または製品）は進化し続ける必要があります。したがって、ほとんどの組織では、通常、コードを維持するためにすべてのリポジトリに対してオープンになっています。

通常、気付かない不正アクセスを防ぐため（コードの盗難などを防ぐため）のアクセス権などがありますが、ほとんどの上位のアクセスは実際にはこれを禁止されていません。組織内では、コードで信頼できる人を（十分に）信頼する必要があります。従業員（または同僚）からコードを隠すことは、大きな動機付けの要因です。

私たちの組織では、人々が実際にコードに貢献していない場合でも、開発者に物事をダンプして眠りにつくのではなく、（所有権を持って）現場で問題と戦う/修正しようとするので役立つコードに直接アクセスできます！