Czy należy używać pseudokodu przed właściwym kodowaniem?

Pseudokod pomaga nam rozumieć zadania w sposób niezależny od języka. Czy najlepszą praktyką lub sugerowanym podejściem jest tworzenie pseudokodów w ramach cyklu rozwojowego? Na przykład:

• Zidentyfikuj i podziel zadania kodowania
• Napisz pseudokod
• Uzyskaj zatwierdzenie [przez PL lub TL]
• Rozpocznij kodowanie na podstawie pseudokodu

Czy to sugerowane podejście? Czy jest to praktykowane w branży?

Pisanie pseudokodu przed kodowaniem jest z pewnością lepsze niż zwykłe kodowanie bez planowania, ale daleko mu do najlepszej praktyki. Rozwój oparty na testach jest ulepszeniem.

Jeszcze lepiej jest analizować domenę problemów i projektować rozwiązania przy użyciu technik takich jak historie użytkowników, przypadki użycia, karty CRC, diagramy, jak zalecają metodologie takie jak Cleanroom, RUP, Lean, Kanban, Agile itp.

Dokładne zrozumienie natury problemu i komponentów używanych do wdrożenia rozwiązania jest podstawą najlepszych praktyk.

Używam komentarzy jako rodzaju pseudo kodu bardzo wysokiego poziomu, ponieważ piszę komentarze przed napisaniem kodu. Uważam, że przemyślenie całego problemu, nawet na wysokim poziomie, znacznie poprawia mój kod.

Nie, nie pseudokod najpierw

To za dużo narzutów. Robisz pracę nad pisaniem logiki bez żadnych korzyści. Sugerowałbym zamiast tego jedno z poniższych:

1. Prototyp w języku, w którym zamierzasz wysyłać (AKA Napisz jeden do wyrzucenia )
2. Diagramy architektury z fragmentami kodu do testowania założeń / kluczowych projektów
3. Test Driven Development, w którym najpierw piszemy interfejsy / strukturę kodu, a następnie testy, a następnie implementację kodu.

Wszystkie trzy z nich przenoszą cię bezpośrednio do rozwiązania, w przeciwieństwie do pseudokodu. Osobiście używam technik 1 lub 2 w zależności od wielkości zespołu. W przypadku mniejszych (np. 5 osób lub mniej) zespołów prototypowanie działa bardzo dobrze. W przypadku większych zespołów, w których pracuje wiele grup programistów pracujących równolegle, stwierdziłem, że dokumentacja utworzona wcześniej techniką 2 działa dobrze, ponieważ daje możliwość wcześniejszej dyskusji i pomaga lepiej zdefiniować granice komponentów. Jestem pewien, że TDD również działałoby bardzo dobrze, ale muszę jeszcze pracować w zespole, który zaangażował się w ten proces.

Moim zdaniem pseudo-kod ma tylko dwa ważne cele:

(1) Do programowania studentów, którzy muszą nauczyć się pojęć modułowości i algorytmów, ale nie znają jeszcze płynnie języka programowania.

(2) Komunikowanie się, jak coś będzie działało z osobą nietechniczną, lub tylko ze względu na celowość podczas spotkania typu whiteboard.

Czy pseudo-kod jest sugerowanym podejściem? Początkującym programistom mówię tak. Pomaga nowemu programistowi nauczyć się, jak tłumaczyć problem na kod, nie martwiąc się o dokładną składnię języka. Kształtuje to proces myślowy i może pomóc w zakotwiczeniu przydatnych nawyków (i przypuszczam, że również złe nawyki). Dlatego jest tak często używany w szkołach.

Czy jest to praktykowane w przemyśle? Z mojego doświadczenia wynika, że ​​nie. Nikt nie ma czasu na dokładne opracowanie projektu między dokumentacją (wymagania, specyfikacje, scenariusze, przypadki użycia lub cokolwiek innego, z czego korzystają) a rzeczywistym kodem. Ogólnie przyjmuje się, że problem został już przemyślany przed zielonym światłem do zakodowania. W tym momencie kodowanie projektu jest ważniejsze niż dodanie jeszcze jednej warstwy przygotowania projektu.

Zdecydowanie poleciłbym pseudokod. Pomaga wyjaśnić, co zamierzasz zrobić, i zidentyfikować przedmioty, o których mogłeś zapomnieć lub o potencjalnych problemach. O wiele łatwiej / szybciej jest naprawić kod, gdy jest on jeszcze w fazie planowania, zamiast czekać, aż kod zostanie już zakodowany.

Pseudokod może być przydatny, jeśli nie znasz języka lub potrzebujesz zmienić konteksty mentalne. Przy rzadkiej okazji, gdy piszę pseudokod, jest on na papierze. Czasami po prostu zdejmowanie rąk z klawiatury i pisanie na papierze może pomóc w rozwiązaniu problemu psychicznego.

Ale jako sformalizowana część procesu rozwoju? Nie ma mowy. Jest to sporadycznie pomocne narzędzie dla osób fizycznych. Są lepsze sposoby „wiedzieć, co piszesz, zanim je napiszesz”, na przykład:

1. zdefiniowanie kontraktu (warunki wstępne / niezmienne / niezmienne) metody przed rozpoczęciem
2. TDD
3. 1 i 2 łącznie (testy pisemne w celu wykonania umowy)

Sugeruję również, że uzyskanie jakiegokolwiek zatwierdzenia przed rozpoczęciem pisania kodu może spowodować znacznie więcej problemów niż jest to warte. Przeglądy projektów (przedwdrożeniowe) mogą być przydatne, ale muszą być na wyższym poziomie niż poszczególne algorytmy.

Nie zgadzam się z poprzednimi odpowiedziami i mówię „nie”, ale z zastrzeżeniem: możesz pozbyć się psuedocode tylko wtedy, gdy gorączkowo poświęcasz refaktoryzacji kodu, aby poradzić sobie z pojawiającymi się problemami. Psuedocode jest w istocie sposobem definiowania kodu przed jego zdefiniowaniem; w wielu okolicznościach jest to niepotrzebna abstrakcja, a ponieważ twój kod nigdy nie będzie idealny za pierwszym razem (i prawdopodobnie nie będzie zgodny z projektem psuedokodu do końca), wydaje mi się, że jest obcy.

Jeśli piszesz w języku COBOL lub C, pseudokod może być pomocny, ponieważ napisanie rzeczywistego kodu zajmie znacznie więcej czasu, a jeśli możesz zweryfikować algorytm / wymagania z pseudokodu, możesz zaoszczędzić trochę czasu.

W bardziej współczesnych językach pseudokod nie ma tak dużego sensu. Lepsze byłoby pisanie kodów metod i wypełnianie logiki najwyższego poziomu oraz tyle szczegółów, ile potrzeba, aby zweryfikować algorytm i wymagania, a wszystko to w rzeczywistym kodzie. Następnie możesz pokazać ten kod szefowi zespołu do zatwierdzenia i mieć już uruchomiony prawdziwy kod.

W ciągu ostatnich 10 lat użyłem pseudokodu tylko podczas wywiadu, kiedy pracujemy na tablicy, a konkretny język nie ma znaczenia.

Jest to z pewnością pomocne w swobodnym omawianiu procesu / algorytmu bez zagłębiania się w składnię. Na przykład napisanie klasy C ++, która ma właściwości C #, tylko dla zilustrowania tego.

Ma swoje „miejsce”, ale powinno się go używać tylko tam, gdzie jest to potrzebne (to praca, którą wyrzucisz) i na pewno nie jest to część formalnego procesu, chyba że wymagają tego standardy typu ISO.

Dla mnie i ludzi, z którymi pracowałem przez ostatnie kilka lat, pseudokod zmienił się prawie w nie do końca prawdziwy, prawdziwy kod. chyba że pracujesz w wielu językach jednocześnie, wydaje się, że większość ludzi zaczyna myśleć zgodnie z ogólnym wzorcem swojego głównego języka. Od dłuższego czasu pracuję w sklepach .net, więc większość ludzi pisze na tablicy w biurze, jak w przypadku vb lub c #, z brakiem niektórych znaków interpunkcyjnych.

Ćwiczenie jest nadal cenne, gdy dyskutuje się nad opcjami i tym podobnymi, ale język agnostyczny ma tendencję do zanikania, gdy spędzasz więcej czasu z kilkoma językami.

Coraz częściej pseudokod jest pisany graficznie za pomocą narzędzi takich jak UML. Na przykład wypróbuj YUML .

narzędzie online do tworzenia i publikowania prostych diagramów UML. Ułatwia to:

• Osadzaj diagramy UML w blogach, e-mailach i wiki.
• Publikuj diagramy UML na forach i blogach.
• Używaj bezpośrednio w internetowym narzędziu do śledzenia błędów.
• Skopiuj i wklej diagramy UML do dokumentów MS Word i prezentacji Powerpoint ...

... yUML oszczędza czas. Jest przeznaczony dla tych, którzy lubią tworzyć małe diagramy i szkice UML.

Bez yUML tworzenie diagramu UML może wymagać załadowania narzędzia UML, utworzenia diagramu, nadania mu nazwy, manipulowania układem, wyeksportowania go do mapy bitowej, a następnie przesłania go gdzieś online. YUML nie każe ci tego robić ...

Świetna robota. Rozpocząłeś dobrą dyskusję. Od samego początku pisałem pseudokody, kiedy uczyłem się programowania, aby zrozumieć różne pętle i algorytmy. To było ponad półtora dziesięciolecia temu. W tamtych czasach nawet języki programowania nie były zbyt potężne ... a programowanie oparte na zdarzeniach było przyszłością. Teraz z 4GL i 5GL myślimy raczej w samym języku niż w zwykłym języku angielskim. Kiedy myślimy o problemie, myślimy o obiektach i operacjach. I dopóki nie będzie to skomplikowane algo, pisanie pseudo kodów (lub kodów PSEU-DO, tylko żartowanie) nie ma sensu. Lepiej, przedstaw rozwiązanie w sposób graficzny.

Zależy od używanego języka i jego znajomości.

Wiele współczesnych języków, takich jak Python lub Java, jest już tak blisko pseudokodu, że najpierw napisanie jakiegoś pseudokodu ad hoc jest marnotrawstwem, IMHO. Lepiej po prostu zrób to od razu, używając podejścia pocisku znacznika .

To inna sprawa, jeśli robisz jakieś rzeczy na niskim poziomie, zbliżone do metalowych lub nie czujesz się jeszcze komfortowo z językiem, którego używasz. Wtedy pseudokod może być zdecydowanie przydatny.

W mojej pracy zdarza się kilka przypadków, w których pseudokod często się psuje, czyli w środowisku akademickim, gdzie programowanie jest zwykle używane jako narzędzie lub „i teraz rozwiązujemy to”, wypełniając środek projektu:

1. Kiedy kod będzie przynosił efekt przeciwny do rzeczywistego zrozumienia tego, co się wydarzy, niż pseudo-kod. Na przykład SAS zajmie połowę tablicy wykonując dość podstawowe zadania programistyczne. Zobacz także C, o którym rozmawiali inni plakaty.
2. Przy dużej ilości analiz danych i kodowaniu statystyk, przy generowaniu wyników często pojawia się majsterkowanie przy kodzie. Pseudokod jest nieco łatwiejszy w użyciu, ponieważ „w tym przypadku chodzi o proces tam iz powrotem, jeśli wykres diagnostyczny nie wygląda dobrze, spróbuj X”.
3. Uczniowie uczą się wielu różnych języków programowania. Na przykład wśród osób, które znam, problem statystyczny można analizować w SAS, R lub Stata. Coś, co wymaga czegoś bliższego tradycyjnemu programowaniu, można wykonać w R, Matlab, C, C ++, Java, Python ... tak naprawdę zależy to od tego, który konkretny uczeń wdraża program i do jakiego celu. Ale nadal przydatne dla ludzi Java, Python i Matlab jest wspólne wyobrażenie o tym, co robią inni i jak działa to podejście , a nie sam kod.

To nie jest pytanie typu tak / nie. Należy raczej zastanawiać się, kiedy użyć pseudokodu. Ważne jest, aby zrozumieć problem przed zaprojektowaniem rozwiązania i ważne jest, aby mieć jasny obraz rozwiązania przed jego wdrożeniem. Pseudokodu można użyć w dowolnym z następujących kroków:

1. Podczas definiowania problemu często zapisuje się przypadki użycia, czasem używając sekwencji działań.
2. Podczas projektowania rozwiązania. Diagramy klas są ładne, ale opisują tylko część „statyczną”, tj. Dane. W przypadku części dynamicznej, gdy tylko zajdzie potrzeba obsługi pętli i nietrywialnych danych, pseudo-kod jest najlepszą dostępną metodą. Alternatywy graficzne obejmują maszyny stanu (dobre dla złożonego przepływu sterowania z małą ilością danych) i diagramy przepływu danych (dobre dla prostych przepływów ze złożonymi danymi).
3. Podczas wdrażania rozwiązania (lub tuż przed nim). Niektóre języki programowania są trudne do odczytania (pomyśl, asembler). Alternatywne przedstawienie może być w tym przypadku cenne. Jeśli nie znasz języków, warto to zrobić.

Używany jest również pseudo-kod, który jest właściwie prawidłowym kodem w języku wysokiego poziomu, zwykle nazywany jest prototypowaniem.

Oprócz zrozumienia, pseudo-kod jest również dobry do komunikacji.

Jeśli zastanawiasz się, czy powinieneś regularnie używać pseudokodu, osobiście jestem przeciwny wszelkim sztywnym regułom. Może to łatwo przerodzić się w nudną stratę czasu, jeśli zostanie zastosowany do drobnych problemów, które wszyscy w zespole rozumieją. Korzystanie z pseudokodu w specyfikacjach, które zachowuje się przez cały czas trwania projektu, może być również kosztowne i mieć niewielką wartość.