Ile swobody powinien mieć programista przy wyborze języka i frameworka?

Zacząłem pracować w firmie, która jest głównie zorientowana na C #. Mamy kilka osób, które lubią Javę i JRuby, ale większość programistów tutaj lubi C #. Zostałem zatrudniony, ponieważ mam duże doświadczenie w tworzeniu aplikacji internetowych i ponieważ skłaniam się ku nowszym technologiom, takim jak JRuby on Rails lub nodejs.

Niedawno zacząłem od projektu budowy aplikacji internetowej z naciskiem na wykonanie wielu rzeczy w krótkim czasie. Lider oprogramowania podyktował, że używam mvc4 zamiast szyn. To może być OK, z wyjątkiem tego, że nie znam mvc4, nie znam C # i jestem jedynym odpowiedzialnym za tworzenie serwera aplikacji WWW i interfejsu użytkownika front-end.

Czy nie ma sensu używać frameworka, który już znam bardzo dobrze (Railsy) zamiast mvc4? Powodem tej decyzji było to, że lider technologii nie zna Jruby / rails i nie będzie możliwości ponownego użycia kodu.

Kontrargumenty:

• Nie będzie uczestniczył w tworzeniu kodu i, szczerze mówiąc, nie jest potrzebny w
  tym projekcie. Tak więc nie ma znaczenia, czy on zna JRuby / szyny, czy nie.

• W rzeczywistości możemy ponownie użyć kodu, ponieważ mamy wiele aplikacji Java, z których JRuby może pobierać kod i odwrotnie. W rzeczywistości poświęcił niektóre zasoby na konwersję biblioteki Java do C #, zamiast po prostu uruchamiać bibliotekę Java w aplikacji JRuby on Rails. Wszystko dlatego, że nie lubi Javy ani JRuby

Zbudowałem wiele aplikacji internetowych, ale używanie czegoś nieznanego powoduje pewne rozproszenie i nie jestem w stanie zbudować niesamowitej aplikacji w tak krótkim czasie, jak jestem przyzwyczajony. To by było w porządku; nauka nowych technologii jest ważna w tej dziedzinie. Problem polega na tym, że w tym projekcie musimy szybko wiele zrobić.

W którym momencie deweloper powinien mieć możliwość wyboru swoich narzędzi? Czy to zależy od firmy? Czy moja firma jest do kitu, czy jest to normalne? Czy istnieją bardziej zielone pastwiska? Czy patrzę na to w niewłaściwy sposób?

Powiedziałbym, że musisz porozmawiać z kierownikiem zespołu i powiedzieć coś takiego:

Wiem, że jesteście sklepem .NET, ale tak naprawdę zostałem zatrudniony do moich umiejętności Java / JRubyRails. Mogę zbudować nową aplikację w X czasie przy użyciu narzędzi, które już znam. Mogę nauczyć się C # / mvc4 tak, jak chcesz, ale zajmie to >> X czasu. Co chcesz?

To podnosi kwestię „umiejętności-you-were- (przypuszczalnie) -hired-for” kontra „umiejętności-you-need-teraz”, a także pokazuje, że jesteś w stanie nauczyć się nowych umiejętności, ale że będzie brać dłużej, aby opracować nową aplikację, ponieważ jesteś nowy w tym zestawie narzędzi. A ty nie chcesz pokazać, że jesteś chętny do nauki nowych umiejętności. Brak otwartości na naukę nowych umiejętności jest dobrym sposobem na zapewnienie, że twoje zatrudnienie zakończy się, gdy twoje umiejętności nie będą już potrzebne.

Co do twojego pytania na końcu:

W którym momencie deweloper powinien mieć możliwość wyboru swoich narzędzi? Czy to zależy od firmy? Czy moja firma jest do kitu, czy jest to normalne? Czy istnieją bardziej zielone pastwiska? Czy patrzę na to w niewłaściwy sposób?

Zwykle zależy to od firmy. Jeśli firma kupi narzędzia MS i standaryzuje wszystko na platformie VisualStudio i frameworku .NET, może być bardzo niewygodne, jeśli jeden programista nalega na użycie Linuksa i C. Jest to normalne. Mogą istnieć wyjątki, gdy firma jest mniej wybredna wobec redaktorów, na przykład pozwalanie programistom na wybranie Vi vs. Emacs, pod warunkiem, że wyniki są takie same. Wiem, że niektóre firmy pozwalają nawet programistom wybierać system Windows vs. Linux, ale język, w którym pracują, ma bardzo dobre wsparcie i środowiska wykonawcze dla obu systemów operacyjnych.

Dlaczego firmy to robią? Spójność jest jednym z powodów. Debugowanie rzeczy może być bardzo trudne, gdy aplikacja jest mozaiką plików binarnych zbudowanych w ulubionych językach / ramach różnych programistów, wbudowanych w różne narzędzia i przetestowanych na bardzo różnych systemach. Jeśli wszyscy programiści pracują w większości na podobnych konfiguracjach, tego rodzaju problemy zostaną rozwiązane.

W twoim przypadku wygląda na to, że zostałeś zatrudniony do pracy w technologii, która jest niestandardowa w tej firmie. Wydaje mi się to dziwne i możesz porozmawiać z osobą, która cię zatrudniła, o tym, dlaczego tego chcieli.

W którym momencie deweloper powinien mieć możliwość wyboru swoich narzędzi?

Kiedy nie wpływają na twój zespół.

Czy patrzę na to w niewłaściwy sposób?

Absolutnie.

Tak, masz krótki termin. Tak, możesz to zrobić szybciej w Railsach. Ale firma jako całość musi wdrożyć i utrzymywać aplikację. Jeśli firma ma stabilną grupę dobrych programistów C #, prawdopodobnie utrzymanie aplikacji w języku C # będzie prawdopodobnie tańsze (i przyniesie lepszą jakość).

Twoi DBA i inni pracownicy administracyjni prawdopodobnie znają ten stos i dysponują procesami wdrażania i aktualizacji tego stosu. Nawet jeśli możesz wykonać kod szybciej, może to potrwać dłużej, jeśli weźmiesz pod uwagę wszystkie koszty związane z uruchomieniem profesjonalnej aplikacji internetowej.

Pamiętaj, że poświęcisz znacznie więcej czasu na utrzymanie aplikacji niż jej pisanie. Zoptymalizuj ten koszt.

1. Najwyraźniej zostałeś zatrudniony z powodu swojej zdolności do przystosowania się do „nowych” technologii. C # nie różni się pod tym względem. Czy na pewno nie chcesz skorzystać z okazji, aby nauczyć się czegoś nowego?

2. ASP.NET MVC jest pod wieloma względami bardzo podobny do Ruby on Rails.

3. Nie będziesz wiecznie w tempie ślimaka. Jeśli znasz już ROR, ASP.NET MVC będzie dla Ciebie świetny. Sztuką jest nauka języka C #.

Argumenty za pozostaniem w Javie / JRuby

Możliwe, że twój szef chce, abyś produkował. Zatrudnili cię, abyś mógł zwiększyć wartość firmy. Upewnij się, że rozumieją, że zmusza do korzystania z ram, że nie znają oni będą powodować:

1. Twórz wyniki wolniej
2. Utwórz kod niższej jakości

Nawet najlepsi programiści potrzebują czasu na rozgrzanie w nowych językach / ramach.

Argumenty do nauki MVC4 i C #

Nauka nowych języków jest dobra. Inwestowanie w swoje umiejętności programistyczne jest ryzykowne tylko wtedy, gdy język / platforma, której się uczysz, zniknie w najbliższej przyszłości, a biorąc pod uwagę, że Microsoft się z tobą bawi, nie sądzę, żeby to był problem. Zarówno C #, jak i MVC mają najnowsze aktualizacje, które poprawiły je oba, a kolejne aktualizacje są w przygotowaniu.

Sprawiając, że staniesz się osobiście bardziej dopracowanym programistą, nigdy więcej nie znajdziesz się w takiej sytuacji. Najlepsza część? Twój szef zapłaci ci za naukę tych rzeczy, co oznacza, że ​​zarabiasz, aby zarobić więcej pieniędzy.

Dolna linia

Możesz wygrać tę walkę, ale pozostanie ci praca z niezadowolonymi kolegami. Po prostu wyjaśnij swojemu menedżerowi zalety i wady każdego z nich, a wtedy oboje wyjdziecie szczęśliwsi.

W którym momencie deweloper powinien mieć możliwość wyboru swoich narzędzi?

Gdy wspomniany programista jest liderem oprogramowania.

Z pewnością możesz (i powinieneś) uzasadnić użycie innego zestawu narzędzi, jeśli martwisz się produktywnością, ale bądź przygotowany na odpowiedź, której nie polubisz. Może istnieć cholernie dobry powód, dla którego Twój lider chce, abyś używał określonego zestawu narzędzi, czy to kompatybilność z obecną architekturą, obawy dotyczące konserwacji, problemy z licencjonowaniem itp.

BTW, fraza

z naciskiem na zrobienie wielu rzeczy w krótkim czasie

odpowiada za więcej zgagi i zamętu w branży oprogramowania niż za wszystko inne.

Zauważam, że nie mówisz, że zostałeś zatrudniony jako programista JRuby lub Java.

Oto dlaczego powiedziałeś, że zostałeś zatrudniony: „[B] ponieważ mam duże doświadczenie w tworzeniu aplikacji internetowych i dlatego, że skłaniam się ku nowszym technologiom, takim jak JRuby on Rails lub nodejs.”

Innymi słowy, podoba im się Twoje doświadczenie w Internecie i chęć uczenia się nowych technologii.

Teraz proszą Cię o korzystanie z Internetu i naukę nowej technologii.

Pytanie brzmi: czy zamierzasz to zrobić, czy nie?

Największy koszt oprogramowania polega na jego utrzymaniu

Przeczytałem, że największy koszt (80%) to utrzymanie oprogramowania. Początkowy rozwój to tylko 20% całkowitych kosztów rozwoju.

Czytałem przypadek o deweloperze, który opracował kod i komentarze w swoim ojczystym języku (nie angielskim), a kiedy inni członkowie zespołu udoskonalili i utrzymali kod, było to prawie niemożliwe, ponieważ język (nie żaden język programowania) był obcy do nich.

Podobnie, jeśli opracujesz kod w wybranym przez siebie języku programowania, pozostanie innym członkom zespołu byłoby trudne do utrzymania.

Rozwiązanie: programowanie w parach

Zastanów się, czy nie poprosić pracodawców o powiązanie cię z kimś, kto zna wymagany język programowania i możesz współpracować. Możesz uczyć się od siebie nawzajem, a jeśli jedno z was opuści firmę, drugi zna kod.

Artykuł w Wikipedii na temat „Programowania par”: http://en.wikipedia.org/wiki/Pair_programming

Wiele firm po prostu woli trzymać się tego, co zawsze robili, lub tego, co jest „bezpieczne”. Jest powód, dla którego Java i PHP są nadal bardzo popularne. W tej chwili wyszukanie „COBOL” na rzeczywiście.com zwraca 2144 ofert ... co powinno naprawdę mówić samo za siebie. W branży nie zależy na dobrym kodzie, zależy mu na kodzie, który może doić tak długo, jak to możliwe (nie oznacza to, że C # jest zły, a tak naprawdę nie jest).

Pomyśl o tym: kod przetrwa. Istnieje duża szansa, że ​​ktoś zachowa Twój kod, a C # jest bezpieczniejszym rozwiązaniem niż Node.js i Rails. Nie zdziwiłoby mnie to, gdyby za 5 lub 6 lat liczba programistów Rubiego zmniejszyła się o połowę, po tym wszystkim, co przytrafiło się Perlowi i innemu językowi, który w pewnym momencie był uważany za język „it”. JavaScript prawdopodobnie nie zniknie, ale już zaczynamy widzieć, że jest używany jako swego rodzaju ASM (lub nawet C) sieci - język pośredni, który inne języki mogą skompilować, aby napisanie w nim kodu po stronie serwera mogło bardzo dobrze stają się przestarzałe.

Moją główną troską związaną z tym, że programiści wybierają sposób realizacji swoich celów, jest to, że zwykle zakładają, że tylko będą edytować kod. Spójrz na to w ten sposób, 12 miesięcy później mogą potrzebować zmian; nie jesteś dostępny (opuściłeś firmę lub naprawdę zajęty innym zadaniem), a inny programista musi zrezygnować z kodu. Jeśli jest to sklep C #, to korzystanie z ich zestawu narzędzi jest dobrą pracą zespołową. Nowe technologie powinny być badane i wdrażane, ale tylko wtedy, gdy kierownictwo uzna, że ​​czas jest odpowiedni, ponieważ mają oko na wiele celów, a nie tylko jeden.

Proszę to odwrócić. Wyobraź sobie, że zatrudniasz programistę Ruby, a oni nalegają na wdrożenie swojej pracy w Asp.net/MVC.

Co byś im powiedział? To jest nasz stos, stary. Naucz się z tym żyć.

Złota zasada, oto ona, która ma złoto, ustanawia reguły.

Istnieje wiele sprzecznych celów, a problemem jest znalezienie najlepszego kompromisu. Mamy termin, mamy kierownika zespołu, który żąda określonego zestawu narzędzi, i mamy programistę niedoświadczonego z tym zestawem narzędzi, ale skazanego na wyprodukowanie czegoś w (oczywiście krótkim) terminie.

Ważne jest, aby zrozumieć, że kierownik zespołu ma prawdopodobnie kilka dobrych powodów, dla których żąda dokładnie tego zestawu narzędzi (jednym z nich może być rzeczywiście przyzwyczajenie się do tego zestawu narzędzi z jakiegoś powodu, którego jeszcze nie znasz). Najlepsze, co możesz zrobić przy pierwszym uruchomieniu, to dowiedzieć się, jakie dokładnie są te powody.

Postawmy na twoim stanowisku, spróbuję porozmawiać z kierownikiem zespołu i wyjaśnić sytuację, jaka jest Twoim zdaniem, oraz opcje i jaki wynik (w tym krótko- i długoterminowe efekty ekonomiczne) zostaną wygenerowane postępując zgodnie z każdą z tych opcji. Na przykład może zostać wyznaczony inny, bardziej doświadczony programista, który będzie cię trenować, być może z sesjami programowania w parach lub podobnymi.

O ile kierowanie zespołem nie jest kompletnym kretynem, powinieneś być w stanie znaleźć konsensus, który ma sens w odniesieniu do projektu i ogólnych celów firmy.

Bah. Wszyscy się mylą.

Bądź lepszym twórcą niż ludzie z jednej platformy, a będziesz mieć o wiele ciekawsze opcje niż kiedykolwiek. Na razie więc naucz się MVC. A we własnym czasie dowiedz się więcej o platformach, które naprawdę Cię interesują. Rozwijaj swoje umiejętności węzłowe. Naucz się Django. Zwróć uwagę na wszelkie shenanigany Java lub wcześniejsze MVC .NET, na które jesteś narażony, a następnie uciekaj, ale przynajmniej naucz się wystarczająco, aby móc krytykować i wyjaśniać, ile myśli włożyłeś w ledwo ukryte uprzedzenia związane z nienawiścią tych platform. (okej, może tam wyświetlam)

A teraz ważna rada. Jeśli nadal będziesz doskonalić swoje specjalizacje, jednocześnie dywersyfikując swoją wiedzę w innych obszarach, w końcu znajdziesz się w miejscu, w którym możesz znaleźć nową pracę o każdej porze roku w mniej niż dwa tygodnie w dowolnym większym mieście, robiąc rzeczy, które są najbardziej interesujące co najmniej w połowie czasu. Kiedy znajdziesz się w tym miejscu, nie godzi się na pracę, w której mówią, że tego chcą, a do drugiego dnia robią to, ŻE bez nadziei na ulgę przewidywalną w długiej perspektywie. Po prostu grzecznie wyjaśnij i przeproś, ale nie, naprawdę nie chciałeś tego robić i powiedziałeś tyle w swoim wywiadzie, a potem! @ # $ Ing przestań i ruszaj dalej, gdy upłynie kilka tygodni i nieuchronnie nie zrobili nic, aby pomieścić fakt, że przedstawili ci fałszywe stanowisko i odmawiają uznania tego.

Ale zaufaj mi, znalezienie nowego koncertu jest zawsze o wiele lepsze niż bycie poważnie zirytowanym i nieszczęśliwym przez jakikolwiek czas dłuższy niż 5 minut. Ale oczywiście najpierw musisz zapłacić swoje składki, abyś mógł to zrobić. Niektórzy ludzie nigdy tego nie zrobią. Dlatego chcą wszystkiego, co znają najlepiej. I oczywiście inne odpowiedzi nie są tak naprawdę błędne. Ma sens, aby sklep .NET współpracował z .NET, jeśli muszą zachować głupie rzeczy.

Oczywiście nie ma sensu, dlaczego dywersyfikują się za pomocą dewelopera Rails / JS / UI i mają tylko do robienia aplikacji MVC. Ale teraz. Być może będziesz musiał go odebrać i spłacić swoje składki. I jak powiedziałem w komentarzach, MVC naprawdę nie jest takie złe. Naprawdę zły wybór, biorąc pod uwagę wszystkie opcje, ale na pewno nie najgorszy. Jest to całkiem proste, nie rzuca 10.000 warstw abstrakcji na wszystko, co się faktycznie dzieje, i nie jest tak przekręcone po stronie klienta, że ​​przekląłbyś nazwiska inżynierów MS odpowiedzialnych, gdyby ktokolwiek mógł się niepokoić uczyć się ich.

Więc dotrzyj do tego miejsca, w którym możesz odejść, kiedy chcesz, jeśli jeszcze tego nie zrobiłeś, a może nawet okaże się, że masz bardziej sceptyczne spojrzenie na rzeczy, które obecnie lubisz. Możesz nawet nie lubić szyn tak samo jak ja. Nie chodzi o to, że z Ruby jest coś nie tak (oczywiście poza tłumaczem).

W zależności od twojej sytuacji może być niebezpieczne założenie, że wiesz, dlaczego cię zatrudnili, a tym bardziej założenie, że twój kierownik wie o tym i zgadza się, że zatrudnianie osób posiadających twoje umiejętności jest dobrym pomysłem.

Poprosiłbym o skorzystanie z powyższej porady i uzasadnienie biznesowe, dlaczego powinieneś pójść z JRuby nad C #, może twój argument i ramy czasowe oznaczają zerwanie ze starymi sposobami ma sens. Nie zakładałbym po prostu, że jest w porządku, czy nie, przekazał kierownikowi lub poprowadził fakty i pozwolił im podjąć decyzję, to po co im płacą duże dolary plus trochę CYA.

Moim szczerym zdaniem, jedną rzeczą, która odróżnia dobrych programistów od wielkich, jest ich zdolność do przystosowywania się do nowych technologii. Żyjemy w dynamicznym świecie, w którym dzisiejsza najlepsza technologia stanie się jutro przestarzała. Dlatego deweloper, który nie chce się dostosować, ma ograniczone zastosowanie dla firmy. Byłoby dobrze, gdyby nie fakt, że znalezienie i zatrudnienie dobrych ludzi jest naprawdę bardzo trudne, a kiedy firma znajdzie swój klejnot, planuje na dłuższą metę.

Widziałem firmy zatrudniające się poza zakresem technologii i robią to z tego samego powodu. Chcą zdobyć świetnych programistów, nawet jeśli oznacza to czekanie na dostosowanie się do nowych technologii.

Teraz twoja sytuacja. Jako nowy facet w grupie byłbym bardzo ostrożny co do tego, co mówię, a nie do moich przełożonych. Jasne, że uciekniesz od wielu rzeczy w oparciu o założenie, że wciąż jesteś w trakcie dostosowywania się do nowego środowiska. Jednak podważenie autorytetu i upartej wytrwałości w preferowanej technologii sprawi, że przełożeni będą myśleć, że popełnili błąd, zatrudniając cię i że nie chcesz opuścić strefy komfortu.

To, co wybierzesz, zależy od ciebie, ale proponuję, abyś spróbował nauczyć się nowej technologii. Nie zaszkodzi, obiecuję.

Zakładam, że byłeś szczery podczas wywiadu na temat braku wiedzy na temat C #, ponieważ jeśli tak nie było, możesz być w bardzo niepewnej sytuacji z prawnego punktu widzenia.

Dobrzy programiści znają programowanie. Podczas gdy nikt nie może być oczywiście dobrze obeznany we wszystkich językach i ramach, istnieje znaczna podobieństwo między większością z nich. Jeśli nie zostaniesz poproszony o pracę w języku, który znacznie różni się od tego, co stanowi obecnie główny nurt (na przykład Lisp), dobry programista powinien być w stanie się przystosować.

Oczywiście jest krzywa uczenia się. Jeśli pracodawca cię zatrudnił, musi mieć pewność, że potrafisz postępować zgodnie z tą krzywą w rozsądnym czasie (ponownie, zakładając, że byłeś szczery z góry, jeśli nie znasz C #). Język C # pożycza dużo od Javy, a bardziej ogólnie, większość języków programowania opartych na klasach jest zasadniczo całkiem podobna (wspomniałeś o node.js, który opiera się na ECMAScript, który jest językiem opartym na prototypach, więc oczywiście jesteś wygodne z innymi paradygmatami programowania.

Dobrzy programiści powinni nie tylko być elastyczni, ale także chętni do uczenia się nowych rzeczy. Podczas tworzenia oprogramowania zazwyczaj uczysz się lub przestajesz mieć znaczenie.

Oczywiście twój pracodawca, zakładając, że wiedział, że nie znasz C #, musi się z tobą spotkać w połowie drogi. Jeśli wykażesz ochotę do nauki, muszą dać ci czas i środki, aby to zrobić. Wrzucanie cię do głębokiego końca jest niesprawiedliwe i niepotrzebnie stresujące. Musisz usiąść i odbyć spokojną, racjonalną dyskusję z przełożonym. Jeśli chcą tego w języku C #, muszą być gotowi zaakceptować, że będziesz na krzywej uczenia się podczas pracy nad tym i niesprawiedliwe byłoby narzucanie ci ścisłych terminów. Jeśli terminy nie są elastyczne i mają duże znaczenie strategiczne, należy je przygotować, aby pozwolić sobie na pewną swobodę w wykonywaniu pracy w tym terminie. Jeśli potrzebują w swoim biurze bardziej popularnego języka, być może możesz poprosić o wdrożenie go teraz w tym, co „ zna się na dotrzymywaniu terminu, a następnie jako kolejny projekt ponownie wdrożysz go w języku C # jako ćwiczenie edukacyjne i dostosujesz oprogramowanie do wymagań wewnętrznych, gdy tylko spełni zewnętrzne. Tak jak powiedziałem, większość dziś najczęściej używanych języków ma wiele cech wspólnych, więc sprowadzają się one głównie do szczegółów implementacji.

Musisz być przygotowany na to, że prędzej czy później zaakceptujesz, że pracujesz w sklepie C #, a zatem musisz mieć C # za pasem.

Może nie są zadowoleni ze sposobu, w jaki wszyscy używają MVC w środowisku .NET. Zbyt wiele może być traktowane jak formularze internetowe. Nie inaczej jest, gdy ktoś z wykształceniem proceduralnym zaczyna w OOP, umieszcza wszystko w jednej dużej klasie i kontynuuje biznes jak zwykle.

Ten pierwszy projekt nie jest idealną sytuacją, ponieważ chcą, aby zostało to zrobione tak szybko. Zdobądź jak najwięcej szybkości w .NET i zacznij jak najszybciej uruchamiać funkcje. Nie spodoba ci się sposób, w jaki to robisz, po prostu pamiętaj, że zaczniesz refaktoryzować to i zastosować swoje umiejętności w innym języku.

Mam nadzieję, że twój sposób korzystania z MVC4 (zakładając, że wszyscy inni nie robią tego całkiem dobrze) w bardziej Rubinowym stylu, przyłapie i oderwie wszystkich od mentalności Webforms.