팀의 모든 구성원이 동일한 IDE를 사용해야합니까? [닫은]

팀의 모든 구성원이 동일한 IDE를 사용해야한다는 것이 합리적이라고 생각하십니까?

예를 들어, 이미 팀에있는 모든 엔지니어는 IDE X를 사용합니다. 두 명의 새로운 엔지니어가 와서 IDE Y를 대신 사용하려고합니다. 그 이유는 그들이 몇 년 동안 사용해 온 것입니다.

"혼합 IDE"팀에 대한 경험이 있습니까? 그렇다면 무엇입니까?

지속적인 빌드 서버에서 사용되는 '공식적인'빌드 시스템이 모두 동일하다면 팀의 각 구성원이 원하는 도구를 선택할 수없는 이유는 없습니다.

팀이 특정 IDE에서만 사용 가능한 특정 플러그인을 사용하는 경우 동일한 개발 플랫폼에서 모든 사람을 통합하는 것이 좋습니다. 또한 저와 동일한 IDE를 사용하는 경우 개발 문제가있는 사람을 돕는 것이 더 쉬운 반면, 익숙하지 않은 인터페이스가있는 사람의 화면을 읽으려면 시간이 조금 더 걸립니다.

한 가지 단점은 페어링 할 때 키보드를 유창하게 교환 할 수 없다는 것입니다. 주류 IDE 사이에서 이것은 큰 문제는 아니지만 한 사람이 Eclipse에 익숙하고 다른 사람은 vim에 익숙하면 불일치가 발생합니다. 이클립스 사용자는 vim을 완전히 사용할 수 없을 수도 있지만, vim 사용자 (나)는 바닐라 이클립스를 사용하는 끔찍한 속도로 숨을 쉴 때 많은 시간을 소비한다.

즉, 여전히 vim을 직접 사용하고 싶습니다. 당신의 쌍이 오랫동안 "운전하는"사람 중 한 명만 만족한다면 제대로 작동합니다.

그리고 vi와 같은 Eclipse를 작동시키는 플러그인이 있다는 것을 알고 있지만 Eclipse를 좋아하는 사람과 어울리는 곳에 앉아 플러그인을 설치하지 않을 것입니다.

Linux 커널의 모든 개발자가 동일한 IDE를 사용하도록 (또는 IDE를 전혀 사용하지 않도록)하는 것은 전혀 의미가 없습니다.

텍스트 편집기 "multiple IDEs"를 가끔씩 보완하여 상용 IDE를 계산하지 않으면 혼합 IDE에 대한 경험이 없지만 몇 가지 장단점을 생각할 수 있습니다.

찬성

• 각 개발자는 자신이 가장 잘 아는 것으로 생산성을 높일 수 있습니다
• 일부 IDE는 다른 IDE보다 이점을 제공 할 수 있습니다 (하나는 리팩토링이 더 좋을 수도 있고, 다른 것은 코딩 보조를 제공하는 데 더 좋을 수도 있고, 다른 것은 데이터 통합에 더 좋을 수도 있습니다). 블렌드를 사용하면 팀에서이를 활용할 수 있습니다.
• IDE 중 하나가 작동하지 않을 가능성에 대비하여 약간의 위험이 있습니다.

단점

• 라이센스 문제. 여러 상용 IDE가 포함 된 경우 더 비쌀 수 있습니다. 최소한 추적하는 것이 더 좋습니다.
• 라이센싱 문제 2. IDE 또는 언어로 라이센스가 부여 된 프레임 워크 또는 플러그인이있는 경우 이것이 문제입니까?
• Dszordan이 언급했듯이 특정 플러그인은 다른 IDE와 호환되지 않을 수 있습니다.
• IDE에 코드 생성 구성 요소 또는 스타일 형식 엔진이 다르게 작동하는 경우 약간의 혼동이 발생할 수 있습니다.

이것이 강제 될 수있는 이유가 있습니다. 비주얼 스튜디오와 emacs / vim을 고려하십시오. Windows에서와 같이 Visual Studio는 줄 끝에 여분의 \ r을 추가합니다. 이것은 emacs / vim의 디스플레이와 엉망입니다. 또한 탭에서 문제가 발생합니다. 우리의 문제는 개발자가 Linux에서 작업하지만 소프트웨어 아키텍처가 Visual Studio에서 편안하다는 것입니다. 그는 우리가 파일을 올바르게 포맷하지 않는다고 말하면서 우리를 저주합니다. 그러나 이것이 기본 설정 문제 때문이라는 것을 알았을 때 우리 모두 같은 형식에 동의했습니다.
누군가 내가 특정 IDE를 사용하도록 강요해도 나쁘지 않을 것입니다. 팀에게 좋은 것이 무엇이든 나는 그것을 존중하고 타협 할 것입니다.

오늘날 개발자는 자신의 도구를 선택하려고합니다.

이것은 시간이 지남에 따라 변했다. 10 년 또는 15 년 전 제가 일했던 곳에서 많은 선택이 없었습니다. (그렇습니다. 많은 편집자가 있었지만 '선택'은 아니 었습니다). 내가 15 년 전에 일했던 가게는 매우 오래된 학교 였고 (그때에도!) vi는 편집자였습니다. 선택의 여지가 없다. cussing과 맹세의 첫 달 후에 나는 그것을 실제로 좋아했기 때문에 이것은 실제로 꽤 유용했습니다.

오늘날 많은 선택이 있으며 각각에는 많은 장점이 있습니다.

개인적으로 필자는 'back'을 vi (m)로 바꾸기 전에 몇 년 동안 IDE 인 rubyMine을 사용했습니다. Ruby는 (오리 타이핑 및 기타 동적 기능)을위한 IDE를 작성하기에 매우 어려운 언어이기 때문에 IDE가 느리고 최신의 가장 빠른 컴퓨터를 필요로하기 때문에 이렇게했습니다.

글쎄, 나는 혼합 된 windows / unix & c ++ / java 팀의 일부라는 점에서 experiecne을 가지고 있습니다. 모든 사람들이 다른 IDE로 작업하는 것이 편안하거나 IDE Y에 익숙하지 않은 사람이 다른 사람 (즉, IDE Y를 가진 사람)에서 일할 필요가없는 상황이 없을 경우에는 이것이 문제가 아니라고 생각합니다. ) 시스템.

모두가 원한다면 괜찮지 만 다른 사람들은 다른 편집기 / IDE를 사용하고 싶을 수도 있습니다. 팀과 함께 큰 일을 할 때 사람들이 내가 선호하는 편집자가 아닌 다른 편집자를 사용하도록 강요하고 싶지는 않습니다. 사람들이 특정 편집기를 사용하도록 강요하지 않으면 상황에 가장 만족할 수 있습니다.

BTW, 이맥스!

모든 사람이 "동일한"IDE를 가질 필요는 없다고 생각하지만 모든 사람이 "지원되는"IDE를 갖는 것이 좋을 것입니다.

예를 들어, 코드 주석 달기 및 업데이트가 진행되는 한 IDE가 코드 검토 프로세스에 통합 된 경우 모든 사람이 지원되는 플랫폼에있는 것이 좋습니다.

회사에서 Rational Team Concert 와 같은 협업 환경을 사용하고 있고 한 두 사람이 지원되지 않는 IDE (또는 다른 버전)를 사용하는 반면 다른 사람이 호환되는 IDE를 사용하려는 경우 선택한 사람에게는 인생이 어려울 수 있습니다. 지지 루프 외부.

우리는 Visual Studio를 사용하여 프로젝트를 빌드합니다. 텍스트 편집에 관해서는 Emacs로 전환합니다. 작업이 완료되는 한 회사는 신경 쓰지 않아야합니다.

"우리는 이것을 내 오래된 직장에서 사용했다"와 같은 소리가납니다. 글쎄, 그들은 그들의 오래된 직장에 있지 않습니다.

툴 체인이나 소스 컨트롤 플러그인에 영향을 미치지 않는다면 가능할 것입니다. 그렇다면 다시 두 사람이 분명한 이점을 보여 줄 수 있습니까? IDE를 사용 했습니까?

그렇지 않으면, 나는 좋은 사례가 없다면이 말도 안되는 인내심이 없습니다. 그들은 예전 직장에 있지 않았습니다. 그들이 떠나고 싶어하는 것은 그리 좋은 일이 아니 었습니다. 이전 IDE에서 다른 IDE를 사용했을 때의 주요 특징은 STFU이며 감사해야합니다.

예! 싱글 톤 IDE를 시행하십시오.

프로젝트 종속성이 변경되면 문제가 발생합니다. 프로젝트에 새로운 의존성을 도입한다면, 모든 사람들은 그 새로운 의존성을 도입하는 데 시간을 낭비하게되고, 일부는 그 과정에서 실패하고 시간을 낭비 할 수 있습니다. 엄청난 시간 낭비.

팀에 다른 IDE를 추가 할 수있는 좋은 정당성이 있어야합니다. 즉, 절약 된 시간은 시스템을 다른 IDE로 마이그레이션하는 데 소요되는 시간을 초과해야합니다.