W jaki sposób zespoły programistów mogą zapobiec niskiej wydajności aplikacji konsumenckich?

32

Kiedy wcześniej zapytałem, co jest odpowiedzialne za wolne oprogramowanie, kilka odpowiedzi, które otrzymałem, sugerowało, że był to problem społeczny i zarządzania:

To nie jest problem techniczny, to problem z marketingiem i zarządzaniem. Właściwie menedżerowie produktu są odpowiedzialni za napisanie specyfikacji tego, co powinien otrzymać użytkownik. Wiele rzeczy może się nie udać: menedżer produktu nie umieścił odpowiedzi przycisku w specyfikacji ... Ludzie ds. Kontroli jakości wykonują mierne testy w stosunku do specyfikacji ... jeśli kierownictwo produktu i personel kontroli jakości śpią za kierownicą, my, programiści, nie możemy tego nadrobić. - Bob Murphy

Ludzie pracują nad aplikacjami dobrej wielkości. Gdy działają, pojawiają się problemy z wydajnością, podobnie jak błędy. Różnica polega na tym, że błędy są „złe” - krzyczą „znajdź mnie i napraw mnie”. Problemy z wydajnością po prostu siedzą i stają się coraz gorsze. Programiści często myślą: „Cóż, mój kod nie miałby problemu z wydajnością. Raczej zarząd musi kupić mi nowszą / większą / szybszą maszynę”. Faktem jest, że jeśli programiści okresowo polują na problemy z wydajnością ( co w rzeczywistości jest bardzo łatwe ), mogą po prostu je usunąć. - Mike Dunlavey

Więc jeśli jest to problem społeczny, jakie mechanizmy społeczne może wprowadzić organizacja, aby uniknąć wysyłania wolnego oprogramowania do swoich klientów?

Crashworks
źródło
2
Komentatorzy: jeśli podoba ci się pytanie, oddaj je na głos. Jeśli masz odpowiedź, zostaw ją jako odpowiedź , a nie komentarz. W przeciwnym razie zostaw komentarz, jeśli uważasz, że pytanie zostało wyjaśnione lub poprawione, lub jeśli masz link do powiązanego zasobu.

Odpowiedzi:

34

Przy poprawnie napisanych i kompletnych wymaganiach nie ma czegoś takiego jak rozróżnienie między błędami a niską wydajnością . Ponieważ określasz wydajność jako wymaganie niefunkcjonalne, słaba wydajność staje się błędem, tak jak każdy inny błąd, i zostanie przechwycona przez kontrolę jakości i rozwiązana przez programistów przed wydaniem.

Czy istnieje problem społeczny? Nie wydaje mi się Głównym problemem jest to, że wymagania są niekompletne. Pracując przez wiele lat jako freelancer, nigdy nie widziałem niefunkcjonalnego wymagania mówiącego, że określone zadanie musi wykonać średnio w maksymalnie N sekundach. Jeśli menedżer / klient / interesariusz lub cokolwiek innego nie przejmuje się zasobem związanym z wydajnością, dlaczego ja, jako programista, niepokoiłbym się nim, skoro ludzie, którzy muszą się tym przejmować, w ogóle się tym nie przejmują?

Jest jeszcze jeden czynnik, który wpływa na niską wydajność: fakt, że programiści pracują na drogich komputerach, które działają dobrze . Kiedy od lat pracujesz na czterordzeniowym komputerze z 8 GB pamięci RAM, wysokiej klasy dyskiem SSD, najnowszym systemem operacyjnym itp., Bardzo trudno jest wyobrazić sobie, jak aplikacja będzie działać w systemie Windows XP na dwurdzeniowym komputerze 512 MB pamięci RAM i stary dysk twardy wypełniony w 90% i nie defragmentowany przez lata. Niestety w niektórych krajach ostatnim przypadkiem jest ten, który widzimy dla większości konsumentów aplikacji. Im większa przepaść między komputerami programistów a komputerami konsumenckimi, tym trudniej jest programistom zadbać o wydajność swojej aplikacji.

MainMa
źródło
2
Opierając się na tym komentarzu, myślę, że najlepszym sposobem, aby zapewnić, że przynajmniej twórcy (i testerzy) są świadomi tych problemów, należy ZAWSZE przetestować je na starszym, niższym końcu wymagań sprzętowych lub maszynach wirtualnych . Jako deweloper trudno mi powiedzieć te słowa, ale czasami nie pracujemy nad rozwiązaniem problemu, dopóki sami go nie doświadczymy. Dlatego przynajmniej wymuszenie na programistach testowania ich aplikacji w systemach podrzędnych zmusi ich do znalezienia wydajnych rozwiązań z powodu niskiej wydajności, której bezpośrednio doświadczają.
RLH
3
Nie sugerowałbym tego na co dzień, ponieważ zmniejszy to ogólną wydajność działu kontroli jakości i obniży pracowników pracujących na wolnych maszynach. IMHO, stawianie wskaźników wydajności jako wymagań jest wystarczające, jeśli jest określone poprawnie (tj. Na jakiej maszynie należy wykonać automatyczny test wydajności, przy jakim obciążeniu, ile razy należy przyjąć średnią itp.).
Arseni Mourzenko
1
Pracuję zgodnie z wymaganiami, które mają formalne (niefunkcjonalne) wymagania dotyczące wydajności. Jest to oprogramowanie krytyczne dla życia w czasie rzeczywistym. Dane techniczne to „odpowiedź średnio w xi 95% czasu”. Oprogramowanie nadal jest powolne w porównaniu z tym, czym mogłoby być, ale wiemy, kiedy poprawić wydajność, ponieważ staje się defektem, podobnie jak każda inna czynność, którą system robi nieprawidłowo. Pozostawienie programistom decyzji to bardzo zły pomysł. Większość deweloperów, pozostawionych tam własnym urządzeniom, pod każdym względem inżyniera i potrójnie z obawami dotyczącymi wydajności.
mattnz
3
Innym problemem związanym z wydajnością jest to, że nie można przetestować wydajności na niczym innym, jak tylko na trywialnym systemie, dopóki końcowa integracja nie zostanie zakończona, często długo po zakończeniu pracy twórców oprogramowania. Weź aplikację na telefon - działa dobrze na gołym, błyszczącym fabrycznie nowym telefonie, ponieważ kilka pobranych aplikacji i pamięć się
zapełniają
2
Problem polega na tym, że NIGDY NIE dostaniesz „poprawnie napisanych i pełnych wymagań”. Nie dotyczy aplikacji o dowolnym rozmiarze ani złożoności.
CaffGeek
12

Problem(?):

  • Klient (lub użytkownik końcowy) nie narzeka (wystarczająco)
  • Dlatego kierownik projektu (/ produktu) nie uważa tego za wymóg
  • W ten sposób programista nie ma czasu, aby to naprawić.

Musisz zacząć od początku, edukować klientów. Ale jeśli kupią iPhone'a zamiast szybszego, mniej błyszczącego telefonu, programiści mają rację, spędzając czas na wyglądzie zamiast na wydajności. Organizacja nie stanowi problemu.

Oczywiście niektóre rzeczy i tak mogą pomóc. Oczekiwanie na zautomatyzowane testy jest denerwujące, więc jeśli masz zautomatyzowane testy, programiści mają stałą informację zwrotną na temat problemów z wydajnością i będą bardziej skłonni je rozwiązać (jako problem techniczny, a nie jako funkcja).

Ale nie możesz zrobić wszystkiego. Optymalizuje lub dodaje funkcje, a ci, którzy wydają pieniądze, decydują.

Ale dobra wiadomość: zauważyłem, że aplikacje SaaS / Cloud / Buzzword bardzo tu pomagają. Kiedy ludzie wybierają między kilkoma podobnymi aplikacjami internetowymi i zaczynają testować na żywo, zamiast najpierw tworzyć sztuczne listy „wymaganych” funkcji, szybciej reagują na nie, a tym samym wydajność zyskuje większą uwagę.

Jaap
źródło
Wiem to bardzo dobrze, wystarczy
odmierzyć
8

Niestety, największym problemem jest to, że nie możesz zrobić wszystkiego. Masz datę wysyłki i wiesz, że jest powolna, ale POTRZEBUJESZ wprowadzić funkcje X, Y, Z na rynek.

W twoim umyśle wolno możesz to naprawić później, ale aplikacja przynajmniej działa.

Martwisz się więc funkcjonalnością i estetyką (ponieważ użytkownicy często skupiają się na estetyce). W następnej wersji poprawisz wydajność.

Ale PM po prostu daje listę funkcji i nie ma czasu na poprawienie wydajności.

Błędne koło trwa nadal.

CaffGeek
źródło
3
Naprawia się to tylko wtedy, gdy PM daje ci „funkcję” o nazwie „poprawiona wydajność”!
FrustratedWithFormsDesigner
4
Zanim premier chce poprawić wydajność, jedynym prawdziwym sposobem na to jest przepisanie :)
Job
Kluczową kwestią jest to, że w przypadku większości aplikacji konsumenckich wydajność nie jest funkcją sprzedającą oprogramowanie. To nie jest coś, co wygląda błyszcząco na liście kontrolnej „Rzeczy, które robi to oprogramowanie”. Gry komputerowe są świetnym przykładem tego myślenia. Wymagania systemowe dotyczące gier stale rosły w czasie, co oznacza, że ​​nowe gry są wolniejsze z tym samym sprzętem, co wcześniej, ponieważ wyższa liczba klatek na sekundę nie przeniesie tego pudełka z półki, ale realistyczne środowiska renderowane w czasie rzeczywistym z detalami fraktalnymi będzie ...
Malachi
1
+1 Tutaj naprawdę pomaga mieć konkurenta z dobrą wydajnością. Kiedy premierzy to zobaczą, przestraszą się i proszą o zrobienie czegoś z tym.
Mike Dunlavey
1
@Chad, prawdopodobieństwo warunkowe jest wysokie, ale absolutne jest niskie. Pracuję nad aplikacją, która rozpoczęła się jako 16-bitowy program C dla wersji Windows „tuż po moim urodzeniu”. Przewiń do przodu, że do dziś i wielu lat i dziesiątki programistów później masz mieszankę C, C ++, C #, VB.Net i wielu dostawców SQL. Przepisywanie niektórych kluczowych części aplikacji na F # nie brzmi teraz jak okropny pomysł ...
Job
4

Zgadzam się z innymi, że powinniśmy znaleźć sposoby, aby programiści bardziej dbali o problem, na przykład zmuszając ich do testowania na wolniejszym sprzęcie i osiągania celów wydajnościowych. Wszystko w porządku, ale tak naprawdę, jeśli chodzi o dostrajanie wydajności -

Ludzie muszą wiedzieć jak - a nie wiedzą

Mogą tak myśleć , ale po prostu przejrzyj wszystkie pytania i odpowiedzi związane z wydajnością na StackOverFlow i na tym forum. To bolesne, jak wielu z nich wykazuje bardzo mało zdrowego rozsądku na temat wydajności.

To nie jest coś, o czym można tylko rozmawiać, ludzie muszą się uczyć, robiąc to. W tym trybie mogą przebywać tylko wtedy, gdy biorą lekcje lub uczą się nowych rzeczy z książki lub bloga.

Więc jedynym sposobem na rozwiązanie tego problemu jest złapanie ludzi uczących programowania i nauczenie ich, jak to robić.

Niebo wie, próbowałem na tych forach, jak w -

Każdy może to zrobić. Po prostu muszą to zrobić .

Mike Dunlavey
źródło
4

Ustaw wydajność jako wymaganie.

Robert Harvey
źródło
+1: To takie proste. „Funkcja X musi zostać ukończona za Y milisekund”.
don; 'nie zapomnij podać środowiska, w którym zostanie uruchomiony - np. mamy NFR, który wykonałby do standardu, gdy jest uruchomiony w sieci z opóźnieniem 40 ms (tj. WAN). Jeśli tego nie zrobisz, deweloperzy zaprezentują coś, co działa dobrze tylko na superkomputerze.
gbjbaanb
2

Pisanie kodu wykonawczego jest trudne. Wymaga solidnego zrozumienia takich pojęć, jak wątkowanie, asynchroniczna obsługa zdarzeń, buforowanie i asymptotyczna złożoność. Sądząc po grupach programistów, z którymi współpracowałem, około 20–40% jakiejkolwiek grupy nie rozumie tych pojęć wystarczająco dobrze, aby w codziennej pracy uwzględnić kwestie wydajności.

Jednak ci programiści są oczywiście nadal przydatni dla firmy, ale przydzielani są do zadań, które nie są uważane za krytyczne pod względem wydajności, więc otrzymujesz odtwarzacz Blu-ray, który może bezproblemowo odtwarzać strumienie Netflix bez pomijania ramek, ale zajmuje to 30-60 sekund aby otworzyć pozycję menu wyświetlającą kolejkę.

O ile nie jesteś firmą zajmującą się oprogramowaniem typu hotshot, która może pozwolić sobie na zwolnienie 20% personelu i zastąpienie go bardziej doświadczonymi (i droższymi) programistami, jedynym prawdziwym sposobem na rozwiązanie tego problemu jest szkolenie programistów i zgłaszanie błędów. Nie wiem, jak to jest w innych firmach, ale tutaj, jeśli programiści zauważą problem z wydajnością, którego nie mamy czasu ani priorytetu biznesowego do rozwiązania, mamy pełne prawo do zgłoszenia własnego błędu. Może zająć kilka wydań, aby dostać się na szczyt zaległości, ale zwykle są one ostatecznie rozwiązywane.

Karl Bielefeldt
źródło
Ponadto nawet świetni programiści potrzebują doskonałych narzędzi do instrumentacji i profilowania, aby uzyskać wgląd w problemy z wydajnością. (Istnieje wiele paradygmatów programistycznych o charakterystykach wydajności, które wymykają się analizie śladu stosu.) Narzędzia te są ogólnie dostępne dla platform Linux w stylu open source, ale na platformach zastrzeżonych i niestandardowych narzędziom tym często odmawia się pracowników.
rwong
Nie zgadzam się z wyrażonym sentymentem. Osiągnięcie maksymalnego poziomu może być bardzo trudne, ale często można znaleźć dużo nisko wiszących owoców. Więc po prostu zrób proste profilowanie (być może technikę sugerowaną powyżej przez Mike Dunlavey) i spróbuj naprawić oczywiste problemy. Często to zajmie długą drogę.
sleske 30.09.11
2

Jeśli wymagana jest wydajność, sprawdź ją.

W przeciwnym razie Wally może napisać nieskończoną pętlę i wyjść wcześnie „To zajmuje chwilę”. On może żądać.

Test akceptacji oprogramowania powinien zawierać szczegółowy test akceptacji różnych charakterystyk wydajności działania.

Jeśli tego nie zrobisz, nie wprowadzasz żadnych zmian w produkcie.

Wydajność (podobnie jak zużycie zasobów) powinna zostać zapisana w budżecie na podsystemy. Następnie testy akceptacji podsystemu mogą je sprawdzić.

Następnie możesz wcześnie i często testować wydajność. Nawet testy jednostkowe mogą to sprawdzić.

Dlatego teraz programiści mają to jako kryterium akceptacji i mogą odpowiednio dostosować swoje podejście.

W miejscu, w którym teraz pracuję, test warunków skrajnych wydajności jest 2x większy niż jakikolwiek znany nam zestaw danych klientów. Regularnie psuje nową wersję produktu. Dobre testy.

Tim Williscroft
źródło
2

Pamiętam raz w połowie lat 90. i spędziłem trochę czasu próbując coś zoptymalizować, a współpracownik powiedział mi: „To działa na pentium, kogo to obchodzi?” .... to było otwieracz do oczu. Niestety, był to tylko wierzchołek góry lodowej. Słyszałem o tym w całej mojej karierze - choć część „pentium” zmieniała się z czasem.

Jedynym sposobem, aby zwrócić uwagę przeciętnego programisty, jest brak wydajności, który może być postrzegany jako błąd ze strony klienta. W zależności od aplikacji i odbiorców może to być łatwe lub trudne zadanie (widziałem oba). Jeśli publiczności nie zależy na niskiej wydajności, programiści nigdy nie będą (szybko, dobrze, szybko - wybierz dwa).

geoffjentry
źródło
2

Ale programista nie powinien potrzebować listu od QA, aby uświadomić sobie, że 3-sekundowe opóźnienie między naciśnięciem klawisza a odpowiedzią jest niedopuszczalne

Zgadzam się, że nie powinno. Powinno to zająć więcej: dowód, że uzyskane opóźnienie jest istotne dla użytkowników końcowych .

Ponieważ nie podałeś żadnego kontekstu, wydaje się całkiem możliwe, że opóźnienie w środowisku deweloperskim / QA jest spowodowane lokalnymi problemami powolnego dostępu do dysku / pamięci / sieci. W takim przypadku kontrola jakości i programista po prostu marnują wysiłki na naprawianie rzeczy, które nie mają znaczenia dla użytkowników końcowych.

Poleganie na programistach w testowaniu wydajności jest tak samo produktywne, jak rzucanie kostką, aby wybrać element funkcjonalności, który przyspieszy. Aha, i jest mniej więcej tak niezawodny - „programiści zazwyczaj mają okropną intuicję na temat tego, gdzie faktycznie będą występować problemy z wydajnością aplikacji” ( Brian Goetz ).

  • Byłem w projekcie, w którym kiepskie kierownictwo uznało kiedyś, że ich błyskotliwi marketingowcy i inteligentni programiści są wystarczająco dobrzy, aby poradzić sobie z problemami dotyczącymi wydajności klientów. To była świetna lekcja. Odrzucone wydanie, pół roku starań na śmieci, a firma prawie straciła strategicznego partnera. Na koniec zaprosili profesjonalistów (ekspertów w zakresie testów porównawczych, statystyki, UX, optymalizacji niskiego poziomu, itp.) Oraz specjalistów, którzy naprawili ten problem.

czy wszyscy programiści powinni przeprowadzić własną kontrolę jakości, aby natychmiast dostrzegli takie problemy?

Fakt, że jest to wykonalne, nie oznacza, że ​​jest to dobra droga. Przeciwnie - z mojego doświadczenia był to jeden z najbardziej niezawodnych sposobów na zmniejszenie produktywności programistów . Prawie tak dobre jak niekończące się spotkania, a nawet lepsze niż przeprowadzanie wywiadów z kandydatami.

  • Jako były tester pomyślałem kiedyś, że połączenie rozwoju i kontroli jakości nie powinno stanowić problemu. Wyglądało na to, że różnica między rutynowymi testami programistycznymi a systematyczną kontrolą jakości nie będzie miała większego znaczenia. Myślałem, że separacja programistów od kontroli jakości jest jedynie tradycją w branży oprogramowania. Nauczyłem się dość ciężko, że tak nie jest. Separacja okazała się kwestią skupienia i produktywności, a także dość poważna.

Jeśli występuje problem z wydajnością, daj mi tylko punkt odniesienia i ustal docelową wydajność, a ja postaram się go osiągnąć. Nie jestem zbyt dobry w testowaniu wydajności, ale wiem trochę o optymalizacji.

komara
źródło
downvoter - czy zdarzyło Ci się współpracować z profesjonalnymi testerami pokrywającymi potrzeby zespołu programistów w zakresie kontroli jakości i testowania wydajności? Jeśli nie, należy rozważyć nadanie jej szansę
gnat
1

Myślę, że w 99% przypadków problemem jest pełzanie zakresu. Na przykład z rejestratorem. Można by pomyśleć, że jest to łatwe, ale wtedy TIVO lub konkurent wprowadza nową dobrze przyjętą funkcję. Następną rzeczą, którą wiesz, że nowa funkcja jest na talerzu. Może to być niezgodne z istniejącym produktem i nie będziemy go przerabiać, co zajmie dużo czasu. Tak więc funkcja się zacina i zmniejsza wydajność. Pewnie, że dane są dostępne, aby uzyskać informacje, ale jeśli nie pomyślano o uzyskaniu tych informacji, istnieje duża szansa, że ​​nie będzie to łatwe. Teraz ma złożony proces gromadzenia tych informacji za każdym razem, gdy zbliżasz się do listy programów.

SoylentGray
źródło
1

Ignorowanie programistów, którzy nie dbają o to ...

Myślę, że często programiści pracujący nad kodem nie mają narzędzi do ciągłego mierzenia wydajności.

np. jeśli można zmierzyć czas reakcji aplikacji (np. aplikacja internetowa lub zapytania do bazy danych itp.) - Czy otrzymujesz obecnie powiadomienia (e-mail, SMS, cokolwiek), które wskazują na „najgorszą” 10 wykonywać (lub przekraczać określony próg) odpowiedzi?

W wielu, wielu przypadkach - programiści nie otrzymują tych informacji z wdrożeń „w świecie rzeczywistym”, w wyniku czego bardzo łatwo można zignorować informacje, których nie widać.

Jeśli jednak codziennie / kilka godzin otrzymujesz wiadomość e-mail z informacją, że ekran „x” zajmuje 13 sekund i ładuje się następująca kwerenda SQL SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN..., lepiej uwierzyć, że programista może (i mam nadzieję) że wszystko się naprawi to.

Tak więc chociaż chciałbym wierzyć, że wszyscy programiści zrobić wydajność poważnie myślę, że brak widoczności na problem (s) jest często winowajcą.

Uwaga: Myślę, że jest to coś, o co programiści powinni prosić o dostęp (lub nawet opracowanie takiej funkcji), a zarząd powinien zapewniać / finansować takie narzędzia.

scunliffe
źródło
1

Czy możesz wymyślić lepsze przykłady, w których możemy obwinić programistów? Oprócz Eclipse, a jeden z komentatorów już zauważył, że robią to wtyczki (moja pierwsza instalacja każdej nowej wersji Eclipse działa jak błyskawica, ale kiedy dodam inne narzędzia, zaczyna zwalniać), twoje przykłady mogą nie być programistą i związany z kodem, ale związany ze środowiskiem.

Minęły dni, kiedy program działał na komputerze osobno i ustalał, czy jest „szybki”, czy „wolny”. Inne przykłady, które podajesz, zależą od ich środowiska - bieżące przeciążenie sieci, to, czy serwery zaplecza są przeciążone, źle skonfigurowane karty sieciowe, wadliwy kabel, liczba innych osób korzystających z niego w pobliżu lub setki innych zmiennych. na przykład. nasz dostawca hostingu naliczył dodatkową opłatę za połączenia gigabitowe z serwerem, ale ostatecznie ustaliliśmy, że wszystko to przeszło przez starożytne urządzenie firewall z portami 10 Mb. Problemy te się zmieniają i są trudne do znalezienia.

Uzgodniono, że jest wiele rzeczy, które mogą zrobić programiści (minimalizacja przepustowości, sztuczki interfejsu użytkownika, które poprawiają szybkość reakcji i pokazują postępy, aby sprawiać wrażenie, że jest szybki). Ale kiedy wkroczysz do prawdziwego świata, istnieją różne okoliczności, których uczysz się tylko przez doświadczenie (i obserwujesz, jak twoje założenia rozpadają się przed tobą).

jqa
źródło
Podane przeze mnie przykłady to wszystkie przypadki, w których wydajność była słaba w czysto lokalnym środowisku - rejestrator opóźnia się tylko w nawigacji po menu lokalnie nagranych programów. iTunes powoli przegląda lokalne dane, a nie patrzy na sklep. Nawet w „trybie samolotowym” - bez żadnej sieci - iPhone 3G wyświetla tyle zdjęć, że czasami strażnik systemu operacyjnego zabije aplikację, zanim się uruchomi. Wszystko to są przykłady przypadków, w których programiści dokładnie wiedzieli, na jaki sprzęt są kierowani, pisząc kod, a zwłaszcza na iPhonie, ponieważ z każdą aktualizacją było coraz gorzej.
Crashworks
@ Crashworks - ktoś usunął te przykłady z twojego pytania. Czy możesz dodać je ponownie ze szczegółami? Przykład zdjęcia brzmi, jakby działo się coś innego, jak brakująca zależność lub próbuje on znaleźć coś w Internecie i upłynął limit czasu. Czy uruchomiłeś debugowanie, aby zobaczyć, co się dzieje? Dobra historia polega na tym, że MS wypuściło HyperV, recenzent VMWare z radością zauważył, że chociaż zainstalował go dzień po wydaniu, musiał pobrać kilka aktualizacji systemu Windows. Czemu? proces aktywacji HyperV ponownie wykorzystał bibliotekę DLL IE8. W nowoczesnych środowiskach jest wiele gotów.
jqa
1

Ile chcesz zapłacić za lepsze oprogramowanie? Ile rynek będzie czekał na lepsze oprogramowanie? Jak niewiele cruft będzie chciał dodać do następnej wersji?

Jest to przełomowy rynek, na którym można znaleźć wiele kompromisów. Jeśli to naprawdę bzdura, rynek (lub powinien) zawieść produkt. Może jest wystarczająca liczba klientów, którzy mogą żyć z obecnym status quo?

Paddy3118
źródło
0

Myślę, że najbardziej ogólna odpowiedź na ten problem jest również najtrudniejsza do zarządzania, a mianowicie, że każdy programista powinien pamiętać o wydajności we wszystkim, co robi. Zdaję sobie również sprawę, że to trochę dziwactwo.

W zależności od wielkości projektu i odpowiedniego zespołu uważam, że posiadanie dedykowanych programistów wydajności może mieć dużą wartość.

Jako przykład pracowałem nad zespołem, w którym zespół projektowy (w tym około 30 programistów) miał co najmniej 2 osoby zajmujące się optymalizacją wydajności. Ta szczególna aplikacja była również dość podatna na problemy z wydajnością, ponieważ istniało mnóstwo składników interoperacyjności, nie tylko przez usługi sieciowe, ale także pod względem starszych warstw z różnymi komponentami mapowania danych i adaptera.

Wayne Koorts
źródło
0

Ważne jest doświadczenie z pierwszej ręki. Daj programistom szybki komputer do kompilacji i kompilacji, ale naprawdę powolny przeciążony komputer (jak może mieć pewien odsetek użytkowników) do uruchamiania aplikacji. (Można to zrobić w środowiskach programistycznych opartych na chmurze / serwerze, dzieląc maszyny wirtualne lub serwery według funkcji.) Daj im telefon komórkowy z na wpół rozładowaną baterią i wymagaj od nich używania go tylko do początkowego testowania aplikacji mobilnych.

Jeśli programiści zrozumieją klienta pod względem wydajności i żywotności baterii, nie uznają wydajności za jakąś półfałszą specyfikację zarządzania, którą należy umieścić na dole listy priorytetów. (Jak w: „hej, myślałem, że to przedwczesna optymalizacja” aż do zbyt późno).

hotpaw2
źródło
0

Przestań kupować te rzeczy i komentuj słabą wydajność wszystkich napotkanych recenzji online.

Jeśli urządzenia nadal się sprzedają, to oprogramowanie jest „wystarczająco dobre”, aby nie inwestować więcej czasu i pieniędzy. Jeśli złe recenzje na temat wydajności znacznie zmniejszają sprzedaż, to oprogramowanie jest „niewystarczająco dobre” i wymaga naprawy.

Jedynymi miernikami, które interesują producenta dóbr konsumpcyjnych, są sprzedaż i zysk na jednostkę.

James Anderson
źródło
0

Zgadzam się, że programistów należy uczyć lepiej maksymalizacji wydajności itp.

Myślę jednak, że rozwiązaniem nie jest zapewnienie programistom niemal konającego sprzętu do codziennego użytku. Jak stresujące będzie, jeśli Twoje studio wizualne ulegnie awarii dwa razy dziennie, zajęło to x sekund, aby zbudować takie rzeczy, y sekund, aby otworzyć rozwiązanie, z sekund, aby zmienić okna. Nie sądzę, aby było to bardzo opłacalne dla firmy, ponieważ sprzęt jest tani, a czas programistów jest drogi.

Ponieważ kolejną ręką, która będzie obsługiwać kod, będzie zespół ds. Kontroli jakości (testowania), czy nie lepiej byłoby uczyć ich o znaczeniu wydajności, mieć standard akceptowalnego standardu wydajności itp. Jako standard korporacyjny (cóż, w idealnym świecie , standard wydajności powinien być w specyfikacji, ale to nie zdarza się bardzo często)? (tzn. zwykła strona / karta zmieniająca ee przedsiębiorstwa powinna nastąpić natychmiast, „zapisz aktualizację powinno nastąpić za x sekundę”, jeśli jest to wtedy krytyczna aplikacja ...). Komputer, na którym działają zespoły kontroli jakości, powinien być typowym komputerem użytkownika. (nie chcemy ich wkurzyć, dając im 386, ale nie dajmy im czterordzeniowego rdzenia na przykład z 8 GB pamięci RAM). Czy nie odpowiedzieliby programistom, gdyby byli wystarczająco wkurzeni występem?

Myślę, że klient / kierownik projektu powinien zmusić programistę / zespół qa / programistę / przedstawiciela zespołu firmy do przeprowadzenia prezentacji na najniższym typowym sprzęcie, jaki mają. (na przykład najsłabszy komputer w firmie). Jeśli jest przepisany, będą musieli zebrać dane o tym, jak szybko wykonuje się proces X w starym oprogramowaniu i porównać go z szybkością w nowym oprogramowaniu (może być wolniejszy, ponieważ nowe oprogramowanie może wymagać dodatkowego procesu biznesowego, ale powinno być dopuszczalne okno).

Squee
źródło
-1

Powiedziałem to wcześniej, ale powiem to jeszcze raz: Myślę, że jednym z najlepszych sposobów na poradzenie sobie z tym jest po prostu umożliwienie programistom pracy na (względnie) najnowocześniejszym sprzęcie.

Dla typowego programisty większość oficjalnych rozważań dotyczących wydajności ma drugorzędne znaczenie: „czy denerwuje mnie, gdy próbuję go uruchomić?” Jeśli uznają to za irytujące, (przynajmniej spróbują) to naprawić. Jeśli są zadowoleni z sposobu, w jaki to działa, najlepszą próbą jest beznadziejna próba naprawy. Pomaga to również wcześnie znaleźć problemy, zanim ich naprawienie stanie się znacznie droższe.

Jeśli dojdzie do tego, że kontrola jakości będzie musiała egzekwować reguły, w które programiści naprawdę nie wierzą, ponieważ uważają, że wydajność jest wystarczająca, są całkiem spore szanse, że większość otrzymanych „poprawek” uzyska kreatywne sposoby obejścia zasad, nie prawdziwe poprawki poprawiające życie użytkownika końcowego.

Jednocześnie powinienem dodać, że rzadko postrzegałem to jako problem. Jeśli już, to widziałem, jak programiści spędzają zbyt dużo czasu na poprawianiu wydajności, w którym tak naprawdę nie miałem na tyle problemów, aby zawracać sobie głowę (grzech, którego często jestem również winny).

Jerry Coffin
źródło
1
Łatwo wpaść w pułapkę obsesji na punkcie rzeczy, które nie mają znaczenia, ale jeśli telefon komórkowy jest dostarczany z interfejsem użytkownika tak wolno, że połączenia przychodzące trafiają do poczty głosowej przed odpowiedzią przycisku „Odbierz”, najwyraźniej ktoś nie poprawił wydajności, gdy to zrobiło materia.
Crashworks
4
W takim przypadku firma powinna kupić mi porządny miecz, ponieważ większość czasu spędzę na kompilacji.
David Thornley,
Połowa problemu polega na tym, że trudno jest przetestować na maszynie deweloperskiej. Maszyny deweloperskie są zwykle duże i szybkie, więc deweloper nigdy nie zobaczy problemu. Trudno coś naprawić, jeśli nie widzisz problemu (na który wpływ miałby), nie mówiąc już o tym, jak poprawka zmieni zachowanie.
Martin York,
7
Zasugerowano to w komentarzu Slashdot (o czymś) sprzed lat. Odpowiedź brzmiała: „programiści powinni rozwijać się na szybkich komputerach i testować na wolnych”.
user16764
1
@ user16764: Często zbyt mało uwagi poświęca się testowaniu środowisk programistycznych innych niż środowisko programistyczne. Moja żona miała bardzo trudności z uzyskaniem zarówno konta administratora (do rozwijania się), jak i konta bardziej ograniczonego (do testowania), a wcześniej miały ciągłe problemy z przypadkowym wprowadzeniem poprawki serwisowej, która nie działałaby na zwykłym użytkowniku konto.
David Thornley,