Czy zamówienie firmy, aby przełączyć się na określone IDE, jest czerwoną flagą? [Zamknięte]

80

Niedawno dołączyłem do szybko rozwijającego się startupu. W ciągu ostatnich 3 miesięcy zespół programistów powiększył się z 4 do 12. Do tej pory byli bardzo otwarci na temat tego, co programiści wykonywali swoją pracę. W rzeczywistości jedną z rzeczy, które początkowo uważałem za atrakcyjne w firmie, jest to, że większość programistów używała Linuksa lub innego systemu operacyjnego, który według nich najlepiej pasował do ich wysiłków.

Teraz pojawiły się zamówienia, bez dyskusji, że wszyscy mają przejść na Eclipse. Świetny edytor. Wolę SublimeText2, ale to tylko mój osobisty gust.

Żeby było jasne: jesteśmy zespołem JS używającym Backbone, a Eclipse po prostu nie jest dobry w zrozumieniu kodu Backbone. Oznacza to, że osoby w zespole, które używają / good / IDE (PHP Storm), muszą wrócić do robienia wielu rzeczy typu szukaj-znajdź-och-czekaj-gdzie-był-ja-trzy-kroki-temu zamiast po prostu ctrl + kliknięcie i użycie wstecz / do przodu - prawdopodobnie zmniejsza produktywność o powiedzmy 15% i przyjemność o 50% ...

Czy to czerwona flaga? Wydaje się kapryśne i nieuzasadnione kontrolowanie, aby powiedzieć programistom (spoza MS), jakiego IDE lub zestawów narzędzi użyć, jeśli są już osiedleni i produktywni.

Justin Alexander
źródło
7
Jaki jest twój proces kompilacji? Co musi być na miejscu, aby wpisane znaki stały się kodem binarnym, aby przejść do klientów
22
To jest start-up. Jeśli kierownictwo jednostronnie podejmie decyzję, taką jak wpływ na rozwój, bez dyskusji, może to być poważna czerwona flaga niezależnie od tego, o co chodzi.
joshin4colours
29
Nie - istnieje wiele powodów, dla których warto wybrać jedno IDE: licencjonowanie, proces, ciągłość, spójność ...
Wonko the Sane
55
Rozwijająca się firma, która stara się wcześnie ustalić standard, jest inteligentna w mojej książce (bez względu na to, co to jest)! Umieść wszystkich na tej samej stronie i zdobądź wiedzę dzięki wspólnemu IDE. Następnie zespół staje się bardziej wydajny, ponieważ każdy może sobie pomóc i może łatwiej współdzielić kod, nie martwiąc się o szerokość tabulacji, kodowanie itp.
Yanick Girouard,
23
Eclipse to całe środowisko, a nie tylko edytor. Być może IT stwierdziło, że radzenie sobie z każdym specjalnym płatkiem śniegu w rozwijającej się firmie staje się ogromnym i uciążliwym zadaniem i chciał ustandaryzować. Być może w zarządzaniu ekosystemem Eclipse znajdzie się narzędzie, które wkrótce będzie potrzebne. Może 12 różnych edytorów automatycznego formatowania wkurzyło twoje repozytorium i spowodowało dodatkowe kompilacje. Prawdopodobnie nielicencjonowane narzędzia „z domu” do zarządzania zmartwieniami, które nie chcą zostać pozwane. Może jesteś nowym facetem, czy naprawdę spodziewasz się konsultacji w sprawie ogólnych decyzji dotyczących IT i rozwoju? To może być milion powodów, całkiem rozsądnych.
Patrick Hughes,

Odpowiedzi:

92

„Teraz rozkazy, bez dyskusji , spadły, że wszyscy mają przejść na Eclipse”.

Myślę, że to prawdziwa czerwona flaga. Twój zespół jest ekspertem w dziedzinie tworzenia oprogramowania i tym, na który ma wpływ decyzja, a mimo to nie powiedziałeś ani słowa w dyskusji, która doprowadziła do takiej kolejności?

To brzmi jak nadmierne zarządzanie przez spiczastych włosach szefów. Czy osoba / zespół podejmujący decyzję ma odpowiedni wgląd w tę decyzję?


Biorąc pod uwagę, że decydenci są wystarczająco wykwalifikowani do takiej decyzji, brak prośby o opinię zespołu programistów ma co najmniej dwa niedociągnięcia:

  • Zespół nie czuje się zaangażowany. Zaangażowanie zespołu powinno być priorytetem dla zarządzania. Nie chciałbym pracować jako programista gdzieś, gdzie moja opinia na temat tak centralnych zagadnień, jak IDE, nie jest wystarczająco ceniona, aby o nią prosić. Przyznaję, że pytanie o czyjąś opinię, a następnie podjęcie decyzji przeciwko niej może być gorsze, ale w takim przypadku oczekiwałbym solidnego uzasadnienia tej decyzji.

  • Kierownictwo, jakkolwiek doświadczone, nie działa w 100% przy opracowywaniu tego konkretnego kodu. Zakładając, że ludzie, którzy nie mają w ogóle interesującego wglądu, byliby naiwni. Oczywiście może być tak, że menedżerowie pomyśleli o wszystkim, co wymyślili twórcy, ale jedynym sposobem, aby się dowiedzieć, jest zapytanie.

Gauthier
źródło
9
Nonsens. To, że nie skonsultowano się z zespołem, nie oznacza, że ​​wyższe awanse nie mają pojęcia. Jest to interesujące, ponieważ nie jest programistą Java. Wiem, że Eclipse to IDE, którego można używać, ale nigdy nie słyszałem o ulubionych OP, dopóki go nie opublikował. Błędem byłoby pozwolić zespołowi na standaryzację na IDE, co jest rzadkie, co powoduje problemy z rekrutacją innych nowych programistów.
Andy,
5
Czy uważasz, że „wyższym kierownictwem” mogą być wyżsi programiści? Niektóre organizacje mają wiele warstw?
2
Zbyt dużo w to czytasz. Kierownictwo może mieć inne obawy, takie jak opcje wsparcia, i może sprowadzać się do czegoś, co było dość popularne przy rozsądnych kosztach wsparcia (mówię o incydentach z płatnym wsparciem). Jeśli tak jest, być może nie było innego wyboru, więc jaki sens ma pytanie do deweloperów? Czy próbowałeś nawet uzyskać niewielką liczbę (10–15) programistów, aby się na coś zgodzić? Istnieje powód, dla którego twierdzą, że porozumienie deweloperów jest jak gromadzenie kotów.
Andy,
3
@ Andy Hoarding koty jest łatwe (porozmawiaj z dowolnym spinsterem), usłyszenie ich to zupełnie inna sprawa. ; o)
JW01
3
@ JW01 Ahh, mam złe słowo. Ale czy to nie byłby stado? :-)
Andy,
63

Rozsądne jest, aby podczas wspólnej pracy nad wspólnym projektem mieć na każdym stanowisku roboczym wszystkie narzędzia do edycji / kompilacji / debugowania oprogramowania oraz że podstawowe narzędzia do wykonywania około 90% prac rozwojowych są znane wszystkim w drużyna. Ten cel jest trudniejszy do osiągnięcia, jeśli Twój zespół się powiększa, a każdy korzysta ze swojego ulubionego zestawu narzędzi - im więcej ludzi, tym więcej opinii. A praca administracyjna staje się łatwiejsza, jeśli nie pozwolisz, aby liczba narzędzi wzrosła więcej niż to konieczne.

Oczywiście, jeśli jeden programista nalega na użycie swojego ulubionego edytora, może to być w porządku, o ile może upewnić się, że źródło nie wygląda lub nie zachowuje się inaczej w głównym edytorze zespołu (w twoim przypadku Eclipse), więc jeśli programista B musi edytować źródło dev A, dev B nie powinien być zmuszony do nauki osobistego ulubionego edytora A, aby móc skutecznie zmieniać źródło. Ale uważaj, jeśli oba muszą od czasu do czasu współpracować przed tym samym wyświetlaczem (lub wykonać programowanie parami), rzeczy są często łatwiejsze, jeśli wybrany edytor jest dobrze znany przez oba.

Doc Doc Brown
źródło
2
Po pierwsze, rzadko zdarza się, że deweloper musi wprowadzać zmiany na czyimś komputerze. Zgadzam się z „im więcej ludzi, tym więcej opinii”, ale nie stanowi to problemu, chyba że ludzie będą próbowali narzucać opinie innym. Re źródło, wszystkie projekty powinny mieć automatyczny proces kompilacji jednym poleceniem. Tak długo, jak to działa, a kod jest zgodny z konwencjami, nie ma znaczenia, które osoby IDE używają. Większość IDE jest intuicyjna w prostych sprawach (każda z nich ma swoje zalety w przypadku bardziej złożonych zadań), więc programowanie par nie stanowi problemu. W przypadku pytań programista korzystający z IDE może odpowiedzieć.
Matthew Flaschen
Jeśli oboje znacie język, patrzenie na inny edytor naprawdę nie stanowi problemu. Niektóre składnie są wyróżniane w różny sposób, a nazwa pliku może znajdować się w innym miejscu, ale nie ma problemu, chyba że faktycznie używasz konfiguracji innego programisty.
Izkata,
30
Pracuję w google i w moim konkretnym zespole jedna osoba używa Eclipse na osobach używa intellij Używam Emacsa w trybie zła do emulacji Vima, a jedna osoba używa samego Vima. Współpracujemy dobrze, a różnice w narzędziach nie stanowią problemu. Pomaga to, że wszyscy używamy tego samego systemu kompilacji i mamy zestaw stylów do odczytu kodu, ale nie ma to nic wspólnego z wyborem edytora dla każdej osoby.
Jeremy Wall
@JeremyWall: jak powiedziałem, może być w porządku, jeśli kod źródłowy jest wyświetlany jednakowo we wszystkich używanych edytorach i nie programujesz zbyt wiele par.
Doc Brown
5
@JeremyWall: To, że Twój zespół programistów może tak działać, nie oznacza, że ​​wszystkie zespoły mogą tak działać, i tak naprawdę uważam, że zespół programistów Google jest poza normą.
James P. Wright
25

Dla programowania w parach dobrze jest, jeśli obie strony przed ekranem mają takie same umiejętności podczas korzystania z klawiatury. Miło jest również wiedzieć, że jeśli twój projekt ma specjalne potrzeby konfiguracyjne w IDE, to jest skonfigurowany w ten sam sposób dla wszystkich. Rozpoczęcie pracy z nowym programistą jest łatwiejsze, gdy narzędzia są takie same dla wszystkich.

Ale jeśli porównasz to z próbą bycia najbardziej skutecznym, to naprawdę nie jest tego warte

Espen Schulstad
źródło
7
+1 za zauważenie korzyści płynących z podobnych środowisk programistycznych podczas programowania w parach
jcmeloni
1
+1. Nie mogłem się więcej zgodzić. Praca z wieloma programistami, z których każdy ma własne preferowane narzędzia i sposoby kodowania, może być piekłem! Na przykład możesz wymusić miejsce na tabulatorach, określony rozmiar wcięcia i kodowanie UTF-8 dla wszystkich źródeł. Musiałem przejść przez to wcześniej w moim zespole i musieliśmy sprawić, aby wszyscy używali tego samego IDE na końcu dokładnie z powodów wymienionych powyżej. I tak każdy poważny programista nie musiałby długo spędzać na adaptacji do nowego IDE, więc nie widzę w tym żadnej szkody. Ułatwia także nowym członkom przyspieszenie, jeśli wszyscy używają tego samego narzędzia.
Yanick Girouard
@Yanick: Spacja nad tabulatorami, wielkość wcięcia, kodowanie ... Wszystkie tego rodzaju parametry muszą znajdować się w standardzie kodowania, którego muszą przestrzegać wszyscy programiści. Nie ma znaczenia, w jaki sposób chcą ich przestrzegać, prawda? Wymagania dotyczące formatowania powinny koncentrować się na poprawności wyniku, a nie na tym, jak się tam dostać. Jeśli deweloperzy muszą zmienić IDE, aby uzyskać prawidłowe formatowanie, nie nazwałbym ich „poważnymi programistami”, przepraszam, że jestem odważny.
Gauthier
18

Tak, to trochę czerwona flaga, że ​​kierownictwo uważa się za lepszego oceniania, z których narzędzi byłbyś bardziej wydajny niż jesteś.

matowy b
źródło
38
Silnie zależy od powodów, dla których IDE powinno być takie samo.
3
Nie jesteśmy pewni z pytania, kto podjął decyzję i dlaczego. Termin „bez dyskusji” może oznaczać, że nie uwzględnili nowego faceta.
mhoran_psprep
3
Nie mam przedstawiciela, aby głosować, ale nie zgadzam się z tą perspektywą. Nawet gdyby narzędzie zadeklarowane przez kierownictwo w rzeczywistości nie było najlepsze, byłoby lepsze niż brak standaryzacji. Najwyraźniej twórcy nie są w stanie podjąć decyzji, która opcja jest „najlepsza”, ponieważ wszyscy sami wybrali różne narzędzia. Głupio jest twierdzić, że różne narzędzia działają lepiej w różnych kontekstach, ponieważ większość z tych programistów i tak naprawdę nie stanie się biegła w wielu przypadkach.
FumbleFingers
4
„Oczywiste deweloperów nie są zdolne do podjęcia decyzji, o której jest«najlepszy», od lewej do własnych urządzeń oni wszyscy wybrani różne narzędzia” Oni wybierają najlepszą (najbardziej wydajne) narzędzie do siebie . Każdy ma inne doświadczenia i wzorce pracy. Wszyscy mogą mieć rację.
Matthew Flaschen
2
@Andy Thats nie jest tak naprawdę prawdą, jak pokazują spory między Vimem a Emacsem. Są to przede wszystkim edytory tekstu, a nie pełne IDE. Przyspieszenie w nowym środowisku może zająć lata .
Izkata,
14

To nie jest sama czerwona flaga.

Czasami kierownictwo musi podejmować decyzje . Wszelkie problemy wymagające standaryzacji na czymś należą do tej kategorii. Kiedyś pracowałem u klienta, który pozwalał na znoszenie standardów przez kilka lat, a oni mieli ponad 20 różnych narzędzi SCM. To, co zaczęło się jako niezależny wybór różnych zespołów programistów, przerodziło się w logistyczny koszmar, który poważnie utrudnił dzielenie się umiejętnościami i współpracę w zakresie kodu w całej organizacji. Zintegrowane kompilacje były ... eee ..... niezbyt zintegrowane ...

Co więcej, nie jest praktyczne ani konieczne konsultowanie się ze wszystkimi przy każdej decyzji . Zakres, w jakim należy to zrobić, zależy od kultury organizacji i znaczenia / złożoności decyzji. Zazwyczaj wybierasz jedną z tych opcji, które wymagają mniej konsultacji:

  1. Podejmij decyzję samodzielnie, jeśli masz wystarczającą wiedzę na temat zalet / wad i nie jest to wystarczająco ważna decyzja, aby wymagać szerokich konsultacji.
  2. Skonsultuj się z kilkoma kluczowymi osobami (prawdopodobnie najlepszymi programistami najlepiej wykwalifikowanymi do podjęcia decyzji).
  3. Podnieś fakt, że podejmujesz decyzję dla wszystkich, których może to dotyczyć (e-mail, spotkanie w ratuszu, spotkania zespołu). Powiedz, co uważasz za właściwą decyzję, ale że jesteś gotów to zmienić, jeśli pojawią się nowe dowody przeciwne. Poproś ludzi, aby wystąpili indywidualnie, jeśli mają jakieś ważne poglądy
  4. Poproś ludzi, aby utworzyli pod-zespół, aby przejrzał opcje i zalecił decyzję. Dobra opcja, jeśli jest to naprawdę bliskie połączenie, nie znasz odpowiedzi i chcesz, aby zaangażowani w nią byli zaangażowani w podejmowanie decyzji.

W przypadku narzędzi programistycznych (co jest potencjalnie kontrowersyjnym problemem) prawdopodobnie zrobiłbym 2, a następnie 3 lub 4. tzn. Zdecydowanie byłyby pewne osoby, z którymi osobiście nie rozmawiałbym w tej sprawie, ale z drugiej strony większość kluczowych osób miałoby szansę na udział w podejmowaniu decyzji.

Dla mnie prawdziwa czerwona flaga byłaby w pobliżu, jeśli masz wrażenie, że podjęto złą decyzję (zła == szkodzi firmie, a nie tylko wybranemu ulubionemu narzędziu). Jak reaguje kierownictwo, gdy podniesiesz ten problem:

  • Dobre zarządzanie wysłucha twoich argumentów, dziękuję szczerze za opinie i ponownie rozważę ich stanowisko w przypadku, gdy uzyskałeś nowe spostrzeżenia . Mogą nadal nie zgadzać się z tobą i mogą trzymać się swojej decyzji, ale docenią to, że podniosłeś ją wraz z tobą i uprzejmie powiesz, dlaczego trzymają się tej decyzji. Mogą nawet zmienić sposób, w jaki podejmują takie decyzje w przyszłości, a jeśli zrobisz dobre punkty, możesz umieścić cię na liście „inteligentnych ludzi do zapytania”.
  • Złe zarządzanie stanie się defensywne, powiedz, że „decyzja została podjęta” i inne takie taktyki, aby uniknąć zmierzenia się z faktem, że mogli oni podjąć złą decyzję. Mogą postrzegać cię jako „sprawcę problemów”. Cierpi firma, podobnie jak twoja wiara w zarządzanie. To jest prawdziwa czerwona flaga! Wyjdź, póki możesz!
mikera
źródło
6
Istnieje spora różnica między ide / edytorem a systemem SCM lub kompilacji. a ide / edytor jest do użytku osobistego i zwykle jest dostosowany do konkretnej osoby. System scm lub build jest używany przez wszystkich na całym świecie. Jedna z tych rzeczy wymaga scentralizowanego zarządzania, a druga zdecydowanie nie.
Jeremy Wall
2
Moja odpowiedź dotyczyła raczej kwestii zarządzania, a nie konkretnej decyzji dotyczącej IDE per se. Istnieje jednak wiele dobrych powodów, aby ujednolicić IDE (np. Umiejętności, szkolenie, koszty licencjonowania, wydajność programowania par, integracja z innymi narzędziami, ogólna jakość IDE, koszty wsparcia, łatwość wdrożenia). W niektórych kontekstach słuszna decyzja będzie standaryzacja - jesteś niepoprawny jeśli uważasz, że może zawsze być pozostawione do indywidualnego wyboru (nawet jeśli jest to właściwa decyzja w wielu sytuacji)
mikera
2
@Jeremy: Myślę, że twoja perspektywa jest idealna dla zespołu jednoosobowego lub małej grupy hakerów. Bardzo współczuję: jestem dokładnie taki sam dla moich osobistych projektów. Ale to podejście po prostu nie daje się skalować do większych kontekstów korporacyjnych. Preferowanie narzędzi jest w porządku, ale spodziewam się, że dobry profesjonalny programista będzie chętny do nauki i adaptacji narzędzi, które sprawią, że organizacja będzie najbardziej skuteczna jako całość.
mikera
3
Mój punkt widzenia podziela mój pracodawca Google, który z pewnością kwalifikuje się jako większy kontekst przedsiębiorstwa. Zgadzam się, że dobry profesjonalny programista powinien chętnie uczyć się i dostosowywać narzędzia, aby organizacja była jak najbardziej skuteczna jako całość. Nie zgadzam się, że ide lub redaktor mógłby kiedykolwiek należeć do tej kategorii.
Jeremy Wall
2
Fajna, świetna firma i masz szczęście pracować w miejscu, które jest w stanie działać jak wiele „małych grup hakerów” przy stosunkowo niezależnych projektach. Niestety, większość dużych przedsiębiorstw nie ma tego luksusu. Pomyśl o dużym banku, który musi zatrudnić i przeszkolić 100 koderów Java klasy podstawowej w Indiach, aby pracować nad utrzymaniem aplikacji call center. Zachęcanie ich do kreatywności i wybrania własnego przepływu pracy IDE / build po prostu nie zadziała.
mikera
12

Jeśli używasz maven lub czegoś podobnego, nie powinno mieć znaczenia, którego IDE używasz. Mogą istnieć przypadki, w których jeden jest powiązany z konkretnym IDE, takim jak eclipse, jeśli istnieją wtyczki, na których można polegać.

Myślę, że powinieneś mieć możliwość wyboru własnego IDE, IDE, w którym jesteś najbardziej produktywny. Jednakże, jak już powiedziałem, są przypadki, w których sensowne jest użycie standardowego IDE.

Jarle Hansen
źródło
na przykład. jeśli chcesz zrobić ADF, to JDeveloper jest naturalnym wyborem, wtyczki dla innych idów mogą nie mieć pełnej funkcjonalności.
Rohit Banga
11

Miałbym zainstalowane IDE „korporacyjne”, ale nadal większość pracy wykonywałbym w dowolnym IDE, jakie chciałem - to nie jest tak, że nikt nie może powiedzieć, jakiego IDE użyto do edycji pliku źródłowego.

Na froncie IDE vs. edytor ... dla prawie wszystkich języków zdecydowanie wolę IDE (IntelliJ), ponieważ jest o wiele więcej możliwości dla ciebie niż edytor. Są pewne rzeczy, dla których powracam do ST2 lub Emacsa, ale do codziennego kodowania, pomimo tego, jak bardzo lubię oba ST2 / Emacs, IDE prawie zawsze wygrywa.

Dave Newton
źródło
1
Kwestionuję twoje twierdzenie, że IDE może zrobić znacznie więcej niż redaktor. Są wyraźnie gorsze edytory, np. Nie zrobiłbyś poważnego rozwoju z nano lub gedit, ale mogę kodować szybciej w vimie niż ja, i przypuszczam, że większość innych potrafi w IDE. I choć nienawidzę bronić emacsa, jestem pewien, że doświadczony użytkownik emacsa jest szybszy w emacs również niż IDE.
Kevin
1
@Kevin Spór - już od dłuższego czasu korzystam z Emacsa i poprawiam się dzięki ST2 i po prostu nie ma porównania. Lepsze, bardziej zależne od kontekstu zakończenie, ściślejsza integracja debugowania, nie ma zbyt wielu rzeczy, za które dałbym skinienie edytorowi tekstu. Niektóre języki radzą sobie lepiej niż inne, na przykład, nie napisałbym Java w Emacsie prawie bez względu na wszystko, dla Ruby i Pythona mam około półtora, ale IntelliJ mnie przekonuje. Do faktycznej edycji tekstu , czy to kodu, czy nie, używam edytora.
Dave Newton
1
Wiem, że pytanie i większość odpowiedzi jest skierowana do świata Java, ale tutaj, w świecie Microsoft .NET, pomysł, że edytor może być lepszy niż główny program IDE (Visual Studio), jest całkowicie opóźniony. Nie zatrudniłbym programisty .NET, który nalegałby na używanie Notepad ++ nad Visual Studio.
Graham
11

Każdy zespół, w którym kiedykolwiek byłem, miał wiele IDE i edytorów: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - nigdy nie było problemu. Nigdy.

Dla mnie świadczy to o nieporozumieniu na wysokim szczeblu organizacji, co do tego, co naprawdę ma znaczenie. Ważne jest, aby pozwolić dobrym programistom robić to, co muszą, i korzystać z narzędzi, które zapewniają im najwygodniejszy komfort. Jednorodność IDE ma bardzo niewiele wspólnego z prawdziwą komunikacją, która zachodzi w podstawowych kwestiach dotyczących architektury obiektu, testowania jednostek, algorytmów itp.

Posiadanie tego samego IDE co następny facet oznacza po prostu, że oboje wiemy, jak przeglądać kod przy użyciu tych samych skrótów i jak konfigurowana jest nasza kompilacja / konfiguracja. Nic z tego nie będzie miało znaczenia, gdy mówimy o prawdziwych problemach z kodem.

Patrz, jest znośny, w zależności od innych czynników w firmie. Zawsze możesz użyć własnego preferowanego edytora do codziennych czynności. A może twoja grupa robi inne wspaniałe rzeczy, które tworzą wspaniałą kulturę. Ale obowiązkowe IDE to ogromny błąd IMO. Dla mnie, jeśli ja były rozmowy z firmą, a oni poinformował mnie, który byłem IDE wolno używać, chciałbym podziękować im grzecznie za ich czas.

Dave Sims
źródło
8

W naszym sklepie Ruby istnieje silna rekomendacja używania IDE, którą lubi większość zespołów (RubyMine), ponieważ wiemy, że spełnia swoje zadanie i możemy się uczyć skrótów itp.

Programiści mogą swobodnie korzystać z różnych IDE, ale wymagamy od nich posiadania solidnych umiejętności w tym edytorze, jeśli tak wybiorą. Jeśli widzimy, że ktoś stara się poruszać projektem lub edytować tekst w niestandardowym FooEdit, to dla niego jest to RubyMine.

triskweline
źródło
4

Jeśli programista jest ekspertem w danym środowisku IDE, powinien go użyć. Jeśli nie są ekspertami w żadnym IDE, prawdopodobnie istnieje jeden lub dwa, które są bardzo powszechne w twoim języku programowania lub w zespole, i prawdopodobnie ma sens, aby się go uczyli.

Bycie zmuszonym do standaryzacji na IDE brzmi jak okropny pomysł.

Matt Rogish
źródło
2

Powody, dla których firma wymusza na programistach określony edytor lub ogólnie oprogramowanie, powinny zostać zbadane. Paranoiczna część (może nie tego słowa, której szukam) uważa, że ​​do zaćmienia, do którego zainstalowania prosi deweloperów, można dodać śledzenie wydajności. O wiele mniej paranoiczne (znowu) sądzi się, że spędzili czas dodając narzędzia do budowania produktu do tego IDE, co znacznie ułatwiłoby, gdyby wszyscy nacisnęli ten sam przycisk, aby przetestować i zbudować swoją gałąź kodu.

W każdym razie próbuję powiedzieć, że jest to prawdopodobnie coś więcej niż zwykła biurokracja lub metoda na bałagan z głowami programistów.

Pykler
źródło
2

To jest masywna czerwona flaga. Każda firma ma kilka takich głupich pomysłów, ale jeśli nadal pojawiają się inne czerwone flagi, po prostu wyjdź.

wyprawiać
źródło
Nie zgadzać się. Wiele wielkich firm szybko podejmuje decyzje, a jeśli popełni błąd, posłuchaj opinii i powtórz. Nie tracą czasu na utknięcie w niekończących się konsultacjach przy każdej decyzji.
mikera
2

Łatwo jest zgubić motywację do podjęcia niektórych decyzji - szczególnie w przypadku szybko rozwijającego się zespołu. Motywacją do przejścia na Eclipse może być fakt, że większość programistów wydaje się tracić dużo czasu na samą konfigurację IDE i że wiedza na temat Twojej firmy jest ograniczona.

Po prostu przejdę do przejścia na Eclipse, co oznacza, że ​​powinieneś mieć konfigurację Eclipse na wypadek, gdyby była potrzebna, ale kontynuuj pracę w swoim ulubionym edytorze. (Może być konieczne stopniowe przejście do Eclipse, jeśli Twoja firma zacznie wdrażać fajne narzędzia w Eclipse).

Czerwona Flaga: Poczekałbym, zanim pojawi się jeszcze kilka takich irracjonalnych rozkazów.

Vineet
źródło
1

Start-up zazwyczaj stara się pozostać zwinnym wystarczająco długo, aby znaleźć zrównoważony model biznesowy. Po ustaleniu części dotyczącej pieniędzy zarząd przenosi się, aby zwiększyć skalę działalności. Zasadniczo wtedy wszyscy początkujący pracownicy technologiczni zaczynają odchodzić, ponieważ procesy inżynieryjne zostają zaostrzone.

Jak wiesz, nie wiesz, co właściwie zrobi kod, dopóki go nie uruchomisz. Turing udowodnił to we wczesnych dniach komputerów. Oznacza to, że nie ma czegoś takiego jak miarodajna miara produktywności, jeśli chodzi o pisanie oprogramowania. Jednak, aby kierownictwo wykonało swoje zadanie, wydajność musi być czytelna. Ponieważ nie możesz zmierzyć kodu (a ludzie próbowali - na przykład wiersze kodu), zmierzą to, co mogą zobaczyć. Programiści są bardziej czytelni niż oprogramowanie, które opracowują. Typowy zespół zarządzający próbuje kontrolować programistów, aby uczynić te rzeczy czytelnymi (zamiast wykonywać swoje prawdziwe zadania: zejść im z drogi). A ponieważ mierzą niewłaściwe rzeczy, nie działa to zbyt dobrze.

Powiedziawszy to, nadal możesz przejść długą drogę z luźno powiązanym zespołem. Zespół programistów Github ma około 50 osób i łamią wszelkie zasady zawarte w podręcznikach zarządzania biznesem. Wydaje się, że wszystko w porządku. Błędy zostaną naprawione (ostatecznie). Funkcje zostaną dodane. Pożary gasną.

Wielką czerwoną flagą jest to, że próbują zwiększyć skalę, nie wiedząc, jak zarabiać pieniądze. W tym momencie zastanawiasz się, ile naprawdę warte są twoje niezainwestowane opcje i granty.

Ho-Sheng Hsiao
źródło
Wydaje się to całkowicie niezwiązane z pytaniem. Czy chciałeś napisać gdzie indziej?
Daenyth
@ Daenyth Mam na myśli opublikowanie tego tutaj. Oryginalny nagłówek „Jedno IDE, by rządzić nimi wszystkimi?” nie miało nic wspólnego z akapitem wyjaśniającym. OP wydaje się pytać, czy zmuszenie do użycia IDE wskazuje czas na zwolnienie za kaucją z firmy.
Ho-Sheng Hsiao
1

Z pewnością to zły pomysł. Jest nieuniknione, że zespół będzie mniej produktywny, ponieważ będzie musiał nauczyć się korzystać z nowych narzędzi. I nawet wtedy nie będą tak skuteczne, jak w przypadku narzędzi, które już grokują .

Ponieważ sam próbowałem różnych narzędzi, zawsze miałem wrażenie, że „kurde, ten edytor denerwuje mnie <wstaw błąd / różnicę w stosunku do preferowanego narzędzia>”. Będzie to więc także moralna wada.

Ale oczywiście są też profesjonaliści, aby cały zespół korzystał z tych samych narzędzi. Udostępnianie konfiguracji, skryptów, wtyczek i innych tego typu rzeczy. Nie byłoby to możliwe przy różnorodności zestawów narzędzi.

Z drugiej strony… ten ostatni kawałek nie byłby konieczny, gdyby wszyscy korzystali z jego preferowanego oprogramowania. ;)

noxoc
źródło
0

Możesz „używać” Eclipse podczas pisania w SublimeText2.

Oznacza to, że Eclipse jest zainstalowany i skonfigurowany do twoich projektów i przyśpieszasz go, abyś był równie wygodny w użyciu, jeśli, powiedzmy, programowanie w parę. Nikt nie będzie (a przynajmniej nie powinien) dbać o to, jakiego edytora rzeczywiście użyłeś do wpisania kawałka kodu, pod warunkiem że utrzymanie równoległej konfiguracji nie zajmuje zbyt wiele czasu i nie odcinasz się od standardowe środowisko programistyczne.

Tiberiu Ana
źródło
0

Jeśli korzystasz z Git, a Twoje rozgałęzienia są wyłączone, nie powinieneś i tak używać innych edytorów. Możesz po prostu pchnąć gałąź i poprosić innego dewelopera, aby uruchomił ją, jeśli naprawdę nie jest w stanie zrozumieć twojego zestawu narzędzi. Zmuszanie wszystkich do korzystania z tego samego edytora brzmi jak zamówienie jakiegoś szefa firmy, który chce wyglądać elegancko, ale tak naprawdę nie rozumie, jak działacie.

tubbo
źródło
0

Jeśli myślisz o tym z punktu widzenia zarządzania, powodem tego może być zgodność z prawem. Firma jest odpowiedzialna za zapewnienie, że każde użyte narzędzie jest używane zgodnie z prawem, a także nie będzie obciążać opracowywanego produktu. (Niektóre edytory są bezpłatne do użytku osobistego, ale nie są bezpłatne do żadnych innych celów itp.) Audyt każdego narzędzia, z którego może chcieć korzystać każdy programista, może być kosztowny. Widziałem, że w projektach, w których terminy są napięte, zarządzanie będzie ostrożne w kwestii tego, które narzędzia / biblioteki / itp. Są używane w celu zminimalizowania zmian w późniejszym etapie projektu, które są kierowane przez osoby prawne.

W projektach o wyższym bezpieczeństwie istnieje również obawa, gdzie IDE przechowują pliki tymczasowe i jakie informacje są przechowywane między sesjami.

SammyO
źródło
0

Wszystko zależy od powodów, dla których muszą polecać Eclipse. Jeśli programiści mają problemy z konfiguracją swojego środowiska, ponieważ wszyscy organizują coś inaczej, może istnieć powód, aby polecić kaftan bezpieczeństwa. Jeśli jednak wszyscy byli szczęśliwi i produktywni, wykorzystując to, czego chcieli, nie ma powodu, aby wprowadzać zmiany w czymś tak głęboko zaangażowanym w proces twórczy.

Eclipse to znacznie więcej niż edytor - możesz nadal używać swojego ulubionego edytora do edytowania kodu i polegać na Eclipse do kontroli źródła, debugowania i wszystkiego innego, czego wymaga korporacyjny obieg pracy.

I ostatnia rzecz - proces egzekwowania na tym poziomie może wskazywać, że firma zamierza rozszerzyć zespół programistów i chce mieć pewną strukturę, aby nowi członkowie drużyny mogli szybciej uzyskać wydajność. Jeśli uważasz, że Railsy (lub Django) są „opiniotwórczym” środowiskiem, zorientujesz się, że struktura pomaga łatwiej zrozumieć nowe aplikacje.

wariat
źródło
0

Czerwona flaga to nie tyle, że na każdego programistę nakłada się jedno IDE / edytor, ale że ta decyzja, a zwłaszcza decyzja o tym, który IDE / edytor miał zostać zastosowany, nie została podjęta przez wszystkich programistów, a być może żaden z nich im!?!

Z pewnością najlepiej byłoby, gdyby programiści osiągnęli konsensus, szczególnie dlatego, że są najwyraźniej najlepiej wykwalifikowani do podjęcia decyzji (przynajmniej co do tego, który edytor / IDE). Może istnieć dobry powód, aby się dostosować i taka decyzja powinna uwzględniać preferencje kierownictwa, ale który redaktor / IDE powinien być decyzją wszystkich programistów.

Zdobycie 12 programistów, którzy oddadzą kilka głosów, byłoby łatwe. Z pewnością było wystarczająco dużo czasu, aby to zrobić! Wniosek byłby i tak bolesny dla niektórych, a może nawet skończyłby się Eclipse, ale oznaczenie wymogu jako „czerwonej flagi” w tym przypadku byłoby znacznie bardziej dyskusyjne.

ghbarratt
źródło