Jak przekonać członka zespołu do korzystania z frameworka internetowego? [Zamknięte]


10

Pytanie brzmi następująco: czy jest coś, co mogę powiedzieć / przywołać jako programista, aby przyprowadzić go na moją stronę?

Chciałbym usłyszeć uzasadnione argumenty dla obu stron w tej sprawie, ale głównie sugestie, jak go porozmawiać.


Moja sytuacja jest taka: pracuję nad projektem zespołowym na moim studiach dyplomowych, budując średniej wielkości stronę internetową jako prototyp uniwersytetu. Wszyscy są uznawani za równych w grupie i nie ma jednego wyznaczonego lidera, więc odpowiedzią na ten problem nie może być „pull rank”.

Wszyscy są równi, jednak istnieje ogromna luka w wiedzy między członkami. Członek zespołu, o którym mowa, i ja jesteśmy zdolnymi programistami, chociaż nie ma on doświadczenia w branży. Pozostali trzej członkowie są mniej zdolni, a dwóch całkowicie zrezygnowało z rozwoju. Wszyscy trzej odmówili skomentowania sytuacji z powodu braku wiedzy.

Jako grupa decydujemy, jakie technologie zastosować przy wdrażaniu strony internetowej; konkretnie, czy użyć frameworka PHP (Code Igniter), czy nie.

Opowiadam się za, cytując:

  1. Nie wymyślać koła na nowo
  2. Dobrze napisana i przetestowana baza kodu do pracy
  3. Rozpoczęcie pracy (termin jest bliższy niż chcielibyśmy)
  4. Szybkość rozwoju
  5. Solidne i łatwe do utrzymania wzorce projektowe oraz dobre praktyki

Opiera się na pracy w taki sposób, w jaki kiedyś:

  • Pisanie na zamówienie, jednorazowe funkcje w pliku „biblioteki” tak, jak tego potrzebuje
    • Funkcje dostępu do danych i renderowania tych danych na stronie, pobierania / ustawiania do i z sesji oraz pobierania / wysyłania danych itp
  • Posiadanie 1 pliku na stronę (co nie powoduje rozdzielenia obaw między kontrolę, prezentację i dane)

Powody, dla których nie chce używać ram, są w większości oparte na tym, że nie jest w stanie zrozumieć sensu: może już robić te wszystkie rzeczy. Struktura tego nie zmienia, tylko utrudnia, ponieważ musi nauczyć się tej struktury; nie chce używać kodu, którego osobiście nie napisał.

Powiedział także, że „nie ma znaczenia jakość bazy kodu, ponieważ projekt jest jedynie prototypem i nigdy nie będzie utrzymywany”. Dla mnie nie jest to żadna wymówka do napisania niemożliwego do utrzymania kodu.

Rozumiem, dlaczego wysuwa te argumenty, ale mam problem z jego „brakiem troski o łatwość utrzymania” i jego „lekceważeniem dobrego projektu”, a nawet oddzieleniem obaw. Podejrzewam jednak, że nigdy nie badał wzorców projektowych, więc nie wiem, jak skuteczne byłoby wykazanie, dlaczego jego metoda może okazać się niemożliwa do utrzymania.

Chcę zająć się tym projektem, ale nie chcę tego robić bez względu na wszystko, czego nauczyłem się przez lata. Jak powiedziałem wcześniej, nie ma tu możliwości podniesienia rangi, ani inni członkowie zespołu nie są skłonni do wskakiwania. Czy powinienem po prostu się wycofać i zrobić coś po swojemu? Czy jest zbyt uparty i niedoświadczony, by wiedzieć lepiej? A może jestem tu uparty?

TL; DR Niedoświadczony członek zespołu jest uparty, jak mogę go przekonać?


2
Naprawdę trudno jest znaleźć rzeczywiste pytanie w swoim blogu :) Prosimy o poprawienie w sposób podkreślający techniczne argumenty, które przedstawicie. Chociaż nie jesteśmy w stanie powiedzieć, jak rozmawiać z osobą, której nie znamy, możemy pomóc ci podejść do sytuacji z punktu widzenia programisty. Wydaje się, że istnieje dobre pytanie na temat ewolucyjnego prototypowania, ale nie jestem pewien ...
yannis

4
Części tego prawdopodobnie lepiej by pasowały do: area51.stackexchange.com/propations/30887/professional-matters
Karlson

3
he doesn't want to use code he hasn't personally written.Lepiej wyrzuć swój system operacyjny, IDE, telefon, sygnalizację świetlną itp.
StuperUser

4
@AndyBursh I want to know exactly how everything worksjest ważnym argumentem podczas nauki, ponieważ ponowne wynalezienie koła jest w rzeczywistości dopuszczalne. Może po prostu mógłbyś to odczytać jako wołanie o pomoc, a nie upór.
yannis,

4
since the project is only a prototype and will never be maintained Ostatnie słowa :) Chciałbym mieć dolara za każdym razem, gdy przyjmowałem to założenie i dowiedziałem się, że niecierpliwość i krótkotrwała chciwość wyższych sędziów zdecydowały, że prototyp JEST teraz produktem.
wałek klonowy

Odpowiedzi:


20

Nie będziesz w stanie namówić go do tego. Nazywa się to efektem Dunninga-Krugera . Jest zbyt ignorantem, aby wiedzieć, czego nie wie, i zbyt boi się stracić to, co uważa za zaletę.

Jeśli nie jesteś w stanie osiągnąć konsensusu, musisz zamiast tego dojść do kompromisu. Może możesz podzielić pracę, aby jego potrzeba uczenia się ram była minimalna. Może masz jakieś „projektowanie”, w którym każdy robi to po swojemu przez kilka tygodni, a następnie zespół głosuje, który z nich jest najlepszy. Być może możesz zaangażować swojego profesora sponsorującego lub kogokolwiek, kto jest klientem w rozwiązywanie remisu.


3
+1, ponieważ czasami zdarza się to w prawdziwym świecie. Byłem w pracy, w której nie mogłem się zgodzić z innym twórcą, co do najlepszego podejścia. Więc oboje opracowaliśmy POC, a następnie zbadaliśmy zalety i wady każdego z nich. 9 razy na 10 ostatecznie przyjęliśmy rozwiązanie, które było połączeniem dwóch POC i wszyscy nauczyli się czegoś z tego procesu.
Timothy Baldridge

1
+1 za nauczanie o Dunning-Krugerze! Wszyscy muszą o tym wiedzieć.
Stephen Gross

Bah. Kiedy nie zgadzasz się z kimś, zbyt łatwo jest cytować Dunninga-Krugera - zbyt łatwo nazwać go głupcem. Może kolega z drużyny wierzy, że frameworki naruszają ducha zadania, może chce rozwiązać z pierwszej ręki problemy, które frameworki rozwiązują, może chce uniknąć debaty CodeIgniter, Cake, Symfony ... Moje pierwsze założenie nie było takie był idiotą.
Corbin Marzec

1
@Corbin, Dunning-Kruger nie polega na braku inteligencji, ale na braku doświadczenia. Dwie bardzo różne rzeczy. Zgadzam się, że twoje powody mogą być ważne, ale OP powiedział, że to nie były argumenty, które przedstawił. Zamiast tego „nie widzi sensu” korzystania z frameworków, ponieważ może napisać coś równie dobrego od zera w krótszym czasie. Niedoświadczony człowiek przeceniający swoje kompetencje w porównaniu z rozwiązaniem, o którym, jak wiadomo, prawie nic nie wie, to podręcznikowy przykład Dunninga-Krugera. Tacy ludzie nie mogą być w coś „namówieni”, muszą zostać pokazani.
Karl Bielefeldt

7

Jednym argumentem na twoją korzyść jest możliwość ponownego wykorzystania wiedzy. Wszyscy członkowie zespołu, którzy nauczą się dobrze znanego i szeroko stosowanego frameworka (takiego jak CodeIgniter), będą mogli ponownie wykorzystać swoją wiedzę przy następnym projekcie. Podczas gdy wiedza o przypadkowej, zastrzeżonej „bibliotece” nie jest wielokrotnego użytku. Może to dobrze współbrzmieć z innymi członkami zespołu, ponieważ prawdopodobnie wolą oni zdobyć trochę użytecznej wiedzy na temat tego projektu.

Kolejnym argumentem może być konkretny pomiar kosztów prac rozwojowych / utrzymania. Wyobrażam sobie, że programista dobrze zorientowany w CodeIgniter może rozwijać się szybciej niż twój kolega, pisząc wszystkie te zastrzeżone funkcje. Można to wykazać, budując identyczną stronę internetową - ty i CodeIgniter, on na swój sposób - i mierząc czas do ukończenia. Następnie dokonaj zestawu modyfikacji / rozszerzeń stron, ponownie mierząc czas do ukończenia. Oczywiście specyfikacja powinna zostać przygotowana przez osobę niezależną od was obu, aby walczyć na neutralnym gruncie.

Kolejnym - jak wspomniałeś - jest jakość kodu. Gdy strony będą gotowe, uruchom na każdym z nich ten sam zestaw testów akceptacyjnych i porównaj gęstość błędów.

Oczywiście, gdy jesteś pod presją czasu, może nie być możliwości zatrzymania się i wykonania takich pomiarów. Prawdopodobnie chcesz więc szybko rozwiązać ten dylemat. Spróbuj przekonać innych członków zespołu (np. Każąc im przeczytać nadchodzące odpowiedzi na Twój post tutaj :-), aby wywrzeć na niego presję grupową. W końcu, jeśli naprawdę nie da się go przekonać, możesz podzielić projekt na dwie części, jedną dla niego i - najlepiej - dla reszty zespołu, używając CodeIgniter. Skoncentruj się na wykonywaniu własnych zadań najlepiej jak potrafisz i pozwól mu robić, co tylko zechce. Wyniki prawdopodobnie będą mówić same za siebie.


Podoba mi się pomysł testu prędkości, aby to udowodnić. Jakie testy akceptacyjne moglibyśmy uruchomić? Z pewnością zasugeruję to, ale nie jestem pewien, czy będzie on dobrze pasował do niego (lub grupy), ponieważ wszyscy mamy inne terminy do zarządzania i wątpię, aby ktokolwiek szczególnie chciał napisać specyfikację lub „marnować czas” (ponieważ Jestem pewien, że zostanie to postawione).
Andy Hunt

1
Nauka, to działa: xkcd.com/54
StuperUser

5

Uważam, że musisz zaangażować pozostałych 3 członków drużyny. Oboje musicie przedstawić im swoje argumenty i wyjaśnić im różne rzeczy, aby zrozumieli. Pod koniec dnia będą musieli również pracować z tą bazą kodu. A jeśli wszyscy są równi, powinni mieć coś do powiedzenia nad tym, z czym chcą pracować.

Myślę, że dobrym podejściem dla każdego z was byłoby przedstawienie korzyści płynących z poszczególnych rozwiązań i pokazanie pozostałym członkom zespołu, dlaczego uważasz, że to najlepsza droga. Następnie pozwól im zdecydować. Jest ich 3, więc będzie remis.

Jedną rzeczą, na którą powinieneś zwrócić uwagę, jest to, że jeśli jest to twój projekt starszy, a pozostali członkowie zespołu nie mają innego doświadczenia, projekt ten musi odzwierciedlać pracę, jaką mogą wykonać dla potencjalnych pracodawców. Jeśli zrobisz to dobrze, może to być dobry punkt do rozmowy w wywiadzie. Wiem, że pytam nowych absolwentów o zarys ich projektu dla seniorów oraz o to, jak został zaprojektowany i opracowany.

Jeśli pójdą z podejściem drugiego faceta, będziesz musiał go wyssać. Ale nie porzucaj nadziei. Wymyśl dobry projekt, aby chaos, który pisze, nie wpłynął na wszystko. Jeśli masz czas, zrób trochę kodu, uporządkuj niektóre z jego rzeczy i pokaż mu, że nie musi za każdym razem wymyślać koła na nowo.


Szczerze mówiąc, nie myślałem o tym, jak to odbija się na pozostałych w grupie. Na pewno to zaznaczę.
Andy Hunt

1

Czuję, że college jest jak piaskownica. Większość rzeczy, które tam robisz, nie są używane podczas wdrażania. Dzięki temu masz dużo więcej swobody w eksperymentowaniu i wydostaniu się ze strefy komfortu. Przeglądaj nowe rzeczy, ponieważ niepowodzenie nie będzie miało zbyt dużego wpływu. Również w twojej sytuacji członkowie twojego zespołu mają tę dodatkową zaletę, że pomagają im osoby z wcześniejszą wiedzą.

Jeśli chodzi o drugiego doświadczonego członka zespołu, nie musiał on przychodzić na studia, jeśli nie chciałby uczyć się niczego nowego. To dobra okazja, aby dowiedzieć się czegoś nowego i dodać to do swojego zestawu narzędzi.

A dla niedoświadczonych członków zespołu ich szanse na zatrudnienie / lepsze zatrudnienie wzrosną wraz z ramami takimi jak CodeIgniter w ich życiorysie (w rzeczywistości wiedza uzasadniająca to w życiorysie).

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.