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?
design
pseudocode
Vimal Raj
źródło
źródło
Odpowiedzi:
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.
źródło
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.
źródło
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:
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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:
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
Coraz częściej pseudokod jest pisany graficznie za pomocą narzędzi takich jak UML. Na przykład wypróbuj YUML .
źródło
Ś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.
źródło
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.
źródło
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:
źródło
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:
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ść.
źródło