회사가 특정 IDE로 전환하라는 명령이 적기입니까? [닫은]

최근에 빠르게 성장하는 스타트 업에 합류했습니다. 지난 3 개월 동안 개발 팀은 4 명에서 12 명으로 성장했습니다. 지금까지 그들은 개발자들이 자신의 작업을 수행 한 것에 대해 매우 공평한 상태 였습니다. 실제로 회사에 대해 처음에 매력적으로 생각한 것 중 하나는 대부분의 프로그래머가 Linux를 사용했거나 노력에 가장 적합한 OS를 사용한다는 것입니다.

이제 토론없이 모든 사람이 Eclipse로 전환해야한다는 명령이 내려졌습니다. 훌륭한 편집자. SublimeText2를 선호하지만 내 개인적인 취향입니다.

우리는 Backbone을 사용하는 JS 팀이며 Eclipse는 Backbone 코드를 잘 이해하지 못합니다. 이것은 / good / IDE (PHP Storm)를 사용하는 팀의 사람들이 많은 검색-찾기-오-대기-어디-나-세 -3 단계-걸음 일을해야한다는 것을 의미합니다. Ctrl + 클릭 및 뒤로 / 앞으로 사용하는 대신 생산성을 15 %, 즐거움을 50 % 줄입니다.

이것이 붉은 깃발입니까? 개발자 (MS 이외)에게 IDE 또는 툴 세트가 이미 정착되어 있고 생산적인 경우 사용할 도구를 알려주는 것은 변덕스럽고 부당하게 통제하는 것 같습니다.

"이제 토론없이 모든 사람이 이클립스로 전환해야한다는 명령 이 내려졌다."

이것이 진짜 적기 라고 생각합니다 . 귀하의 팀은 소프트웨어 개발에 대한 전문가이며 결정에 영향을받는 전문가이지만이 명령을 내린 토론에서 한마디도하지 않습니까?

뾰족한 머리 보스가 과도하게 관리하는 것처럼 들립니다. 의사 결정자 / 팀이 해당 의사 결정에 대한 적절한 통찰력을 가지고 있습니까?

의사 결정자들이 그러한 결정에 충분한 자격을 갖추고 있다는 점을 고려할 때 개발자 팀의 의견을 요구하지 않는 것은 적어도 두 가지 단점이 있습니다.

• 팀은 관여하지 않는다고 생각합니다. 팀을 참여시키는 것이 경영의 최우선 과제가되어야합니다. IDE와 같은 핵심 문제에 대한 나의 의견이 요구되지 않을 정도로 가치가없는 곳에서 개발자로 일하고 싶지 않습니다. 다른 사람의 의견을 구한 다음 반대 의견을 결정하는 것이 더 나쁠 수 있지만, 그 경우에는 그 결정에 대한 확실한 근거가 필요합니다.

• 그러나 경험이 풍부한 경영진은이 특정 코드를 개발할 때 100 % 작동하지 않습니다. 흥미로운 통찰력이 전혀없는 사람들은 전혀 순진하다고 가정합니다. 물론 관리자가 개발자가 생각하는 모든 것을 생각했을 수도 있지만 알 수있는 유일한 방법은 묻는 것입니다.

공통 프로젝트에서 함께 작업 할 때 모든 워크 스테이션에서 소프트웨어를 편집 / 빌드 / 디버깅하는 데 사용할 수있는 모든 도구가 있으며 개발의 약 90 %를 수행하기위한 핵심 도구가 모든 사람에게 알려져 있다는 것이 합리적입니다. 팀. 팀이 성장하고 모든 사람이 자신이 좋아하는 도구 세트를 사용하면 더 많은 사람들이 의견을 제시 할 수 있습니다. 필요한 도구 수보다 더 많은 도구가 커지지 않으면 관리 작업도 쉬워집니다.

물론 한 개발자가 개인적으로 좋아하는 편집기를 사용해야한다고 주장하는 경우 팀의 기본 편집기 (귀하의 경우 Eclipse)에서 소스가 다르게 보이거나 다르게 작동하지 않는 한 괜찮을 수 있습니다. B는 개발자 A의 소스를 편집해야하며 개발자 B는 소스를 효과적으로 변경하기 위해 A가 개인적으로 좋아하는 편집기를 배우도록 강요해서는 안됩니다. 그러나 두 디스플레이가 동일한 디스플레이 앞에서 때때로 함께 작동해야하거나 일부 페어 프로그래밍을 수행해야하는 경우 선택한 편집기를 둘 다 잘 알고 있으면 작업이 더 쉬워 질 수 있습니다.

페어 프로그래밍을 위해 키보드를 사용할 때 화면 앞의 두 당사자가 같은 기술을 사용하는 것이 좋습니다. IDE에 프로젝트에 특별한 구성이 필요한 경우 모든 사람에게 동일한 방식으로 구성된다는 것도 알고 있습니다. 도구가 모두에게 동일 할 때 새로운 개발자를 시작하는 것이 더 쉽습니다.

그러나 당신이 그것을 가장 효과적으로하려고 노력하는 것과 비교한다면, 그것은 실제로 가치가 없습니다.

그렇습니다. 경영진이 어떤 도구를 자신보다 더 효율적으로 사용할 것인지 더 잘 판단 할 수 있다고 생각합니다.

그 자체로는 붉은 깃발이 아닙니다.

때때로 경영진은 결정을 내려야 합니다. 무언가에 대한 표준화가 필요한 문제는 해당 범주에 속합니다. 한 번은 표준을 몇 년 동안 표류하고 20 가지 이상의 SCM 도구를 보유한 클라이언트에서 근무했습니다. 서로 다른 개발 팀에 의해 독립적 인 선택으로 시작된 것은 조직 전체의 코드에 대한 기술 공유 및 공동 작업을 심각하게 방해하는 물류 악몽으로 바뀌 었습니다. 통합 빌드는 ..... 어 ..... 매우 통합되지 않았습니다 .....

또한 모든 결정에 대해 모든 사람과상의하는 것이 실용적이거나 필수적인 것은 아닙니다 . 이것이 수행되어야하는 범위는 조직의 문화와 결정의 중요성 / 복잡성에 달려 있습니다. 일반적으로 상담이 덜 필요한 다음 옵션 중 하나를 선택하십시오.

1. 찬반 양론에 대한 충분한 지식이 있고 광범위한 상담이 필요한 결정이 중요하지 않은 경우 스스로 결정하십시오.
2. 결정을 내릴 자격이있는 수석 개발자 일 것입니다.
3. 영향을받을 수있는 모든 사람 (이메일, 시청 회의, 팀 회의)에게 결정을 내린다는 사실을 제기하십시오. 올바른 결정이라고 생각하지만 반대로 새로운 증거가 나오면이를 바꿀 의사가 있다고 말하십시오. 사람들에게 중요한 견해가 있다면 개인적으로 나아 오도록 권유하십시오
4. 사람들에게 하위 팀을 구성하여 옵션을 검토하고 결정을 권유하십시오. 진정으로 가까운 전화 인 경우 좋은 옵션입니다. 답을 모르고 관련된 사람들을 결정에 넣기를 원합니다.

개발자 툴링 (잠재적으로 논쟁의 여지가있는 문제)과 같은 경우 아마도 2 다음에 3 또는 4를 수행 할 것입니다. 핵심 사람들 중 하나가 의사 결정에 기여할 수있는 기회를 얻었습니다.

나에게 잘못된 결정이 내려 졌다고 강하게 느끼면 실제 적기 가 발생할 것입니다 (잘못 된 == 당신이 좋아하는 도구를 선택하지 않고 회사에 해를 끼칩니다). 이 문제를 제기 할 때 경영진은 어떻게 반응합니까?

• 좋은 경영진은 당신의 주장에 귀를 기울이고, 피드백에 대해 진심으로 감사하며, 새로운 통찰력을 얻은 경우에 그들의 입장 을 재고 할 것 입니다. 그들은 여전히 ​​당신에게 동의하지 않을 수도 있고 그들의 결정에 충실 할 수도 있지만, 당신이 그들과 함께 그 결정을 내렸다는 것에 감사하고 그들이 왜 그들의 결정에 고착하고 있는지에 대한 예의를 보여줄 것입니다. 그들은 미래에 그러한 결정을 내리는 방식을 바꿀 수도 있으며, 만약 당신이 좋은 지적을한다면 그들의 "스마트 한 사람들"목록에 당신을 포함시킬 수 있습니다.
• 나쁜 결정은 방어적일 것이며, "결정이 내려졌다"고 말하고 다른 전술들이 그들이 잘못된 결정을했을 수도 있다는 사실에 직면하지 않도록 할 것이다. 그들은 당신을 "고장 쟁이"로 볼 수 있습니다. 회사는 경영에 대한 믿음과 마찬가지로 고통을 겪습니다. 이것은 진짜 붉은 깃발입니다! 당신이 할 수있는 동안 나가!

maven 또는 이와 유사한 것을 사용하는 경우 사용중인 IDE는 중요하지 않습니다. 의존하는 플러그인이있는 경우 Eclipse와 같은 특정 IDE에 묶여있는 경우가 있습니다.

가장 생산적인 IDE 인 자신의 IDE를 선택할 수 있어야한다고 생각합니다. 그러나 이미 언급했듯이 표준 IDE를 사용하는 것이 적절한 경우가 있습니다.

"corporate mandated"IDE를 설치했지만 원하는 IDE에서 여전히 대부분의 작업을 수행 할 것입니다. 소스 파일을 편집하는 데 어떤 IDE를 사용했는지 아무도 알 수 없습니다.

거의 모든 언어에 대해 IDE 대 편집기 앞면에서 나는 편집기가 할 수있는 것보다 훨씬 많은 일을 할 수 있기 때문에 IDE (IntelliJ)를 강력하게 선호합니다. ST2 또는 Emacs로 되돌아가는 것이 있지만 ST2 / Emacs를 얼마나 좋아하더라도 IDE가 거의 항상 승리합니다.

내가 본 모든 팀에는 Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine과 같은 다양한 IDE 및 편집기가 있습니다. 문제는 없었습니다. 못.

나에게 이것은 조직의 높은 수준에서 실제로 중요한 것에 대한 오해를 말합니다. 중요한 것은 훌륭한 코더가 자신이해야 할 일을하고 가장 편안한 도구를 사용하게하는 것입니다. IDE 균일 성은 객체 아키텍처, 단위 테스트, 알고리즘 등의 필수 질문에 대해 발생하는 실제 통신과 거의 관련이 없습니다.

다음 사람과 동일한 IDE를 사용한다는 것은 동일한 바로 가기로 코드를 탐색하는 방법과 컴파일 / 구성이 설정되는 방법을 모두 알고 있다는 것입니다. 실제 코드 문제에 대해 이야기 할 때는 어느 것도 중요하지 않습니다.

회사의 다른 요소에 따라 살기 좋습니다. 당신은 항상 일상적인 것들을 위해 자신이 선호하는 편집기를 사용할 수 있습니다. 그리고 아마도 당신의 그룹은 훌륭한 문화를 만드는 다른 위대한 일들을하고있을 것입니다. 그러나 위임 된 IDE는 큰 실수 IMO입니다. 나를 위해, 만약 내가 회사와 인터뷰를했다 그리고 그들은 내가 한 IDE 저를 알렸다 허용 내가 그들의 시간을 정중하게 그들을 감사 것, 사용하는.

에서 우리의 루비 가게 가 우리가이 일을 알고 있기 때문에, 팀의 대부분이 즐기는 IDE (RubyMine)를 사용하는 강력한 권고 그리고 우리는 서로의 바로 가기 등을 가르 칠 수

개발자는 다른 IDE를 자유롭게 사용할 수 있지만 원하는 경우 해당 편집기에서 뛰어난 기술을 갖추어야합니다. 우리가 누군가 자신의 프로젝트를 탐색하거나 커스텀 FooEdit에서 텍스트를 편집하는 데 어려움을 겪고 있다면 RubyMine을 추천합니다.

프로그래머가 주어진 IDE의 전문가라면 그것을 사용해야합니다. IDE에서 전문가가 아닌 경우 프로그래밍 언어 또는 팀 내에서 매우 일반적인 하나 또는 두 개가 있으며 아마도 배우는 것이 합리적입니다.

IDE에서 표준화하도록 강요받는 것은 끔찍한 생각처럼 들립니다.

회사가 개발자에게 특정 편집자 나 소프트웨어를 강요해야하는 이유를 조사해야합니다. 편집증 (내가 찾고있는 단어가 아닐 수도 있음) 부분은 개발자에게 설치를 요청하는 일식에 생산성 추적이 추가 될 수 있다고 생각합니다. 훨씬 덜 편집증 적이라고 생각하면 모든 사람들이 동일한 버튼을 눌러 코드 분기를 테스트하고 빌드하면 훨씬 쉽게 만들 수있는 제품 빌드 도구를이 IDE에 추가하는 데 시간을 보냈다고 생각할 것입니다.

어쨌든 내가 말하려는 것은 아마도 단순한 관료주의 이상이거나 개발자의 머리를 어지럽히는 방법 일 것입니다.

이것은 거대한 적기입니다. 모든 회사에는 그러한 바보 같은 아이디어가 있지만 다른 적기가 계속되면 떠나십시오.

특히 빠르게 성장하는 팀에서는 일부 결정의 동기가 사라지기 쉽습니다. Eclipse로 전환하려는 동기는 대부분의 개발자가 IDE를 구성하는 데 많은 시간을 낭비하고 회사에 대한 전문 지식이 제한되어 있다는 사실 일 수 있습니다.

필자는 Eclipse로 이동하라는 명령을 받아 필요할 때 Eclipse 설정이 필요하다는 것을 의미하지만 좋아하는 편집기에서 작업을 계속하십시오. 회사에서 Eclipse에 멋진 도구를 배포하기 시작하면 점차 Eclipse로 이동해야 할 수도 있습니다.

적기 : 걱정하기 전에 비이성적 인 명령이 몇 개 더 있으면 기다릴 것입니다.

스타트 업은 일반적으로 지속 가능한 비즈니스 모델을 파악할 수있을 정도로 민첩성을 유지하려고합니다. 일단 돈 부분을 파악하면 경영진이 사업 규모를 확대합니다. 엔지니어링 프로세스가 강화됨에 따라 모든 초기 기술 직원이 떠나기 시작하는 것이 일반적입니다.

아시다시피 코드를 실행할 때까지 실제로 어떤 코드를 수행할지 알 수 없습니다. Turing은 컴퓨팅 초기에이를 입증했습니다. 이것은 소프트웨어를 작성할 때 의미있는 생산성 측정치가 없다는 것을 의미합니다. 그러나 경영진이 업무를 수행하려면 생산성이 분명해야합니다. 코드를 측정 할 수없고 (예를 들어 사람들이 시도한 코드 행), 그들이 볼 수있는 것을 측정 할 것입니다. 프로그래머는 자신이 개발 한 소프트웨어보다 읽기 쉽습니다. 일반적인 관리 팀은 실제 작업을 수행하는 대신 방해가되지 않도록 프로그래머가 이러한 작업을 읽기 쉽게하기 위해 제어하려고합니다. 그리고 그들은 잘못된 것을 측정하기 때문에 잘 작동하지 않습니다.

그럼에도 불구하고, 느슨하게 연결된 팀과 함께 먼 길을 갈 수 있습니다. Github의 개발 팀은 약 50 명의 직원을 보유하고 있으며 비즈니스 관리 교과서의 모든 규칙을 위반합니다. 그들은 잘하고있는 것 같습니다. 버그는 결국 수정됩니다. 기능이 추가됩니다. 화재가 발생합니다.

큰 적기가 무엇인지는 돈을 버는 방법을 찾지 않고 물건을 확장하려고하는 경우입니다. 그 시점에서, 당신은 당신의 미 투자 옵션과 보조금이 실제로 얼마나 가치가 있는지 궁금해 할 것입니다.

분명히 이것은 나쁜 생각입니다. 팀이 새로운 도구를 사용하는 법을 배워야하므로 생산성이 떨어질 수밖에 없습니다. 그럼에도 불구하고 그들은 이미 구워낸 도구만큼 효과적이지 않을 것 입니다.

다양한 도구를 직접 사용해 보았으므로 항상 "이런 느낌이 들었습니다.이 편집기는 <삽입 된 도구와의 버그 / 차이가 있습니다"라는 귀찮은 일입니다. 도덕적 단점이기도합니다.

물론 전체 팀이 동일한 도구를 사용하도록하는 전문가도 있습니다. 구성, skripts, 플러그인 및 모든 종류의 것들을 공유합니다. 다양한 도구 세트로는 불가능합니다.

반면에 ... 모든 사람이 자신이 선호하는 소프트웨어를 사용했다면 마지막 부분은 필요하지 않습니다. ;)

SublimeText2를 입력하는 동안 Eclipse를 "사용"할 수 있습니다.

즉, 프로젝트를 위해 Eclipse를 설치 및 구성하고 속도를 높이면 쌍 프로그래밍과 같이 편안하게 사용할 수 있습니다. 병렬 설정을 유지하는 데 과도한 시간이 걸리지 않고 자신을 차단하지 않는 한 커밋 한 코드를 입력하는 데 실제로 사용한 편집기를 신경 쓰지 않을 것입니다. 표준 개발 환경.

Git을 사용 중이고 브랜칭이 중단 된 경우 다른 편집기를 사용하지 않아도됩니다. 브랜치를 밀고 다른 개발자가 실제로 툴셋을 알아낼 수 없다면 다른 브랜치를 가져 와서 작동하게하십시오. 모든 사람이 동일한 편집기를 사용하도록 강요하는 것은 현명 해 보이지만 실제로는 운영 방식을 이해하지 못하는 일부 비즈니스 책임자의 지시처럼 들립니다.

관리 관점에서이 점을 생각하면 이들이이를 수행하는 이유는 법적 준수 때문입니다. 회사는 사용 된 모든 도구가 합법적으로 사용되도록하고 개발중인 제품을 방해하지 않도록 할 책임이 있습니다. (일부 편집자는 개인적 용도로는 무료이지만 다른 목적으로는 무료로 사용할 수 없습니다.) 모든 개발자가 사용할 수있는 모든 도구를 감사하는 것은 비용이 많이들 수 있습니다. 타임 라인이 빡빡한 프로젝트에서는 나중에 법률 담당자가 지시하는 프로젝트의 변경을 최소화하기 위해 어떤 도구 / 라이브러리 등이 사용되는지 신중하게 관리해야합니다.

보안 수준이 높은 프로젝트에서는 IDE가 임시 파일을 저장하는 위치와 세션간에 저장되는 정보에 대한 우려도 있습니다.

모두 Eclipse를 추천해야하는 이유에 따라 다릅니다. 모든 사람이 다르게 구성하여 개발자가 환경을 설정하는 데 문제가있는 경우 직선 자켓을 추천해야 할 이유가있을 수 있습니다. 그러나 모든 사람이 원하는 것을 사용하여 행복하고 생산적이라면, 창작 과정에 깊이 관여하는 것에 변화를 줄 이유가 거의 없습니다.

Eclipse는 편집기 그 이상입니다. 코드를 편집하기 위해 자주 사용하는 편집기를 계속 사용하고 소스 제어, 디버깅 및 회사가 규정 한 워크 플로우에서 원하는 다른 용도로 Eclipse를 사용할 수 있습니다.

마지막 단계-이 수준에서 프로세스를 시행한다는 것은 회사가 개발 팀을 확장하고 새로운 팀원의 생산성을 높일 수 있도록 특정 구조를 원한다는 것을 나타낼 수 있습니다. Rails (또는 Django)를 "선택된"프레임 워크로 생각하면 구조를 갖추면 새로운 응용 프로그램을보다 쉽게 ​​이해할 수 있습니다.

레드 플래그는 모든 개발자에게 단일 IDE / 편집기가 강요되는 것은 아니지만,이 결정, 특히 IDE / 편집기가 사용될 의사 결정은 모든 개발자가 수행 한 것은 아니며 아마도 그들!?!

확실히 개발자가 합의에 도달하는 것이 가장 좋을 것입니다. 특히 의사 결정에 가장 적합한 자격을 갖추고 있기 때문입니다 (최소한 편집자 / IDE). 합당한 이유가있을 수 있으며 의사 결정은 경영진의 선호도에 영향을 미치지 만 모든 개발자가 결정한 편집기 / IDE는 무엇입니까?

12 명의 개발자가 투표를하는 것은 쉬운 일입니다. 확실히 그렇게 할 시간이 충분했습니다! 어쨌든 결론은 어려울 것이며 결국 이클립스가 될 수도 있었지만 그 경우 요구 사항을 "적색 플래그"로 표시하는 것이 훨씬 더 논쟁의 여지가 있습니다.