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:
- Nie wymyślać koła na nowo
- Dobrze napisana i przetestowana baza kodu do pracy
- Rozpoczęcie pracy (termin jest bliższy niż chcielibyśmy)
- Szybkość rozwoju
- 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ć?
he doesn't want to use code he hasn't personally written.
Lepiej wyrzuć swój system operacyjny, IDE, telefon, sygnalizację świetlną itp.
I want to know exactly how everything works
jest 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.
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.