Dlaczego programiście lepiej jest zaprojektować algorytm przed rozpoczęciem pisania kodu?

Czy odpowiedni algorytm naprawdę pomaga poprawić jakość, a ostatecznie wydajność programu?

Czy nadal możemy stworzyć program dobrej jakości bez algorytmu?

Czy odpowiedni algorytm MUSI być stosowany w nowoczesnym programowaniu?

Myślę, że to pytanie wymaga pewnej perspektywy historycznej.

W „dawnych czasach” (których nie jestem osobistym świadkiem, więc jest to tylko moja rekonstrukcja tamtej epoki - możesz mnie poprawić, jeśli doświadczyłeś inaczej) Przestrzeń sprzętowa i wydajność były zerowe w porównaniu z dzisiejszymi. Więc wszystko, co ludzie pisali, musiało być bardzo wydajne. Dlatego musieli dużo przemyśleć i wynaleźć najlepsze algorytmy, aby osiągnąć wymaganą wydajność przestrzenno-czasową, aby wykonać zadanie. Innym czynnikiem było to, że programiści pracowali głównie nad tym, co możesz nazwać infrastrukturą : systemami operacyjnymi, stosami protokołów, kompilatorami, sterownikami urządzeń, edytorami itp. Wszystko to jest używane przez wiele osób, więc wydajność naprawdę robi różnicę .

W dzisiejszych czasach rozpieszcza nas niesamowity sprzęt z procesorami wielordzeniowymi i gigabajtami pamięci nawet w podstawowym laptopie (cholera, nawet w telefonie komórkowym). Co oczywiście oznacza, że ​​w wielu przypadkach wydajność - a więc algorytm - przestała być głównym problemem, i ważniejsze jest zapewnienie szybkiego rozwiązania niż szybkiego. OTOH, mamy mnóstwo frameworków, które pomagają nam rozwiązywać problemy i obejmują wiele algorytmów jednocześnie. Nawet jeśli nie myślimy o algorytmach, możemy bardzo dobrze używać ich w tle.

Jednak nadal istnieją obszary, w których wydajność ma znaczenie. W tych obszarach nadal musisz dużo myśleć o swoich algorytmach przed napisaniem kodu. Powodem jest to, że algorytm jest centrum projektu, określając wiele struktur danych i relacji w otaczającym kodzie. A jeśli zbyt późno odkryjesz, że twój algorytm nie skaluje się dobrze (np. Jest to O (n ³ ), więc wyglądał ładnie i szybko, gdy testowałeś go na 10 elementach, ale w rzeczywistości będziesz mieć miliony), to jest bardzo trudne, podatne na błędy i czasochłonne, aby zastąpić go w kodzie produkcyjnym. Mikrooptymalizacje nie pomogą ci, jeśli podstawowy algorytm nie jest odpowiedni do zadania.

Wystarczy wskazać coś:

Algorytm sam w sobie stanowi ogólne rozwiązanie problemu. Tak więc, jeśli rozwiązałeś problem, faktycznie użyłeś algorytmu.

Najważniejsze w tym miejscu jest to, że musisz użyć algorytmów do rozwiązania problemu, w taki czy inny sposób. Przez większość czasu lepiej jest pomyśleć o swoim problemie, zanim przejdziesz do kodowania - ta faza jest często nazywana projektowaniem. Ale to, ile i w jaki sposób to zrobisz, zależy od ciebie.

Nie powinieneś także mieszać pojęcia algorytmu ze schematami blokowymi (podejrzewam, że to się tutaj dzieje). Schematy blokowe to tylko jedna graficzna reprezentacja, której można użyć i która była używana w starszych czasach w celu zilustrowania algorytmu. Obecnie jest to bardzo przestarzałe.

EDYTOWAĆ:

Rzeczywiście istnieje wiele sposobów przedstawienia algorytmu, a sam kod języka programowania jest jednym z nich. Jednak dość często lepiej lub łatwiej jest nie rozwiązać całego problemu na raz, a jedynie zarys, a następnie wypełnić puste pola.

• Moim osobistym ulubionym tutaj jest pseudo-kod, i tylko w celu omówienia ogólnego abstrakcyjnego zarysu omawianego algorytmu - niedorzeczne jest wchodzenie w szczegóły za pomocą pseudokodu , po to jest prawdziwy kod.

• Ale do konspektu można użyć prawdziwego kodu. Na przykład ludzie TDD lubią projektować algorytm podczas kodowania, a ponieważ nie są w stanie rozwiązać go jednocześnie, projektują zarys wykonania programu w prawdziwym kodzie i używają próbnych obiektów (lub funkcji, metod ... .) jako puste pola do wypełnienia później.

• Diagramy aktywności UML wydają się być nowoczesnym wcieleniem schematów blokowych w starym stylu z dodanym zapisem nowych rzeczy, takich jak polimorfizm i wielowątkowość. Nie jestem w stanie powiedzieć, jak bardzo jest to użyteczne, ponieważ tak naprawdę nie używałem ich zbyt wiele - po prostu wspominam o tym dla kompletności.

• Ponadto, jeśli opierasz swój algorytm na przełączaniu między stanami, diagram stanu jest bardzo pomocny.

• Ogólnie rzecz biorąc, każdy sposób, w jaki musisz po prostu naszkicować ideę określonego algorytmu, jest dobrym rozwiązaniem.

Dobrą analogią jest to, że musisz znać przepis przed rozpoczęciem gotowania. Ok, możesz go ulepszyć w trakcie pracy, ale zanim zaczniesz, musisz wiedzieć, co chcesz zrobić. Jeśli chcę zrobić gulasz jagnięcy, będę robił różne rzeczy, niż gdybym chciał upiec bochenek chleba.

Kod implementuje algorytmy. Próba napisania kodu bez zaprojektowania algorytmu przypomina próbę pomalowania domu przed wybudowaniem ścian. Algorytmy są „MUSZĄ” od początku programowania.

Biegła znajomość języka pomaga poprawić jakość i produktywność. A rozwiązywanie małych problemów algorytmicznych jest o wiele bardziej przydatne niż powtarzanie tego samego MVC 100 razy.
Chociaż przypuszczam, że istnieją inne sposoby osiągnięcia płynności.

Czy algorytm stanie się koniecznością we współczesnej dziedzinie programowania?
Jest to już „must”, chyba że jesteś jakimś „ninja php” piszącym „cool codez”. Wszystkie „najlepsze” firmy (Google, Amazon itp.) Testują twoje algorytmiczne doświadczenie w wywiadzie i wyobrażam sobie, że nie zrobiłyby tego bez powodu.

Ale wracając do pierwotnego punktu, powinieneś stale stawiać sobie wyzwania, jeśli chcesz poprawić. A ponieważ normalne zadania (znane również jako „teraz piszą menedżery CRUD dla 100 dodatkowych obiektów”) nie zawsze stanowią dobre wyzwanie, algorytmy to kompensują.

Powiedziałbym, że potrzebujesz przynajmniej wstępnego pomysłu na algorytm, zanim zaczniesz kodować. Prawdopodobnie zrewidujesz swój pomysł podczas kodowania w oparciu o struktury danych itp.

Później możesz ponownie poprawić kod, jeśli profilowanie sugeruje, że występuje problem z wydajnością w tym obszarze.

Powodem jest to, że szybciej jest naprawić błędy, zanim napiszesz błędny kod.

Mówiąc prościej, między programistami rutynowo mierzy się 10 do 1 różnic wydajności. Kiedy patrzysz na programistów, którzy są na 10-krotnym poziomie wydajności, spędzają najmniejszą część swojego czasu na kodowaniu. Czas na wpisanie kodu nie powinien stanowić wąskiego gardła. Zamiast tego spędzają większą część swojego czasu, upewniając się, że mają proste wymagania, planowanie, testowanie itp.

I odwrotnie, gdy patrzysz na programistów, którzy nurkują w kodowaniu bez przerwy, nieuchronnie muszą pisać kod w kółko, ponieważ napotykają całkowicie przewidywalne problemy, a końcowy wynik jest mniej konserwowalny i bardziej błędny. (Nawiasem mówiąc, wiesz, że średnio 80% pieniędzy wydanych na rozwój oprogramowania jest w fazie konserwacji?

Generalnie najpierw algorytmy i struktury danych, później kod. Ale to zależy w dużej mierze od dziedziny programowania. Często robiłem matematykę i naprawdę spoglądałem na ówczesny model wodospadu. Stało się tak, ponieważ algorytmy od niskiego do średniego poziomu rzadko można uznać za coś oczywistego. Zaprojektuj dużą strukturę wokół istnienia niepisanych podsystemów, a następnie odkryj w dalszej części gry, że matematyka dla jednego z tych kluczowych podsystemów nie działa (jest niestabilna lub coś w tym rodzaju). Zawsze więc najpierw myślałem o najtrudniejszych podsystemach, a jeśli pojawiały się jakiekolwiek wątpliwości, najpierw je pisałem i testowałem. Ale w przypadku niektórych problematycznych domen możesz po prostu iść do przodu bez większego planowania.

Zaprojektuj algorytm w sekcjach, a następnie podziel te sekcje i koduj każdą z nich osobno. W ten sposób możesz łączyć oba punkty widzenia:

1. Użyj swoich umiejętności językowych, aby uruchomić algorytm
2. Spróbuj pomyśleć przed kodem, aby Twój pomysł nie łączył się z językiem (pewnego dnia musisz przenieść algorytm na inny język, a skończysz na spagetthi)

Dla mnie to prawie cały kod. Myślę, że dotyczy to większości bardzo produktywnych programistów. Potrafię pisać kod tak łatwo, jak piszę tekst.

W miarę możliwości staram się uchwycić wymagania jako testy wykonywalne (kod). Projekt to po prostu kodowanie na wysokim poziomie. Uchwycenie projektu w języku docelowym jest szybsze i bardziej precyzyjne niż uchwycenie go w innej formie, a następnie przetłumaczenie.

Przekonałem się, że większość użytkowników nie może skutecznie przeglądać wymagań tekstowych. Radzą sobie z sekwencyjnymi przypadkami użycia, ale przypadki użycia nie mogą uchwycić każdego aspektu interfejsu użytkownika. Jak dotąd najlepiej jest zrobić pierwsze cięcie przy implementacji, pozwolić użytkownikom wypróbować je, uzyskać ich komentarze i odpowiednio zmodyfikować kod.

Kiedy siadasz i zaczynasz kodować, masz na myśli algorytm, „zaprojektowany” czy nie.

Jeśli usiądziesz i zaczniesz kodować bez kompletnego algorytmu, wykonasz jedną z następujących czynności:

1) losowe łączenie kluczy. Prawdopodobnie spowoduje to błąd kompilatora

2) pisanie kompilowalnego kodu, który prawdopodobnie robi cokolwiek poza tym, co chcesz

3) pisanie kodu w celu rozwiązania niewielkich części problemu i budowanie go w miarę agregacji, ale tak naprawdę nie myślenie naprzód - więc w końcu problem zostanie rozwiązany - ale kod nie jest zbyt wydajny, a przy możliwość cofnięcia się i marnowania czasu po drodze

Ludzie zwykle programują z algorytmem w głowie. Być może zostało to rozwinięte lub uzasadnione na papierze lub innym nośniku.

Dobrą dyscypliną może być myślenie o ataku na problem z dala od klawiatury, szczególnie we wczesnych latach programowania. Jak zauważyły ​​inne odpowiedzi, w miarę zdobywania doświadczenia możesz lepiej kodować niektóre „łatwiejsze do opanowania” fragmenty problemu „w locie”. Jednak w przypadku trudnych lub dużych problemów przydatne jest myślenie i projektowanie z dala od klawiatury: gdy zajmujesz się kodem, bardziej prawdopodobne jest, że myślisz o konstrukcjach języka i o tym, jak podejść do najbardziej bezpośredniego zadania w problem. Myślenie o problemie z, powiedzmy, długopisem i papierem, uwalnia cię bardziej od językowego aspektu kodu i pozwala myśleć na wyższym, bardziej abstrakcyjnym poziomie.

Musisz przestać patrzeć na konstrukcję oprogramowania jako coś zasadniczo z konstrukcji czegoś innego wartościowego. Nie jest. Tak więc, jak wszystko inne, zawsze potrzebny jest przemyślany plan lub projekt, bez względu na to, jak jest skuteczny.

Czy odpowiedni algorytm naprawdę pomaga poprawić jakość, a ostatecznie wydajność programu?

Czy odpowiedni plan / schematy budynku pomaga skutecznie zbudować dom wysokiej jakości?

Czy nadal możemy stworzyć program dobrej jakości bez algorytmu?

Czy potrafisz skutecznie zbudować dom dobrej jakości bez odpowiedniego planu budowy? Zgodnie z twierdzeniem o nieskończonej małpie , najprawdopodobniej tak (tak jak milion małp, piszących losowo przez wieczność, w końcu napisze kompletne dzieła Szekspira.

Czy odpowiedni algorytm MUSI być stosowany w nowoczesnym programowaniu?

Jeśli nie chcesz być małpą kodową i chcesz się upewnić, że nie dostarczasz oprogramowania, które wygląda i działa jak gówno, tak, jest to koniecznością. Każdy projekt, który musiałem uratować (ponieważ kod wyglądał jak możliwe do zapamiętania gówno), niezmiennie zaczynał od negatywnej odpowiedzi na to pytanie.

W rzeczywistości, nowoczesne programowanie było odejście od programowania kowbojskim inżynier oprogramowania, gdzie planuje jakiegoś jeśli moszczu.

Nawet jeśli masz do dyspozycji bibliotekę algorytmów i struktur danych (.ie. Boost w C ++ lub bibliotece kolekcji Java), musisz wiedzieć, jak to działa, aby odpowiednio go użyć i skomponować go w rozsądny, wyższy- algorytmy poziomu.

Nie jest lepiej. Lepiej niczego nie „projektować”. To jest dla ludzi, którzy nie piszą programów. Wiesz, ludzie z prawdziwym doświadczeniem tego problemu. Jeśli jesteś matematykiem, inżynierem lub logistą, dobrze, musisz popracować nad procesem gdzie indziej. Ale to nie jest „programowanie”.

Najpierw umieść test i test porównawczy.

Więc napisz coś, cokolwiek. Wykonaj refaktor-przepisz-pętlę, aż skończy Ci się czas lub nie będziesz mógł już poprawić.

Podczas gdy wielu uważa, że ​​można robić rzeczy z komputerem bez robienia czegokolwiek na komputerze, myślę, że jest to jeden z najczęstszych mitów. Architektura astronautyzmów.

Ponadto nie można zoptymalizować algo przed napisaniem.

IOW, „trzymaj się blisko metalu”.