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

23

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?

finrod
źródło
4
Problem, który często miałem ze środowiskami z edytorem mieszanym, to automatyczne formatowanie kodu i traktowanie takich rzeczy jak tabulatory. Dopóki wszystko będzie proste, nie będzie to miało większego znaczenia.
Michael Kohne

Odpowiedzi:

54

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 ...

Xavier Nodet
źródło
5
To właściwa odpowiedź.
31
Dodałbym, że jeśli oficjalny system kompilacji zależy od IDE, istnieje problem.
AProgrammer
4
Kiedy spędzasz dużo czasu na biurkach innych członków zespołu, może być denerwujące ustalenie ich konfiguracji, zanim możesz im pomóc.
Doug T.,
4
O MÓJ BOŻE!!! Wewnętrznie opracowane IDE ??? To przepis na katastrofę, taki jak wewnętrzny system śledzenia błędów.
Job
8
@ Job, pracuję w Microsoft, więc ściśle mówiąc VS jest również wewnętrznie opracowanym IDE. Używamy również wewnętrznie opracowanych systemów śledzenia błędów ... TFS i Product Studio :).
JSB
7

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.

Dszordan
źródło
7
Jeśli Twój zespół polega na wtyczce IDE do wszystkiego, co nie jest trywialne, masz już większe problemy.
HedgeMage
@HedgeMage Tylko sith zajmuje się absolutami. Np. Co jeśli projekt jest oparty na platformie Eclipse? Nie wiem, jaki jest obecny stan, ale kilka lat temu IntelliJ nie był w stanie przeprowadzić skomplikowanej weryfikacji i takich metadanych wtyczek Eclipse. Mieliśmy programistę w zespole, który nalegał na IntelliJ - niejednokrotnie sprawdzając uszkodzony kod.
Eugene
3

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.

Hamish Downer
źródło
2

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

segfault
źródło
2

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.
Bernard Dy
źródło
1

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.

Manoj R.
źródło
1
Mylisz standard formatowania kodu z użyciem IDE. Jeśli zdecydujesz się użyć 3 spacji dla poziomu wcięcia, możesz ustawić to w Visual Studio lub Emacs (wiem, używam ich obu). Inne problemy, takie jak różne zakończenia linii w systemach Windows, Mac i Unix, można rozwiązać za pomocą niestandardowych skryptów odprawy / wymeldowania, np. Jeśli OS == Windoze ...
SnoopDougieDoug
1

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.

Michael Durrant
źródło
0

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.

Gauraw
źródło
0

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!

compman
źródło
0

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.

Zoot
źródło
-2

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.

rfcoder89
źródło
-3

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 ..

gbn
źródło
Czy preferencje ludzi nie powinny mieć znaczenia w miejscu pracy? Czy preferencje to bzdury? Czy zadowolenie programistów nie jest korzyścią dla firmy? Przykro mi, ale to nie „kompiluje” mnie.
daramarak
@daramarak: Gdzie to przechodzi w arogancję lub jest prima donna, szczególnie w przypadku większych sklepów o korporacyjnym standardzie? Pamiętaj: nowi faceci wchodzący do nowej firmy mówią „chcemy tego”, to arogancja.
gbn
-6

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

Wyświetlana nazwa
źródło
IDE to tak naprawdę edytor. W żadnym wypadku edytor nie jest zależny od projektu. (Zdaję sobie sprawę, że ta odpowiedź mogła być sarkastyczna, jednak nie jest to miejsce na sarkazm)
Arafangion
IDE nie jest tak naprawdę edytorem, ponieważ nie używasz „Notepad.exe”. potrzebujesz dodatkowej pracy wykonanej przez IDE, a ide nie ma standardów, co utrudnia korzystanie z zewnętrznych zdolności. a jeśli weźmiesz pod uwagę, że edycja szesnastkowa jest po prostu „edytorem tekstu”, to kod nie jest tylko tekstem.
Wyświetl nazwę
IDE to tak naprawdę tylko edytor z wieloma innymi narzędziami, z których zdecydowaną większość można wywołać w wierszu poleceń.
Arafangion
nie mam tu ludzi. mówią, że wewnętrzny ide jest zły, a jednolity ide jest zły. więc ide powinien być jednolity dla wszystkich programistów, ale nie dla wszystkich programistów pracujących nad tym samym projektem. HUH ?! NIE DOSTAJĘ GO!
Nazwa wyświetlana
2
To tylko narzędzie. Każdy kompetentny programista powinien być w stanie odpowiednio wykorzystywać swoje narzędzia, a jeśli uważają, że inne IDE jest bardziej odpowiednie do tego, jak robią programowanie, powinni to zrobić.
Arafangion