Oprócz wielu bardziej doświadczonych kolegów można znaleźć wiele źródeł: książki, blogi zręcznych programistów, Stack Exchange, wykłady / konferencje itp. Kluczowe znaczenie mają również recenzje kodu, a CodeReview.SE jest cennym zasobem.
Zobaczmy, jak to może działać na przykładzie.
Przykład
Czytasz post na blogu, który wymienia termin „ETL”. Nie znasz jego znaczenia, ale z tego artykułu niejasno rozumiesz, że jest to rodzaj procesu lub przepływu pracy, który przenosi dane z obsługi niektórych danych na inne.
Idziesz do Wikipedii i innych zasobów i zyskujesz bardziej precyzyjną wizję tego. Nadal nie jest jasne, kiedy użyteczne byłoby użycie ETL. W końcu wydaje się o wiele łatwiej napisać zapytanie SQL, które wykona całą pracę, zamiast spędzać zbyt dużo czasu na budowaniu prawdziwego ETL.
Aby odpowiedzieć na te pytania, pożyczasz książkę o ETL z lokalnej biblioteki. Wyjaśnia, że niektóre procesy wyodrębniania-transformacji-obciążenia nie są łatwe do wykonania za pomocą prostego zapytania SQL: nie tylko faza wyodrębniania może poradzić sobie z kilkoma różnorodnymi nośnikami danych, nie tylko relacyjną bazą danych, ale także etap transformacji może być bardzo skomplikowany dla zarówno sprawdzanie poprawności / normalizacji danych i mapowanie.
Masz teraz jasną wizję tego, czym jest ETL, jak go używać, a zwłaszcza, gdy potrzebujesz ETL i kiedy nie jest to odpowiednie narzędzie. W międzyczasie zaimplementowałeś mały ETL jako osobisty projekt. Ten projekt pozwala odkryć pewne punkty, które nie są dla ciebie wystarczająco jasne i nie są objęte książką. Te punkty są raczej abstrakcyjne i niezwiązane z kodem źródłowym, więc zadajesz pytanie na Programmers.SE .
Kiedy masz możliwość zbudowania jednego w swojej firmie, zaczynasz go tworzyć. Masz kilka problemów. Niektóre są związane z kodem; publikujesz pytania na temat Przepełnienia stosu . Inne są powiązane z bazą danych; zadać pytania na temat DBA.SE .
Na koniec odbywa się konferencja wysoce wykwalifikowanego programisty na temat optymalizacji ETL. Uczestniczysz w tej konferencji, która daje cenne wskazówki na temat ulepszeń, które możesz zrobić dla swojego projektu.
Zaczynasz również obserwować blog programisty, który od lat pracował nad różnymi ETL. Ciekawie jest zobaczyć różne podejścia, a za pośrednictwem tego bloga poznajesz ECCD; jesteś zainteresowany, więc pożyczysz zestaw narzędzi ETL Data Warehouse autorstwa Ralpha Kimball, książki szczegółowo omawiającej proces „wyodrębniania, czyszczenia, dostosowywania i dostarczania”. Ten sam blog wspomina również o wielu aplikacjach służących do tworzenia ETL-ów bez umiejętności programowania. Jest to szczególnie przydatne w przypadku ETL, które zrobiłeś dla swojej firmy, ponieważ twój szef, osoba bez wiedzy technicznej, stale prosi cię o wprowadzenie drobnych zmian w tym, co zrobiłeś.
Odkrywanie rzeczy
IMHO, trudną częścią, kiedy nie masz mentora lub bardziej doświadczonego kolegi, jest odkrywanie rzeczy, a przez odkrycie mam na myśli przejście od stanu „Nigdy o tym nie słyszałem” do „Mam słyszałem o tym, ale nie bardzo wiem, co to jest ".
Jeśli ktoś przejrzy mój kod i powie, że naprawdę powinienem zacząć stosować pewne konwencje stylów, z niewielką ciekawością stwierdzę, że w programowaniu istnieją różne style pisania kodu, że należy trzymać się stylu dla danego języka i bazy kodu, i że wiele języków ma narzędzia do egzekwowania stylu (jak StyleCop dla C #).
Gdyby nikt nie powiedział mi o stylu, skąd miałbym wiedzieć, że coś takiego istnieje?
W tym miejscu przydatne są zasoby takie jak blogi lub Stack Exchange. Wikipedia nie pomogłaby (chyba że spędzasz dni przeglądając przypadkowe strony o programowaniu), a książki rzadko mówią o tych sprawach.
To samo dotyczy wzorców i praktyk lub rzeczy, które są mniej związane z kodem. Na przykład, prawie nie wyobrażam sobie, żeby jakiś programista budził się rano, mówiąc sobie, że musi się czegoś nauczyć o ITIL, podczas gdy nigdy wcześniej nie lubił ITIL.
Gdy odkryjesz nowy termin, bardzo łatwo go poznać. Jeśli podałeś nowy termin „umowy kodowe” i jesteś programistą C #, możesz łatwo znaleźć wystarczającą ilość informacji na MSDN (lub, lepiej, w książce Jona Skeeta).
Ciekawość pomaga
Kiedy pracuję ze stażystami, zawsze zauważam, że najlepsi są ci, którzy byli ciekawi poza swoimi wykładami. Mogą wiedzieć, że istnieje coś, co nazywa się programowaniem funkcjonalnym, nawet jeśli żaden z ich nauczycieli nigdy o nim nie wspominał, i chociaż nie znają żadnego języka funkcjonalnego, wciąż są w stanie wyjaśnić ogólnie, czym jest FP i czym różni się od innych paradygmaty. Mogą wiedzieć o Agile, Unicode lub modelu częściowego zaufania / piaskownicy, tylko dlatego, że czytali blogi i korzystali z Stack Exchange, a nie tylko uczestniczyli w swoich wykładach.
Nawet jeśli nie mają mentora, wciąż uczą się tych wszystkich rzeczy, o których nie mówi się na studiach.