Nauczyłem się w szkole i czytałem wszędzie, że dobra metodologia rozwoju wymaga koncepcji i projektu przed prawidłowym kodowaniem.
To nie jest nowa informacja nawet dla początkującego programisty. Zastanawiam się jednak, czy to dobra rada, ponieważ odkąd zacząłem rozwijać się w kilku językach programowania, nigdy nie udało mi się zaprojektować i wymyślić wszystkiego od samego początku.
Mam na myśli, że zawsze roztapiałem design, koncepcję i programowanie. Czy jestem najgorszym programistą na świecie, czy też pomysł, którego się uczymy w szkole, to stary bezsensowny religijny dogmat?
Jak możemy nawet wymyślić i zaprojektować coś, czego nigdy wcześniej nie doświadczyliśmy i nie zaprogramowaliśmy? Czy to nie jest śmieszne? Czy programowanie nie prowadzi zamiast tego koncepcji i projektu?
Odpowiedzi:
Myślę, że odpowiedź musi brzmieć: Zaplanuj tyle, ile możesz, ale nie więcej.
Niewiele osób sprzeciwiałoby się cnotom planowania, ale w debacie przeoczono ważny aspekt. Planowanie działa tylko wtedy, gdy masz umiejętność wykonania dobrego planu, umiejętność ta ma zwykle doświadczenie. Jeśli nie masz dużego doświadczenia, każdy sporządzony plan będzie prawdopodobnie wiązał się z poważnymi problemami, co oznacza, że aby stworzyć produkt, który nie jest całkowitą katastrofą, plan będzie musiał zostać mocno zmieniony podczas opracowywania, jeśli plan jest szczegółowy, prawdopodobnie spowoduje to unieważnienie wielu szczegółów lub, co gorsza, spróbujesz ograniczyć korekty do minimum, aby móc postępować zgodnie z planem.
Niektóre rzeczy na pewno wymagają planowania, a jeśli nie masz umiejętności przygotowywania wymaganego poziomu planu, to jedyną drogą, jaką mogę sobie wyobrazić, jest prototypowanie, pisanie kodu po prostu w celu zdobycia doświadczenia z zadaniem wymaganym do stworzenia odpowiedniego planu .
Niezależnie od tego, czy jesteś gotowy do pisania kodu produkcyjnego, po osiągnięciu maksymalnego poziomu planowania nie pozostaje już nic innego jak kodowanie. Może to będzie katastrofa, ale są to dobre doświadczenia edukacyjne i będziesz o wiele lepiej przygotowany do opracowania zmienionego planu.
źródło
To jest absolutna prawda. Im większe i bardziej złożone wymaganie, tym bardziej jest to prawdziwe.
W przypadku małej aplikacji konsolowej do obliczania sekwencji Fibonacciego może nie być potrzebnych więcej niż kilka minut na zastanowienie się nad tym, jak ustrukturyzować algorytm i interfejs użytkownika (który tak może być po prostu stdin i stdout).
Ale co powiesz na platformę handlową w czasie rzeczywistym, która spodziewa się wykonywać miliony transakcji na sekundę, dystrybuowanych na całym świecie, a to wymaga 99,9999 czasu bezawaryjności i 100% poprawności? Czy po prostu wskoczyłbyś w to?
Istnieje wiele innych opcji między tymi dwiema skrajnościami.
Spójrz na projekt Euler . Rozwiąż niektóre problemy w przedstawionej kolejności. Dowiesz się, że aby rozwiązać niektóre problemy w rozsądnym czasie, musisz pomyśleć przed skokiem do kodu.
Jeśli nie potrzebujesz czasu na przemyślenie i zaprojektowanie programu przed rozpoczęciem pisania kodu, pracujesz nad trywialnymi sprawami lub brakuje czegoś większego.
Nikt nie robi nic poza najbardziej trywialnymi problemami. Ponownie, im większy i bardziej złożony projekt, tym bardziej jest to prawdą - w projektach będą błędy, rzeczy, które zostaną przeoczone itp.
Sztuka polega przede wszystkim na projektowaniu na wysokim poziomie, sprawdzając, czy duże elementy pasują. Następnie uzyskaj listę priorytetów - najpierw zacznij pracę nad najważniejszą / infrastrukturą. Następnie idziemy i dzielimy większe kawałki na mniejsze, upewniając się, że każdy większy kawałek składa się z elementów, które mają sens.
Wymaga to czasu i wysiłku - i na początku może nie być kompletne lub całkowicie poprawne.
Ale dlatego nazywa się to oprogramowaniem miękkim, a nie twardym . Jest plastyczny i można go zmienić.
źródło
To prawda.
I jest twój problem.
W przypadku większości nietrywialnych problemów będziesz musiał się zastanowić, aby dowiedzieć się, jak wszystko będzie działać - jak wszystko będzie do siebie pasować. Paradoksalnie, w przypadku większości nietrywialnych problemów nie ma możliwości zaplanowania wszystkiego . Jest po prostu zbyt wiele rzeczy nieznanych do wyjaśnienia, zbyt wiele zmian, które nastąpią podczas programowania. Zwinny zyskał lepszą przyczepność, ponieważ akceptuje drugą połowę umowy: ludzie nie są wszechwiedzący, a zmiany są stałe.
Więc to prawda, że trzeba zrobić projekt z wyprzedzeniem, ale prawdą jest również, że to niemożliwe, aby tylko zaprojektować wyprzedzeniem.
źródło
Przed kodowaniem absolutnie musisz mieć jakiś projekt .
Powód jest dość prosty - jeśli nie masz żadnego projektu, nie wiesz, co tworzysz .
Absolutnie musisz mieć trochę kodu, zanim projekt będzie ostateczny.
Powód jest dość prosty - projekt się zmieni, a rozwijanie jego części ujawni pytania, możliwości i wyzwania, których trudno przewidzieć bez rozpoczęcia pracy nad rozwiązaniem.
Rozwój jest iteracyjny.
Niezależnie od tego, czy planowo, czy nie, czy zespół zdaje sobie z tego sprawę, czy nie, każdy projekt oprogramowania jest wykonywany iteracyjnie - część pracy jest zakończona, a następnie oceniona, a ocena prowadzi do zmian w sposobie wykonania pozostałej części pracy.
Wypróbuj więcej niż jedno podejście.
Potrzeba praktyki i doświadczenia, aby wiedzieć, jak najlepiej zrównoważyć projekt z tworzeniem kodu. Jest to umiejętność, której prawie nikt nie opanował, a każdy projekt będzie miał inne ideały (rozważ zaprojektowanie małego narzędzia do własnego użytku w porównaniu z zespołem tworzącym duży, pojedynczy produkt, taki jak duża gra wideo).
źródło
W przeszłości projektowałem i obserwowałem, jak inni projektują wiele systemów i widziałem, jak proces ten przebiega na wiele różnych sposobów, ale wspólne dla mnie jest to, że początkowa architektura powinna przynajmniej planować istnienie większości głównych funkcji.
Na przykład widziałem system sterowania HVAC, który nie miał koncepcji modernizacji budynków, podłóg, pokoi itp., A wynik był tak brzydki, jak tylko się da. Lub mobilne urządzenie muzyczne zbudowane z komponentów lepiej dopasowanych do (nie inteligentnego) zegarka kieszonkowego. Nie trzeba dodawać, że produkty końcowe w obu przypadkach nie były ulubieńcami klientów.
Kiedy mówisz „koncepcja”, jest to tylko jeden krok od „pomysłu”, a koncepcja może być bardzo rozmyta. Biznes zwykle dba o koncepcje. Klienci zwykle dbają o UX - koncepcję wprowadzoną w życie w sposób łatwy i przyjemny w użyciu oraz wnoszący pewną wartość poprzez jego użycie.
Musisz wykonać „koncepcję” przed jakimkolwiek programowaniem, nie wyobrażam sobie otwarcia studia wizualnego (lub twojego IDE z wyboru) i losowego pisania kodu, aby zobaczyć, dokąd zmierza.
Nie możesz wykonać pełnego projektu (i nie powinieneś) przed kodowaniem, ale powinieneś mieć przybliżony szkic tego, jaki byłby przepływ pracy użytkownika.
Projektowanie i kodowanie UX dość często się nawzajem nawzajem zużywa, prawdopodobnie będziesz zmuszony zastosować pewne zwinne podejście do niczego poza najmniejszymi projektami jako sposób na uwzględnienie tego faktu w podejściu do pracy. Więc nie myśl, że jesteś najgorszym z programistów, jeśli nie widziałeś tego wszystkiego naraz - nikt nie może, a ludzie, którzy myślą, że potrafią, to ci, którzy po prostu ignorują wystarczająco dużo problemu, aby mogli twierdzić, że mają kompletność obrazek.
Jeden przykład, aby nadać rozmiar coś dużego. Koncepcja: „Utwórz wizualne narzędzie oparte na chmurze, które umożliwia firmom integrację platform oprogramowania”. Brzmi świetnie i można zacząć pisać materiały marketingowe i sprzedawać je, zanim jeszcze tam będą. Musisz to mieć przed kodowaniem.
Wstępne projektowanie: „Mają kształty i strzałki, takie jak w Visio, aby opisać logikę; mają możliwości wtyczek, aby umożliwić połączenia z różnymi platformami (SAP, SF, bazy danych ...); mają konsolę monitorującą, w której można wyszukiwać dane przechodzące przez system; mieć sposób wizualnego opisywania danych i przekształcania jednego formatu na inny ". Kolejny świetny marketingowy blob. Daje również kilka pomysłów na to, co ważne, powinien mieć tak szorstki szkic przed kodowaniem.
Projekt / Kod: „Poproś projektanta HTML hostowanego w przeglądarce z takimi i takimi funkcjami; zakoduj backend w Javie, aby można go było uruchomić na dowolnym istniejącym serwerze; zdefiniuj struktury danych i UX do zapytań lub modyfikacji w razie potrzeby; zaplanuj odzyskiwanie po awarii, błąd raportowanie, rejestrowanie audytu; kontrola wersji planu; kontrola dostępu do planu; .... ”- im dokładniejsza lista, tym bardziej nierealistyczne jest przewidywanie wszystkich.
... jednak należy być świadomym co może wyglądać mniej więcej w przybliżeniu, lub twój produkt końcowy może mieć naprawdę bezużyteczne implementacje, które ostatecznie zabijają świetnie brzmiącą koncepcję - powiedz, że twój projektant wizualny wymaga 40 " ekran, aby pokazać przepływ pracy w świecie rzeczywistym, lub nie można przeszukiwać dzienników poza dokładnym dopasowaniem ciągu ograniczonym do jednego z 20 pól w dzienniku itp. itp. Nie ma dobrego sposobu, aby temu zapobiec poza wykonaniem implementacji - niektórym się uda, innym się nie uda.
źródło
Zawsze przeznaczam czas w następujący sposób:
Design: nie tylko wizualny, ale także koncepcyjny. Podziel go na części, zarówno wizualnie, jak i według logiki. Poszukaj cech wspólnych, które są ponownie wykorzystywane i same w sobie stanowią wzór.
Rozwój: gdy poznasz swoje części, koduj je. Następnie je integrujesz.
Testowanie: Nie tylko testowanie, czy kod został poprawnie zintegrowany i napisany, niezmiennie będą dostrzeżone spostrzeżenia i wyciągnięte wnioski, a także stworzą nowe sposoby interakcji, zostaną opracowane i pożądane nowe możliwości. Uważaj na pełzanie zakresu.
Oprócz tych aspektów należy pamiętać, że projekt ma również 3 fazy oprócz tych faz.
Przekonałem się, że im lepiej wykonasz fazę projektowania, tym bardziej zminimalizujesz dodatkowe próby. Zamiast przerabiać całość, możesz mieć tylko podsystem, który zostanie przerobiony.
Jestem programistą i kierownikiem ds. Rozwoju oprogramowania w projektach wewnętrznych, outsourcingowych i off-shore.
źródło
Jest tu fundamentalne błędne założenie. Nigdy nie będziesz w stanie wymyślić dobrego projektu bez uprzedniego napisania kodu (szkoła nigdy cię tego nie nauczy). Jednak szkoła ma rację, że nie dostaniesz dobrego kodu bez projektu.
Rozwiązaniem jest:
Wyrzucanie cały kod jest nie opcjonalny krok w tym procesie, ale dla małych projektów formalnie pisanie projekt może być. W przypadku dużych projektów bardziej prawdopodobne jest powtórzenie kroku „ wyrzuć cały kod ” - chociaż jeśli masz wystarczającą modułowość, może to dotyczyć tylko części bazy kodu.
Zbyt wiele projektów trzyma się starszego kodu, ponieważ nie chce go zmienić - lub ponieważ jest zbyt skomplikowany, ponieważ nigdy nie został zaprojektowany do wyrzucenia. Uznanie faktu, że Twoja pierwsza próba zakończy się niepowodzeniem, znacznie poprawi Twoje życie.
źródło
koncepcja jest kluczowa konstrukcja zawsze można zmienić programowanie będzie musiało spełniać wymagania w pełni pomyślanej aplikacji.
1. o co chodzi, 2. jak trzeba uzyskać do niego dostęp, 3. kim jest użytkownik, 4. określa pełny zakres prac w zakresie SOW, określając konkretnymi warunkami wszystko, co ma zrobić ta aplikacja. i jak będzie działać każda dodana funkcja.
przed dokonaniem jakichkolwiek wyborów dotyczących architektury aplikacji sieci web należy ją dokładnie zaplanować i przemyśleć.
następnie wybierz najlepszy stos
Jestem programistą LAMP
więc staram się zawęzić pytanie do tego, jakiego frp php użyję. i skrypty frontonu będę musiał sprawić, że zrobi wszystko, czego potrzebuję, aby robić to w idealny sposób
aby to dodać, naucz się używać frameworków MVC, ZEND i CAKEPHP to najlepsze frameworki szybkiego programowania (PHP)
źródło