Jak mogę poprawić swoje umiejętności podczas pracy nad rzeczywistymi projektami, przy braku bardziej doświadczonych programistów? [Zamknięte]

Jestem głównym programistą w małej firmie, współpracuję z C # i ASP.Net. Nasz zespół jest mały, 2-3 osoby, bez dużego doświadczenia w projektowaniu i projektowaniu. Nie mam okazji uczyć się od starszych programistów, w moim zespole nie ma nikogo, kto by mnie poprowadził i pomógł mi wybrać najlepsze podejście, ponieważ sam zajmuję się większością projektów.

Jak mogę poprawić swoje umiejętności programowania podczas pracy nad rzeczywistymi projektami, przy braku bardziej doświadczonych programistów?

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.

Jestem w podobnej sytuacji: jesteśmy małym zespołem, a naszą podstawową pracą nad programowaniem są głównie przyrostowe zmiany w bazie kodu, która ma kilka lat.

Kilka technik, których używam, aby być na bieżąco i doskonalić swoje umiejętności.

W czasie pracy:

• Czytaj: książki, blogi, materiały PR. Śledzę wiele kanałów RSS. Gdy oferta dnia O'Reilly dotyczy technologii, o której nie słyszałem, przeczytałem opis książki. Jeśli technologia ma duży związek z czymkolwiek, nad czym pracuję, spędzam pięć lub dziesięć minut badając ją bardziej szczegółowo, podobnie jak odpowiedź MainMa. Powtarzam to z kilkoma różnymi kanałami RSS.
• Stwórz ze swoim zarządem plan szkoleniowy, który może być wsparty zasobami firmy (czas i / lub pieniądze)
• W przeciwieństwie do tendencji większości programistów, spróbuj zastosować zmiany i nowe opcje projektowania. Zmiana ze względu na zmianę nie jest dobra , ale uważam, że zbyt często programiści unikają używania nowego projektu lub struktury z powodu zmiany. Jest to dobra linia do chodzenia i nie spiesz się z podejmowaniem wiążących decyzji, ale miej oko na nowe sposoby robienia rzeczy. Niektóre zmiany mogą mieć nieoczekiwane korzyści: przejście na DVCS pozwala mi łatwiej eksperymentować z naszą bazą kodu i wypróbować tam nowe technologie.
• Niektórzy ludzie lubią konferencje; Przekonałem się, że zainwestowany czas jest niewielki.

Poza pracą:

Przekonałem się, że praca nad moimi umiejętnościami poza codzienną pracą ma kluczowe znaczenie. Wolność eksperymentowania, popełniania błędów i dążenia do zainteresowań utrzymuje mnie w branży IT. Gdybym miał tylko projekty w pracy i musiałem ograniczyć naukę do tego, co było natychmiast przydatne, szybko wypaliłbym się.

• Zaangażuj się w niepracujący projekt. Dla mnie jest to tworzenie funkcjonalnej strony internetowej związanej z osobistym zainteresowaniem. Dowolnie refaktoryzuję i aktywnie próbuję eksperymentować z różnymi technologiami. Wkład w Open Source zapewni Ci również kontakt z kodem innych osób. Zapewni to również dobry materiał do dzielenia się wywiadami z firmą, która będzie miała bardziej doświadczonych programistów.
• Code Camp: Jeśli w Twojej okolicy znajduje się kod Camp, weź udział. Ponieważ nie odbywają się one w godzinach pracy i są bezpłatne, masz swobodę uczestniczenia w dowolnych sesjach poświęconych interesującym Cię tematom. W porównaniu z typowymi konferencjami są to zwykle spotkania lokalne i obejmują szeroki zakres technologii, więc uważam, że wartość jest bardziej skoncentrowana.

I nie zapomnij często odwiedzać SO lub Programmers.SE.

Odpowiedzi tutaj zapewne będą bardzo pomocne, ale chciałbym coś podkreślić: nic nie zastąpi pracy z kimś lepszym od ciebie (dla arbitralnych i osobistych definicji lepszych) przez 8 godzin dziennie, 5 dni w tygodniu. To jest pewne.

Jeśli jesteś typem programisty, który zawsze chce być lepszy, zawsze chce się uczyć, to w końcu będziesz musiał udać się do innej firmy. Tyle jest nieuniknione i należy je zaplanować.

Gdy znajdziesz odpowiednią dla siebie firmę, przekonasz się, że możesz w niej nadal się rozwijać, niż z niej wyrastać.

Tworzenie oprogramowania to sport zespołowy. Podobnie jak sport, aby grać na bardzo wysokim poziomie, musisz być z innymi graczami i rywalizować z nimi. Szukaj okazji do poruszania się.

Pamiętaj, że praktyka staje się trwała, więc jeśli nie pracujesz nieustannie w kierunku lepszej techniki i wiedzy, jeśli pracujesz w izolacji bez krytyki lub wzoru do naśladowania, może się okazać, że twoje umiejętności nie rosną.

Na całym świecie sytuacja staje się coraz bardziej konkurencyjna, więc spodziewaj się, że Twoja nisza będzie tymczasowa i przygotuj się na okazję, która spełni twoje kryteria satysfakcjonującej pracy, a jednocześnie zabierze Cię poza strefę komfortu do pracy z lepszym zespołem.

Zanim przejdę do jakichkolwiek sugestii, muszę powiedzieć, że byłem w bardzo podobnej sytuacji nieco ponad rok temu.

Jeśli wykonujesz projekty, ale czujesz, że jest dużo miejsca do poprawy, to dobrze.

Pewnego razu nie miałem technicznej zdolności i pewności, aby ukończyć projekt. Często kupowałem książkę, czytałem dość techniczny blog i znajdowałem się „z głębi”. Myślę, że największym problemem dla mnie był fakt, że nie miałem kontaktu z żadnymi aplikacjami dla dużych przedsiębiorstw. Dość często robiłbym coś dobrze, ale nie miałbym przy sobie nikogo, kto mógłby potwierdzić to, co zrobiłem.

To było demotywujące i trudne, więc widzę, skąd pochodzisz. Jak rozwiązałem ten problem? Opuściłem firmę i dołączyłem do znanego domu programistycznego, który pomógł mi zdobyć duże doświadczenie w ubiegłym roku.

Jeśli nie chcesz odejść z firmy, sugerowałbym książki napisane przez pionierów naszej branży. Zaczynam od The Pragmatic Programmer Andrew Hunta. Książka zawiera mnóstwo przydatnych analogii, które są bardzo łatwe do zapamiętania. Kilka pierwszych rozdziałów tej książki zachęciło mnie do wybrania zupełnie innego języka programowania niż ten, którego używamy w pracy. Zacząłem czytać literaturę nietechniczną - teraz wierzę, że czytanie powieści i science fiction uczyni mnie lepszym programistą. Pisanie esejów nie jest daleko od pisania czystego kodu. Niektórzy pisarze są dobrzy, a inni źli. Ta książka zmusiła mnie do dbania o to, co piszę. Jedna z analogii nosi nazwę „Broken Windows”. Zostawiasz samochód porzucony na ulicy przez kilka dni i nic się z nim nie dzieje. Po rozbiciu jednego okna samochód prawdopodobnie zostanie zniszczony następnego dnia. Kod nie jest inny. Jeśli widzisz uszkodzony lub źle napisany kod, napraw go natychmiast, nie zostawiaj go tam, bo wcześniej czy później wróci, by cię „prześladować”. Gdy zaczniesz czytać tę książkę, dostrzeżesz dziesiątki podobnych analogii, które sprawią, że pomyślisz o kodzie w inny sposób.

Sugerowałbym następnie przejście do Clean Code autorstwa Roberta C. Martina. Ta książka jest bardziej praktyczna, ponieważ zmusza cię do czytania złego i dobrego (czystego) kodu. Autor wykorzystuje próbki kodu z jednego z projektów open source. Mówisz, że nie ma nikogo, kto by cię prowadził. Jest idealna okazja, aby przyjrzeć się kodowi innej osoby, porównać go z własnym kodem i zobaczyć, jak możesz go ulepszyć. Dla mnie czytanie tej książki było jak zacienianie kogoś, kto pracuje nad projektem. Książka kładzie również duży nacisk na najłatwiejszą i najtrudniejszą rzecz - rozdzielenie obaw. Autor zapytał pionierów naszej branży, co uważają za „czysty” kod. Po przeczytaniu ich odpowiedzi będziesz mógł porównać je z własną opinią na temat tego, na czym polega czysty kod.

Wreszcie, czy zastanawiałeś się nad pracą nad projektami typu open source? Będziesz współpracował z innymi, prawdopodobnie bardziej doświadczonymi programistami, którzy będą mogli przejrzeć Twój kod i skierować Cię w dobrym kierunku.

Jak powiedziałem w mojej pierwotnej odpowiedzi, nie wydarzy się to w nocy. Robię to od kilku lat i prawie codziennie dowiaduję się, że robię to źle.

Powodzenia!

Ćwicz rozwiązywanie problemów. Przeczytaj i pracuj, aby zrozumieć kod innych użytkowników (github jest do tego świetnym źródłem informacji) i prześlij poprawki do niego. Wykonywanie prac doradczych może naprawdę pomóc poszerzyć Twój zestaw umiejętności.