Jakie są przyczyny, które prowadzą do przesadnego oprogramowania? [Zamknięte]

Dzisiaj postanowiłem przeprowadzić czystą instalację sterowników Creative Sound Blaster, ponieważ zawsze zaczynają się same zlewać po pewnym czasie. A to oznaczało, że musiałem przejść całą procedurę czyszczenia. I zajęło mi to prawie 2 godziny ..

I szczerze mówiąc, nie widzę powodu, dlaczego ?! I chociaż Creative, IMHO, jest absolutnym zwycięzcą pierwszego miejsca w produkcji oprogramowania niskiej jakości, które nigdy nie działa, problem wzdęć nie jest dla nich wyłączny.

Komputer PC ze sterownikiem aparatu cyfrowego Canon będzie miał około 10 wpisów Canon, które są połączone z różnego rodzaju połączeniami. Visual Studio jest również doskonałym przykładem, istnieje około 50 wpisów do pełnej instalacji, a naprawa tego jest możliwa tylko przy pełnym nukowaniu. I kiedy udało się nawet zepsuć całą instalację systemu operacyjnego, gdy aktualizowałem VS2k8 do VS2k8SP1 lub coś w tym stylu. Jak się okazuje, 5 GB wolnego miejsca nie wystarczyło na łatę 300 Mb ...

To naprawdę wydaje się być powszechnym problemem. Prawie każda aplikacja zwykle zawiera obecnie rozpakowywacze, zainstalowanych jest wielu „szpiegujących” znajomych, sterowniki mają zwykle około 600 Mb na wszystko, łącznie z drukarkami i tak dalej.

Ale dlaczego? Czy to wina programisty? Takie aplikacje są koszmarem do obsługi, nigdy nie działają teraz w 100%, a prawie wszyscy użytkownicy, których znam, są bardzo negatywnie nastawieni do tego wzdęcia, które dostają jako obowiązkową instalację sterownika dla napędu USB / drukarki / aparatu / karty dźwiękowej / przeglądarki.

Wygląda na to, że NSIS z Nullsoft to jedyny czysty system instalacyjny, który nie jest rozdęty, z tego co wiem, na przykład instalacja Firefox. Czysta, oparta na xcopy instalacja bez żadnych problemów.

Dlaczego ludzie nie używają prostych konfiguracji i aplikacji, które nie są zakorzenione w 30 warstwach połączeń? Czy to dlatego, że programiści są leniwi? Używasz narzędzi codegen? Czy to dlatego, że korporacje wymuszają ciężkie aplikacje, co pokochają użytkownicy? Co jest przyczyną i czy istnieje nadzieja, że ​​oprogramowanie wróci kiedyś do podstaw? Jakie są kroki, aby uniknąć pisania wzdęcia po uruchomieniu nowej aplikacji od zera?

Domyślam się, że istnieje wiele funkcji, które ktoś uważał za dobry pomysł. Jeśli jednak wiele osób ma osobne pomysły, które składają się na jedną aplikację, może to być tak skomplikowane. Nie winiłbym programisty w przypadku dużych produktów korporacyjnych, w których powinni być menedżerowie produktów odpowiedzialni za to, co jest w produkcie i jak zoptymalizować go z różnych perspektyw.

Inną stroną tego problemu byłby dług techniczny, który prawdopodobnie nie jest dobrze zarządzany w większości przypadków, ponieważ nie jest postrzegany jako wielka inwestycja czasu. Podejrzewam, że nowe funkcje i poprawki błędów są bardziej sensowne niż refaktoryzacja lub inne zadania zadłużenia, które mogą wydawać się mieć niewielką bezpośrednią wartość biznesową. Jak często zespół programistów miałby kilka tygodni na wyczyszczenie starszego kodu, jeśli baza kodu jest dość stara? Domyślam się, że nie często.

Cytując Joela w strategii Letter IV: Bloatware i mit 80/20 :

[...] istnieje wiele wspaniałych powodów, dla których powstaje wzdęcie. Po pierwsze, jeśli programiści nie muszą się martwić, jak duży jest ich kod, mogą go wysłać wcześniej. [...] Jeśli sprzedawca oprogramowania przestanie, przed wysyłką, i poświęci dwa miesiące na zmniejszenie kodu, aby zmniejszyć go o 50%, korzyść netto dla ciebie będzie niezauważalna. [...] Ale strata związana z czekaniem dodatkowych dwóch miesięcy na nową wersję jest zauważalna, a strata dla firmy programistycznej, która musi zrezygnować z dwóch miesięcy sprzedaży, jest jeszcze większa.

Wielu programistów kusi stara zasada „80/20”. To wydaje się zrobić wiele sensu: 80% osób korzysta z 20% funkcji. Przekonujesz się więc, że wystarczy zaimplementować tylko 20% funkcji i nadal możesz sprzedawać 80% tylu kopii.

Niestety, nigdy nie jest tak samo 20%. Każdy korzysta z innego zestawu funkcji. [...]

Kiedy zaczynasz sprzedawać swój „lite” produkt i mówisz ludziom: „hej, to lite, tylko 1 MB”, zazwyczaj są bardzo szczęśliwi, a następnie pytają, czy ma on swoją kluczową cechę, a tak nie jest, więc nie kupują twojego produktu.

Dość duża część ma związek z zależnościami produktu. Twój system operacyjny jest wyposażony w wiele standardowych bibliotek do wszelkiego rodzaju rzeczy. Te standardowe biblioteki mają jednak różne wersje w trakcie ewolucji systemu operacyjnego i żaden ogólny instalator nie może zakładać, że konkretna wersja, dla której została zbudowana, będzie faktycznie obecna w systemie operacyjnym.

Dlatego pełny instalator będzie musiał dołączyć poprawną wersję każdej zależności, aby upewnić się, że wszystko na pewno zadziała po instalacji, bez względu na początkowy stan każdej zależności na komputerze docelowym. Może to być dość znaczące dla niektórych typów aplikacji, na przykład aplikacji opartych na .NET, które należy wdrożyć w systemach Windows XP.

Do niedawna jeden system instalacyjny, z którym pracowałem, wymagał zainstalowania każdej poprzedniej wersji .NET, aby móc wdrożyć najnowszą wersję, co oznaczało, że każda aplikacja .NET 3.5 wymagała plików binarnych instalacji dla .NET 1, 2, 2.5 i 3 NA GÓRZE 3.5. W takim przypadku tylko instalator jest wzdęty.

Jednym z obejść jest instalator sieciowy, który pobiera tylko te komponenty, które w rzeczywistości nie są obecne w systemie docelowym - i może to być gigantyczna korzyść w postaci rozmiaru / wzdęcia. Oczywiście ogranicza to twoje instalacje do systemów, które mają łączność z Internetem.

Myślę, że wiele z tego ma związek z warstwami kodu biblioteki. Oczywiście, kiedy korzystasz z biblioteki, nie używasz wszystkiego w niej, więc nadmiar sumuje się, gdy dołączasz coraz więcej bibliotek.

W połączeniu z faktem, że koszt godziny pracy programisty staje się coraz droższy, podczas gdy moc przetwarzania / pamięci typowego komputera z roku na rok staje się coraz tańsza, widać, że jest to w rzeczywistości bardziej opłacalne.

• „Potrzebujemy czegoś do zrobienia X. Użyjmy biblioteki $ BIGFATLIBDESIGNEDFORSOMETHINGELSE, ponieważ użyłem jej w innym projekcie”
• „Myślę, że nie potrzebujemy już tego fragmentu kodu, ale aby upewnić się, że nic się nie zepsuje, po prostu go zachowaj”
• Brak lub za mało testów jednostkowych, które prowadzą do
• Bez refaktoryzacji
• Bez śledzenia, gdzie ustawienia były przechowywane przez lata, więc teraz ustawienia są wszędzie
• ...

To błędne koło, w którym można obwiniać każdego, kto znajduje się w kręgu rozpaczy . Jeden cykl rozpaczy składa się z następujących kroków:

1. Ludzie biznesu pytają o rozdęte funkcje.
2. Programiści wdrażają rozdęte funkcje, chociaż wiedzą, że nie powinni.
3. Klienci płacą za rozdęte funkcje, mimo że chcą tylko produktu, ale nie głupiej funkcji.
4. Ludzie biznesu uważają, że klienci chcą rozdętych funkcji.
5. Przejdź do kroku pierwszego i powtórz.

Jak to zatrzymać? Nie ma łatwej odpowiedzi na pytanie, jak to zrobić, ale jasne jest, że aby zatrzymać cykl, jeden z kroków musi zostać przerwany. Tak więc może to zostać zerwane tylko przez biznes, deweloperów lub konsumentów podejmujących rewolucyjne działania.

1. Inżynier próbował zoptymalizować moduł, ale wprowadził kilka problemów klientów. Następnie jego kierownik powiedział „nie”. Następnie inżynier postanowił nie „sprawiać kłopotów”, dopóki kłopoty go nie niepokoją.
2. W przypadku złożonego systemu sprzedawca dodał już wiele poprawek i naprawił tysiące błędów, aby zapewnić stabilność w środowisku klienta. Nie ma dobrej jakości z punktu widzenia oprogramowania, ale działa. Nikt nie chce przepisać go, aby naprawić tę samą liczbę błędów.
3. ze względu na kompatybilność wsteczną, nawet jeśli funkcja nie jest popularna na rynku, musimy ją tam zachować.

Niezmiennie lenistwo powoduje wzdęcia. (lub błoto jak w kluczowym artykule na ten temat, Wielka Kula Błota )

Na przykład tam, gdzie pracuję, mamy „starszą” aplikację C ++, która jest jednak całkiem dobrze zaprojektowana. Klienci rozmawiają z interfejsem API, który komunikuje się z serwerem, który działa z DB. Wszystko rozsądnie zrobione. Ostatnio potrzebowaliśmy dodatkowego modułu, ale zamiast poprawnie go wdrożyć, deweloper postanowił zaimplementować to w .NET, a co gorsza, zdecydował, że dostęp do danych przez API jest zbyt trudny (to nie, ale ...) nawiąże połączenia DB bezpośrednio. Widzisz więc, jak to się dzieje. (i wszystko za zgodą TA, która stawiła „szybkie” na „dobre”)

Widziałem już tego rodzaju rzeczy - w starym miejscu niewielką częścią GUI był HTML, ponieważ niektórzy deweloperzy uważali, że dobrym pomysłem jest zapisywanie danych w HTML i wyświetlanie tego w GUI. Więc 1 mała część robi coś innego niż reszta.

Krótko mówiąc, lenistwo jest złe, a spójność dobra (niezależnie od zastosowanej technologii). Wolałbym mieć aplikację opartą wyłącznie na MFC, a nie taką, która jest częściowo MFC i częściowo Winforms, a częściowo WebGL z wieloma różnymi architekturami zaplecza, wiążącymi to wszystko razem.