Czy każdy członek zespołu powinien używać tego samego IDE? [Zamknięte]

Czy uważasz, że sensowne jest narzucenie, że każdy członek zespołu musi używać tego samego IDE?

Na przykład wszyscy inżynierowie, którzy są już w zespole, używają IDE X. Dwóch nowych inżynierów przychodzi i chce zamiast tego używać IDE Y, ponieważ używają tego od kilku lat.

Czy masz jakieś doświadczenie z zespołami „mieszanymi IDE”? Jeśli tak to co to jest?

Pod warunkiem, że „oficjalny” system kompilacji (używany przez serwery Continuous Build) jest taki sam dla wszystkich, nie widzę żadnego powodu, dla którego każdy członek zespołu nie mógłby wybrać narzędzi, których chce ...

Jeśli Twój zespół polega na niektórych wtyczkach dostępnych tylko dla określonych IDE, sensowne jest zjednoczenie wszystkich na tej samej platformie programistycznej. Łatwiej jest mi też pomóc komuś z problemem programistycznym, jeśli ma takie samo IDE jak ja, natomiast jeśli mam odczytać czyjś ekran z nieznanym interfejsem, potrwa to trochę dłużej.

Jednym minusem jest to, że podczas parowania nie można tak płynnie zamieniać klawiatury. Pomiędzy IDE głównego nurtu nie jest to prawdopodobnie duży problem, ale jeśli jedna osoba jest przyzwyczajona do Eclipse, a druga do vimów, nastąpi niedopasowanie. Użytkownik Eclipse może nie być w stanie używać vima, podczas gdy użytkownik vim (to ja;) spędza dużo czasu przeklinając pod nosem na straszną powolność korzystania z waniliowego Eclipse.

To powiedziawszy, nadal wolałbym używać vim. Pod warunkiem, że twoja para jest zadowolona z tego, że tylko jeden z was „jeździ” przez dłuższy czas, działa dobrze.

Wiem, że istnieją wtyczki, dzięki którym Eclipse działa jak vi, ale mówię o parowaniu tam, gdzie idę i siedzę z kimś, kto ma Eclipse, który mu się podoba, więc nie będą instalować tej wtyczki.

Nie miałoby żadnego sensu zmuszanie każdego dewelopera jądra Linuksa do używania tego samego IDE (lub używania dowolnego IDE).

Nie mam doświadczenia z mieszanymi IDE, chyba że policzysz komercyjne IDE z okazjonalnym uzupełnianiem przez edytor tekstowy „wielu IDE”, ale mogę wymyślić kilka zalet i wad.

Plusy

• Każdy programista może być najbardziej produktywny dzięki temu, co wie najlepiej
• Niektóre IDE mogą dawać przewagę nad innymi (jeden może być lepszy w refaktoryzacji, inny może być lepszy w dostarczaniu pomocy do kodowania, inni mogą być lepsi w integracji danych, cokolwiek). Zastosowanie mieszanki może pozwolić zespołowi na wykorzystanie tego.
• Będziesz miał trochę zabezpieczenia przed możliwością, że jedno z IDE przestanie działać.

Cons

• Problemy z licencjonowaniem. Jeśli w grę wchodzi wiele komercyjnych IDE, być może jest to droższe. Przynajmniej można śledzić więcej.
• Problemy z licencjonowaniem 2. Jeśli istnieją frameworki lub wtyczki licencjonowane przez IDE lub langauge, czy będzie to stanowić problem?
• Jak wspomniał Dszordan, niektóre wtyczki mogą nie być kompatybilne z różnymi IDE.
• Jeśli IDE mają komponenty do generowania kodu lub mechanizmy formatowania stylu, które działają inaczej, może to powodować pewne zamieszanie.

Istnieje powód, dla którego można to wymusić. Po prostu rozważ studio graficzne i emacs / vim. Podobnie jak w systemie Windows, studio wizualne doda dodatkowe na końcu linii. Ten problem z wyświetlaniem w emacs / vim. Problemem są także zakładki. Problem z nami polega na tym, że programiści pracują w systemie Linux, ale nasza architektura oprogramowania jest wygodna w studiu wizualnym. Kiedyś przeklina nas, mówiąc, że nie formatujemy poprawnie pliku. Ale kiedy odkrył, że dzieje się tak z powodu problemu z ustawieniem domyślnym, wszyscy zgodziliśmy się na ten sam format.
Jeśli ktoś zmusi mnie do użycia określonego IDE, nie będę się czuć źle. Cokolwiek będzie dobre dla zespołu, uszanuję to i odpowiednio pójdę na kompromis.

Dzisiejszy programista chce wybrać własne narzędzia.

Z czasem to się jednak zmieniło. 10 lub 15 lat temu w miejscach, w których pracowałem, nie było tak wielu wyborów. (tak, było wielu redaktorów, ale nie byli „wyborem”). Sklep, w którym pracowałem 15 lat temu, był bardzo „oldschoolowy” (nawet wtedy!), A vi była redaktorką. Bez wyboru. To było naprawdę przydatne, ponieważ po pierwszym miesiącu przekleństw i przekleństw naprawdę mi się podobało.

Obecnie istnieje wiele możliwości wyboru, a każda z nich ma wiele zalet.

Z mojego osobistego doświadczenia korzystałem z IDE - rubyMine - przez kilka lat, zanim przestawiłem „z powrotem” na vi (m). Zrobiłem to, ponieważ Ruby jest bardzo trudnym językiem do napisania IDE (pisanie kaczków i inne funkcje dynamiczne), w wyniku czego IDE zwykle działa wolno i / lub wymaga najnowszej, najszybszej maszyny.

Cóż, tak, mam trochę doświadczenia w tym zakresie, będąc częścią mieszanego zespołu Windows / Unix i C ++ / Javy. Myślę, że to nie jest problem, pod warunkiem, że albo wszyscy będą swobodnie pracować z innym IDE, albo nigdy nie będzie takiej sytuacji, że ktokolwiek, kto nie jest zaznajomiony z IDE Y, będzie musiał pracować nad drugim facetem (to jest facet z IDE Y ) system.

Jeśli wszyscy chcą, to dobrze, ale różni ludzie mogą chcieć używać różnych edytorów / IDE. Naprawdę nie chciałbym, żeby ludzie zmuszali mnie do korzystania z edytora innego niż mój preferowany, gdybym pracował z zespołem nad czymś dużym i wątpię, czy jestem sam. Ludzie mogą być najbardziej zadowoleni z sytuacji, jeśli nie zmusisz ich do korzystania z określonego edytora.

BTW, Emacs!

Nie sądzę, aby każdy musiał mieć „takie samo” IDE, ale byłoby miło, gdyby każdy miał „obsługiwane” IDE.

Na przykład, jeśli twoje IDE jest zintegrowane z procesem przeglądania kodu, jeśli chodzi o komentowanie i aktualizowanie kodu, wtedy sensowne byłoby, aby wszyscy byli na obsługiwanej platformie.

Jeśli Twoja firma korzysta ze środowiska współpracy, takiego jak Rational Team Concert, a jeden lub dwóch facetów chce używać nieobsługiwanego IDE (lub innej wersji), podczas gdy wszyscy inni używają kompatybilnych, życie może być trudne dla ludzi, którzy zdecydowali się być poza pętlą wsparcia.

U nas budujemy nasze projekty za pomocą Visual Studio. Jeśli chodzi o edycję tekstu, przełączam się na Emacsa. Twoja firma nie powinna się przejmować, dopóki praca jest wykonywana.

Brzmi trochę jak „użyliśmy tego w mojej starej pracy”. Cóż, nie są w dawnej pracy.

Jeśli nie wpływa to na łańcuch narzędzi lub wtyczki kontroli źródła, być może tak. Z drugiej strony, czy dwaj nowi ludzie mogą wykazać wyraźną korzyść? Czy użyli twojego IDE?

W przeciwnym razie nie mam cierpliwości do tych bzdur, chyba że jest na to dobry argument. Nie są w dawnej pracy: nie mogło być tak dobrze, gdyby chcieli odejść. Używałem innego IDE jako jedynego wyróżnienia w swojej starej pracy: jeśli tak, powinni STFU i byli wdzięczni ..

TAK! Egzekwuj singleton IDE.

Powoduje problemy, gdy zmienia się zależność projektu. jeśli ktoś wprowadzi nową zależność do projektu, wówczas każdy straci czas na wprowadzenie tej nowej zależności, a niektórzy mogą zawieść i marnować czas na ten proces. Ogromna strata czasu.

powinno być NAPRAWDĘ dobre uzasadnienie dodania innego IDE do zespołu, co oznacza, że ​​zaoszczędzony czas powinien przewyższyć czas poświęcony na migrację systemu do różnych IDE