Jak komunikować się ze współpracownikiem, który uważa ramy za uderzenie wydajności

Jak sprzedać pomysł typu „powinniśmy używać jQuery, ponieważ jego wysoce zoptymalizowana i kompatybilna z różnymi przeglądarkami” lub „struktura encji jest fajna, ponieważ jest schludna i dba o nasz model automatycznie”, gdy powszechną odpowiedzią jest ogólne wyrażenie, takie jak „jquery nie działa dobrze ”lub„ byty wprowadzają 12 kolumn na stole, gdy potrzebujemy tylko 10 ”?

Jestem pragmatycznym facetem, który ma tendencję do ufania aksjomatom, które rozwinąłem przez doświadczenie (nie jest to problem z wydajnością, dopóki nie nastąpi wyraźne spowolnienie). Nie wiem, czy jest jakaś konkretna „kategoria”, do której pasuje druga skrajność, podczas gdy wszystko stanowi problem z wydajnością, dopóki nie zostanie udowodnione inaczej ... lub nawet od czego zacząć komunikację tutaj.

Przynieś im twarde fakty!

Na przykład istnieją testy wydajności dla platform ORM i JS. Ponadto wszystkie frameworki i ORM mają dobre argumenty sprzedażowe na swojej stronie głównej.

Po przeczytaniu komentarza uważam, że w twoim przypadku problemem nie jest odpowiednia technologia. Ludzie odmawiają nauki nowej technologii.

Wcześniej miałem do czynienia z tym problemem, ponieważ ludzie chcieli wynaleźć koło na nowo. Zazwyczaj tłumaczę im, że możemy ulepszyć i dopracować produkt, jeśli poświęcamy czas na doskonalenie tego, co ważne, a nie tego, co leży pod spodem. Plus ... Mam na myśli ramy dla POWODU, a wydajność naprawdę nie jest tak dużym problemem w dzisiejszych czasach. Niezawodność jest ważniejsza, a jeśli frameworki mają dobre recenzje / oceny, to prawdopodobnie są bardziej niezawodne niż coś, co każdy może wymyślić w locie.

Wydaje się, że wszyscy nie zgadzają się z twoim kolegą, ale myślę, że powinieneś poważnie potraktować jego argumenty, jeśli nie z innego powodu niż zrozumienie jego punktu widzenia. Mocno wierzę w frameworki, kiedy są one potrzebne lub gdy faktycznie zapewniają optymalizację, ale wierzę również, że nadmierne poleganie na frameworku może w niektórych przypadkach prowadzić do słabego rozwoju.

Myślę, że powinieneś podchodzić do problemu mniej z punktu widzenia tego, że twój współpracownik się myli, a bardziej z punktu widzenia tego, że użycie frameworków, o których myślisz, skróci czas programowania, wydajność, konserwację itp.

Zawsze staram się pamiętać o użyciu odpowiedniego narzędzia do właściwej pracy. Nie potrzebuję sań 12lb (jQuery) do wbijania gwoździa w celu zawieszenia obrazu (zamiana obrazu). Ale jeśli napotkam sytuację, w której wiszę zdjęcie, które wymaga kolca kolejowego, aby utrzymać go na ścianie, lepiej przygotuj się do sań.

ma rację, jest nad głową

ale założenie, że narzut szkieletu jest czymś więcej niż rozwiązaniem kodowanym ręcznie, może nie być poprawny, a nawet jeśli jest poprawny, narzut może nie być znaczący.

zaproponuj test:

• oboje piszecie coś realistycznego, ale stosunkowo małego
• używasz jQuery (lub cokolwiek innego), a on nie może nic używać
• zmierzyć dwie rzeczy:
  1. ile czasu zajmuje wam oboje kodowanie rozwiązania (zakładając, że twoje umiejętności kodowania są równoważne)
  2. ile czasu zajmuje wykonanie (pełny cykl życia) każdego rozwiązania

istnieje prawdopodobieństwo, że frameworka będzie miała niewielki narzut - bardzo mały - ale ogromna różnica w tym, ile czasu zajmuje kodowanie [i debugowanie!] rozwiązania

wtedy twój przyjaciel może kłócić się z faktami, a nie z tobą

Uwaga: bądź przygotowany na ciągły opór; wiele razy reakcja na frameworki jest określana technicznie, ale w rzeczywistości jest zasłoną dymną dla „nie wymyślono tutaj” lub „nie chcę uczyć się innego narzędzia”

Przypomnij swojemu nowemu koledze, że robi różne optymalizacje przedwczesne. Skąd może wiedzieć, że te ramy reprezentują niedopuszczalny spadek wydajności, dopóki nie zostanie wykazane, że powodują problem. Tymczasem twoja wzajemna produktywność z pewnością spadnie ZMNIEJSZENIA przy wszystkich dodatkowych pracach, które musiałeś wykonać.

Co powiesz na wyjaśnienie wpływu wydajności na czas realizacji projektu, gdy nie korzystasz z tych ogromnych, oszczędzających czas i przetestowanych w bitwie platform?

Jedną z opcji byłoby powiedzenie mu, że będzie odpowiedzialny za dostrajanie wydajności - jeśli można to wykazać, istnieje problem z wydajnością! Lub, jeśli masz zasoby, zbuduj dwa Dowody koncepcji: budujesz swój przy pomocy jQuery i wszystkiego, czego chcesz. Może zbudować swój własny, superszybki, ręcznie toczony system. Nie pozwól, aby trwało to dłużej niż kilka dni (jest to dowód koncepcji) i sprawdź, kto osiąga lepsze wyniki na końcu.

I oczywiście, jak wspomnieli inni, uzyskaj twarde liczby i profile wydajności dla obu stron argumentu.

Po pierwsze, może być odpowiedni dla twojej konkretnej sytuacji.

Ponieważ wydaje się, że masz problemy z nakłonieniem go do spojrzenia na twój punkt widzenia, musisz wykonać lepszą pracę, aby go przekonać.

Wy dwaj jesteście w dwóch różnych punktach wzdłuż linii „Buduj” i „Kup”. To dość długa linia. Po lewej stronie w „Build” masz SpaceX, który musiał zbudować całą branżę. Po prawej stronie w „Kup” masz pełny outsourcing wszystkich funkcji IT do IBM, HP i podobnych, a firma w ogóle nie koduje. Pośrodku, w odległości około 2 mm, jest was dwoje. Oboje musicie przekonać kierownictwo, że wasze podejście do „budowania vs kupowania” na platformie i orm i takie - i przez „kupowanie” mam na myśli „nie wbudowane we własnym zakresie” - leży w najlepszym interesie firmy, długo -semestr. Twitter by umarł, gdyby zlecił IBM. Przetoczyli swoje. Pomyśl o tym.

Tak czy inaczej, zarząd musi zejść z pola golfowego i tam wejść i wykonać swoją pracę.

Cóż, dla ORM odpowiedź brzmi: „Tylko jeśli napiszesz zapytanie w ten sposób, to samo można powiedzieć o SQL”. Jak powiedzieli inni, potrzebne są twarde fakty.

Zadaj też konkretne pytania, aby zagłębić się w to, co mówi - „Czy możesz podać mi przykład działania JQuery, ponieważ nie jest to moje doświadczenie”.

Trzecia opcja i mądry stary programista mi to zasugerowali, po prostu i tak dodaj „rzecz” (zakładając, że nie ma złych problemów).

Poszukiwanie zgody prowadzi tylko do odpowiedzi „nie”. Wejdź tam, a następnie możesz poprosić ich o wskazanie określonych obszarów i poprosić, aby powiedzieli ci, na czym polega problem.

„Hej, ten kod EF przywraca tylko 2 potrzebne dane z tej tabeli, w czym problem” itp.

Oczywiście musisz być pewny siebie i narzędzia, którego używasz, zanim zastosujesz to podejście! :-)

Odrzucanie takich bibliotek z ręki jest głupie, a czasem aroganckie. Godziny pracy zainwestowane w te produkty, a myśl za nimi sprawia, że ​​odrzucenie ich jest po prostu zbyteczne.

Może się zdarzyć, że twój współpracownik ma rację, ponieważ musisz porównać i przewyższyć wymagania oprogramowania, które jest częścią projektu. Może się zdarzyć, że rozwiązanie ORM lub ActiveRecord jest po prostu przesadą lub wręcz przeciwnie, że oprogramowanie potrzebuje naprawdę połączonego rozwiązania dla DB, a ORM po prostu go nie wyciszy.

Uwzględnienie tych elementów jest ważne przy każdym projektowaniu oprogramowania.

W przypadku bibliotek po stronie klienta powiedziałbym, że to głupie, ponieważ zawsze możesz znaleźć platformę odpowiednią dla twoich potrzeb. I jak niektórzy mówili przede mną: Co jest lepszego niż ramy przetestowane w bitwie?

Pozwól mu usunąć bzdury ze wszystkich problemów związanych z przeglądarkami, chętnie przyjdzie do ciebie w sprawie sposobu korzystania z frameworka.

A tak przy okazji, miałem kiedyś szefa, który nie brał pod uwagę frameworków. Właśnie pokazałem mu, jak łatwo jest składać żądania ajax zamiast kopiować funkcje raz po raz (co było głupim pomysłem), cóż, nie wiedział, jak napisać kod, więc ..