DejaVu |
» 2013-05-23 01:27:33 Jak sądzisz DejaVu, czy taki początkujący czy też średniak (ja :-) w trakcie pisania swojego, tam prostego kodu powinien już w trakcie pisania obmyślać tricki optymalizujące np. szybkość czy dopiero jak wykona prototypowy działający program? Chodzi mi o taki kod 2000 linijek (czytelnych ale bez rozwlekania).
|
Moim zdaniem najważniejszym jest umiejętność dzielenia kodu na 'klocki'. Tworząc 'klocki' możesz zarówno szybko pisać dobry kod, jak również łatwo go później zoptymalizować gdy zajdzie potrzeba. Niestety kursów na takie bajery próżno szukać w necie, a mi na razie nie śpieszno do pisania takich rzeczy, dopóki kurs C++ (z mojego punktu widzenia) jest w powijakach ;) |
|
usmiech |
» 2013-05-23 11:29:13 Odnosnie studiowania IT w Polsce to zgadzam sie z DejaVu. Zdecydowanie lepiej wyglada to np w UK. Osoba, ktora znam b.dobrze tu skonczyla takowe studia. Przez trzy lata studiowania bylo tylko 6 czy 7 przedmiotow, wszystkie powiazane z IT /sieci, programowanie, bazy danych itp . Uczelnia ma umowy z Microsoft , Cisco itp.. Student ma bezplatny dostep do calej 'oferty programowej' tych firm. Staz w najlepszych firmach. Mozna by jeszcze sporo pisac, ale co najwazniejsze .. Uczelnia jest dla studenta, a nie odwrotnie !. A odnosnie programowania to podoba mi sie takie stwierdzenie.. Pisz kod tak, zeby osoba , ktora zacznie pracowac na tym kodzie po Tobie, a wiesz , ze to wariat i potencjalny zabojca...i co wazniejsze - zna twoj adres !! , nie wkurzyla sie hahahhhahahaha. Pozdrawiam :) ps pomimo tych roznic uczelnia rowniez i tu nie jest w stanie nauczyc dobrze programowania i dopiero w pracy /dobra firma/ tak naprawde zaczyna sie powazna 'zabawa w programowanie' :) |
|
DejaVu |
» 2013-05-23 11:47:20 Zmieniłem nazwę tematu i przeniosłem go do innego działu - w sumie dyskusja sprowadziła się do pytania aktualnie postawionego w temacie :P |
|
akwes |
» 2013-05-23 12:07:53 To ja jeszcze wtrącę swoje 3 gorsze, a właściwie nie swoje ;> Wytyczna 8 Wystrzegaj się przedwczesnej optymalizacji Nie bodzie się chętnego wierzchowca. Przedwczesna optymalizacja jest równie uzależniająca jak bezproduktywna, pierwsza reguła optymalizacji mówi bowiem: zaniechaj jej. Druga reguła (dla ekspertów) mówi zaś: powstrzymaj się jeszcze. Jedną optymalizację trzeba poprzedzić dwoma pomiarami dowodzącymi jej konieczności. [...] Często przedwczesna i niepoparta pomiarami optymalizacja, mimo włożonego w nią wysiłku, nie daje dosłownie żadnego efektu wydajnościowego. [...] Nie należy więc od początku skupiać się na szybkości kodu - w pierwszej kolejności powinna nas interesować raczej jego przejrzystość i czytelność. W kodzie czytelnym łatwiej o poprawność, zrozumienie jego działania, wprowadzanie poprawek i zmian, i wreszcie optymalizację. Komplikacje, nieodzowne dla optymalizacji zawsze można wprowadzić później - i tylko wtedy, gdy są niezbędne. [...] Oczywiście nadejdzie taki wreszcie ten dzień, kiedy kod trzeba będzie nieco zoptymalizować. W takim przypadku w pierwszej kolejności należy szukać ratunku w zmniejszeniu złożoności obliczeniowej algorytmu i równocześnie próbować hermetyzować i ograniczać zasięg optymalizacji. [...] Powszechnym błędem początkujących programistów jest pisanie - z dumą! - nowego kodu z obsesyjną myślą o jego jak największej wydajności, kosztem czytelności i zrozumiałości. Najczęściej efektem takiej pracy jest kod spaghetti, który - nawet jeśli poprawny - utrudnia analizę i ewentualne modyfikacje. [...] Nie jest przed wczesną optymalizacją przekazywanie argumentów i wartości zwracanych przez referencję, preferowanie przedrostkowych wersji operatorów inkrementacji i tym podobne idiomy. [...]
|
Gdzieś jeszcze autor wspomina o bezcelowości urywania tu i ówdzie pojedynczych instrukcji procesora. |
|
DejaVu |
» 2013-05-23 13:48:05 Prawdziwe stwierdzenia i słuszne, ale ostatniego zdania jakoś nie rozumiem :P |
|
akwes |
» 2013-05-23 14:10:16 Gdzieś jeszcze autor wspomina o bezcelowości urywania tu i ówdzie pojedynczych instrukcji procesora.
|
Nie mogę właśnie dokładnie namierzyć tego fragmentu książki. Głównie chodziło o to, aby kosztem czytelności nie starać się robić "sztuczek", które zmniejszą kod wynikowy o jedną operację asma. Bo często kompilator i tak sam to z optymalizuje a kod traci na czytelności. A nawet jeżeli kompilator tego nie zoptymalizuje to i tak dziesiątki takich sztuczek nie dadzą tego co optymalizacja algorytmu. Czyli na przykład zamiast próbować zapisać jednego ifa bardziej optymalnie, lepiej zastanowić się, co u nas robi algorytm O(n^3) :) Zauważyłem u siebie na zajęciach, że koledzy potrafią kilka razy przebudować ifa, szukać sposobu na uniknięcie zmiennych tymczasowych typów wbudowanych, zamieniać czytelne funkcje w funkcje postaci int fun() { return } stosując jednocześnie nieoptymalne algorytmy. Pamiętam, że zostało to właśnie nazwane "urywaniem tu i ówdzie pojedynczych instrukcji procesora". Owszem, czasem nawet i taka optymalizacja jest przydatna, ale jak często piszemy coś co wymaga aż takiej optymalizacji :P? |
|
1 « 2 » |