ソフトウェア会社には、研究および/またはユーティリティライブラリの専任チームが必要ですか？

私はさまざまな銀行やいくつかの小規模なeショップ向けのWebアプリケーションを扱う会社で働いています。私たちは約20人の開発者を雇用し、4〜5つのプロジェクトをいつでも開発しています。開発チームはあまりやり取りせず、同じ問題の多くがさまざまな方法で行われます（良いものから悪いものまで）。

会社が現在のフレームワークを研究し、機能の共通ライブラリと共通フレームワークを継続的に改善し、現在および将来のプロジェクトをより速く、より効率的に構築するプログラマーのチームを持つことは良い考えだろうかと思いました。

このようなチームはどのくらいの大きさにすべきですか？

また、他の人を訓練する常任のメンバーが必要ですか、それとも人を交代させるべきですか？

更新：私は、人々が興味をそそるかもしれない楽しみのために取り組むことができる一般的なプロジェクトについて考えていました。人々が仕事のプレッシャーを抱えているとき、彼らが思いつく解決策は最良ではないようです。

1つの重要なポイントは、完全に分離した状態で優れたフレームワークを開発することは不可能だということです。優れたフレームワークは有機的に成長します。プログラマーが特定の機能を必要とすることに気づくと、フレームワークに追加します。そのため、フレームワークは少しずつ成長します。アーキテクトは、最終的にすべてのユースケースを明らかにすることはできません。

もちろん、フレームワークを有機的に成長させると、内部の整合性があまり良くないという欠点があり、スパゲッティに変わります。チームが良好な内部コミュニケーションを維持している場合、両方の長所を組み合わせることができます。フレームワークの整合性を維持しながら、エンドユーザー（開発者）の実際のニーズに合わせて構築する別のアーキテクトチームです。

私の気持ちはノーです。

これを実行した場合、チームの外部に誰も使用していないライブラリを個別のチームが作成する代わりに、チームの外部に誰も使用していないライブラリを作成する専門チームがいると思いますかなりの追加費用で）。

あなたが説明するチームにはさまざまな問題がありますが、私にとって重要なのは、あなたが実際に抱えている問題に対処していないことです。

あなたが持っている問題は、誰がライブラリを作成するかではなく（これらの問題に対する多くの解決策を既に持っているものの音によって、もう1つはどのように役立つのでしょうか？）、チームが話したりやり取りしていないことです。

チームがお互いのコードを再利用しないのには十分な理由があります（たとえば、表面的に類似している問題は微妙に異なる、またはプロジェクトのタイミングでは何かを一緒に開発するという追加の依存関係が許可されないなど）可能な場合にどのようにやり取りできるかを見てください。

私はお勧めします：

• プロジェクト間でチームを交代させる
• チーム間ランチとディスカッショングループを開催する
• 問題の解決方法を検討するプロジェクトレビューを投稿する（他のチームが参加）
• 再利用可能なコードの概要を説明するウィキの領域を設定します（そして誰がそれについて話すか）
• 良い再利用を奨励することを考えてください-実際にそれを行うために人々に余分にお金を払ってください。コンポーネントを再利用することで5日間と2000ドルのコストを節約できる場合は、プロジェクトの最後の夜（チームが節約が本物であると確認したとき）に今余分な利益の200ドルをチームに与えてはいけません。

図書館チームは、利益なしでオーバーヘッドになると思います。

開発者が楽しみのために取り組む一般的なプロジェクトであるという点で、会社は自分の時間に物事に取り組むプログラマーに頼るべきではありません。それはただの無給の残業であり、いずれの場合も、誰も物事に取り組むことを望まない大きな期間がある可能性が高いため、信頼できません。

プロジェクトの合間に会社で働く人だと言っているのなら、うまくいくかもしれませんが、それでも本当の問題だとは思いません。それでも、人々にライブラリを使用させる方法を考え出す必要があります。私が言ったように、あなたはすでに各プロジェクトで開発されているこれらの問題の解決策を持っています、あなたの問題はなぜそれらが共有されないのかです。

それは建築家の仕事です。

ソフトウェアアーキテクトの主な責任は次のとおりです。

• アプリケーション開発を追求する標準的な方法を選択することにより、開発中に利用可能な選択肢を制限する
• アプリケーションのアプリケーションフレームワークの作成、定義、または選択
• より広範なシステム環境を観察および理解することにより、組織またはアプリケーションでの再利用の可能性を認識する
• コンポーネント設計の作成組織内の他のアプリケーションの知識を持つ

続きを読む：- ソフトウェアアーキテクト - ソリューションアーキテクト - エンタープライズアーキテクト。

「自分のドッグフードを食べる」という言葉は、この問題に対処しています。あなたのトップクールロックスターコーダーが実際に使用したことのないライブラリを作成した場合、彼はそれが良いライブラリであるとどのように言えますか？

機能をフレームワークに開発する主な理由は次のとおりです。

1.それは開発者にとって有用です2.それが有用であっ
たいくつかのケースがあります3.
他の人にとって有用かもしれない

2を押すと、機能は既にそこにあります。他の人にどのように渡すことができますか？

私はゲームに少し遅れましたが、誰もこれに取り組んでいないように感じました：

さまざまな問題をさまざまな方法で解決している個々のチームは、共有機能の恩恵を受けることは間違いありません。また、単一のチームを開発に専念させない方法でそれを実現するさまざまな方法がありますが、私は多くを見てきましたする場所の。

ほとんどの場合、これはあなたの製品ラインの「コア」と呼ばれ、時には（Amirが提案したように）アーキテクトが率いるチームがメンテナンスを担当します。通常、これは、組織で設定した最も厳しい標準に従うフレームワークを活用または作成する方法を見つけることができる方法ですが、本格的なアプリケーションに拡張する必要がある場合とそうでない場合があります。個々の製品チームが提供するもの。これにより、使用する個々の場所にコアコードを実装することでコアコードを "ドッグフード"することができ、実装がまったく異なる可能性のあるさまざまな製品に分岐することもできます。これにより、すべてのチームがコアライブラリに貢献できますが、必要な機能だけでそれを行き詰まらせることはできません。

ライブラリが有用であるためには、実際のプロジェクトの問題を解決するのに役立つ必要があるため、それは良いアイデアではないと思います。

それ以外の場合は、「理論的に」非常に優れたライブラリで終了できます！

私が働いていたある会社では、同じようなことがありましたが、うまく機能していないようでした。内側のチームの人々は、きちんとしたアイデアを思いつき、ほとんどが機能するプロトタイプを思いついた後、それが壁を越えて、製品になると期待されていました。

ツールグループが独自の小さなプログラムを実行して、実際にはそれほど便利ではないが、APIが乱雑になり、十分に使用できないため簡単に使用できない関数を生成することになると思います削除されました。彼らは適切に文書化しません。

ツールグループが、実際にツールを使用している人々と継続的に接触しているシステムアーキテクトの十分下にあれば、機能する可能性があります。ツールグループが頻繁に回転すると（多くの外部調査の実行が妨げられる）、動作する可能性があります。しかし、私は支払い作業をしている人々との接触を失うことを恐れるでしょう。

フレームワークを使用することがすべての場合にメリットになるかどうかの議論にどれだけの時間を費やしますか？フレームワークがアップグレードされるのを待つことでプロジェクトが遅れますか？ある時点で、フレームワークの存在を正当化するために、フレームワークの使用が必要になります。