Pytanie:
Wspieranie programistów, którzy nalegają na używanie ich ulubionego języka
vavojediha
2019-07-11 22:00:21 UTC
view on stackexchange narkive permalink

Dołączyłem do zespołu około pięciu programistów tworzących witrynę internetową opartą na mikrousługach w sklepie, który kładzie nacisk na autonomię i naukę. Okazuje się jednak, że jeden z programistów pisze „swoje” fragmenty w swoim ulubionym nowym języku, X”.

Nie będę nazywać X, aby uniknąć religijnych kłótni, ale zamiast tego lista powodów, dla których jestem zaniepokojony:

  • X jest nowy, stosunkowo mało znany i wydaje się być bardziej ukierunkowany na pisanie narzędzi wiersza poleceń, a nie interfejsów API usług internetowych.
  • szybko ewoluuje - najwyraźniej podczas dokumentowania starszego kodu, niektóre podstawowe funkcje zostały usunięte, nie można było kompilować w nowszych wersjach, więc ponowne zaimplementowanie zajęło kilka dni.
  • wydaje się, że dotychczasowy stan wiedzy na temat tego, jak podejść do danego zadania w X-ach, jest niewielki. Nadchodzące żądanie ma dodać wyszukiwanie do punktów końcowych API. Nie ma pojęcia, jak się do tego zabrać, na szczęście przyznał, że każdy punkt końcowy jest zaimplementowany w inny sposób i „może przepisać całość”. Podoba mi się jego postawa „da się zrobić”, ale czy naprawdę tak należy podejść do kodu produkcyjnego?
  • inni programiści wyraźnie czują się nieswojo z X, pomimo kilku miesięcy ekspozycji. Widziałem problemy z witryną na żywo związane z wdrażaniem uszkodzonego kodu, gdy go nie było. Tak, potrzebna jest rozmowa na temat testowania, ale brak możliwości wykrycia błędów showstoppera w X jest czerwoną flagą
  • Zaczął dodawać wtyczki do innych usług, „aby były bardziej podobne do X”. Nie wiem jeszcze, co to oznacza.
  • itp. itd.

Jest miłą i przystępną osobą. Nie jest arogancki, kłótliwy ani nic w tym rodzaju. Po prostu naprawdę, naprawdę interesuje się X, wrzuca go do każdej rozmowy, w tym do osób nietechnicznych. Miło jest widzieć, że jest pasjonatem, ale graniczy to z obsesją.

Jestem jego nowym przełożonym i martwię się zarówno o niski numer autobusu, jak i przejrzyste codzienne ryzyko z powodu kruchych, trudnych do zrozumienia torebek X.

Chociaż mógłbym poprosić go, aby przestał używać X, to najwyraźniej nie poszłoby dobrze, a poza tym chcę, aby mój zespół był autonomiczny i szczęśliwy, budując ich, a nie wyłączając. I tak, rezerwuję czas, aby dowiedzieć się, czego X potrafię. Może zobaczę światło i pomogę mu w ten sposób.

Jak poradzić sobie z ryzykiem dla projektu przedstawionego przez X? Czy sam X w ogóle jest problemem?

Kto jest liderem zespołu?
Na ile to warte, myślę, że absolutnie ** genialne ** to, że język nie jest określony w tym pytaniu, ponieważ tak naprawdę nie ma znaczenia dla udzielenia odpowiedzi.
@ventsyv nazwanie danego języka sprawiłoby, że odpowiedzi byłyby mniej przydatne, a nie bardziej przydatne, a * także * generowałyby dodatkową pracę dla moderatorów.Jedyna wygrana byłaby w umyśle ludzi, którzy mają okazję argumentować za / przeciw własnemu ukochanemu / znienawidzonemu X. Lepiej pozostawić to anonimowe.+1 do pytania o tę zachwycającą innowację.
Czy zapytałeś innych programistów, czy im się to nie podoba?
Kiedy mówisz, że używa X do rozwiązywania „swoich części” aplikacji, czy reprezentuje to całą warstwę aplikacji, czy też są to fragmenty jednej lub więcej warstw?Na przykład, jeśli pisze usługi REST w X, czy _wszystkie_ usługi REST są napisane w X, czy też niektóre z nich są napisane w innym języku (językach)?
Teraz, gdy to pytanie ma akceptowaną odpowiedź i przyciąga kilka dobrych odpowiedzi i komentarzy, czy nauczymy się, jakim językiem jest ** X **?
Piętnaście odpowiedzi:
#1
+138
ventsyv
2019-07-11 22:11:21 UTC
view on stackexchange narkive permalink

Proponuję poddać pytanie do dyskusji zespołowi. Przedstaw swoje obawy na następnym spotkaniu zespołu i zapytaj, co o nich myślą.

Ponieważ brzmią jak uzasadnione obawy, wyobrażam sobie, że otrzymasz wsparcie od innych programistów.

Upewnij się, że dyskusja będzie profesjonalna i zachowaj otwarty umysł. Skoncentruj się na tym, jak użycie X wpływa na resztę zespołu. W ten sposób deweloper będzie mniej skłonny do obrony, a kiedy zda sobie sprawę, jak jego użycie X wpływa na resztę zespołu, będzie mu bardzo trudno po prostu odrzucić ich obawy.

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/96213/discussion-on-answer-by-ventsyv-supporting-developers-who-insist-on-using-their).
#2
+92
Neo
2019-07-11 22:17:21 UTC
view on stackexchange narkive permalink

Jak poradzić sobie z ryzykiem związanym z projektem przedstawionym przez X?

Aby rozwiązać ten problem, użyję Twoich własnych słów:

ewoluuje szybko / niestabilnie - podczas dokumentowania starszego kodu stwierdził, że niektóre podstawowe funkcje zostały usunięte, nie można ich kompilować w nowszych wersjach, więc ponowne wdrożenie zajęło kilka dni

ORAZ

pozostali deweloperzy wyraźnie nie lubią X, mimo kilku miesięcy ekspozycji. Widziałem problemy z witryną na żywo związane z wdrażaniem uszkodzonego kodu, gdy go nie było. Tak, potrzebna jest rozmowa na temat testowania, ale brak możliwości wykrycia błędów showstoppera w X jest czerwoną flagą

Ten język jest oczywiście niezbyt dojrzały . Budowanie swojego imperium na ruchomych piaskach nie jest dobrym planem i myślę, że o tym wiesz. Jako menedżer do Ciebie należy zarządzanie ryzykiem i wyznaczanie standardów .

Czy sam X w ogóle jest problemem?

Myślę, że problem może polegać na tym, że nie ma określonych standardów w Twojej grupie . Sugerowałbym, abyście wraz ze swoim zespołem uzgodnili, jakie języki będą używane, a następnie pójdą dalej.

Wszelkie nowe technologie powinny zostać zaprezentowane zespołowi zanim zostaną użyte w produkcji . Gdy prezentowana jest nowa technologia, zespół głosuje nad jej ważnością. W ten sposób nie ma ani jednego złego gościa, który powinien zostać odrzucony w głosowaniu.

Poza tym, co jest dla ciebie naprawdę ważne: musisz być w stanie wspierać kod, gdy programista odchodzi. Jeśli pozwolisz na jednorazowe, stanie się to dla ciebie trudniejsze. Możesz również zechcieć zbadać popularność i użycia tych języków, aby upewnić się, że w odpowiednim czasie możesz zatrudnić nową pomoc.

Amen do tego.Nie można powiedzieć, czy X jest „problemem”, czy nie, bez określenia, co stanowi sukces.Jedną z najważniejszych równowagi w prowadzeniu sklepu z oprogramowaniem jest zapewnienie programistom swobody robienia rzeczy w sposób, który * uważają * za najlepszy, z uwzględnieniem robienia rzeczy * najlepszych dla firmy * pod względem zrównoważonego rozwoju.Najlepiej, gdy możesz połączyć te dwa cele, a posiadanie dobrych standardów jest sposobem na osiągnięcie tego.
Przy okazji, znajomość X do przyszłego zatrudnienia i pokazanie, że używasz X, jest bardzo ważnym atrakcyjnym punktem dla większości przyszłych programistów (najlepszych, tych, których chcesz zatrudnić).Dlatego wiele renomowanych firm pozwala na niewielkie użycie dziwnych języków.BTW, większość firm używa [`make`] (https://en.wikipedia.org/wiki/Make_ (oprogramowanie)), ale kilka atrakcyjnych używa [ninja] (http://ninja-build.org/)dla prawie * tej samej * roli.
Zgoda.Wszystkie * odnoszące sukcesy * firmy, z którymi współpracowałem, ustandaryzowały języki (i ogólnie standardy kodowania, aby każdy kod wyglądał podobnie).Najważniejszą częścią oprogramowania nie jest zmuszanie go do tego, co robi na początku, ale upewnienie się, że można go rozsądnie utrzymywać w przyszłości (co może nie być przez Ciebie!).
@BasileStarynkevitch "Znajomość X do przyszłego zatrudnienia i pokazanie, że używasz X jest bardzo ważnym atrakcyjnym punktem dla większości przyszłych programistów (najlepszych, tych, których chcesz zatrudnić)" Ech ?!Nie jestem pewien, jak możesz to twierdzić, nie wiedząc, czym jest X.W każdym razie wydaje mi się, że nie znam wielu dobrych programistów, którzy aktywnie poszukują ról pracujących z dziwnymi, ezoterycznymi językami.Zwykle wręcz przeciwnie.
Deweloperzy mogą wybierać technologie są świetne i wszystko, ale tylko do pewnego momentu.I jednym z tych punktów jest to, że nie pozwolimy każdemu facetowi na samodzielne umieszczenie w silosie.Nie tylko dlatego, że inni ludzie będą musieli przeglądać i utrzymywać ten kod, ale Twoi administratorzy / operatorzy / pracownicy bezpieczeństwa absolutnie wolą nie mieć kolejnej technologii do utrzymania i śledzenia.
„Aby rozwiązać ten problem, użyję twoich własnych słów” + „Ten język jest oczywiście niezbyt dojrzały” - przeczytałem to i pomyślałem, że obrzucasz OP, zanim zdałem sobie sprawę, że językiem, który miałeś na myśli, było „X”, a nie ich angielski...
To jest odpowiedź, z którą najbardziej się zgadzam.Stwierdziłbym, że autonomia nie oznacza całkowitej swobody podejmowania wszystkich decyzji.Firma, a nawet Ty jako kierownik tego zespołu, możesz i powinieneś podejmować zgrubne decyzje ramowe.To, co programiści robią w tych ramach, może być autonomiczne, ale jeśli ostatecznym celem jest wyprodukowanie jakiegoś elementu, czy to sprzętowego, czy programowego, czy to rzeczywistego, czy wirtualnego, wtedy _ wszystko_, co potencjalnie zakłóci przepływ gotówki, co w najlepszym przypadku, zwolnienia i redukcje etatów.Zawsze, zawsze, zawsze ... pamiętaj o tym cholernym autobusie seryjnego mordercy ...
#3
+70
berry120
2019-07-12 00:46:14 UTC
view on stackexchange narkive permalink

Byłbym bardzo, bardzo zaniepokojony tym.

Jeśli jutro zostanie potrącony przez autobus lub zdecyduje się wyjechać jutro, to obecnie masz:

  • Ogromny koszt, zarówno pod względem czasu, jak i pieniędzy, znalezienia eksperta w X, który go zastąpi;
  • Zespół, który nie rozumie żadnego napisanego przez siebie kodu;
  • Zespół, który nie może niezawodnie nawet wdrożyć żadnego napisanego przez siebie kodu;
  • Kod, który prawdopodobnie będzie działał tylko z określoną, nieznaną wersją X i zerwij z przyszłymi wersjami.

Wtedy twoi przełożeni będą spadać na ciebie jak tona cegieł, pytając, dlaczego, do diabła, pozwoliłeś na to w ogóle.

Mówisz, że jest miłym facetem - po prostu zbyt entuzjastycznym, więc przedstawiłbym te problemy jemu i całemu zespołowi w ogóle. Poproś o przemyślenia na temat rozwiązań. Podkreśl, że to nie jest kara ani nic złego, tylko potencjalny problem, który wszyscy musicie rozwiązać. Podkreśl, że nie jest to problem związany z językiem , ale z biznesem . Upewnij się, że jesteś otwarty na krytykę, jeśli twoje zrozumienie któregokolwiek z powyższych punktów jest niepoprawne, ale jeśli nie, musisz stanąć na swoim miejscu, upewniając się, że:

  • Nie jest napisany żaden nowy kod X;
  • Najlepiej, jeśli masz długoterminowy plan migracji istniejącego kodu, który został napisany w X, do innego języka.

To nie znaczy, że nie powinien odegrał kluczową rolę w wyborze innego , bardziej odpowiedniego języka, którego można użyć, a to nie znaczy, że musi całkowicie porzucić X. Być może mógłbyś zorganizować warsztaty lub prezentacje, w których demonstruje nowe wzorce / paradygmaty w X i jak można je zastosować (odpowiedni język w miejscu pracy). Być może mógłby poszukać innego języka, który jest bardziej powszechny, ale ma więcej właściwości X.

Jednak gdybym był szefem zespołu, z pewnością nie ustąpiłbym, jeśli chodzi o pozwolenie na użycie takiego języka w kontekście krytycznym dla biznesu.

Pamiętaj, że [współczynnik autobusowy] (https://en.wikipedia.org/wiki/Bus_factor) jest powszechną analogią do oceny ryzyka, użytkownik nie stara się być dramatyczny.
@TravisClark Ciekawostka;łącze, które masz, prowadzi do strony, na której zdjęcie Wikimedia opisane jako „Autobus czekający na przejściu dla pieszych w Limie” jest opatrzone podpisem „Osoba w niebezpieczeństwie potrącenia przez autobus”.Porozmawiaj o szklance do połowy pustej / do połowy pełnej!
Rozwiązanie dla określonej wersji X: „Sprawdź kompilator pod kątem kontroli źródła”
#4
+43
R.. GitHub STOP HELPING ICE
2019-07-12 07:30:22 UTC
view on stackexchange narkive permalink

Trudno nie.

Wprowadzanie do projektu języków dla zwierząt domowych, a nawet nadmierna ich liczba sprawia, że ​​jest on całkowicie nie do utrzymania na dłuższą metę. Kiedy programista odejdzie, otrzymasz kod w swoim ulubionym języku, niezależnie od statusu, w jakim go zostawili, oraz stos obejść w innych komponentach, aby załatwić sprawy bez konieczności zmiany kodu, którego nikt nie rozumie. Mówię z doświadczenia o projektach, w których to się stało.

Ten zespół / projekt / firma oczywiście albo ma nieograniczone zasoby, albo szybko umrze.
#5
+39
200_success
2019-07-12 07:34:40 UTC
view on stackexchange narkive permalink

Absolutnie nie! Całe firmy zginęły, ponieważ wybrały niewłaściwy język, w którym napisały swoją bazę kodów. Jeśli język umiera, staje się niepopularny lub prowadzi do trudnych do rozwiązania problemów ze skalowalnością, kod również umiera. Czy możesz sobie pozwolić na przepisanie go?

Kiedy musisz całkowicie przepisać kawałek oprogramowania w innym języku, będziesz siedzącą kaczką, ponieważ nie możesz wypuścić nowego produktu, dopóki nie nadejdzie funkcja przepisywania zgodność ze starym produktem. Jeśli możesz uniknąć przepisywania, powinieneś!.

Studia przypadków:

  • Twitter cierpiał z powodu częstych „niepowodzeń wielorybów” i ostatecznie przepisał serwer Ruby on Rails.
  • WordPerfect został zniszczony przez Microsoft Word. Chociaż istnieje wiele biznesowych powodów ich upadku, część ich problemu polegała na tym, że duża część kodu została napisana w języku asemblera, co utrudniało przeniesienie go do systemu Windows.
  • John Ousterhout , który wynalazł język Tcl, założył Ajuba Solutions, firmę, której oprogramowanie zostało napisane głównie w Tcl. Chociaż technicznie nie było nic złego w Tcl, po prostu nie było tak popularne. Jego firma miała kilku utalentowanych i oddanych programistów Tcl, ale trudno było ją zatrudnić. Ostatecznie firma została przejęta, baza kodu została porzucona, a większość programistów straciła zainteresowanie pracą po przejęciu.

Żaden pojedynczy język programowania nie jest doskonały we wszystkim, a Ty chcesz, aby programiści aby móc wybrać odpowiednie narzędzie do pracy. To powiedziawszy, muszą istnieć pewne ograniczenia przy wprowadzaniu języków do bazy kodu Twojej firmy. Niektóre kryteria do rozważenia:

  • Wystarczająca liczba członków zespołu musi biegle władać językiem, aby możliwe było przeglądy kodu i wielu opiekunów.
  • Musisz umieć zatrudniać programistów chętnych do pracy w języku i jego ekosystemie. (I musisz być w stanie tolerować rodzaje programistów, którzy skłaniają się ku tym językom.)
  • Język powinien być na tyle wszechstronny, aby inwestycja była opłacalna.
  • Należy rozpoznać i zaakceptować ryzyko związane z językiem (np. częste niezgodne zmiany, częste luki w zabezpieczeniach, jakość standardowej biblioteki, skalowalność , bezpieczeństwo pamięci, czytelność, strategie obsługi błędów, nieintuicyjne zachowanie itp.)

Czasami mogą istnieć czynniki łagodzące ryzyko wyboru bardziej niejasnego języka. Na przykład język może współdziałać z innymi językami na wirtualnej maszynie języka Java lub w programie Microsoft Common Language Runtime. Lub język (np.Swift) może być zaprojektowany do współpracy z innym (Objective-C). Interoperacyjność zapewnia przynajmniej ścieżkę migracji, która nie pozostawia cię bez oporu podczas przepisywania.

Możesz rozważyć zapewnienie większej elastyczności dla kodu jednorazowego użytku lub kodu prototypowego. Czasami możliwość szybkiego prototypowania jest ważniejsza niż długoterminowe problemy wymienione powyżej. Uważaj jednak, ponieważ prototypy mogą mieć tendencję do przekształcania się w trwałe rozwiązania.

W swoim konkretnym przypadku powiedziałeś, że masz witrynę internetową opartą na mikrousługach, której części są zaimplementowane w innym języku. Nawet jeśli nie stawiasz przyszłości swojej firmy na język X , niepotrzebne mieszanie języków implementacji jest szkodliwe dla budowania spójnej architektury. ( Fakt, że jeden deweloper ma całkowitą swobodę panowania nad jedną częścią projektu, jest sygnałem ostrzegawczym o braku projektu architektonicznego w Twojej firmie. ) Konieczność nauki języka nie jest jedyną barierą; zwiększa również złożoność narzędzi do tworzenia, tworzenia, analizy statycznej, testowania i wdrażania. Jest też więcej bibliotek, które będziesz musiał załatać w przyszłości. Wspomniał Pan również, że język wprowadza od czasu do czasu niekompatybilne zmiany, co wskazuje, że jest to oprogramowanie o eksperymentalnej jakości , a nie produkcyjnej. Jeśli cały zespół ponosi te koszty tylko z powodu osobistych preferencji jednego programisty, wszyscy będą urażać tego programistę, potajemnie lub otwarcie.

Ogólnie rzecz biorąc, wybór języka programowania (lub frameworki programistyczne) muszą być decyzją zespołu i nie powinny być podejmowane przez jednego samotnego wilka lub programistę gwiazdy rocka. Wygląda na to, że Twój zespół nie czuje się dobrze z językiem X , a sentyment grupy powinien być dobrym powodem, aby wymagać od niezależnego programisty zaprzestania jego używania.

Myślę, że większość głosów to dobry sposób.Jednak ludzie nadal muszą nauczyć się konwencji kodowania i idiomów przed rozpoczęciem pracy z jakimkolwiek językiem, a jedynym sposobem na upewnienie się, że ludzie piszą kod idiomatyczny, są przeglądy kodu.
`Uważaj jednak, że prototypy mogą mieć tendencję do przekształcania się w trwałe rozwiązania. 'Absolutne +1 ode mnie - zbudowałem system" prototypowy "w VB3 (wiem, wiem) dla dużej firmy z londyńskiego City.koncepcji i ostatecznie trafił do produkcji.Ostatecznie skorzystało z niego 4500 osób.Wciąż drżę do dziś.
Word celowo początkowo celował w WordPerfect i miał Exchange, aby wykorzystać pakiet Office.
#6
+15
Abigail
2019-07-11 23:00:01 UTC
view on stackexchange narkive permalink

To jedna z niewielu rzeczy, w których myślę, że menedżer powinien postawić nogę i się nie poddawać. To, co robi programista, na dłuższą metę zaszkodzi firmie. I nie ma znaczenia, czym jest X - liczy się tylko to, że Twoja firma nie ma dużego doświadczenia w X i trudno będzie przyciągnąć ekspertyzę w X.

Twój programista się myli że X jest właściwym rozwiązaniem. Nie dlatego, że jest to niewłaściwy język dla projektu, jest to niewłaściwy język dla firmy .

Powiedz swojemu programistowi, że jego działania nie są działaniami starszego programisty, a nawet poniżej oczekiwania dla zwykłego programisty. Wyjaśnij, że jego działania nie będą dobrze widoczne w jego następnej ocenie wydajności, a jeśli będzie kontynuował w ten sposób, czy wpłynie to na jego szanse na awans i bonusy.

Powiedz mu, że oczekujesz od programistów działaj jak najlepiej dla firmy i pracuj nad produktem, od którego oczekuje się, że będzie rozwijany i utrzymywany przez długi czas, a nie tylko przez niego. Każdy obecny i przyszły programista powinien mieć możliwość pracy nad produktem, bez konieczności uczenia się wcześniej innego języka. Powiedz mu, że spodziewasz się, że dobry deweloper rozważy, jaka będzie sytuacja w przyszłym roku, za pięć i dziesięć lat. I że dzisiejsze decyzje wpłyną na przyszłość.

Innymi słowy, powiedz mu, żeby zostawił dumę za drzwiami i został graczem zespołowym.

Takie podejście jest niezwykle uciążliwe i może wywołać urazę w zespole, w którym ceniona jest współpraca i współpraca oraz kreatywność.Są chwile, kiedy pracownika powinno się zachęcać do „robienia swoich rzeczy”, i takie, kiedy trzeba powiedzieć pracownikom, żeby trzymali się linii.Ponieważ nie było to sprzeczne z zasadami zespołu, menedżer musi przyjąć bardziej delikatne podejście.
Jak powiedziałem w innym miejscu, to jest praca, a nie szkoła Montessori dla dorosłych.To powiedziawszy, zgadzam się z tobą i Julie w Austin.Jest oczywiste, że deweloper musi przestać traktować X jako odpowiedź na wszystkie problemy, ale sposób dostarczania wiadomości ma znaczenie.Cięższa ręka może stać się konieczna, jeśli całkowicie odmówi wykonywania swojej pracy (tj.Oczekuje, że praca będzie jego osobistym placem zabaw), ale nie musi to być dźwięk wychodzący z bramki.
Ta odpowiedź jest zabawna, bo mówi o działaniu w najlepszym interesie firmy, ale gdyby OP miał tak przemówić do dewelopera, to prawdopodobnie firma by na tym ucierpiała.Bycie częścią lidera to szkolenie podwładnych w tym, co ważne.Podczas gdy łatwość konserwacji może być oczywistym problemem dla niektórych, dla innych po prostu nie rejestruje się na radarze.
#7
+10
J. Chris Compton
2019-07-12 19:14:20 UTC
view on stackexchange narkive permalink

Czy sam X jest problemem?

Nie.

X nie jest problemem ... dla każdej wartości X

To jest problem zarządzania. Jako nowy menedżer trafiłeś w trudny okres.

Problem w tym, że

  1. masz bardzo entuzjastycznego programistę, którego chciałbyś
    przekierować w bardziej produktywnego pracownika.
  2. Podejrzewasz, że jeśli powiesz mu, że nie może używać X , będziesz musiał go zastąpić, ponieważ odejdzie
    Opowiada o X osobom nietechnicznym, więc masz rację (obecnie jest to dla niego religijne )

Wyjaśnij, jak działa świat:

Jako nowy menedżer Uwielbiam pozwalać ludziom korzystać z tego, co ich pasjonuje. W Twoim przypadku jest to X .

Problem polega na tym, że gdy coś się psuje, jesteśmy źle oceniani. To słabo odbija się na całym zespole .
Kilka razy kompilacja się zepsuła , kiedy cię tu nie było. Próbuję się nauczyć X , żeby móc do Ciebie dołączyć. Chociaż jest to interesujące, nie mogę teraz poświęcić temu wystarczająco dużo czasu.

Jak możemy zachować X bez sprawiania, że ​​wszyscy wyglądają źle?

Ponieważ nie ma ustalonego zestawu najlepszych praktyk za to, co robimy, nie możemy ujednolicić języka tak nowego jak X. Dlatego mieliśmy z nim problemy, mimo że jesteś w tym ekspertem.

Więc ... jak to rozwiązujemy w perspektywie krótkoterminowej?
Czy są bardziej stabilne kompilacje, których można użyć? Jak możemy się upewnić, że nic się nie zepsuje i nikt inny nie musi przerywać tego, co robią, aby się uczyć X?

Zmiana „ kompilacja się zepsuła ”do najbardziej oczywistego problemu spowodowanego obecnością X .

Daj mu czas na odpowiedź. Jeśli nie odpowie zbyt wiele, pozwól mu wrócić do swojego biurka (powtórz pytanie, zanim pójdzie, aby skupić się na tym, „jak”).

Jak właśnie wyjaśniłem przy innej odpowiedzi, rozwiązaniem radzenia sobie z szybko zmieniającym się kompilatorem jest „sprawdzenie kompilatora pod kątem kontroli źródła”.
#8
+8
Josiah
2019-07-12 12:15:35 UTC
view on stackexchange narkive permalink

Jak powiedzieli inni, ta sytuacja nie powinna trwać dalej. Rzeczywiście brzmi to tak, jakby podstawowa odpowiedź miała postać „Nie, przepraszam, nie możesz użyć X”. I masz pełne prawo to powiedzieć. Twój najgorszy scenariusz jest taki, że ten deweloper się zdenerwuje i zrezygnuje. Byłoby to smutne, ale jest to przesadne, a twoja odpowiedź prawdopodobnie nadal powinna brzmieć „Nie X”.

Oprócz problemów już zidentyfikowanych, jeden programista zaczął samodzielnie posługiwać się ulubionym językiem

  • uniemożliwia efektywne przeglądanie kodu
  • utrudnia współdziałanie z pracą innych programistów
  • wymaga duplikowania kodu dla wszystkich popularnych narzędzi używanych przez X i nie-X ( szczególnie te, które są wykonane na zamówienie i nie znajdują się w standardowej bibliotece X)
  • Zmniejsza spójność zespołu, szczególnie między frakcjami X i nie-X.

Być może bardziej pomocna odpowiedź niż zwykłe powiedzenie „Nie X” w sposób kłótliwy jest

  • Zapytaj, co w szczególności w X jest pożądane. Jeśli są autentyczne, zbadaj, czy niektóre z tych zalet można by wykorzystać w bardziej standardowym języku. (Zdziwiłbyś się, jak wiele modnych funkcji trafia do nowych wersji starych języków, takich jak C ++ i Java, lub przynajmniej korzysta z obsługi bibliotek innych firm)
  • Zaproś danego programistę, aby przejął inicjatywę ( choć nie bez nadzoru) w rozwijaniu przydatnych lekcji, których można się nauczyć od X i przenoszeniu ich do najlepszych praktyk Y.
  • Zbierz trochę danych, aby obronić swój punkt widzenia. Na przykład. Pomocne może być stwierdzenie: „Spędziliśmy już _% czasu programistycznego X zajmując się niestabilnością X, w porównaniu z _% przy aktualizowaniu zmian w Y” lub „Integracja i debugowanie kodu X zmniejszyło wydajność zespół ogółem o _%.
  • Zastanów się, czy istnieją inne przyczyny tego problemu niż preferencje językowe. Na przykład, jeśli ujawni to ogólną kulturę zespołową odizolowanych programistów pracujących nad izolowanymi funkcjami, zrób coś z tym. Może na przykład być tak, że wprowadzenie programowania parami mogłoby pomóc w rozwiązaniu problemu, a nie w rozwiązaniu problemu.

Na marginesie, prawidłowa odpowiedź może brzmieć „tak przejdźmy wszyscy do używania X. ” Tak nie jest w tym przypadku, bardzo przekonująco, ponieważ X jest mały, niejasny, niestabilny i słabo pasuje do problemu. Załóżmy jednak, że na przykład jesteś sklepem z Androidem i masz jednego dewelopera, który chce przejść z Java do Kotlin, ponieważ Google zalecił przejście z Javy na Kotlin i obiecał, że Kotlin będzie lepiej obsługiwany w przyszłości niż Java. Ostatecznie mają bardzo prawdopodobną rację.

Istnieje wiele takich samych obaw. Będziesz musiał martwić się o szkolenie, zgodność kodu, o to, jak członkowie Twojego zespołu reagują, a nawet o ryzyko, że jednemu z twoich programistów tak nie spodoba się zmiana, że ​​zdecyduje się zakończyć. W międzyczasie miałoby zastosowanie wiele takich samych środków zaradczych: upoważnienie zainwestowanych ludzi do przewodzenia mu, zbieranie danych o powodach podjęcia decyzji, słuchanie różnych interesariuszy itp.

Chciałbym podkreślić koncepcję programowania w parach w odpowiedzi Josiaha.Konieczność wyjaśnienia składni X każdemu sprawiłaby, że programista albo powróciłby do znanych języków, albo cały zespół byłby podekscytowany X ...
Samo stwierdzenie „uniemożliwia skuteczny przegląd kodu” jest znaczącym uzasadnieniem.Widziałem, jak to się właśnie stało, i ten programista szalał, ponieważ nikt nie był w stanie sprawdzić jego pracy.
Czy w zespole, który „kładzie nacisk na autonomię i uczenie się”, mają oni przeglądy kodu (uczenie się), czy nie (autonomia)?Czy jakość rozstrzygania remisów (przeglądy kodu) czy zabawa (brak recenzji kodu)?
#9
+8
Danubian Sailor
2019-07-13 01:36:52 UTC
view on stackexchange narkive permalink

Myślę, że podchodzisz do problemu z złej perspektywy .

Obracasz go w naszym ulubionym języku kontra jego problem z językiem zwierząt domowych. Języki to tylko narzędzia, dość uniwersalne, więc ich wybór jest kwestią poboczną.

Prawdziwym problemem jest to, że w zespole panuje totalny chaos . Wygląda na to, że każdy może robić, co chce, wybierając dowolne narzędzie, nawet te, których naprawdę nie zna. To jest to, co musisz rozwiązać.

Posiadanie tylko jednej osoby w zespole, która może wspierać jakąkolwiek istotną część projektu, jest po prostu szalone. Co najmniej 2 osoby w zespole powinny opanować X w stopniu umożliwiającym konserwację, albo X musi odejść.

Fakt, że programista X-pet nie jest pewien, jak zaimplementować jeden z kluczowych aspektów X, oznacza, że ​​nawet on nie opanował go w rozsądnym zakresie. Chwila, żeby powiedzieć przepraszam, ale Twoja firma zatrudnia ludzi do wykonywania pracy, a nie po to, by bawić się uczeniem nowych narzędzi.

Znaczącym rozwiązaniem może być umożliwienie mu opracowania eksperymentalnych narzędzi / funkcji w czasie, powiedzmy, 20%. Całkowite zbanowanie X może przynieść efekt przeciwny do zamierzonego, jeśli chcesz zatrzymać tego gościa w swoim zespole (i najprawdopodobniej tak będzie, ponieważ zespół składający się z 5 osób, który zmieni się w zespół 4-osobowy w produktywnej aplikacji, z pewnością nie pomoże w utrzymaniu aplikacji).

#10
+5
cjs
2019-07-13 08:05:29 UTC
view on stackexchange narkive permalink

Nie, sam język X nie jest tak naprawdę problemem. To, co tutaj opisałeś, to symptomy znacznie głębszego problemu, który wpłynie również na wszystkie inne systemy produkowane przez twój zespół: zespół nie pracuje tak naprawdę jako zespół, ale jako grupa odłączonych osób.

Twój instynkt, że „chcesz, aby [Twój] zespół był niezależny i szczęśliwy, budując go, a nie wyłączając” jest poprawny; musisz rozwiązać ten problem, trenując zespół, aby go naprawić. Zacząłbym od próby usunięcia wyraźnej własności kodu, która ma miejsce, gdy kod napisany w języku X jest „jego” kodem. Jest to kod zespołu, a zespół jako całość musi być odpowiedzialny za jego utrzymanie i rozszerzenie.

Możesz zacząć od tego, jak przypisywane są historie (lub cokolwiek innego). W idealnym przypadku wszyscy członkowie zespołu powinni regularnie pracować nad wszystkimi częściami systemu, a nie nad określonymi częściami systemu „należącymi” do poszczególnych programistów. W porządku, jeśli masz programistów, którzy są ekspertami w określonej technologii lub części systemu, a inni nie, ale w systemie nie powinno być nic, w którym nie ma co najmniej dwóch programistów, którzy uważają, że znają tę część wystarczająco dobrze, aby być technicznym liderem w każdej konkretnej historii, w której jest to główny składnik.

Programowanie w parach i samo proszenie o pomoc to typowe sposoby rozpowszechniania wiedzy. Programowanie ekstremalne radzi sobie z tym, pozwalając każdemu wybrać i być liderem w historii, bez względu na to, jak dużo lub mało o niej wie, i polega na tym, że programiści nie mogą powiedzieć „nie” żądaniom pomagać w tej historii, pozwalając deweloperowi, gdy otrzyma pomoc, poznać wszystkie krwawe szczegóły niezbędne do ukończenia historii. (Przypisywanie historii w XP jest w rzeczywistości funkcją zarządzania projektami: programista zarządzający historią dla tej iteracji jest odpowiedzialny za upewnienie się, że zostanie ona ukończona, znajdowanie wszystkich niezbędnych do tego zasobów. zrozumienie historii do końca iteracji, niezależnie od tego, czy zaczęła od tego, czy nie).

Wyjaśnij więc swojemu zespołowi , że jesteś zadowolony z używania języka X lub cokolwiek innego, jeśli cały zespół jest zgodny, że to dobry pomysł i zgadza się, że jeśli programista, o którym mowa, zostanie zaczepiony przez kosmitów, zespół poradzi sobie bez niego. Wtedy to ten programista może sprzedawać swoje pomysły techniczne w zespole. Wyjaśnij, że nawet jeśli zespół nie zgadza się na uczynienie X głównym językiem programowania dla wszystkich nowych funkcji, nie oznacza to, że nie można go w ogóle używać; być może mógłby być używany tylko w niektórych mniejszych obszarach, aby go przetestować i zdobyć doświadczenie. Zachęcaj do regularnych przeglądów zarówno tego, jak język X sprawdza się tam, gdzie jest używany, jak i poszczególnych podsystemów (niezależnie od tego, czy używa języka X , czy nie) pod kątem tego, jak dobrze działają. rodzi się z tego problemy i jak można je złagodzić.

#11
+3
Daniel R. Collins
2019-07-12 08:45:12 UTC
view on stackexchange narkive permalink

Opierając się na innych odpowiedziach, zgadzam się, że języki / technologie, które mają być użyte w projekcie, powinny być pozytywnie wybrane przez zespół przed ich użyciem (z wyjątkiem ewentualnej próby lub przypadku testowego wykonalności, bez obietnicy lub ścieżki krytycznej użyte w samym projekcie).

Martwię się, że to nie zostało zrobione, a próba poruszenia tematu do dyskusji z zespołem teraz skutkowałaby tym, że nikt nie chciałby skonfrontować się z nieuczciwym programistą i powiedzieć „nie” (wynika to z faktu że nawet menedżer obecnie boi się podjęcia tego kroku).

Rozważ następujące możliwe sposoby rozwiązania tego problemu: Zorganizuj spotkanie "resetujące", podczas którego zespół wspólnie wybierze / zatwierdzi technologie, które mają być używane i wspierane w projekcie. Zachowuj się tak, jakby projekt był nowo rozpoczynany, do tej pory nie wybrano żadnego języka, a zaczynasz od czystej karty. Teraz ciężar dowodu spoczywa na uzyskaniu odpowiedzi na „tak” dla nowego języka (jak powinno być), zamiast na „nie” (gdzie obecnie się wydaje).

#12
+2
Dmitry Grigoryev
2019-07-12 14:42:26 UTC
view on stackexchange narkive permalink

Powinieneś dać do zrozumienia przełożonym i zespołowi, że X w swoim obecnym stanie jest problemem , ponieważ najwyraźniej obecnie nie wiadomo, że tak jest. Powiedz wszystkim, że zespół potrzebuje co najmniej dwóch ekspertów X na wypadek, gdyby jeden z nich był chory. Poproś o szkolenie w X dla całego zespołu. Za każdym razem, gdy projekt się zepsuje z powodu niekompatybilnej aktualizacji X lub trywialnego błędu, którego nie znaleziono, ponieważ testerzy nie znają X, rozpocznij dyskusję, jak zapobiec takim nieszczęściom w przyszłości.

Albo firma zdecyduje się rzucić X lub zdecyduje się pójść all-in i sprawić, że X zostanie powszechnie przyjęty. W obu przypadkach problem X jako „ulubionego języka” zniknie.

I nie obwiniaj programisty za „sprowadzenie X na nas”. Przystępni i pełni pasji programiści tworzą wspaniałe aktywa firmy i wspaniali współpracownicy. To nie ich wina, że ​​kierownictwo kupiło pomysł przyjęcia X, który uważał za genialny, bez oceny ryzyka.

#13
+1
AlexanderM
2019-07-12 00:10:15 UTC
view on stackexchange narkive permalink

Myślę, że musisz porozmawiać z zespołem na temat tego języka. Pozwól programistom najpierw zaprezentować język, usłyszeć, jakie korzyści daje język, a także jakie wady ma język. Przedstaw swoje obawy dotyczące stabilności, kompatybilności itp. Spójrz na historię twórców języka (na przykład Microsoft znany jest z zabijania technologii, które promował na krótko przed ogłoszeniem zabicia (zobacz wiele iteracji Windows Phone, Silverlight itp.)) Zachęcaj innych programistów do dzielenia się swoimi przemyśleniami.

Jeśli dyskusja obraca się przeciwko X i tak naprawdę nie chcesz całkowicie zamknąć tego dewelopera lub nawet by się to udało, możesz podjąć decyzję o pozostawieniu języka jako jedynego projektu i zobaczyć, jak to będzie idź i zrób drugą rundę po zakończeniu projektu (szczerze, to bym zrobił bez względu na wszystko (chyba że X to kompletny śmieć): niech mały, jednorazowy projekt zostanie w całości wykonany w tym języku i zrób drugą rundę) .

PS: czasami niektóre naprawdę „dziwne” i rzadkie języki mogą dać ogromną przewagę w niektórych projektach: http://www.paulgraham.com/avg.html (artykuł ma prawie 20 lat, więc możesz zignorować technologie i języki, ale zastanowić się więcej nad koncepcją)

#14
  0
asmgx
2019-07-15 04:13:23 UTC
view on stackexchange narkive permalink

U góry odpowiedzi

Myślę, że problem polega na pewności siebie.

Twój programista jest pewien, że używa X i boi się używać innego język, w którym nie jest zbyt dobry.

prawdopodobnie szkolenie w zakresie możliwości Twojego języka Y może dać mu pewność w używaniu Y

#15
-1
SeverityOne
2019-07-15 03:00:15 UTC
view on stackexchange narkive permalink

Rozważ możliwość, że Twój programista (ten, który naprawdę lubi X) znajduje się w spektrum autyzmu lub przynajmniej ma cechy autystyczne. Obsesyjne skupienie się na jednej rzeczy, ciągłe o tym mówienie, może wskazywać, że ta osoba ma jakiś stan, który utrudnia mu obiektywne podejście do sprawy.

Powodem, dla którego to mówię, jest to, że jeśli tak jest, być może będziesz musiał podejść do sprawy inaczej niż w przypadku osoby neurotypowej (tj. „Normalnej”). Nie oznacza to, że wspomniany programista mniej nadaje się do tego zadania.

Mój pracodawca płaci mi za pisanie oprogramowania, które sprzedajemy klientom. Nie płacą mi za to, co mi się podoba. Na przykład lubię grać w gry wideo, ale to nie przynosi żadnych pieniędzy.

Podobnie, nieznany język, taki jak X, wydaje się powodować więcej problemów niż ich rozwiązywać. Oznacza to, że produktywność i wydajność całego zespołu jest zagrożona z powodu jednego faceta, który chce robić rzeczy inaczej.

Jeśli można wykazać, że użycie X ma pozytywny wpływ netto na produktywność i wydajność, Zatrzymaj to. W przeciwnym razie wyjaśnij swojemu programistowi, że musi oddzielić hobby (jego fascynacja X) od pracy (co się opłaca).

W pracy mam podobny scenariusz. W moim dziale są zasadniczo dwa główne programy, które zostały napisane dawno temu i tak naprawdę nie były aktualizowane. Anemiczny model obiektowy, słabe praktyki kodowania, staromodne technologie i frameworki ... Lista jest długa.

I chociaż mam doświadczenie i wiedzę, aby wprowadzać nowe koncepcje, takie jak projektowanie oparte na domenie, mikro- usług i aplikacji jednostronicowych, muszę również wziąć pod uwagę, że inni programiści będą potrzebowali czasu, aby nadrobić zaległości. To delikatna równowaga, którą należy osiągnąć.

Ostatecznie jednak musisz skupić się na dobrym samopoczuciu całego zespołu, a nie jego poszczególnych członków. Nie możesz uszczęśliwić wszystkich. To firma, a nie demokracja. Koniecznie trzeba słuchać ludzi, ale równie ważne jest podjęcie decyzji i upewnienie się, że wszyscy się jej trzymają. W przeciwnym razie nie bądź liderem zespołu.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...