Różnice między programowaniem w szkole a programowaniem w przemyśle? [Zamknięte]

50

Wielu studentów, którzy ukończyli studia i dostali pierwszą pracę, ma wrażenie, że tak naprawdę nie wiedzą, jak programować, nawet jeśli byli dobrymi programistami na studiach.

Jakie są różnice między programowaniem w środowisku akademickim a programowaniem w „prawdziwym świecie”?

rdasxy
źródło
Przykład: techcrunch.com/2011/11/12/…
rdasxy,
4
Powiedziałbym, że w środowisku akademickim uczysz się dogłębnie: uczysz się pojęć, zadajesz sobie pytania, poprawiasz myślenie abstrakcyjne. W przemyśle uczysz się szeroko: uczysz się korzystać z wielu różnych technologii bez zadawania zbyt wielu pytań, musisz załatwić sprawę. Dzięki doświadczeniu w branży uczysz się także zarządzania dużymi, złożonymi projektami: jest to bardzo praktyczna kwestia, której nie możesz nauczyć się na uniwersytecie z powodu braku czasu.
Giorgio
9
Czy to pytanie dotyczy naukowców na poziomie doktora, czy po ukończeniu studiów, czy może po prostu ogólne ustawienie „klasa w świecie rzeczywistym”?
Bob
@Kok. Chodziło bardziej o środowisko akademickie. Klasa / badania / ukierunkowane odczyty / zadania a programowanie w „świecie rzeczywistym” w przemyśle.
rdasxy
Dobrze. To nie było bardzo jasne, ponieważ istnieje coś takiego jak „programowanie akademickie”, które jest wykonywane przez ludzi, którzy chcą powiedzieć, pomagają biologom wymyślić symulacje komórkowe.
Bob

Odpowiedzi:

72

W tradycyjnym programem informatyki licencjackich uczysz tylko programowanie. Ale prawdziwy świat nie chce ludzi, którzy są tylko programistami. Prawdziwy świat chce prawdziwych inżynierów oprogramowania. Wiem, że wiele opisów stanowisk nie wydaje się wyrażać tego rozróżnienia, co tylko myli sprawę. W prawdziwym świecie musisz umieć:

  • Zbieraj i analizuj wymagania, gdy nie są ci one bezpośrednio przekazywane
  • Projektuj i analizuj architekturę z niemal nieograniczonymi możliwościami
  • Twórz plany testów i działaj na ich podstawie, aby oceniać i poprawiać jakość systemu
  • Pracuj wspólnie nad zespołem ludzi o różnym pochodzeniu i poziomie doświadczenia
  • Oszacuj i zaplanuj pracę, nawet jeśli nie wiesz dokładnie, co zbudować
  • Skutecznie komunikuj się z interesariuszami, którzy mają różne potrzeby, które niekoniecznie się pokrywają
  • Negocjuj harmonogram, budżet, jakość i funkcje, nie rozczarowując interesariuszy

O tak, i ty też musisz umieć pisać kod, choć zajmuje to średnio tylko 40–60% czasu inżyniera oprogramowania.

Tak więc nie jest tak, że świeżo upieczeni informatycy nie wiedzą, jak programować (wielu jest w rzeczywistości bardzo dobrymi programistami). Wielu z nich nie wie, jak zrobić cokolwiek innego.

Michael
źródło
18
Oh yeah, and you also have to be able to write code too, but that's, on average, only 40 - 60% of a software engineer's time.- Lub nawet 0-20% w naprawdę złych i naprawdę dużych sklepach korporacyjnych.
Ritch Melton,
1
+1 za bardzo dobrą odpowiedź i +1 (powinno być więcej) dla Ritcha. Jeśli inżynier as / w wydaje ponad 20% cyklu życia projektu na kodowanie, to coś jest bardzo, bardzo źle. 50% projekt, 30% test,% 20 dla reszty .... wszystko inne, łącznie z kodowaniem, wydaje się odpowiednie. Przy odpowiednim projekcie kodowanie powinno być trywialne. Bez tego to, co ludzie nazywają „kodowaniem”, jest w rzeczywistości niekończącym się przepisywaniem, próbą zhakowania jakiegoś projektu w miarę
postępów
36

Na Uniwersytecie...

Twój nauczyciel daje ci:

  • Dobrze zdefiniowany, odizolowany problem, którego rozwiązanie może zostać dostarczone w krótkim i dobrze określonym przedziale czasowym (a następnie zostanie odrzucony)
  • Dobrze zdefiniowany zestaw narzędzi, do których zostałeś wprowadzony przed przypisaniem
  • Dobrze określona miara jakości rozwiązania, za pomocą której można łatwo określić, czy rozwiązanie jest wystarczająco dobre, czy nie

W prawdziwym świecie"...

  • Problem jest niewyraźny, złożony i osadzony w kontekście. Jest to zestaw sprzecznych wymagań, które zmieniają się w czasie, a twoje rozwiązanie musi być wystarczająco elastyczne i solidne, abyś mógł zareagować na te zmiany w akceptowalnym czasie.
  • Narzędzia muszą zostać wybrane przez ciebie. Może jest już coś użytecznego w 10-letniej bazie kodu twojego zespołu, może jest jakiś projekt open source, może komercyjna biblioteka, a może będziesz musiał napisać to sam.
  • Aby ustalić, czy bieżąca iteracja oprogramowania jest poprawą (ponieważ prawie nigdy nie skończysz z projektem oprogramowania), musisz przeprowadzić testy regresji i testy użyteczności, przy czym ten ostatni zwykle oznacza, że ​​rozmyte, złożone, sprzeczne , wymagania osadzone w kontekście ponownie się zmieniają.

Wniosek

Programowanie w szkole i programowanie w realnym świecie są z natury różne od momentu, w którym w rzeczywistości nakładają się one na siebie w niewielkim stopniu. CS przygotuje cię do tworzenia oprogramowania w „prawdziwym świecie”, tak jak trening lekkoatletyczny przygotowałby armię do bitwy.

back2dos
źródło
11
Na to właśnie chciałem odpowiedzieć. W szkole znasz problem i znasz rozwiązanie. W „prawdziwym świecie” rzadko znasz rozwiązanie, a często nawet nie znasz prawdziwego problemu.
Bob
20

Stoją przed innym aspektem problemu:

Środowisko akademickie koncentruje się głównie na „nauce programowania”, badając w ten sposób sposób na sprawne działanie konkretnego algorytmu lub opracowanie języków dostosowanych do zwiększenia ekspresji niektórych paradygmatów. Przemysł koncentruje się głównie na produkcji rzeczy, które trzeba sprzedać. Musi polegać na „narzędziach”, które są nie tylko językami i algorytmami, ale także bibliotekami, frameworkami itp.

Ta różnica w „skupieniu” sprawia, że ​​mistrz akademicki w C praktycznie nie jest w stanie napisać aplikacji Windows (ponieważ my Windows API nie jest w standardzie C99!), A zatem czuje się, jakby „nie był w stanie zaprogramować”. Ale w rzeczywistości ma wszystkie możliwości, aby dowiedzieć się, czego brakuje. Coś, co - bez odpowiednich badań akademickich (niekoniecznie wykonane w środowisku akademickim) - jest dość trudne do znalezienia.

Emilio Garavaglia
źródło
10

Dobre odpowiedzi Pozwolę sobie tylko dodać, że programowanie akademickie jest na ogół niemal zabawkowe. To jest dobre do nauczania. Jako nauczyciel starasz się jak najlepiej przekazywać pomysły. Minusem jest realistyczne programowanie, które jest tak jakościowo różne, że trudno jest wypełnić lukę.

Jednym z obszarów różnic jest analiza wyników. Napisałem wiele postów, próbując to podkreślić. Analiza wydajności dotyczy tylko powierzchownie algorytmów i pomiarów. Aby zrobić to naprawdę skutecznie, musisz potraktować to jako proces debugowania.

Innym obszarem różnic jest łatwość konserwacji. Obejmuje to wszystko, od stylu po projektowanie języka specyficzne dla domeny. Nie możesz tego zrobić skutecznie, dopóki nie wiesz, co próbujesz zminimalizować.

Nie uczy się tych rzeczy i mają one ogromny wpływ na wydajność.

Mike Dunlavey
źródło
1
Zastanawiam się, jak można nauczyć tych rzeczy, ponieważ zdobycie ich wymaga dużo czasu i doświadczenia w terenie. Pomagałem kursowi inżynierii oprogramowania, w którym zespoły po 10 studentów musiały opracować mały program w ciągu kilku miesięcy (dwa semestry, od października do kwietnia). Pozwoliło im to poczuć się na temat programowania, planowania, ustalania priorytetów wymagań i zadań, komunikacji i tak dalej. Ale, oczywiście, jest to niewiele w porównaniu z tym, co napotkają w prawdziwym świecie. Ale nie możesz spędzić 4 lat nauki tylko na tym.
Giorgio
@Giorgio: Aby uzyskać wydajność, mam wcześniej istniejącą bazę kodu (niezbyt dużą), którą pokazuję, jak zoptymalizować serię iteracji, uzyskując duże współczynniki przyspieszenia. Nauczenie jest łatwą umiejętnością. W przypadku DSL i łatwości konserwacji mam też kilka ulubionych przykładów, które można wykorzystać do nauczania. Oba mogą z łatwością zmieścić się w kursie semestralnym, z miejscem do stracenia. Myślę więc, że można to zrobić.
Mike Dunlavey,
1
Ok, rozumiem: używaj dużych rzeczywistych przykładów i pozwól uczniom nad nimi popracować. Bardzo dobry pomysł.
Giorgio
@Giorgio: Byłem profesorem 30 lat temu, więc wciąż pamiętam, jak to zrobić. Umieściłem te pomysły w książce, która źle się sprzedała, co oznacza tylko, że miałem czas na przemyślenie i wyjaśnienie, jak to wszystko do siebie pasuje.
Mike Dunlavey,
Nie mam tak dużego doświadczenia, przez kilka lat byłem asystentem nauczyciela. Teraz pracuję w firmie. Jeśli chodzi o programowanie na uniwersytecie, IMHO prawda jest gdzieś pośrodku: Istnieje kilka bardzo przydatnych nauk na uniwersytecie, ale trudno jest omówić wszystkie ważne kwestie, z którymi inżynier oprogramowania będzie musiał zmierzyć się w swojej karierze. Przy odrobinie wysiłku możesz naprawdę uczyć pewnych rzeczy z prawdziwego świata, jak już zauważyłeś. Oczywiście nie wszyscy profesorowie uniwersyteccy są gotowi to zrobić.
Giorgio
8

W świecie akademickim większość ludzi studiuje informatykę lub powiązane kursy. Dijkstra zauważył kiedyś, że „w informatyce nie chodzi o komputery bardziej niż w astronomii o teleskopy”. Osoba studiująca informatykę przede wszystkim uczy się zostać naukowcem, a nie programistą. Jako programista pozostanie amatorem, a przejście do profesjonalnego programisty jest odpowiednio trudne.

Thiton
źródło
8

Aktualizacja: Jakby ktoś czytał w moich myślach: Oczekiwania absolwentów a rzeczywistość ...

Moje zdanie, dwa inne czynniki:

Rozmiar problemu : w środowisku akademickim musiałem głównie opracowywać oprogramowanie „od zera”, co oznaczało, że przez większość czasu największym programem, z jakim się spotkałem, był największy, który napisałem. To nie podkreśla niezbędnej zdolności do radzenia sobie ze złożonością wynikającą z różnych programów współpracujących ze sobą i radzenia sobie z nimi. Gdybym był świadomy wysiłku potrzebnego do zrozumienia ze złożonością, mógłbym w ogóle nie być w branży.

Czytanie VS Writing : Innym efektem ubocznym rozmiaru problemu jest to, że często w „prawdziwym świecie” jesteśmy narażeni na pracę napisaną przez innych, albo w celach konserwacyjnych (nigdzie nie miałem żadnej konserwacji w środowisku akademickim), rozszerzenia, lub po prostu Podział pracy. Dlatego czytanie kodu staje się wielokrotnie ważniejsze niż jego pisanie.

Propozycja ulepszonej edukacji programistycznej : środowisko akademickie powinno nas bardziej narażać na sytuacje w świecie rzeczywistym, bez konieczności cofania się do szkolenia zawodowego. Lekarze muszą w pewnym momencie zmierzyć się ze zwłokami, aby sprawdzić, czy „są do tego stworzeni” (słyszałem historie ludzi, którzy po tym doświadczeniu porzucili kurs). Gdybym miał około dwudziestu lat, widziałem projekt LOC o wielkości 20 000, składający się z różnych stylów programowania, które musiałem zrozumieć w ciągu jednego dnia i poprawić błąd w trzech, mógłbym rozważyć inne opcje kariery - choć prawdopodobnie nie.

Dimitrios Mistriotis
źródło
Aby poszerzyć waszą metaforę i moje własne doświadczenie w medycynie: lekarz uczy się ogólnych pojęć w szkole medycznej, ale wszyscy uczymy się szaleństw i skrótów w prawdziwym świecie w szkoleniach w miejscu pracy jako stażyści i rezydenci.
Hovercraft Full Of Eels
2
To! Za pierwszym razem, gdy zanurzysz się w bazie kodu 1 miliona LOC, zdajesz sobie sprawę, że to nie będzie coś w stylu wszystkiego, co zrobiłeś na uniwersytecie. Bardzo szybko staje się jasne, że nigdy nie zrozumiesz całości tej bazy kodu, a cokolwiek zrobisz, musi pochodzić z czytania i rozumienia kodu innych ludzi, a nie z projektowania i pisania własnego.
Roman Starkov,
4

Największa różnica, jaką znalazłem między programowaniem akademickim a programowaniem przemysłowym, dotyczy niezawodności. Większość ludzi doświadczyła w swojej karierze paradoksu „to działa dla mnie”, co jest przedłużeniem tego warunku. W środowisku akademickim nacisk kładziony jest na algorytmy i funkcje, a niewielką uwagę przywiązuje się do użyteczności i stabilności oprogramowania w codziennych warunkach.

Na przykład w moim biurze mamy inżyniera, który zajmie się oprogramowaniem i jest mistrzem w powodowaniu awarii w warunkach narożnych. Kliknie przycisk tak szybko, jak to możliwe, dopóki coś się nie zawiesi ... jeśli operacja trwa zbyt długo, po prostu zacznie losowo klikać wokół ekranu (z frustracji? IDK ....)

Zmiana naszych filozofii programowania, aby uczynić rzeczy „Steve proof”, ogólnie poprawiła stabilność naszej aplikacji.

Dave Nay
źródło
3

Nie mam osobistego doświadczenia w programowaniu w szkole - byłem studentem języka angielskiego. Zapytaj mnie o Keatsa i Byrona! - ale otrzymałem kilka nowych stopni, wychowałem je i pomogłem w świecie profesjonalnego tworzenia oprogramowania. Więc mogę mówić z tej perspektywy.

Z mojego doświadczenia wynika, że ​​tak naprawdę WSZYSTKO, co otrzymali ze szkoły, było zainteresowaniem programowaniem. Ich umiejętności wahały się od zera do nieistotnych. Ich zdolność do samokierowania nie istniała, nawet u najlepiej wykwalifikowanych. Ich myślenie było nie tylko na małą skalę; tak naprawdę myśleli w miniaturze. System składający się z kilkudziesięciu wierszy kodu spowodował, że całkowicie się rozpadły.

Ale wiesz co? Zyskali zainteresowanie , a to wielka sprawa. Zainteresowanie jest duże . Mogę pracować z kimś zainteresowanym. Mogę zamienić ich w programistę, pod warunkiem, że będą mnie zainteresowani. Do diabła, to wszystko od czego zacząłem. To uznanie dla postmodernistycznych amerykańskich powieściopisarzy.

Dan Ray
źródło
2

W środowisku akademickim

ZWROTY

  • Mamy terminy, które mają głównie na celu zdobycie punktów.
  • Błędy naprawdę nie przysparzają problemów, ponieważ większość projektów nigdy nie jest wykorzystywana w rzeczywistych aplikacjach.

PLUSY

  • Mamy wystarczająco dużo czasu na badania.
  • Kołysanie się od początkowych celów nie powoduje większych problemów.

W przemyśle,

  • Pracujemy nad projektami, które faktycznie będą wykorzystywane przez korporacje.
  • Pracujemy pod presją ciągle zmieniających się wymagań klientów.
  • Terminy rzadko są elastyczne, ponieważ może to prowadzić do ogromnych strat finansowych zarówno dla firmy z branży oprogramowania, jak i dla klientów.

Spójrz na to:

http://www.dodgycoder.net/2011/10/how-to-become-better-programmer.html

SHOUBHIK BOSE
źródło
Będę musiał się nie zgodzić co do części „faktycznie wykorzystanej”. Na początku lat 90. poszedłem 5 lat w 3 różnych firmach, dużych, małych i średnich i nic, co napisałem, nie trafiło do produkcji. Nie wydaje mi się, żeby to było takie niezwykłe doświadczenie.
Bruce Ediger
2

Programowanie akademickie polega raczej na samodzielnym kodowaniu. Jest to ważne, aby dowiedzieć się, jak to działa. Jakość kodu i kontrola poprawek niewiele się liczą. Z godnymi uwagi wyjątkami kod nie ma żywotności przekraczającej przypisanie. Zakres projektów bywa dość ograniczony i mało prawdopodobne, by się pełzały.

W prawdziwym świecie powinieneś mieć jak najmniej oryginalnego kodu. Zespoły opracowują dużo kodu. Lepiej jest używać procedur bibliotecznych niż samemu kodować. Jakość kodu i kontrola wersji stają się coraz ważniejsze. Żywotność kodu jest znacznie dłuższa niż początkowo oczekiwano. Zakres projektu jest zwykle dość szeroki i ma tendencję do znacznego pełzania, jeśli nie jest zarządzany.

BillThor
źródło
1

Tak właściwie,

niemożliwe jest pełne rozróżnienie programowania na poziomie akademickim od programowania w świecie rzeczywistym.

Powiedziałbym, że największa różnica może być taka: w programowaniu w świecie rzeczywistym - musisz wiedzieć więcej niż programowanie i powinieneś być w stanie szybko się dostosować.

W zależności od sektora, w którym pracujesz, musisz być zgodny z jego przepisami.

Michael dotknął tylko czubka góry lodowej, podając zadania związane z programowaniem, które określiłbym jako łatwe (jeśli jesteś wart ciasta, które otrzymujesz).

Zasadniczo przed branżą stoi co najmniej kilka wyzwań:

  • Obowiązujące prawo (np. Poufność dla klientów medycznych)
  • Przedmiotowe know-how (np. System fakturowania-podatków, inwentaryzacja, zarządzanie zasobami, programy medyczne, standardy branżowe)
  • Wymagania klienta, których nie ma lub nie istnieją lub które różnią się od standardów branżowych / obowiązujących przepisów

Jeśli porównasz projekt badawczy na poziomie doktoranckim z projektem ze świata rzeczywistego, są szanse, że są bardzo podobne pod względem trudności, wiedzy na poziomie początkowym i tym podobne.

Jedyną prawdziwą różnicą jest to, że projekt z prawdziwego świata

  • ma klienta
  • ma budżety (czas, pieniądze, zasoby ludzkie)

To inna gra w piłkę, gdy ktoś inny ustanawia zasady :)

Schalk
źródło
0

Jeśli spojrzysz na przedmioty studiowane w informatyce na uczelniach, znajdziesz około połowy czasu zmarnowanego na matematykę, naukę, przedmioty do wyboru itp., A drugą połowę na przedmioty akademickie, takie jak: projektowanie kompilatorów, teoria algorytmów, architektura komputerowa, Optymalizacja, systemy operacyjne, elektronika cyfrowa i kilka innych kursów związanych z przemysłem, takich jak programowanie C i programowanie sieciowe.

Większość z wyżej wymienionych tematów jest miła, ale nie zapewni bezpośrednio silnego tła w zakresie potrzeb codziennej IT.

Weź pod uwagę wymagania Microsoft Web Programming (czyli obszary wymagane przez kogoś, aby być produktywnym członkiem zespołu w organizacji):

1- C # .NET lub VB.NET

2-ASP.NET

3- HTML i CSS

4- SQL Server (lub inna baza danych)

5- Programowanie i projektowanie aplikacji OO

6- skrypt Java

7- Framework MVC

8- Trochę ekspozycji na narzędzia kontroli źródła

9- Pewne narażenie na zautomatyzowane narzędzia testowe

Narzędzie do śledzenia 10 błędów

Koncepcje 11-e-commerce (opcjonalnie)

12-ORM

13-Niektóre umiejętności analizy biznesowej

14-Niektóre umiejętności komunikacyjne

15-Prawdopodobnie niektóre podstawy przetwarzania w chmurze

Jak widać, większość powyższych wymagań rzadko koncentruje się na (możesz uzyskać co najwyżej 1 kurs) na studiach.

Nie można w pełni obwiniać instytucji, ponieważ istnieje wiele takich stosów technologii i ciągle się zmieniają.

Większość powyższych informacji od Microsoft nie pomoże komuś, kto chce tworzyć aplikacje w Javie.

Prawdziwy problem polega na tym, że żaden z zestawów technologicznych, które są dziś potrzebne firmie, nie jest w pełni pokryty.

Powyższe obejmuje kwestię przydatności absolwentów do pracy w firmie, takiej jak programowanie w środowisku biznesowym. Ta odpowiedź nie obejmuje potrzeb laboratoriów badawczych itp. Również inne obszary wymagają więcej umiejętności niż powyższe, takie jak tworzenie gier, programowanie osadzone, tworzenie systemów czasu rzeczywistego itp.

Bez szans
źródło
12
Masz 15 pozycji na liście. Wydaje mi się, że mógłbym dodać kolejne 30. Akademia nie ma za zadanie uczyć cię tych wszystkich rzeczy, ale raczej nauczyć cię, jak znaleźć drogę przez te wszystkie rzeczy. A także posiadanie wiedzy, która nadal będzie użyteczna, gdy wszystkie obecne technologie staną się przestarzałe (za 10 lat?) Po to jest cała ta teoria, która jest dobra, a nie stratą czasu !
Giorgio
2
@Giorgio, dzięki za komentarz, twój punkt jest ważny. Wyraźnie stwierdziłem, że „nie można w pełni obwiniać instytucji”. Podczas gdy pierwotne pytanie nie dotyczy natury edukacji akademickiej, moim osobistym poglądem jest ogromna przepaść między tym, czego uczą naukowcy, a tym, czego oczekuje biznes. Rachunek za niwelowanie luki płacony był przez firmę w ramach drogich szkoleń w miejscu pracy. Biorąc pod uwagę wielką konkurencję i trudne czasy wszystkich gospodarek, zastanawiam się, kto zapłaci dziś cenę za zniwelowanie tej luki?
NoChance 13.11.11
@Emmad Kareem: Tak, istnieje duża luka, zgadzam się. Często profesorowie uniwersyteccy nie mają pojęcia, co dzieje się w „prawdziwym świecie”, ponieważ koncentrują się na badaniach abstrakcyjnych. Jednak te abstrakcyjne umiejętności myślenia pozwalają mi teraz uczyć się nowego języka w ciągu kilku tygodni (teraz nauka Scali). Rozumiem również, że być może dla ciebie kwestia pieniędzy jest silniejsza. Dorastałem we Włoszech i kiedy studiowałem opłaty uniwersyteckie, gdzie około 200 $ rocznie (plus sami musieliśmy kupić książki). Myślę, że to bardzo niewiele w porównaniu do tego, co płacisz w USA.
Giorgio
3
Podobnie, jeśli studiowałeś inżynierię i uczysz się, jak zbudować samochód, nikt nie nauczyłby cię, jak prowadzić określony samochód: jest to po prostu coś, czego oczekują od ciebie.
Giorgio
1
Zmarnowany? Jeśli masz stopnie, o których mówisz, powinieneś wiedzieć lepiej. Nawet jeśli nie siedzisz tam, programując zaawansowaną matematykę, lekcje zdobyte podczas studiowania bezpośrednio przekładają się na „widzenie” czystego, eleganckiego rozwiązania.
Przypon
0

Skala i fokus
Z moich doświadczeń wynika, że ​​w środowisku akademickim ogólnie skala aplikacji, nad którą pracujesz, jest znacznie mniejsza, co można ukończyć w ciągu dnia lub tygodnia, a może nawet w semestrze jednego lub dwóch programistów - -typowo wszystko, co napiszesz, będzie wyrzuconym kodem, który jest odrzucany po terminie. W prawdziwym świecie może się okazać, że pracujesz nad aplikacją, której opracowanie przez większy zespół zajmowało miesiące, jeśli nie lata. Spędzasz dużo więcej czasu i debugujesz kod innej osoby, próbując zrozumieć infrastrukturę bazy kodu, żonglując, nie niszcząc istniejących części, aby dodać nowe lub zmodyfikowane wymaganie.

Wymagania, integracja, klienci
Istnieją również aspekty związane z tworzeniem kodu, takie jak analiza wymagań, testy integracyjne itp., Które są zwykle mniej reprezentowane w projektach akademickich. W trosce o uczciwą ocenę, instruktor zwykle określa już wymagania, które nie są ustalane wspólnie podczas spotkań. Nie musisz „sprzedawać klientowi” według konkretnego podejścia, które nie jest dokładnie tym, czego chcieli, ale w przeciwieństwie do ich pragnień jest faktycznie wykonalne z technicznego punktu widzenia. W środowisku akademickim twój klient (równiarka lub instruktor) ma dość konkretny pomysł, czego chce, w prawdziwym świecie możesz spotkać klientów, którzy tak naprawdę nie wiedzą, czego chcą i muszą wybrać mózg, aby zrozumieć, co powinien być zbudowany.

Jessica Brown
źródło
0

Konserwacja i utrzymanie

W środowisku akademickim (przynajmniej na poziomie licencjackim) oprogramowanie jest budowane z myślą o krótkoterminowych celach, zwykle w celu wykonania zadań domowych lub projektu semestralnego. Po zakończeniu przypisania kod jest wyrzucany i nigdy więcej go nie widzi.

W środowisku profesjonalnym większość oprogramowania jest pisana z myślą o długotrwałym użytkowaniu; oprogramowanie jest przeznaczone do użytku przez co najmniej kilka lat i musi zostać zbudowane w celu łatwej konserwacji i aktualizacji w miarę upływu czasu.

Związane jest to z pracami konserwacyjnymi. Większość profesjonalnych prac programistycznych obejmuje aktualizację lub utrzymanie istniejącego oprogramowania. Tak zwane projekty typu „zielone pole” są raczej wyjątkiem niż normą.

Ken Liu
źródło