소프트웨어 회사에 연구 및 / 또는 유틸리티 라이브러리를위한 전담 팀이 있어야합니까?

다양한 은행 및 일부 소규모 전자 상점을위한 웹 애플리케이션을 수행하는 회사에서 근무합니다. 우리는 약 20 명의 개발자를 고용하고 있으며 한 번에 4-5 개의 프로젝트를 개발하고 있습니다. 우리의 개발 팀은 많은 상호 작용을하지 않으며 동일한 문제가 다양한 방식 (좋은 것에서 나쁜 것)으로 이루어집니다.

회사가 현재 프레임 워크에 대한 연구를 수행하고 공통 기능 라이브러리와 공통 프레임 워크를 지속적으로 개선하여 현재와 미래의 프로젝트를 훨씬 더 빠르고 효율적으로 구축하는 프로그래머 팀을 보유하는 것이 좋은 아이디어인지 궁금합니다.

이와 같은 팀은 얼마나 커야합니까?

또한 다른 사람을 훈련시키는 영구 회원이 있어야합니까, 아니면 사람들을 교체해야합니까?

업데이트 : 사람들이 재미를 위해 일할 수있는 일반적인 프로젝트에 대해 생각하고 있었는데 흥미를 유발할 수 있습니다. 사람들이 직업 압력을받을 때 그들이 제시하는 솔루션이 최고가 아닌 것 같습니다.

한 가지 중요한 점은 완전한 격리에서 좋은 프레임 워크를 개발하는 것이 불가능하다는 것입니다. 좋은 프레임 워크는 유기적으로 재배됩니다 . 프로그래머가 특정 기능이 필요하다는 것을 알게되면 프레임 워크에 추가하므로 프레임 워크가 조금씩 . 아키텍트는 결국 모든 사용 사례를 알지 못합니다.

물론 유기적으로 성장하는 프레임 워크는 내부 무결성이 좋지 않을 수 있다는 단점이 있으며 스파게티로 바뀝니다. 팀이 내부 의사 소통을 잘 유지한다면 프레임 워크의 무결성을 유지하면서 최종 사용자 (개발자)의 실제 요구 를 충족 시키는 별도의 아키텍트 팀을 결합 할 수 있습니다 .

내 기분은 아니야

내가 그렇게 생각한다면, 팀 외부에서 아무도 사용하지 않은 라이브러리를 생산하는 개별 팀을 보유하는 대신 팀 외부에서 사용하지 않은 라이브러리를 생산하는 전문 팀이 있다는 것입니다. 상당한 추가 비용으로).

설명하는 팀과 관련하여 여러 가지 문제가 있지만, 실제로는 실제로 문제를 해결하지 못한다는 것이 주요 문제입니다.

당신이 가진 문제는 누가 라이브러리를 생산 하는가가 아닙니다 (이러한 문제에 대한 많은 해결책이 이미 있으므로 도움이 될 것입니까?). 팀이 말하고 상호 작용하지 않는 것입니다.

팀이 서로 코드를 재사용하지 않는 데는 충분한 이유가 있습니다 (예를 들어 표면적으로 비슷한 문제는 미묘하게 다르거 나 프로젝트 타이밍으로 인해 무언가를 함께 개발하는 데 추가적인 의존성이 허용되지 않음). 가능할 때 어떻게 상호 작용할 수 있는지 살펴보십시오

나는 제안 할 것이다 :

• 프로젝트 간 팀 교체
• 팀 간 점심 및 토론 그룹 개최
• 문제 해결 방법에 대한 프로젝트 검토 게시 (다른 팀이 참석)
• 재사용 가능할 수있는 위키 개요 코드 영역을 설정하고 누구와 대화해야하는지
• 좋은 재사용을 장려하는 것에 대해 생각하십시오-실제로는 사람들에게 추가 비용을 지불해야합니다. 구성 요소를 재사용하여 5 일에 2,000 달러의 비용을 절약 할 수 있다면 프로젝트 종료시 밤새 팀에 200 달러의 추가 수익을 줄 수 있습니다 (저축이 진짜인지 확인한 경우).

도서관 팀은 아무런 이익이없는 오버 헤드 일 것입니다.

개발자가 재미를 위해 작업하는 일반적인 프로젝트라는 관점에서, 어떤 회사도 자신의 시간에 일하는 프로그래머에 의존해서는 안됩니다. 그것은 초과 근무에 대한 보수를 지불하지 않았으며, 아무도 일을하고 싶어하지 않는 큰 기간이있을 것이기 때문에 어떤 경우에도 신뢰할 수 없습니다.

당신이 그것이 프로젝트 사이에 회사 시간에 일하는 사람들이라고 말할 수 있다면 아마도 효과가 있을지 모르지만 여전히 그것이 진짜 문제라고 생각하지 않습니다. 사람들이 라이브러리를 사용하게하는 방법을 여전히 연구해야합니다. 내가 말했듯이, 각 프로젝트에서 개발중인 이러한 문제에 대한 해결책이 이미 있습니다. 문제는 공유되지 않는 이유입니다.

그것이 건축가 의 일이다 .

소프트웨어 아키텍트의 주요 책임은 다음과 같습니다.

• 응용 프로그램 개발을 추구하는 표준 방법을 선택하여 개발 중 사용 가능한 선택 제한
• 응용 프로그램의 응용 프로그램 프레임 워크 작성, 정의 또는 선택
• 더 넓은 시스템 환경을 관찰하고 이해함으로써 조직 또는 응용 프로그램 에서 잠재적 재사용을 인식
• 구성 요소 디자인 만들기 조직의 다른 응용 프로그램에 대한 지식

더에 대한 읽기 : - 소프트웨어 건축가 - 솔루션 아키텍트 - 기업의 건축가 .

" 자신의 개밥 먹기 "라는 말이이 문제를 해결합니다. 최고의 쿨록 스타 코더가 실제로 사용하지 않은 도서관을 낳았다면 어떻게 좋은 도서관이라고 말할 수 있을까요?

기능을 프레임 워크로 개발하는 주요 이유는

1.It는 developper에 유용
2.There는 유용했습니다 몇 가지 경우입니다
3.It는 다른 사람에게 유용 할 수 있습니다

2를 누르면 기능이 이미 있습니다. 다른 사람에게 어떻게 전달할 수 있습니까?

나는 게임에 조금 늦었지만 아무도 이것을 다루지 않는 것처럼 느꼈다.

다른 방식으로 다른 문제를 해결하는 개별 팀은 공유 기능의 이점을 얻을 수 있으며, 단일 팀을 개발하는 데 헌신하지 않는 방식으로 여러 가지 방법으로 얻을 수 있지만 많은 것을 보았습니다. 하는 장소의.

대부분의 경우,이를 귀사의 제품 라인의 "핵심"이라고하며, 때로는 Amir가 제안한대로 건축가가 이끄는 관리 팀이 있습니다. 이것은 일반적으로 조직에서 설정 한 가장 엄격한 표준을 따르지만 본격적인 응용 프로그램으로 확장 할 필요가없는 가장 기능적인 기능 만 제공하는 프레임 워크를 활용하거나 만드는 방법을 찾는 방법입니다. 개별 제품 팀이 제공하는 이를 통해 코어 코드를 사용하는 모든 개별 장소에서 구현하여 핵심 코드를 "dogfooding"할 수 있고 완전히 다른 구현을 가진 다른 제품으로 분기 할 수도 있습니다. 이를 통해 모든 팀이 핵심 라이브러리에 공헌 할 수 있지만 필요한 기능만으로 정리할 수는 없습니다.

라이브러리가 유용하기 위해서는 실제 프로젝트 문제를 해결하는 데 도움이되어야하며 실제 프로젝트에서 일하는 것만으로도 알 수 있기 때문에 나는 이것이 좋은 아이디어 가 아니라고 생각합니다 .

그렇지 않으면 "이론적으로"매우 좋은 라이브러리로 끝날 수 있습니다!

내가 일했던 한 회사에서 실제로 비슷한 것이 있었지만 제대로 작동하지 않는 것 같습니다. 내부 팀의 사람들은 깔끔한 아이디어를 내 놓았고 대부분 효과가 큰 프로토 타입을 내 놓았고 벽을 넘어서서 제품으로 만들 것으로 예상되었습니다.

내가 기대할 수있는 것은 도구 그룹이 자체적으로 작은 프로그램을 시작하여 실제로 유용하지는 않지만 API를 어지럽히고 쉽게 사용할 수없는 기능을 생성하는 기능을 생성한다는 것입니다. 제거되었습니다. 그들은 제대로 문서화하지 않을 것입니다.

툴 그룹이 실제로 툴을 사용하는 사람들과 지속적으로 연락하는 시스템 아키텍트에 충분히 있다면, 작동 할 수 있습니다. 공구 그룹이 자주 회전하면 (많은 외부 조사를 방해 할 수 있음) 작동 할 수 있습니다. 그러나 나는 유료 업무를 수행하는 사람들과의 연락을 잃는 것을 두려워합니다.

프레임 워크를 사용하는 것이 모든 경우에 도움이 될 것인지 토론하는데 얼마나 많은 시간을 할애합니까? 프레임 워크가 업그레이드되기를 기다리면 프로젝트가 지연됩니까? 어떤 시점에서 프레임 워크의 존재를 정당화하려면 프레임 워크의 사용이 필요합니다.