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

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?

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.

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ę.

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.

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 -

• Podstawowa bardzo prosta metoda
• Przyspieszenie 43x - zrób to za pomocą swojego profilera
• Powody, dla których w szczegółach mdłości

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

Ustaw wydajność jako wymaganie.

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.

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.

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).

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.

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.

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.

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ą).

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?

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.

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).

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ę.

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).

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).