均質なコードを抽出し、チームの共通コードを構築するためのアドバイス/アプローチ

私はカリフォルニア州で働いています。私の意見では、プログラミングチームは実際には「チーム」ではありません。通常、アプリケーション/システムのライフサイクル全体を通じてプロジェクトに単独で取り組んでいるからです。

最終的には、多くの開発者が「車輪を再発明」しています...私たちの大多数が同じOracle DBで作業しているにもかかわらず、独自のデータレイヤーを作成しています...独自のセキュリティスタッフを作成しています...オン。

私は従業員の考え方を変えることができず、チームプロセスの変更に関して現実的な野心はありません...しかし、私の目標は、少なくとも共通の建物を構築するために、チームをもう少し連携させることですすべての定型機能に使用できるブロック片。

明らかな利点は、すべてのユーザーが共通の部分に精通している場合、テストとサポートがはるかに保守可能であり、他の誰かがすでに行ったものと同じリポジトリを作成していない場合、本番までの時間が短縮され、より良いソリューションの提供に焦点を当てることができます私たちのアプリが解決しなければならない特有の問題に...など

私は合唱団に説教していると確信しています。

コツは、国家が変化を好まないこと、そしてその従業員を好まないことです。マネージャーは、摩擦を避けたいので、そのまま続けたいという理由だけで、しばしば新しいアイデアを無視します。

似たような質問がありますが、私が探しているのは、どのようにして同じような状況に直面したかに関するアドバイスと、「草の根」のような取り組みをより簡単に管理に取り入れる方向へのアドバイスです。

編集：いくつかのことを明確にするために：

• 私が探している範囲は、州政府機関のITショップです。私はいくつかの部門を超えて調整しようとはしていません。バイクに乗るように頼む前に、人々を補助輪から降ろしてください。

• セキュリティはそれほど重要ではありません。ほとんどのアプリケーションは内部にあり、Citrixで配布されているWindowsフォームで記述されています（ほぼ）。ほとんどすべてのアプリケーションがOracleの同じエンタープライズテーブルを使用しています。話す。コラボレーションを妨げるべきではありません。

• 私は、NuGetフィードをセットアップし、いくつかの定型コードをパッケージ化し、Oracle用のいくつかのリポジトリを作成し、いくつかのメールを送信しましたが、フィードバックはほとんどありませんでした。私のチームの約3分の1がReSharperを使用していて、ヒントを添えて随時メールを送信しています。

問題は...

明らかな利点

特に彼らが開発者でない場合、あなたの周りの人々にはそれほど明白ではないかもしれません。私は州政府と連邦政府の両方で働いたので、あなたの状況に共感できます。私の経験では、あなたは彼らにお金を示す必要があります。数値への変更（例：メトリックス）の同等化を開始し、次にメトリックスをお金に同等化します。これはおもしろくなくて、あなたもそうあるべきではないと思いますが、これはしばしばやり方です。すべての州が予算危機に陥っており、より多くのお金を必要とせずに、より大きな要求にどのように応えられるかを示すことで、アイデアがより魅力的になる可能性があります。

途中で、やりたいことは音（または感じ）が良くなるかもしれませんが、数値はあなたをサポートしていません。それが起こった場合、あなたは本当に動揺することができる技術の宗教的な議論に乗り出しているかもしれません。または完全に脱線; あなたがしている他の進歩。その場合は、あきらめて次のアイデアに進みます。全員が変更に対してよりオープンになったら、それらに戻ってください。

メトリックについては、クラシックから始めて、ほとんどの場合にうまく機能します。

• 時間/スケジュール（システムのパフォーマンスを含めることができます）
• お金（使用して保存）
• 素材
• 欠陥（レート、重大度、エンドユーザーへの可視性）
• 信頼性（政府の用語では、これはAo [操作の可用性]とMTBF平均障害間隔）

幸運を！

1人または2人の同僚とチームを組んで、共通のフレームワークの構築を開始することを検討できますか？同盟国が必要となり、いくつかのメリットが明らかになって、物事がそれほど孤立しないようになると、それが出発点として私の提案になります。同僚がこれらのアイデアにどれほど受容的であるか、そしてこれを着手するために使用できる初期の採用者であるかを確認するために、同僚といくつかの議論をする必要があるかもしれません。

私の主なテーマは、ここでベビーステップを検討することです。定期的な小さな変更でも問題なく機能する場合があります。

最初のステップは、あなたが持っているものを（同じ雇用主のために興味を持ち、働いている人の中で）宣伝することです。

大学の学部のオフィスのように、あなたが持っている部品のアーキテクチャ、機能性、デザインを説明するポスターを持っています。これは、国家の「在庫」または「資産」です。

2番目の質問は、雇用主が他者のソースコードを閲覧できるかどうかです。これが許可されない場合、コラボレーションは非常に困難になります（州レベルでサポートを受けることができない場合）。

セキュリティに関しては、国がすでにすべてのプロジェクトで満たさなければならない情報セキュリティの義務をいくつか持っている可能性があります。それは標準化の良い出発点になるかもしれません。

ある種の仕事、特に。「カスタマイズプロジェクト」は、所属する場所であるため、常に単独で作業します。

まず、私は再利用可能なコードの巨大な支持者であり、複数の開発者が使用する必要があるクールで気の利いた強力なビルディングブロックを定義していると言います。ただし、独自の再利用可能なコード/ライブラリ/フレームワークをロールすることは、非常に鋭い両刃の剣になる場合があることも指摘しておきます。そして、あなたが時間を節約するべきだと思うものは、時には正反対をするかもしれません。

これは私が過去に観察したパターンでした：開発者が製品/機能/リリースに取り組み続けると、それらの一部（おそらく10-25％）は、再利用可能なコンポーネントまたはクラスを特定して、書き続けるのはばかげているでしょう何度も。残りの人々は、コピー/貼り付けとホイールの再発明を続けます。それらを忘れましょう、あなたは彼らの一人ではありません。

したがって、再利用可能なコードを特定すると、時間の経過とともにあなたの生活をますます簡単にするクールなものの独自の個人用ライブラリーの作成を開始します。XML、スレッド、レジストリの操作に役立つユーティリティクラスがあるかもしれません。私はこれを行い、それを聞いて喜んでくれるだれでもにそれを示しました、そして、何人かの人々は彼らが彼らが必要とするものを6行のコードでXML文書から解析できるという事実を喜んで受け入れました。他の人々は自分のやり方で設定されており、彼らはまっすぐなMSXMLの数百行のコーディングを愛しています。

私の調査結果：

1. あなたのライブラリが改善するにつれて、他の人は徐々にそれを使い始めます。

2. 他の人がそれを使い始めると、今やあなたは彼らが問題を抱えていてそのコードを疑っているときはいつでもサポート担当者になりました。APIの使い方とは少し異なるため、コードにバグが見つかる場合もあれば、APIの使い方がわからずコードにバグが含まれる場合もあります。彼らはあなたのライブラリを追加する前にすべてがうまくいったと彼らが確信しているからです。

3. （これは実際には別の投稿/ブログからのものですが、リンクを見つけることができません）：「再利用可能なコード」を書いて、それを行うのに3週間かかった場合。一般に、他の人がそれを使用して明確なドキュメントを提供できるように、さらに3週間かけてクリーンアップする必要があります。さらに、広範な単体テストの作成と、使用シナリオだけでなく、一般的な使用シナリオのカバーにも3週間かかります。他の人々も同じことを発見しました。フレームワーク/ライブラリーは、オリジナルの開発だけの3倍の労力を費やします。

4. うまくいけば、これに直面する必要はありません。私のコードの一部は再利用可能になり、人々は実際にもっと広い設定でそれを使い始めました。その後、約9か月前に、経営陣は製品を2つの異なる製品に分割することを決定しました。それぞれに独自のリリースサイクルがあります。そのフレームワーク/ユーティリティライブラリはどうなったと思いますか？どちらの製品もそれに依存していますが、製品Bが起動されようとしているときに製品Aを積極的に開発している場合は、ライブラリがどのように変更されるかに注意する必要があります。私たちのソリューションは、フレームワーク自体を、独自の独立したリリースサイクルを持つ製品Cにすることでした。だからここに私は9ヶ月後、そしてこれが引き起こしたすべてのビルド/継続的インテグレーション/パッケージング問題からの余震をまだ感じています。

5. ユーティリティクラスの作成方法には細心の注意を払い、この変更を行うことによるすべての影響を理解する必要があります。しかし、他の人々があなたのコードを使い始めると、いつか彼らはそれを修正したいと思うでしょう。ライブラリに依存するコンポーネントが他に20個ある場合、誰かがライブラリを変更すると、他のコンポーネントが19個壊れる可能性があります（コードを機能させるために変更を加えたと想定しています）。コードがより広く使用されるようになると、コードを変更するのがはるかに高価になります。

6. 私はすべて再利用可能ですが、昼休みまでに自分の個人用ユーティリティライブラリが自分の個人用ユーティリティライブラリのままであることを自分自身に望み始めている日があります。

だから私の経験に基づいて、私が考えることができるいくつかのアドバイス：

1. 必要なことを行う外部のサードパーティライブラリを探し、可能な限りそれらの上にアプリケーションを構築します。これらのライブラリには、すでにそれをサポートする人々のチームがあります。誰でもアクセスできる環境内のグローバルな場所にそれらを紹介します。

2. 全員に自分のものを使用するように依頼するのではなく、チームメイトや他のエンジニアに1対1でアプローチして、自分と同じ考え方を持つ人を確認します。私はあなたがあなたの価値観を共有する他の人をほとんど見つけないでしょう、そしてあなたは共通の利益に向かって働く非公式のコアチームを始めるかもしれません。

3. これが機能するかどうか、または良いアイデアかどうかはわかりませんが、私は自分の会社でこれを試してみたいと思います。グローバルで複数の人/チームが所有/使用するフレームワーク/ライブラリを作成する代わりに。すべてのコードを「内部オープンソース」として扱います。githubに似たリポジトリをセットアップし、さまざまな人/チームがライブラリ/ユーティリティ/ヘルパーコードを送信できるようにします。リポジトリを誰にでも見えるようにして、良いものを書いたら、誰でも自由にコードを取得して使用できるようにします。彼らがオープンソースのようにあなたのコードに変更を加えることを決定した場合、彼らは維持する独自のブランチを作成するか、メイントランクにロールバックするためにあなたに変更を戻すことができます。あなたが彼らの仕事を信頼しないか、変更に同意しない場合、プロジェクトはまだあなたのものなので、それを受け入れるかどうかの最終決定権があります。一部のチームがプロジェクトを開始し、それを放棄したが、別のチームがプロジェクトに役立つと判断した場合、チームは自分のチームリポジトリに分岐して作業を続行できます。私はRedmineを使用してこのようなことを行うことを検討してきましたが、まだセットアップする機会がありませんでした。