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”?
Odpowiedzi:
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ć:
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.
źródło
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.Na Uniwersytecie...
Twój nauczyciel daje ci:
W prawdziwym świecie"...
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.
źródło
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.
źródło
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ść.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
W środowisku akademickim
ZWROTY
PLUSY
W przemyśle,
Spójrz na to:
http://www.dodgycoder.net/2011/10/how-to-become-better-programmer.html
źródło
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.
źródło
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ń:
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
To inna gra w piłkę, gdy ktoś inny ustanawia zasady :)
źródło
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.
źródło
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.
źródło
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ą.
źródło