Kiedy „prawidłowe” programowanie nie ma już znaczenia?

49

W wolnym czasie buduję grę na Androida. Korzysta z biblioteki libgdx, więc trochę ciężkiego podnoszenia jest dla mnie zrobione.

Podczas opracowywania niedbale wybrałem typy danych dla niektórych procedur. Użyłem hashtable, ponieważ chciałem czegoś zbliżonego do tablicy asocjacyjnej. Kluczowe wartości czytelne dla człowieka. W innych miejscach, aby osiągnąć podobne rzeczy, używam wektora. Wiem, że libgdx ma klasy vector2 i vector3, ale nigdy ich nie użyłem.

Kiedy napotykam dziwne problemy i szukam pomocy w przepełnieniu stosu, widzę, że wiele osób po prostu rozmyśla o pytaniach, które wykorzystują określony typ danych, gdy inny jest technicznie „właściwy”. Jak użycie ArrayList, ponieważ nie wymaga zdefiniowanych granic w porównaniu z ponownym zdefiniowaniem int [] z nowymi znanymi granicami. Lub nawet coś tak trywialnego:

for(int i = 0; i < items.length; i ++)
{
    // do something
}

Wiem, że ocenia item.length na każdej iteracji. Jednak wiem też, że przedmioty nigdy nie będą miały więcej niż 15 do 20 przedmiotów. Czy powinno mnie to obchodzić, jeśli oceniam item.length przy każdej iteracji?

Przeprowadziłem kilka testów, aby zobaczyć, jak działa aplikacja przy użyciu metody, którą właśnie opisałem, w porównaniu z właściwą, postępuj zgodnie z samouczkiem i używaj dokładnych typów danych sugerowanych przez społeczność. Rezultaty: To samo. Średnio 45 fps. Otworzyłem każdą aplikację na karcie telefonu i galaktyki. Bez różnicy.

Sądzę więc, że moje pytanie brzmi: czy istnieje próg, kiedy nie ma już znaczenia, aby być poprawnym? Czy można powiedzieć, że „dopóki wykona zadanie, to mnie to nie obchodzi?”

— Kai Qing
źródło

4

To kwestia wielkości. Spróbuj udostępnić bazy danych zawierające wiele terrabajtów do rzeczywistego świata, korzystając z wyszukiwań i agregacji w podsekundowych czasach odpowiedzi z tysiącami żądań na minutę. Twój problem nie jest wystarczająco duży. Chociaż twoje podejście jest w porządku, jeśli podążasz tą ścieżką do nieuniknionego wniosku, jest to bolesne i wymaga czasu.

— Jimmy Hoffa

8

Gdyby twój język miał prawdziwą pętlę FOR, ten problem wielokrotnej oceny nie miałby miejsca. Niestety, wymaga tego składnia C, ponieważ tak naprawdę nie jest to pętla FOR; to pętla PODCZAS noszenia peruki i okularów z dużymi nosami i wymaga zaakceptowania dowolnego dowolnego warunku (lub żadnego) w celu zakończenia pętli.

— Mason Wheeler,

2

Widzę twoją edycję, ale jeśli próbujesz przekonać, że bycie pijanym i lekkomyślnym jest w porządku w każdym kontekście, z wyjątkiem imprezy w piątek wieczorem z wyznaczonym kierowcą, prawdopodobnie szczekasz na złe drzewo.

— Robert Harvey,

17

Skąd wiesz, że „ocenia” długość elementu na każdej iteracji? Kompilatory są dość inteligentne. A nawet jeśli wielokrotnie pobiera item.length, co z tego? Nie chciałbym widzieć kodu takiego jak „int itemsLength = items.length; for (; i <itemsLength; ...) ”, chyba że wystąpił problem z mierzoną wydajnością.

— kevin cline

6

Twoje item.length nie ma absolutnie nic wspólnego z „właściwym programowaniem”. Jest to mikrooptymalizacja, a dobrzy programiści wiedzą, że nie marnować na nie czasu, dopóki nie uruchomią profilera i nie dowiedzą się, gdzie są prawdziwe problemy z wydajnością. Mikrooptymalizacje i dobry styl programowania to często przeciwieństwa, a nie to samo.

— Michael Borgwardt

65

Piszesz program, aby rozwiązać problem. Problemowi temu towarzyszy określony zestaw wymagań do jego rozwiązania. Jeśli te wymagania zostaną spełnione, problem zostanie rozwiązany i cel zostanie osiągnięty.

Otóż to.

Powodem, dla którego przestrzegane są najlepsze praktyki, jest to, że niektóre wymagania dotyczą konserwacji, testowalności, gwarancji wydajności i tak dalej. W rezultacie masz tych nieznośnych ludzi, jak ja, którzy wymagają takich rzeczy, jak odpowiedni styl kodowania. Nie wymaga to dużo więcej wysiłku, aby przekroczyć swoje T i kropić twoje I, i jest to gest szacunku dla tych, którzy muszą przeczytać twój kod później i dowiedzieć się, co on robi.

W przypadku dużych systemów ten rodzaj ograniczenia i dyscypliny jest niezbędny, ponieważ musisz dobrze bawić się z innymi, aby wszystko działało, i musisz zminimalizować dług techniczny, aby projekt nie upadł pod własnym ciężarem.

Na przeciwległym końcu spektrum znajdują się te jednorazowe narzędzia, które piszesz, aby rozwiązać konkretny problem w tej chwili, narzędzia, których już nigdy nie użyjesz. W takich przypadkach styl i najlepsze praktyki są całkowicie nieistotne; zhakujesz coś razem, uruchom go i zacznij następną rzecz.

Tak więc, podobnie jak w przypadku wielu rzeczy w rozwoju oprogramowania, to zależy.

— Robert Harvey
źródło

1

Zwykle się zgadzam. W pracy nie zadaje pytań, jest skrzyżowane i kropkowane. Ale weź pod uwagę, że wiele rzeczy, które robię w pracy, to takie, które naprawdę nie wymagają konserwacji. Przechodzenie trendów. Aplikacje urodzinowe, rzeczy, które przychodzą i odchodzą. Wszystko w porządku, ale tak naprawdę nie muszą.

— Kai Qing,

21

Można sprawić, że dyscyplina przez cały czas ułatwia dyscyplinę, kiedy trzeba. Niektóre osoby zadają pytania na temat przepełnienia stosu bez naciskania klawisza Shift, używając uzasadnienia, że mogą odpowiednio przekazywać swoje pomysły bez niego, a język angielski i tak jest płynny i ewoluuje. Nie znajduję nic bardziej irytującego, z wyjątkiem być może twórców wirusów, którzy uważają, że mój czas procesora jest wolny.

— Robert Harvey

2

@KaiQing Ktoś musi wręczyć ci starszą aplikację 5mloc, która urodziła się w Pascalu i została przeniesiona do przodu, ponieważ po pierwszej próbie dodania lub zmiany dowolnej funkcji w tej aplikacji od razu zrozumiesz, dlaczego istnieją najlepsze praktyki i zostaniesz oświecony.

— Jimmy Hoffa,

5

@KaiQing, Angry Birds musi działać na wielu platformach, a jeśli gra zawiesza się przez 2 sekundy x% publiczności się poddaje, co przekłada się na y mniej dolarów dla Angry Birds. Założę się, że został napisany bardzo, bardzo ostrożnie. Może to odpowiada na twoje pytanie. Jeśli kod jest właśnie dla Ciebie, kogo to obchodzi? Jeśli w grę wchodzą pieniądze lub czas innych ludzi, lepiej bądź bardzo, bardzo ostrożny.

— Charles E. Grant,

2

@KaiQing Nikt nie jest w stanie określić progu, który zmienia się w zależności od projektu i każdego projektu w czasie. Liczba zmiennych, które wpływają na próg między utrzymywalnością systemu i nie zależą od: LOC, baza użytkowników, baza programistów, rodzaj aplikacji (kryptografia vs. crud vs. sterowniki), odporność funkcji, wymagania redundancji, krytyczność oprogramowania (serwer e-mail vs . urządzenie podtrzymujące życie vs. widget zegara), Obsługiwane platformy, Stos technologii, Ilość transakcji lub analizowanych danych, Historyczne ograniczenia audytu i wiele innych rzeczy wpływają na to, jak zły może być kod

— Jimmy Hoffa

18

Jest stary mądry cytat: „Nie podążaj śladami dawnych mędrców. Szukaj tego, czego szukali”. Istnieją powody dla wszystkich zasad „właściwego” kodowania. Wiedza, dlaczego te reguły istnieją, jest ważniejsza niż wiedza o tych regułach.

Istnieje reguła, że nie należy umieszczać testu, który można wielokrotnie obliczać w takiej pętli for. W przypadkach, w których reguła została wymyślona w celu naprawy (gdzie wydajność byłaby naprawdę inna), ma to sens. W takim przypadku jest tylko jedna prawidłowa odpowiedź. W twoim przykładzie wiadomo, że nie ma różnicy w wydajności i że nie może być więcej niż kilkadziesiąt iteracji. W tym przypadku istnieją dwie poprawne odpowiedzi, albo zastosować regułę i tak, ponieważ jest to proste i nic nie zaszkodzi i może pomóc w kształtowaniu dobrych nawyków, lub zignorować regułę, ponieważ nie ma się o co martwić różnicą wydajności.

Wolę pierwszą właściwą odpowiedź, a ty wydaje się, że wolisz drugą. Nie mylisz się co do tego. Myślę, że mylisz się co do tego, na czym polega „właściwe” programowanie. Nie chodzi o przestrzeganie losowo wybranego zestawu reguł, które ci nie pomagają i nie mają żadnego celu. Nie naprawienie pętli for w tym przykładzie jest zgodne z bardzo dobrą regułą przed przedwczesną optymalizacją.

Prawdziwe prawidłowe programowanie polega na przestrzeganiu dobrych zasad, które mają sens w inteligentny sposób.

— Michael Shaw
źródło

Nie powiedziałbym, że wolę drugi. Ktoś zredagował mój post, aby usunąć część o tym, że uczyniłem tę grę na Androida prawie całkowicie pijaną (dla zabawy), w wyniku czego jestem zaskoczony, że moje pijackie wybory nie miały wpływu na wydajność. Niektóre dziwne klasy zastąpiłem odpowiednimi do przetestowania. Zgadzam się jednak, że znajomość reguł jest ważniejsza niż wiedza o regułach ...

— Kai Qing,

Ponadto mój pomysł na „właściwe” programowanie jest kulminacją powtarzających się opinii społeczności stackoverflow, a także kolekcji programistów, którzy przyszli i odeszli w firmie, w której pracuję. Niektóre ze stopniami CI, niektóre samoukami. Istnieje wspólna opinia, na której można oprzeć różne rzeczy, a ja zazwyczaj zgadzam się z tym, co wszyscy mówią wspólnie, zanim zdecyduję, że jeden sposób jest właściwy, a drugi zły. Dziękujemy za udział.

— Kai Qing,

1

Jeśli zabrzmiało to tak, jakbym ci mówił, że łamiesz zasady, to źle to sformułowałem. Żadna z rzeczy, o których mówiłeś, nie byłaby przedmiotem sprzeciwu. Próbowałem zwrócić uwagę, że „duch prawa” jest ważniejszy niż „litera prawa”.

— Michael Shaw

Heh, nie, nie sądziłem, że mi to odpychasz. Byłem tylko komunikatywny. Zadałem to pytanie z jakiegoś powodu i cieszę się, że tak wiele osób odpowiedziało bez głosowania, że zostało zamknięte.

— Kai Qing

10

Właściwym sposobem na to jest zmniejszenie zysków: porównanie dodatkowej korzyści z rozwoju programu z kosztami dodatkowego rozwoju.

Zmniejszające się zwroty pojawiają się, gdy krańcowa korzyść jest mniejsza niż krańcowy czas / wysiłek.

Czy potrafisz uzasadnić sprawę items.lengthwyjścia z forpętli? Z ekonomicznego punktu widzenia, czy ta zmiana może nawet usprawiedliwić czas poświęcony na jej uzasadnienie? Ponieważ nie ma różnicy w doświadczeniu użytkownika, nigdy nie dostaniesz niczego nawet za czas poświęcony na mierzenie (oprócz przydatnej lekcji do zapamiętania). Użytkownikom nie spodoba się program bardziej niż oni, a więcej kopii nie zostanie sprzedanych w wyniku tej zmiany.

Nie zawsze jest to łatwe do oszacowania, ponieważ przypadki biznesowe są pełne niewiadomych i zagrożeń, a zatem są podatne na padanie ofiarą nieuwzględnionych czynników, które staną się oczywiste dopiero z perspektywy czasu. Proponowane zmiany mogą być całkowicie nietrywialne, tak że robią dużą różnicę.

Myślenie polegające na zmniejszaniu zysków może oznaczać poszukiwanie wymówek, aby nie podejmować pewnych działań i unikać ryzyka, które z perspektywy czasu może okazać się ciągiem straconych okazji.

Ale czasem jest oczywiste, kiedy czegoś nie robić. Jeśli jakaś część rozwoju wydaje się wymagać cudu ekonomicznego, który miałby nastąpić tylko po to, by pokryć koszty rozwoju (próg rentowności), to prawdopodobnie zły pomysł.

— Kaz
źródło

Bardzo dobrze napisane. W moim przypadku nigdy nie planowano powrotu. Jakikolwiek powrót może być przypadkowy, ale nie należy go lekceważyć, ponieważ uważam, że niektóre z największych sukcesów zaczęły się od fuksów. Jeśli chodzi o pracę z klientem, gdzie stawką nie jest tak dużo pieniędzy, ponieważ może wystąpić tylko pogorszenie, jeśli aplikacja się zawiesi lub coś stanie się niewielką niedogodnością, jest to grubszy próg. Jeśli testy porównawcze wyglądają dobrze, ale wiadomo, że kod nie jest najskuteczniejszy, to nikt nie przyjdzie i nie skontroluje go przed czasem jego rozwoju i być może nie zażąda migracji mimo wszystko ... trudno powiedzieć na ten temat.

— Kai Qing,

W rzeczy samej. Nie zawsze możemy stworzyć obiektywny przypadek. Nie wszyscy cenią program w ten sam sposób. Załóżmy, że głównym narzędziem w programie jest przyjemność z pracy nad nim. Może to nie przynieść korzyści nikomu innemu i nikt nie zapłaci za ulepszenia (nawet jeśli są programiści oprócz programisty), ale wystarczy uzasadnić jakąkolwiek poprawę.

— Kaz

Dwa użyteczne słowa, które należy dodać do bardzo dobrze napisanej odpowiedzi - „Inwestycja spekulacyjna” - robisz to, ponieważ spekulujesz, że w przyszłości nastąpi zwrot.

— mattnz

@mattnz - to, co mówisz, jest prawdą, ponieważ nikt nie robi nic bez powrotu, nawet jeśli powrót jest dobrym śmiechem. Prawie wszystkie moje osobiste projekty są wykonane dla humoru. Prawie wszystkie z nich wystarczają na uzasadnienie swoich wymagań. Żadne z nich nie pozwoliło mi odejść.

— Kai Qing

Dokładnie wszyscy. Najpierw określamy, co mamy nadzieję zrobić z pisania tego programu lub kontynuowania. Tym czymś może być „zabijanie czasu tak, by było fajnie”. Ale nawet wtedy możemy myśleć: praca nad takim a takim czymś w takim i takim programie jest najlepszym sposobem na osiągnięcie jak największej przyjemności, czy też poświęcamy czas na coś innego.

— Kaz

3

Kiedy nie powinieneś dbać o to, by kod był „właściwy”

Jeśli uda Ci się osiągnąć cel biznesowy i utrzymać go z czasem przy niskim koszcie ogólnym. (użytkownicy nie wyświetlają źródła, zanim ci zapłacą)
MVP / POC - Jeśli pisanie odpowiedniego kodu oznacza marnowanie czasu na koncepcję, zanim będziesz wiedział, jak na tym zarobić (jeśli spędzisz lata i 45 milionów dolarów, pisząc aplikację i zamykając sklep, ponieważ nie ma rynku, nikt nie obchodzi, jak to zrobić właściwy był kod)
W sytuacji zagrożenia życia (np. Prototyp Iron Mana 1 był brudnym hakiem, ale wyciągnął go z jaskini, prawda?)
lub jeśli po prostu nie wiesz, jak napisać odpowiedni kod (jeśli somene zdoła sprawić, że żywe pisanie nie będzie właściwym kodem, w dzisiejszym bezrobociu, powiadam, lepiej pisać zły kod niż być bezdomnym)
jeśli po prostu wiesz, co robisz lub myślisz, że możesz uciec od udawania

Kiedy pisać właściwy kod?

Jeśli będzie to miało znaczący wpływ na działalność, np. Wydajność wpłynie na przychody lub uniemożliwi sprzedaż
Jeśli nie jest to właściwe, utrzymanie kodu staje się problemem biznesowym (wysokie koszty utrzymania)
Jeśli jesteś znanym programistą pracującym nad dużym projektem open source
To samo dotyczy dużej firmy, która wnosi swój własny świat do biblioteki
Jeśli chcesz pokazać swoją pracę jako portfolio w przyszłych wywiadach

— Eran Medan
źródło

1

Niestety, na liście nie troszczącej się o właściwą jest jeszcze jedna, o której wiele osób błogosławi nie wiedzieć: kiedy klient wymiotuje stary system pod twoją opieką i mówi ci, że musi to zrobić za tydzień. Czasami czas i / lub budżet nie nadają się do właściwego kodowania, a Twoja uwaga na projekt jest bardziej wdzięczna niż transakcja biznesowa. Na przykład, jeśli ich kod używa w dużej mierze przestarzałych metod, ale wymaga poprawek (mówiąc w scenariuszu internetowym). Nie mogę tego naprawić. Musisz się ubrudzić.

— Kai Qing

„Jeśli nie jest to właściwe, utrzymanie kodu staje się problemem biznesowym (wysokie koszty utrzymania)”. Ten próg jest znacznie niższy niż większość niedoświadczonych programistów jest skłonna w to uwierzyć. Pisanie solidnego kodu często zwraca się w ciągu kilku godzin, a nie dni lub miesięcy.

— PeterAllenWebb

2

Czy wydajność jest Twoim głównym zmartwieniem? Czy to właśnie próbujesz zmaksymalizować?

Jeśli tak, musisz nauczyć się fundamentalnej lekcji, a jeśli to zrobisz, będziesz jednym z niewielu.

Nie próbuj „myśleć”, co powinieneś zrobić, aby przyspieszyć - to zgadywanie. Jeśli pytasz „Czy powinienem użyć tej klasy pojemnika czy tej?” Lub „Czy powinienem wprowadzić lengthwarunek pętli?”, Jesteś jak lekarz, który widzi pacjenta i próbuje zdecydować, jakie leczenie zastosować bez przesłuchanie lub badanie pacjenta.

To zgadywanie. Wszyscy to robią, ale to nie działa.

Zamiast tego pozwól programowi powiedzieć ci, na czym polega jego problem. Oto szczegółowy przykład.

Czy widzisz różnicę?

— Mike Dunlavey
źródło

Powiedziałbym, że moim jedynym zmartwieniem było to, że w moich testach nie zauważyłem różnic w wydajności między niewłaściwym i właściwym użyciem typów danych dla określonego scenariusza. Tak jak w twojej sugestii, przeciążyłem klasę większą ilością danych, aby sprawdzić, czy jest to po prostu za mało, aby coś zmienić. W końcu oba występowały jednakowo. To prawda, tworzę podstawową grę typu RPG. To nie jest jak oprogramowanie bankowe lub coś złożonego. Ale zastanawiałem się, czy nie byłoby lepiej, gdyby biznes cały czas nie był taki właściwy.

— Kai Qing,

Ponieważ zależy Ci na wydajności, powinieneś zadać programowi to, na co powinieneś zwrócić uwagę, a nie pytać, czy twoje z góry ustalone pytanie ma znaczenie. Kliknij ten link i zrób to, co mówi. Powie ci, na czym tak naprawdę program spędza czas, a także jak przyspieszyć.

— Mike Dunlavey,

Wydajność była moją podstawą do zadawania pytań, niekoniecznie problemem. Nie chcę porównywać każdego powiedzenia. Samo obserwowanie tego nieefektywnego kodu nie spowodowało różnicy w wydajności. Zasadniczo jest przejrzyste dla użytkownika, jak skuteczny lub nieefektywny był program, przez co zaniepokojenie takim profilowaniem nie ma znaczenia. To prawda, że przede wszystkim musiałem się trochę przejmować testem porównawczym, ale była to głównie ciekawość. A jeśli produkt jest gotowy i jest zauważalnie wolny, to tak, profiler ma sens. Dzięki za link

— Kai Qing

2

Twoje pytanie brzmi: „tak długo, jak wykona pracę, nie obchodzi mnie to?”

Moja odpowiedź brzmi: „nigdy nie wiesz, co stanie się z twoim kodem”. Brałem udział w wielu projektach, które rozpoczęły się jako „hej, pozwól mi napisać tę szybką rzecz, aby zająć się problemem użytkownika”. Napisz, umieść tam, nigdy więcej o tym nie myśl.

Pewnego razu ta rzecz, którą napisałem, przekształciła się w „och, teraz cały dział użytkownika chce użyć tego kodu”, który zanim mogłem się odwrócić, stał się „cała firma używa tego kodu i teraz muszę udowodnić, że przetrwa audyt na jutro zaplanowano 20-osobowy przegląd kodu, a jakiś wiceprezes sprzedał go już naszym klientom ”.

Zdaję sobie sprawę, że „piszesz grę na Androida w wolnym czasie”, ale nigdy nie wiesz, czy ta gra wystartuje i stanie się przepustką do sławy i fortuny. Co gorsza, ta gra może stać się przepustką do zniesławienia, ponieważ powoduje awarię telefonów użytkowników. Czy chcesz być osobą, która dostaje ofertę pracy, ponieważ czyjeś dzieci nie mogą przestać grać w gry na swoich telefonach, czy też chcesz być osobą, która jest oczerniana na forach dyskusyjnych takich jak ten?

— Dan Perkins
źródło

1

Odpowiedź jest taka, że to nigdy nie ma znaczenia i zawsze ma znaczenie ...

To nigdy nie ma znaczenia, ponieważ programowanie, właściwe czy nie, jest sposobem na osiągnięcie celu, a nie celem samym w sobie. Jeśli ten cel zostanie osiągnięty bez „właściwego” programowania, co jest w porządku (z perspektywy biznesowej często najlepiej jest, jeśli cel można osiągnąć bez programowania).

Zawsze ma to znaczenie, ponieważ prawidłowe programowanie jest narzędziem, które pomoże ci osiągnąć swoje cele. Właściwy sposób robienia rzeczy to po prostu uznanie, że zrobienie tego w inny sposób powoduje więcej bólu na dłuższą metę niż oszczędza.

Który odpowiada na pytanie, kiedy możesz go zignorować - kiedy masz pewność, że w dłuższej perspektywie łatwiej będzie w inny sposób (być może dlatego, że nie będzie długiej).

Jednorazowe narzędzia są zwykle wykonywane tak szybko i brudnie, jak to tylko możliwe, bez sprawdzania błędów lub sprawdzania poprawności, bez rejestrowania wyjątków, wycinania i wklejania kodu z niewielkimi zmianami lub nawet bez zmian zamiast funkcji ogólnych i tak dalej .

Tylko uważaj: czasami te szybkie i brudne aplikacje nabierają życia, co oznacza, że wszystkie skróty gryzą cię w ...

— jmoreno
źródło

1

„nigdy” i „zawsze” wzajemnie się anulują. Twoja odpowiedź jest dobra i zła.

— Tulains Córdova

@ user1598390: chodziło o ich wzajemne anulowanie. Anuluj dogmat, a zostaniesz, ponieważ wydaje się to przydatne. I pomylisz się i wyciągniesz z tego wnioski.

— jmoreno

Chcę powiedzieć, że się z tobą zgadzam, ale nie doszedłbym do takich skrajności. Nie sądzę, że jednorazowe wypadki często po prostu wypluwają się, unikając testowania lub debugowania. Tylko dlatego, że nie jest zoptymalizowany i doskonale zaprojektowany, nie czyni go mniejszym produktem, jeśli skrót nie wpływa na wydajność i stabilność. O to w końcu chodzi i dlaczego zastanawiam się, dlaczego wszyscy tak śmierdzą kodującymi przykładami, które nie są na pierwszym miejscu. Zdarza się to często przy przepełnieniu stosu.

— Kai Qing,

@KaiQing: Testowanie i debugowanie zdarza się oczywiście, ale ogólnie są ograniczone do tego, co obecnie istnieje - więc na przykład, jeśli proces może się nie powieść z plikiem z kodowaniem UTF i żadnym z plików, nad którymi tak naprawdę pracujesz nie testuj tego. Optymalizację należy przeprowadzić po zidentyfikowaniu problemu z wydajnością. Co do tego, dlaczego smród ponad przykładowymi kodami linii na SO - myślę, że jest to funkcja celów witryny. Ma to być stały zasób, dlatego kod w odpowiedziach (a nawet pytaniach) jest rozpatrywany tak, jakby był szablonem używanym przez innych.

— jmoreno

1

Lub nawet coś tak trywialnego:

for(int i = 0; i < items.length;i ++) {
     // do something 
}

Wiem, że ocenia item.length na każdej iteracji. Jednak wiem też, że przedmioty nigdy nie będą miały więcej niż 15 do 20 przedmiotów. Czy powinno mnie to obchodzić, jeśli oceniam item.length przy każdej iteracji?

W rzeczywistości w końcowym kodzie item.length nie będzie obliczany w każdej iteracji, ponieważ kompilator go optymalizuje. I nawet gdyby tak nie było, długość jest polem publicznym w obiekcie tablicy; dostęp do niego nie kosztuje.

Wydaje mi się, że moje pytanie brzmi: czy istnieje próg, gdy nie ma już> znaczenia, aby być poprawnym? Czy można powiedzieć: „dopóki wykonam zadanie, nie obchodzi mnie to?”

To naprawdę zależy od tego, czego oczekujesz od produktu końcowego; różnica między przeciętnym produktem a doskonałym produktem zależy od szczegółów. Samochód taki jak Tata Nano i samochód taki jak Mercedes S „wykonuje robotę” - zabiera cię z jednego miejsca do drugiego. Różnica polega na szczegółach: mocy silnika, komforcie, bezpieczeństwie i innych. Tak samo jest z każdym istniejącym produktem, w tym z oprogramowaniem; na przykład dlaczego ktokolwiek miałby płacić Oracle, IBM lub Microsoft za bazy danych Oracle, DB2 lub MS SQL Server, skoro MySQL i Postgre są bezpłatne?

Jeśli chcesz zwrócić uwagę na szczegóły i uzyskać produkt wysokiej jakości, powinieneś dbać o te rzeczy (i oczywiście o inne rzeczy).

— m3th0dman
źródło

Nie sądzę jednak, że się z tym zgadzam. W moim poście nie wspominam o różnicy w wydajności. Sugerowałoby to, że nie ma przeciętnego lub świetnego produktu, ale równa równowaga pomimo jego wad. Zgodziłbym się jednak z tym stwierdzeniem, gdyby istniał konkretny projekt o dużym znaczeniu, którego wszyscy używaliśmy jako porównania. Ale abstrakcyjnie, ogólna obserwacja jest taka, że w tym anonimowym projekcie zdecydowanie niewydajna klasa działała na równi z klasą zoptymalizowaną. Czy zatem jest w porządku przyjmować luźne podejście do tej kwestii lub za każdym razem argumentować za doskonałością?

— Kai Qing,

@Kai Qing Pojedyncza klasa nie robi (lub nie powinna) robić dużej różnicy. Powiedziałem to: jeśli oczekujesz, że Twój produkt będzie produktem wysokiej jakości, zwróć uwagę na szczegóły (nawet jeśli oznacza to możliwą niewielką optymalizację lub staranne wykonanie); z drugiej strony, jeśli jedyne, czego chcesz, to funkcjonalny system, prawdopodobnie nie powinieneś zwracać dużej uwagi na drobne szczegóły.

— m3th0dman

Tak, masz rację, to nie powinno mieć znaczenia, nawet jeśli tylko trochę uwagi przyłoży się do jego projektu. Ale może coś zmienić w zależności od celu lub jeśli w ogóle jego cel zmienił się w czasie i stał się czymś, czym nie był przeznaczony. Widziałem to już wcześniej, ale po prostu wybieram tutaj styczną. Aby być uczciwym, produkt może być wysokiej jakości, ale nie musi być funkcjonalny.

— Kai Qing,

1

Jeśli programujesz w domu dla siebie, być może możesz skrócić kilka rogów; a kiedy eksperymentujesz i wypróbowujesz różne rzeczy, jest to całkowicie uzasadnione.

Uważaj jednak. W podanym przykładzie tak naprawdę nie ma potrzeby wycinania tego rogu i musisz być ostrożny. To może rozpocząć trend, a złe nawyki, które robisz w domu, mogą wkradać się do twojego kodu w pracy. O wiele lepiej ćwiczyć i doskonalić dobre nawyki w domu i pozwolić im wniknąć do twojego kodu w pracy. Pomoże ci i pomoże innym.

Każde programowanie i myślenie na temat programowania jest ćwiczeniem. Spraw, by było warto, w przeciwnym razie wróci i cię ugryzie.

Spójrz jednak na dobrą stronę. Zapytałeś o to, więc może już wiesz, o co mi chodzi.

— Daniel Hollinrake
źródło

1

Tak, zdaję sobie sprawę, ale chodzi przede wszystkim o to, że w mniejszym, ograniczonym kontekście nie ma powodu, by być tak właściwym. Przez wszystkie lata programowania naprawdę nie było zbyt wiele, by nas ugryźć. Wątpię, żebyśmy mieli rację. Myślę, że języki i oczekiwania zmieniają się jak normalne oprogramowanie. Niektóre mniej niż inne. Ale ostatecznie nieefektywność jednego projektu może zostać zrealizowana tylko wtedy, gdy projekt jest w przeszłości i nie jest już niezbędny. Utrudnia to uzasadnienie bólu głowy z powodu sztywności.

— Kai Qing,

To słuszna kwestia. Dzisiejsze zasady mogą być ograniczeniami jutra. Nie lubię, gdy mówi się mi, co mam robić, ale szanuję innych, którzy odeszli już wcześniej i nauczyli się trudnej drogi. Czasami może być interesujące dowiedzieć się, jakie reguły są użyteczne, a które już minęły.

— Daniel Hollinrake

1

Jeśli producent mebli przygotowuje mebel do użytku tam, gdzie jakość nie ma większego znaczenia lub gdzie jakość może pozostać niezauważona, czy nadal powinien starać się wyprostować swoje cięcia i wykonać dobrą robotę łącząc te elementy?

Wiele osób uważa oprogramowanie za kunszt. To, co budujemy, powinno nie tylko pełnić funkcję, ale musi być niezawodne, łatwe w utrzymaniu, niezawodne. Tworzenie takiego oprogramowania wymaga umiejętności, a umiejętność ta pochodzi z praktyki.

Tak więc, nawet jeśli wybór pętlowej konstrukcji dla tego, nad czym dzisiaj pracujesz, może nie mieć znaczenia, fakt, że starasz się używać odpowiednich konstrukcji przez cały czas, z czasem uczyni cię lepszym programistą.

— Bryan Oakley
źródło

W programowaniu napotkałem przypadki, w których kod nie musiał być możliwy do utrzymania lub działania poza potrzebami. Podobnie jak narzędzia kiosku na targach lub wydarzeniach, które są bardzo specyficzne i nie będą prawdopodobnie ponownie używane. W przypadku mojej własnej gry - tylko ja ją utrzymuję, więc ten argument może nie być najbardziej odpowiedni. Nadal mam wątpliwości co do wspólnego spojrzenia na „lepszego programistę”, ponieważ sztywne przestrzeganie wytycznych, łatwość konserwacji i właściwe użycie typów danych może wystarczyć do zniechęcenia, aby nie ukończyć projektu. Jeśli kod działa zgodnie z oczekiwaniami, po co go doskonalić?

— Kai Qing,

Nawet jeśli oprogramowanie, które teraz budujesz , nie musi być konserwowane, pisanie go tak, jakby wzmacniało twoje umiejętności kodowania. Kiedy w końcu będziesz musiał napisać łatwy do utrzymania kod, będziesz mógł to zrobić łatwiej.

— Bryan Oakley,

Cały czas muszę pisać możliwy do utrzymania kod. W niektórych przypadkach nie musi tak być. Mam jednak duże doświadczenie, więc zazwyczaj wiem, kiedy i gdzie skracać rogi. Celem tego postu było po prostu pobudzenie rozmowy na temat progu właściwego i niechlujstwa do dowolnego celu. Mój przykład jedynie lekko go omawia, ponieważ podany przykład jest w większości nieszkodliwy w mniejszych aplikacjach. Jednak gdybym pisał oprogramowanie bankowe, nigdy nie byłbym tak nieostrożny.

— Kai Qing,