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

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”?

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.

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.

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.

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ść.

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.

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.

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.

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.

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

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.

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 :)

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.

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.

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ą.