Temat: Praca w .net
Przy czym po jakimś czasie, przy którejś praktyce z kolei okaże się, że... no właśnie....
W firmie (zakładam, że praktyki będą w formie udziału w rzeczywistym projekcie) A będzie kładziony duży nacisk na jakość kodu, który musi działać bezawaryjnie. TDD, rozbudowany dział jakości, ciągłe audyty funkcjonalności. W firmie B powiedziane będzie od razu: nie mamy czasu na zabawy w TDD, wszystkim zajmie się dział jakości, a testować będą także klienci (i będzie to uzasadnione ekonomicznie).
W firmie C dowiesz się, że kod będzie pisany na kolejne 20 lat i ma być w związku z tym dobrze zaprojektowany obiektowo, w celu dalszego rozszerzania funkcjonalności i "wymiany komponentów na nowsze" (więc np. MVC), a także wybrane zostaną pojemne i wydajne bazy danych. W firmie D powiedzą wprost: piszemy kod na 5 lat. Zakładamy, że po 5 latach zestarzeje się moralnie i będzie my pisać kompletnie od nowa, może w zupełnie innej technologii. W związku z czym wybieramy bezpłatne, ograniczone wersje bazy danych (np. SQL Express), bo i tak się nie zdążą zapełnić, a wydajnościowo nam pasują w 100%. A kod ma po prostu działać, nie musi być rozszerzalny, w skrajnym przypadku można nawet wszystko powrzucać do formatek (zaprzeczenie MVC), bo nie przewidujemy zmian.
W firmie E dowiesz się, że aplikacja ma być modularna. Co większe formatki do osobnych modułów, zarządzanych jakimś "app managerem".
Za to w firmie F dowiesz się, że to bzdurne podejście, aplikacja ma być monolitycznym blokiem (...bo jakieś tam, głębsze, uzasadnienie, wynikające z zagadnienia i potrzeb).
Być może w kolejnych firmach trafisz na zbliżone podejścia projektowe i nauczysz się określonych technik projektowania i kodowania. I być może będziesz ich za jakiś czas bronił jak lew w dyskusjach (a czasem flamewarach) o "dobrych praktykach" :)
A być może będziesz odkrywał coraz to inne podejścia, także takie, z którymi dzisiaj absolutnie, ale to absolutnie się nie zgadzasz, ale musisz się w nie wpasować - bo tak pracuje firma (i nawet bez uzasadnienia, po prostu "bo ja tak chcę, panie Michale").
I tak naprawdę to drugie podejście będzie może przydatniejsze - nauczy różnie dobierać narzędzia do różnych celów.
Miałem w pracy kolegę, który pracował wcześniej 4 lata przy wielkim przedsięwzięciu. Ale jednym. Jego doświadczenia w kolejnym projekcie stały się tak oderwane od rzeczywistości, że co chwila wybuchał świętym (!) oburzeniem ("jak tak można?! To jest sprzeczne z podejściem XYZ"), albo kończyło się na "nie zgadzam się z tym, nie będę tak robił". Najpierw robił "z musu", potem mu się podobało.
Tak więc - masz rację, książki wskażą Ci tylko, czym dysponujesz. A także przedstawią tzw. "dobre praktyki", jakie powinno się stosować. Czasem będą one zupełnie sprzeczne z Twoim dotychczasowym doświadczeniem. Ale gdy wejdziesz w rzeczywiste projekty, okaże się, że czasem będą one stanowić przerost formy nad treścią. A czasem "brudne" rozwiązania będą zupełnie OK w danym zagadnieniu.
A z praktycznych rad... kiedyś, jeszcze na uczelni (mieliśmy kółko .NETa) usłyszałem od zaproszonego prelegenta, że doświadczenie niekoniecznie trzeba zbierać w firmach. Na początek, kiedy jeszcze raczkujemy, można sobie obrać jakieś zagadnienie do zaprogramowania, byle użyteczne, a nie "byle co" (to ważne).
Na przykład CMS'a WWW (to nic, że są ich setki, ważne, że chcesz osiągnąć konkretną funkcjonalność), system zarządzania i ewidencji magazynowej, system data miningowy, bazę wiedzy na jakiś temat (mapy pamięci, skojarzenia, sieci semantyczne), systemu agregujące i obrabiające wstępnie informacje z sieci (np. o pogodzie, imprezach i dostępności miejsc w hotelach), systemy naukowe (np. symulatory procesów).
Potem, gdy już zaprogramujesz taką rzecz, możesz się nią pochwalić np. na rozmowie kwalifikacyjnej. Przykładowo w CV, w sekcji poświęconej znanym platformom i językom projektowania, wstawiasz link do Twojego CMS'a (a do koszulki z CV i LM dodajesz "wizytówkę CD" z projektem i prezentacją), by rekrutujący mogli sobie pooglądać namacalny dowód Twoich umiejętności.
Nauczysz się korzystać z WIELU narzędzi (tak to jest - rzeczywiste zagadnienia wymagają często łączenia narzędzi, np. C++/C#/Flash, C#/Java/Macromedia Authorware, C#/WinAPI/Assembler/Analysis Services), będziesz miał czas na testowanie kolejnych "dobrych praktyk" bez poganiania i terminów. Przygotujesz sobie "warsztat pracy", tzn. gotowe kawałki kodu, które będziesz potem wykorzystywać wielokrotnie w różnych projektach w różnych firmach ("aha, ja już to kiedyś robiłem").
I szukaj, dużo szukaj po codeplex, codeproject, c-sharpcorner, stackoverflow, etc. To będzie za chwilę Twój potężny arsenał pomysłów i konkretnych rozwiązań, które tylko "przykroisz" do potrzeb.
Jeśli podejdziesz do problemu poważnie i zacięciem ("eee, dzisiaj mi się nie chce"), to poniesiesz niewielką stratę (np. pół roku na projekt, za to zrobiony "z sercem"), którym potem pochwalisz się w firmie, do której uderzysz na praktyki. Jeśli Ci w domu "dziecko nie płacze" i nie musisz jutro zarabiać w kpln, a masz za co jeść i gdzie mieszkać, to poświęć trochę czasu właśnie na samodzielną naukę.