Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Szybkość programowania wydajnosc

22 Sty 2020 10:40 453 29
  • Poziom 14  
    Chciałem tak ogólnie zapytać jakie są wasze spostrzeżenia na temat ile czasu zajmuje wam napisanie oprogramowanie jakiegoś zadania. Czy jest to proces czasochłonny czy nie.
  • Poziom 26  
    Bywają zadania na 10 minut
    Bywają zadania na 10 godzin
    Bywają zadania na 10 dni
    Bywają zadania na 10 miesięcy

    Zasadniczo proces programowania jest dość czasochłonny. Nie wiem czy o taką odpowiedź Ci chodziło ale mam nadzieję, że pomogłem ;)
  • Poziom 11  
    Ogólnie to tak :)

    Pisanie wysokopoziomowe wydłuża czas programowania. Tzn. Teoretycznie go skraca, ale gdy coś nie działa to okazuje się często że gra nie była warta świeczki :)
  • Poziom 26  
    Fourier5 napisał:
    Pisanie wysokopoziomowe wydłuża czas programowania. Tzn. Teoretycznie go skraca, ale gdy coś nie działa to okazuje się często że gra nie była warta świeczki

    Może przy programowaniu mikrokontrolerów... Cała reszta to ogromne ułatwienie - gotowe frameworki, biblioteki, budujesz praktycznie z klocków i bez problemu stworzysz wielowątkowe aplikacje :)
  • Poziom 11  
    Zgadza się. Ale i tak wiele programów na pc jest tworzonych od zera. Nie bez przyczyny :)

    Ogólnie i na mikro taki hal jest super szybki w pisaniu, ale nie w debugowaniu ;)
  • Poziom 26  
    Na przykład jakie? :) Ja znam jeden - Notepad++, tworzony w C++ i WinAPI czyli dość niskopoziomowo, czy miałeś może na myśli asemblera? :)
  • Poziom 26  
    A w czym wg ciebie napisano to środowisko programistyczne? :)
  • Poziom 11  
    Wydawalo mi sieze w C, ale wyszukania google nic nie potwierdzily. Dla pewnosci napisalem do nich z zapytaniem.

    Ale pewnie masz racje. Pc to inna bajka.
  • Poziom 22  
    Wszystko zależy od tego jakie to zadanie (poziom trudności)i dla kogo ma być gotowy produkt. Ma też znaczenie co umiesz (wiedza+doświadczenie) i co masz (możesz mieć) dostępne. Dla siebie można opuścić np. obsługę błędów i program ma kilka(-naście/-dziesiąt) wierszy. Ten sam program dla zespołu 10 osób będzie już sporo większy. A w korporacji, to ... :)
  • Poziom 38  
    To ja wtrącę o różnicy w pisaniu aplikacji na PC vs oprogramowania dla wahadłowca, czy F-35.
  • Poziom 14  
    konstruktor_123456 napisał:
    Chciałem tak ogólnie zapytać jakie są wasze spostrzeżenia na temat ile czasu zajmuje wam napisanie oprogramowanie jakiegoś zadania. Czy jest to proces czasochłonny czy nie.

    Do tego pięknego wpisu:
    hindoos napisał:
    Bywają zadania na 10 minut
    Bywają zadania na 10 godzin
    Bywają zadania na 10 dni
    Bywają zadania na 10 miesięcy

    Zasadniczo proces programowania jest dość czasochłonny. Nie wiem czy o taką odpowiedź Ci chodziło ale mam nadzieję, że pomogłem ;)

    dodam obrazowo, że to jest tak samo jak napisanie listu. Do kumatego wystarczą dwa słowa, a do tumana możesz pisać w nieskończoność, bo trzeba list aktualizować do końca świata. O.
  • Poziom 11  
    Albo obrazowo jak malowanie obrazu. Dostajesz to ile czasu na namalowanie poświęcił artysta. Nawet świetny artysta potrzebuje bardzo dużo czasu żeby namalować arcydzieło. A czas kosztuje.
  • Poziom 22  
    Yrecki napisał:
    Do kumatego wystarczą dwa słowa, a do tumana możesz pisać w nieskończoność...


    Trochę to nietrafione. List jest do człowieka, który może być kumaty, albo tuman, program jest dla procesora. Nie słyszałem żeby istniały już mądrzejsze i głupsze procesory. :)
  • Poziom 11  
    Zdarzają się w grupie tych samych mcu upośledzone, z tąd czasami coś działa na jednym "revision" a na dokładnie tym samym mcu ale z innym "revision" już nie koniecznie :)
  • Poziom 22  
    Owszem, miałem takie obserwacje "niewyjaśnionych" błędów. W każdym przeanalizowanym przypadku (nie wszystkie analizowałem, niektórych nie warto) był to błąd w programie, a nie w sprzęcie.
  • Poziom 38  
    Witam,
    moze dodam jedno spojzenie, jeden z kolegow wspomnial o tym juz.
    Czas to pieniadz, "naciski ze strony marketingu czy innych dzialow" oraz uzywanie gotowych bibliotek powoduja ze nie istnieje juz chyba pojecie optymalizacji kodu.
    Kiedys za czasow spectrum z 48kB pamieci, jak cos dzialalo za dlugo to sie optymalizowalo kod i naprawde sporo mozna bylo w ten sposob uzyskac obecnie "zmienia sie wymagania sprzetowe" czyli nowa wersja oprogramowania wymaga juz i9 CPU a za rok minumum to i13 itd.
    W ukladach PLC czy mikrokontrolerach moze jest nieco lepiej tam mamy nieco ograniczen sprzetowcyh ale i tak slysze "uzyj szybszego".
    Co o tym uwazacie ?
    Pozdrawiam
  • Poziom 11  
    kinggustav napisał:
    Owszem, miałem takie obserwacje "niewyjaśnionych" błędów. W każdym przeanalizowanym przypadku (nie wszystkie analizowałem, niektórych nie warto) był to błąd w programie, a nie w sprzęcie.


    Wystarczy śledzić fora producentów i zgłaszane tickety. Nie za często się taką sytuację spotyka, ale jednak.

    Ps. Chodzi o błędy których jeszcze nie uwzględniono w erracie
  • Poziom 26  
    viayner napisał:
    Czas to pieniadz, "naciski ze strony marketingu czy innych dzialow" oraz uzywanie gotowych bibliotek powoduja ze nie istnieje juz chyba pojecie optymalizacji kodu.

    Optymalizacja dla optymalizacji to sztuka dla sztuki. Warto pamiętać o dobrych wzorcach - także przy językach wyższego poziomu, ale program to nie jest olej na płótnie który się stawia w muzeum i ogląda. To jest narzędzie, ma pracować i zarabiać, a czasem taniej i szybciej jest ulepszyć sprzęt niż móżdżyć się przez 2 miesiące nad optymalizacją. Dla fanów optymalizacji za wszelką cenę powstała dyscyplina o nazwie code golf, dla zainteresowanych - https://codegolf.stackexchange.com/
    Druga sprawa, że optymalizacja kosztem pogorszenia czytelności kodu to nie optymalizacja tylko ukryte koszty przeniesione na budżet utrzymania projektu. Jak pracuje się samodzielnie, dla siebie, to można robić dziwne sztuczki które przyspieszą nam wykonanie o 1% albo skrócą zapis z 10 do 2 linii. Ale przy pracy zespołowej jest to niedopuszczalne.
    Żeby to wyjasnić dalej, weźmy np. takie zadanie: https://codegolf.stackexchange.com/questions/179998/sing-baby-shark

    W skrócie - mamy sprawić, żeby program wypisał tekst piosenki i zrobił to przy pomocy jak najkrótszej instrukcji w dowolnym języku. Mamy oczywiście kilka ezoterycznych języków programowania, które stanowią raczej ciekawostkę, ale też i rozwiązania w assemblerze czy pythonie - i wbrew pozorom kod w pythonie jest krótszy :) A odnośnie czytelności - bylibyście w stanie powiedzieć co wypisze taki fragment kodu?
    Kod: python
    Zaloguj się, aby zobaczyć kod

    Może nie jestem biegły w pythonie ale to jest totalnie nieczytelne! Utrzymanie czegoś takiego to horror. I dużo lepiej byłoby po prostu wrzucić do pamięci cały tekst:
    Code:
    Baby Shark doo doo doo doo doo doo
    
    Baby Shark doo doo doo doo doo doo
    Baby Shark doo doo doo doo doo doo
    Baby Shark!
    Daddy Shark doo doo doo doo doo doo
    Daddy Shark doo doo doo doo doo doo
    Daddy Shark doo doo doo doo doo doo
    Daddy Shark!
    Mommy Shark doo doo doo doo doo doo
    Mommy Shark doo doo doo doo doo doo
    Mommy Shark doo doo doo doo doo doo
    Mommy Shark!
    Grandpa Shark doo doo doo doo doo doo
    Grandpa Shark doo doo doo doo doo doo
    Grandpa Shark doo doo doo doo doo doo
    Grandpa Shark!
    Grandma Shark doo doo doo doo doo doo
    Grandma Shark doo doo doo doo doo doo
    Grandma Shark doo doo doo doo doo doo
    Grandma Shark!

    Łatwo go zmienić, widać co w nim się znajduje, ale tak - zużywa dodatkową pamięć.
  • Poziom 14  
    kinggustav napisał:
    Yrecki napisał:
    Do kumatego wystarczą dwa słowa, a do tumana możesz pisać w nieskończoność...


    Trochę to nietrafione. List jest do człowieka, który może być kumaty, albo tuman, program jest dla procesora. Nie słyszałem żeby istniały już mądrzejsze i głupsze procesory. :)

    Pozwolę sobie nie zgodzić się z kolegą :)
    Program zawsze jest dla człowieka, mimo, iż piszesz go do procesora. W końcu każde urządzenie docelowo jest dla człowieka. A ludzie z nich korzystający popełniają tyle błędów, że z czasem programistom ręce opadają, jakie poprawki muszą tworzyć ;)
  • Poziom 38  
    Cytat:
    A ludzie z nich korzystający popełniają tyle błędów

    A w drugą stronę, programiści z NASA bazowali nie na tych jednostkach i coś tam się popsuło. Nie pamiętam dokładnie.
  • Poziom 26  
    Fourier5 napisał:


    Dopóki działa, w razie potrzeby da się domalować resztę jak trzeba, jest zgodne z wymaganiami - nie widzę problemu :) Pytanie brzmi - czy koń od początku nie mógł wyglądać tak:
    Szybkość programowania wydajnosc

    Bo być może ktoś próbował zrobić nie wiadomo jakie dzieło sztuki, skoncentrował się na cieniowaniu tylnych nóg i potem musiał ciąć koszty, chociaż wystarczyłby prosty schematyczny konik :)
  • Poziom 11  
    I zapłacił byś za ten szkic konia ... ile? Jak byś się czuł dając artyście 5tyś zł za obraz konia a otrzymał byś ... to. ?

    Szybko, tanio, byle jak, ale konia można rozpoznać.

    Dlatego ten szkic, jako szkic nie przedstawia zbyt dużej wartości. No chyba że wyszedł z pod ręki jakiegoś znanego mistrza - wtedy cena też wlicza się w "markę".
  • Poziom 26  
    Widzisz, porównanie sztuki (i jej wartości artystycznej) do oprogramowania (i jego wartości użytkowej) nie da się przenosić 1:1. Natomiast wydaje mi się, że taki obraz konia bardzo dobrze sprawdziłby się w kolorowance - i z tego powodu byłbym w stanie za niego zapłacić.
    Załóżmy więc, że jestem wydawcą kolorowanek i zażyczyłem sobie, że chciałbym czarno-biały rysunek konia który da się pokolorować.
    Dlaczego powstało więc "Twoje" dzieło? Ktoś popełnił błąd przy szacowaniu - czasu, kosztów lub wymagań.

    Na przykład - ja (wydawca) zwodziłem artystę tym, że jego szkic będzie w galerii sztuki, ale nie wspomniałem, że tak naprawdę potrzebuję tego do kolorowanki. Artysta rysując "po kosztach" (bo liczył na uznanie w galerii i "wpis do CV") mógł się zirytować gdy dowiedział się o właściwym celu jego dzieła i dokończył go byle jak, aby oddać.

    Być może też ja - mówiłem Artyście, że będzie miał 2 miesiące czasu na narysowanie konia, ale po tygodniu powiedziałem mu, że potrzebuję rysunku na jutro. Artysta dokończył tak, żeby sprostać nowym wymaganiom czasowym.

    A może ja narzuciłem wymóg, żeby szkic był fotorealistyczny, ale w połowie konia zmieniłem zdanie jak dowiedziałem się, ile to zajmie i będzie kosztować?

    Albo Artysta zaczął rysować fotorealistyczny zad konia, a gdy pokazał wstępny szkic, dowiedział się ode mnie (Wydawcy) że to się nie nadaje do kolorowanki dla dzieci i rysunek ma być prosty?

    Można tak długo wymieniać :) A paralela do procesu tworzenia oprogramowania jest, myślę, całkiem trafna :)
    Wszystkie ww. problemy wynikają z niepoprawnego zdefiniowania i zrozumienia wymagań.
  • Poziom 11  
    Pierwszy problem jest taki że aby taki nie programista mógł zrozumieć ile pracy, ile wysiłku, ile czasu trzeba to do czegoś porównać :)

    Każdy kto dba o swoją markę che zlecenie wykonać jak najlepiej, co niestety wiąże się ściśle z poświęconym na projekt czasem, z czego z kolei wynika końcowa cena.
  • Poziom 22  
    I tak i nie. Ano porównujemy i to poprzez cenę, więc bezdyskusyjnie poprawnie. Tyle, że nie jakość programowania, ale ... no właśnie. Zbyt dużo jest czynników decydujących o cenie. To już dawno nie jest wyłącznie poziom złożoności problemu i jakość wykonania. Niestety, jak manager nie zna się na sztuce (od zawsze, lub tylko od przyjęcia łapówki), to akceptuje zawyżoną cenę i rynek IT dalej się psuje. Z drugiej strony pojawiają się "programiści", którzy potrafią zrobić coś za grosze i niektórzy managerowie to wykorzystują, biorąc na klatę (niekoniecznie własną) całe ryzyko. W efekcie za program o funkcjonalności X można zapłacić 500 zł albo 500000 zł, często otrzymując za różnicę wyłącznie prestiż. Trochę to absurdalne, ale porównanie ze sztuką jest jak najbardziej ok. Tam też ceny są z kosmosu. :)
  • Poziom 31  
    Pisze się czasami wolno, a czasami szybko, tylko długo się błędów szuka, no i wydajność maleje... pisania oczywiście. Bo wydajność kodu to kolejny problem.


    hindoos napisał:
    Pytanie brzmi - czy koń od początku nie mógł wyglądać tak:
    Szybkość programowania wydajnosc



    Hm..........

    Szybkość programowania wydajnosc

    Generalnie staram się pisać prosto. Kod powinien być tak napisany by przeczytanie go nie zmuszało do wysiłku, ani umysłowego ani wzrokowego, wszystko ma być łatwe do znalezienia i korekty. Nie zawsze jednak ta sztuka wychodzi. A czasami problemik jest bardziej trudniejszy.