Czy powinienem kontynuować samodzielną praktykę kodowania lub nauczyć się profesjonalnego kodowania? [Zamknięte]

Ostatnio pracuję zawodowo, spotykam się z innymi programistami i nawiązuję znajomości w branży. Jedyną rzeczą jest to, że jestem w 100% samoukiem. Spowodowało to, że mój styl bardzo odbiega od stylu tych, którzy są odpowiednio wyszkoleni. Różne są techniki i organizacja mojego kodu.

To mieszanka kilku rzeczy, które robię. Zwykle łączę ze sobą kilka paradygmatów programowania. Jak Functional i OO. Opieram się bardziej na stronie funkcjonalnej niż na OO, ale widzę użycie OO, gdy coś byłoby bardziej sensowne jako abstrakcyjny byt. Jak obiekt do gry. Następnie, gdy coś robię, idę prostą drogą. W przeciwieństwie do tego wydaje się, że czasami kod, który widzę od profesjonalnych programistów, jest skomplikowany ze względu na to! Używam wielu zamknięć. I wreszcie, nie jestem najlepszym komentatorem. Łatwiej jest mi czytać mój kod niż czytać komentarz. I w większości przypadków po prostu czytam kod, nawet jeśli są komentarze. Dodatkowo powiedziano mi, że z uwagi na to, jak po prostu piszę mój kod, bardzo łatwo go odczytać.

Słyszę, jak profesjonalnie wyszkoleni programiści powtarzają takie rzeczy, jak testy jednostkowe. Coś, czego nigdy wcześniej nie używałem, więc nawet nie mam zielonego pojęcia, czym one są i jak działają. Wiele podkreślników „_”, które tak naprawdę nie są w moim guście. Większość technik, których używam, pochodzi bezpośrednio ode mnie lub kilku książek, które przeczytałem. Nic nie wiem o MVC, słyszałem o tym wiele z takimi rzeczami jak backbone.js. Myślę, że to sposób na zorganizowanie aplikacji. Po prostu mnie to jednak myli, ponieważ do tej pory stworzyłem własne struktury organizacyjne.

To trochę boli. W ogóle nie mogę korzystać z aplikacji szablonowych, gdy uczę się czegoś nowego, takiego jak Ubuntu's Quickly. Mam problem ze zrozumieniem kodu, który widzę od kogoś przeszkolonego. Kompletne programowanie OO naprawdę pozostawia nieprzyjemny smak w moich ustach, ale wydaje się, że właśnie tego KAŻDY inny używa.

Nie pozostawiło mnie to tak pewnie w wyglądzie mojego kodu, ani zastanawiania się, czy nie spowoduję iskrzenia przy dołączaniu do firmy, czy może przyczyniam się do projektów open source. W rzeczywistości raczej boję się tego, że ludzie ostatecznie sprawdzą mój kod. Czy to coś normalnego, przez co przechodzi każdy programista, czy powinienem naprawdę zmienić swoje techniki?

W rzeczywistości raczej boję się tego, że ludzie ostatecznie sprawdzą mój kod.

Dobry. Świadomość, że ludzie będą patrzeć na twój kod sprawi, że będziesz się starał.

Programowanie stało się niezwykle dużą dziedziną. Istnieją dziesiątki tematów, narzędzi, nisz i specjalizacji, z których niektóre stanowią dla siebie całe kariery. Jest wiele rzeczy do nauczenia się i poznania, a kiedy pracujesz z innymi programistami, zawsze będą rzeczy, o których wiesz, że nie, i rzeczy, o których wiedzą, że nie. To coś dobrego.

Jeśli obawiasz się, że twoje doświadczenie jest niepełne, możesz podjąć wiele kroków, aby to poprawić poprzez formalną edukację i współpracę z wyszkolonymi ekspertami. Ale wygląda na to, że obawiasz się, że istnieje jakiś wymierny kamień milowy, po którym ludzie mówią: „Dobra, teraz, kiedy to opanowałem, jestem oficjalnie programistą”. Nie ma takiego kamienia milowego. Zdecydowanie miałem momenty, w których pomyślałem „tak, teraz się gdzieś dostaję” po tym, jak nauczyłem się czegoś nowego, ale nie ma magicznej listy rzeczy, które musisz wiedzieć i zrobić, aby nazwać się programistą.

Wiem wiele rzeczy o programowaniu, używałem kilkunastu języków w wielu projektach, a jednak część wiedzy programistycznej, którą mogę nazwać własną, jest niewielka. I lubię to. Szczerze mówiąc, programista nie jest czymś, czym jesteś. Programista jest czymś, czego stale się uczysz.

Dokonaj inwentaryzacji swoich umiejętności, silnych i słabych stron. Uzyskaj opinie od osób z większym doświadczeniem niż ty. Szukaj pozycji, które całkiem dobrze pasują do miejsca, w którym uważasz, że jesteś - ale nie bój się iść do prac, które są nieco poza twoim bieżącym opanowaniem. Jeśli podejmujesz tylko prace, o których już wiesz wszystko, nigdy nie nauczysz się w pracy.

Kiedy zaczniesz opracowywać aplikacje we współpracy z innymi programistami, niektóre z tych osobistych stylów będą przeszkadzać.

Jeśli zaczniesz pracować w sklepie, który używa podkreślników, będziesz używać podkreślników. Każdy, bez względu na swoje wcześniejsze doświadczenie, przestrzega standardu sklepowego w zakresie stylu kodowania.

O ile Twój styl kodowania nie jest wyjątkowo oczywisty, lepiej przyzwyczaj się do pisania jasnych, zwięzłych komentarzy wyjaśniających, jak działa Twój kod, aby inni programiści mogli go śledzić.

Jeśli nie wiesz nic o testach jednostkowych, kup dobrą książkę. Istnieje wiele dobrych książek na temat testów jednostkowych. To samo z MVC.

Profesjonalni twórcy oprogramowania wiedzą, jak dobrze grać z innymi, nie zaśmiecając piaskownicy. Najlepsi wiedzą, jak czytać i pisać kod, niezależnie od stylu.

Programowanie obejmuje komponent artystyczny i dyscyplinę. Elementem sztuki jest wymyślanie najlepszych podejść i ich wdrażanie; dyscyplina polega na upewnieniu się, że zrobiłeś to poprawnie, a inni mogą zrozumieć twój kod i ulepszyć go w razie potrzeby.

Element artystyczny jest zabawny: robisz to, bo ci się podoba. Oczywiście jest to część, której najpierw uczysz się.

Element dyscypliny jest bardziej uciążliwy: robisz to z konieczności. Jest to jednak niezbędny element pracy w zespole: przynajmniej do pewnego stopnia nie można od tego uciec. Kiedy kod zostanie zintegrowany z kodem twoich kolegów z drużyny, twoja elastyczność w „zmienianiu rzeczy do woli” wymaga nurkowania. Potrzebujesz jednak możliwości zmiany kodu w sposób pewny w odpowiedzi na zmieniające się wymagania lub rozwiązywania problemów. W tym miejscu pojawiają się różne „nudne” testy: przy wielu testach łatwo jest sprawdzić, czy ostatnia zmiana psuje, czy nie.

Znaczenie ma również styl kodu, ponieważ przestrzeganie wspólnego stylu sprawia, że ​​kod jest łatwiejszy do odczytania dla wszystkich. W większych firmach można znaleźć nocne zadania, które automatycznie sprawdzają zgodność ze standardami kodowania i wysyłają pocztą elektroniczną nieprzyjemne ostrzeżenia, gdy odstępujesz.

Wracając do pytania, koncentracja na komponencie artystycznym jest naturalnym wczesnym etapem rozwoju programisty. Zanim zaczniesz doceniać element dyscypliny, może minąć kilka lat pracy w branży. Nie musisz jednak aktywnie szukać „zmiany swoich technik”: będą one naturalnie zmieniać się w procesie pracy w zespole.

Na twoje pytanie, tak, zawsze powinieneś starać się zmienić swoją technikę, aby objąć unikalny projekt i powstającą technologię.

@ assfallows twierdzi: „Szczerze mówiąc, programista nie jest czymś, kim jesteś. Programista jest czymś, czym ciągle się uczysz”. to naprawdę wszystko i koniec kodowania.

To wspaniałe, że zauważasz obszary, w których robisz coś innego niż inne, zwłaszcza gdy widzisz, że to standard. Zauważyłeś testy jednostkowe i MVC - a teraz Twoim następnym krokiem musi być ich zdobycie. Zobacz, jak działają, co musisz je wdrożyć i spróbuj zorientować się, kiedy ich wdrożenie jest dobrym pomysłem.

Jest to stale rozwijająca się dziedzina, w której nowe języki i wzorce rosną i spadają. Jeśli nie masz nic przeciwko kodowaniu, zacznij sprawdzać część projektową. Dowiedz się, co czyni je dobrymi i kiedy ich używać.

Z pewnością dołączenie do zespołu to ogromna korzyść - zawsze potrzebujesz innych oczu, aby spojrzeć na kod, aby dostrzec obszary, które rzuciłeś lub nie zastanawiałeś się nad wszystkimi implikacjami.

Nie musisz być większym komentatorem. Ale powinieneś być dobrym komisarzem (tak, zacznij korzystać z VCS - polecam Git).

Styl jest czymś, co ZAWSZE ewoluuje. Nie martw się o to. Dowiesz się, co to jest kod wielokrotnego użytku, a co nie. Ale musisz ćwiczyć i uzyskać pomoc.

Spróbuj pomóc w projekcie Open Source na Github. Niektórzy ludzie są tam naprawdę mili i spróbują ci pomóc. To najlepsza wskazówka, jaką mogę ci dać.

W rzeczywistości raczej boję się tego, że ludzie ostatecznie sprawdzą mój kod. Czy to coś normalnego, przez co przechodzi każdy programista, czy powinienem naprawdę zmienić swoje techniki?

Skąd miałbyś wiedzieć, co zmienić bez opinii od bardziej doświadczonych programistów?

Nakłanianie innych osób do przeglądu twojej pracy może być zniechęcające, szczególnie za pierwszym razem, ale jest to najlepszy sposób na konstruktywną krytykę, że musisz poprawić swoje umiejętności. Istnieje witryna SE z recenzjami kodu , które mogą okazać się pomocne. Prośba inteligentnych przyjaciół o sprawdzenie Twojego kodu to kolejny dobry sposób na uzyskanie opinii.

Najważniejsze jest rozwinięcie elastyczności. Im lepiej znasz podstawowe pojęcia, tym bardziej możesz reagować w dowolnym języku, podejściu programistycznym, stylu lub środowisku.

Mistrzostwo nie polega na uczeniu się wszystkiego / rzeczy / rzeczy do nauczenia, a więcej na uczeniu się / jak / zajmować się rozwiązywaniem problemów w różnych sytuacjach.

A najlepszą receptą na to jest praktyka. Zawsze powinieneś mieć projekt; jeśli jesteś między płatnymi koncertami, weź osobistą zabawkę. Wolny czas w jeden weekend? Pracuj przez „witaj świecie” w języku lub platformie, z której nigdy wcześniej nie korzystałeś. Poszukaj sposobów, aby wiele się nauczyć od razu. Na przykład zbuduj coś w Google App Engine, a od razu dowiesz się o Pythonie, BigTable i bazach danych zorientowanych na kolumny. Dostaniesz również dużą dawkę „profesjonalnego” stylu Google.

Dobry generał wie, jak zastosować wyuczoną taktykę i zebrać doświadczenie na różnych terenach. Wygląda na to, że masz taktykę i doświadczenie, ale musisz napotkać nieznany teren. Jest to prawdopodobnie najlepszy sposób, aby dowiedzieć się, co wiesz i czego musisz się nauczyć.

A jeśli szukasz „profesjonalnego” stylu, podejmij jakieś „profesjonalne” projekty. Znajdź projekt typu open source, który ci się podoba, przydziel sobie zmianę i dokonaj zmiany. Przygotuj się na recenzentów jackass, ale pamiętaj, że większość ludzi w tej dziedzinie nie dostała się za sprawne opanowanie umiejętności społecznych. Chodzi o to, aby narazić się na tyle, na ile chcesz być. I musisz zbudować się wystarczająco dobrze, aby zrobić to sam. Żadna klasa tak naprawdę cię nie nauczy. W rzeczywistości dzisiaj dzieje się zbyt dużo uczenia się w klasie i niewystarczająca ilość solidnych umiejętności w świecie rzeczywistym.

Nie pozostawiło mnie to tak pewnie w wyglądzie mojego kodu ani zastanawiania się, czy nie spowoduję iskrzenia przy dołączaniu do firmy, czy może przyczyniam się do projektów open source. W rzeczywistości raczej boję się tego, że ludzie ostatecznie sprawdzą mój kod. Czy to coś normalnego, przez co przechodzi każdy programista, czy powinienem naprawdę zmienić swoje techniki?

Moim zdaniem nie musisz się martwić tym, co inni myślą o twoim kodzie, jeśli skupisz się na obiektywnych pomiarach jego jakości. Czy to jest

• Poprawny?
• Zrozumiale?
• Konserwowalny?
• Wydajny?

Zgodnie z pierwszą zasadą zawsze Twoim celem powinno być skupienie się na obiektywnych cechach, a nie na opiniach innych. Koncentrowanie się na opiniach innych jest drogą do przeciętności i, jak doświadczasz, lęku.

Jedynym powodem do zainteresowania się opiniami innych jest ich dobra integracja społeczna (lub w środowisku pracy). Jeśli Twoim celem jest poprawa obiektywnych cech swojej pracy, nie musisz się obawiać reakcji innych - są to po prostu możliwości uczenia się lub, w najgorszym przypadku, praktyczne szczegóły, z którymi trzeba sobie poradzić .

Bądź szczery wobec siebie!! Kontynuuj naukę i ciesz się tym, co robisz.

Przypominasz mi siebie po pójściu na studia, by zostać inżynierem oprogramowania. Jeśli chcesz zostać programistą, powiedziałbym, że zajmij pozycję. Będziesz musiał skomentować swój kod, napisać testy jednostkowe, zrozumieć w pełni kod obiektowy. Ale teraz nie masz prawdziwego powodu, aby to zrobić. Tak długo, jak pracujesz nad osobistymi małymi projektami. Gdzie nie musisz odpowiadać nikomu oprócz siebie. Nie będziesz się dalej rozwijać jako programista.

Podejmując duże projekty, nad którymi pracuje wiele osób, i odpowiadając na pytania kierownictwa, takie jak: „Czy ten błąd wydania jest wolny? Ponieważ zamierzamy go udostępnić klientowi”. Będziesz się rozwijać jako programista / inżynier. Dostaniesz mocne uderzenia. Możesz znaleźć rzeczy, o których wspomniałeś, bardziej wartościowe i możesz znaleźć nowe rzeczy, o których nikt wcześniej nie pomyślał. Dorośniesz.

Nawet moja uczelnia nie nauczyła mnie tych rzeczy, mimo że próbowały.

W przypadku testów jednostkowych poszukaj rozwoju opartego na testach.

Aby komentować, pomyśl o kodzie, który napisałeś po odejściu. I czas, który inni ludzie spędzą na inżynierii odwrotnej.

Dla języków zorientowanych obiektowo. Zrozum to przynajmniej. Jest to narzędzie, którego można użyć do rozwiązywania problemów w bardziej czytelny sposób.

Powodzenia: D

Krótko mówiąc, najlepszym sposobem, aby dowiedzieć się, na ogół, aby spędzać czas z kimś, można dowiedzieć się z . Jeśli uważasz, że Twoje umiejętności nie są do zera, najlepiej spędzać czas z ludźmi, którzy są lepsi od Ciebie. Z pewnością znacznie lepsze niż dalsze wycofywanie się i izolowanie.

Myślę jednak, że malujesz bardzo uproszczony i mylący obraz. Daleko od wszystkich „profesjonalnie nauczonych” programistów są naprawdę dobre. To, że coś robią, niekoniecznie oznacza, że ​​jest to właściwe.

I wiele (ale nie wszystkie) z tego, co mówisz, naprawdę brzmi, jakbyś był tym, który mógłby nauczyć ich sztuczki.

Opieram się bardziej na stronie funkcjonalnej niż na OO, ale widzę użycie OO, gdy coś byłoby bardziej sensowne jako abstrakcyjny byt.

Brzmi świetnie dla mnie. Najlepszymi programistami są ci, którzy używają odpowiedniego narzędzia do pracy. Zawsze wybieram kogoś, kto zna oba paradygmaty i używa każdego z nich tam, gdzie ma to sens, nad kimś, kto religijnie stosuje tylko jeden paradygmat.

Następnie, gdy coś robię, idę prostą drogą. W przeciwieństwie do tego wydaje się, że czasami kod, który widzę od profesjonalnych programistów, jest skomplikowany ze względu na to!

Ponownie, prostota jest dobra . Nie rób kompleks kod dopóki nie musi być skomplikowane. Niektórzy ludzie mają tendencję do rzeczy złożonej z jakiegoś błędnej idei elegancji, albo dlatego, że „musimy tę dodatkową funkcjonalność później”. Zasadniczo lepiej jest zrobić najprostszą rzecz, która rozwiązuje problem.

Używam wielu zamknięć. Dobry. Dlatego tam są. Przerażają niektórych ludzi, którzy utknęli w latach 90. i przestarzały model quasi-OOP Javy, ale tak naprawdę to ich problem.

I wreszcie, nie jestem najlepszym komentatorem.

Co należy skomentować i jak, jest wysoce subiektywne. Nie ma tam prawdziwego „dobrego” ani „złego”, ale podczas pracy w zespole ważne jest, aby napisać kod, który zrozumie cały zespół, a nie tylko jego autor. Czasami trzeba iść na kompromis, aby dostosować się do stylu kodowania zespołu. To niekoniecznie oznacza, że ​​powinieneś pisać więcej komentarzy, to po prostu oznacza, że ​​jest to coś, na co ty i twój zespół będziecie musieli się zgodzić.

Słyszę, jak profesjonalnie wyszkoleni programiści powtarzają takie rzeczy, jak testy jednostkowe. Coś, czego nigdy wcześniej nie używałem, więc nawet nie mam zielonego pojęcia, czym one są i jak działają.

Zapytaj ich. :) Testowanie kodu jest niezbędne, a testy jednostkowe są popularnym i przydatnym narzędziem do tego.

Wiele podkreślników „_”, które tak naprawdę nie są w moim guście.

Podobnie jak w przypadku komentowania, jest to subiektywne i zależy od języka. W C i C ++ lowercase_with_underscoresjest dość powszechną konwencją nazewnictwa. W wielu innych językach praktycznie nie zobaczysz podkreślenia. Ale pod koniec dnia to naprawdę nie jest ważne. To, czy funkcja jest wywoływana, write_to_logczy WriteToLognie ma znaczenia. Ktoś będzie musiał to po prostu zassać i dostosować się do tego, co zgodził się tam zespół.

Nic nie wiem o MVC, słyszałem o tym wiele z takimi rzeczami jak backbone.js. Myślę, że to sposób na zorganizowanie aplikacji. Po prostu mnie to jednak myli, ponieważ do tej pory stworzyłem własne struktury organizacyjne.

Podobnie jak w przypadku testów jednostkowych, nigdy nie przestawaj się uczyć. Współpracujesz z ludźmi, którzy wiedzą, czego nie znasz, i którzy pochodzą z innego środowiska niż ty. Ucz się od siebie nawzajem. Są oczywiście rzeczy, których możesz ich nauczyć, ale są też rzeczy, których nie znasz lub o których nigdy nie słyszałeś, a których mogą cię nauczyć. To nie znaczy, że ty (lub oni) jesteś złym programistą. Oznacza to, że dobry programista to taki, który stara się ulepszać i uczyć się od innych.

Pełne programowanie OO naprawdę pozostawia w moich ustach zły smak

To samo tutaj, a ja nazywam cię „profesjonalnie przeszkolonym” (dyplom CS). Ludzie, którzy zostali nauczeni programowania różnią się tak samo jak ludzie, którzy są samoukami. Wygląda na to, że pracujesz z osobami, które naprawdę muszą nauczyć się kilku nowych sztuczek.

W rzeczywistości raczej boję się tego, że ludzie ostatecznie sprawdzą mój kod. Czy to coś normalnego, przez co przechodzi każdy programista, czy powinienem naprawdę zmienić swoje techniki?

Obie. Oczywiście przerażające jest, aby inni patrzyli (i oceniali) to, co stworzyłeś. Ale to także bardzo edukacyjne. Mogą powiedzieć ci, co zrobiliby inaczej lub dlaczego zrobiliby inaczej. Mogą pomóc ci poprawić, a także mogą się czegoś nauczyć. Pokaż im kod, który rozwiązuje problem lepiej niż zrobiłby to ich „preferowany” sposób, i mam nadzieję, że pójdą „och, to fajnie. Skąd wiesz, jak to zrobić? Jak to nazywasz? Powinienem sam użyć tej techniki „

To nie jest pełna odpowiedź, masz już kilka dobrych. Jest jednak kilka kwestii, które wydają mi się nieco zagubione i nie zostały poruszone.

To mieszanka kilku rzeczy, które robię. Zwykle łączę ze sobą kilka paradygmatów programowania. Jak Functional i OO. Opieram się bardziej na stronie funkcjonalnej niż na OO, ale widzę użycie OO, gdy coś byłoby bardziej sensowne jako abstrakcyjny byt. Jak obiekt do gry.

Dla mnie wygląda to tak, jakbyś mylił programowanie deklaratywne z imperatywnym , a nie programowanie zorientowane obiektowo. Jeśli masz na myśli to, że skłaniasz się ku deklaratywnemu programowaniu i odsuwasz się od imperatywu, to dobrze. Deklaratywny ma na celu usunięcie skutków ubocznych, które powinny ułatwić zrozumienie kodu.

Nowoczesne języki programowania często obsługują deklaratywny model programowania. Na przykład w języku C # użycie Linq daje deklaratywny styl, ponieważ nie mówisz, jak uzyskać to, czego chcesz; mówisz tylko, co chcesz.

Kompletne programowanie OO naprawdę pozostawia nieprzyjemny smak w moich ustach, ale wydaje się, że właśnie tego KAŻDY inny używa.

Języki współczesne są często językami wieloparadygmatycznymi. Rzadko zdarza się, aby ktokolwiek używał „czystego” języka. Wiele języków funkcjonalnych obsługuje obiekty i efekty uboczne. Języki brane pod uwagę Zorientowanie obiektowe często nie narzuca ograniczenia, że ​​wszystko jest przedmiotem.

Co rozumiesz przez kompletne OO? Nigdy nie pracowałem nad „czystym” kodem OO. Być może możesz podać nam więcej szczegółów na temat tego, czego nie lubisz. Pomocna może być ilustracja z projektu open source.

Programowanie OO daje nam wiele funkcji do obsługi takich rzeczy jak: abstrakcja danych, enkapsulacja, przesyłanie wiadomości, modułowość, polimorfizm i dziedziczenie. Gdybym spojrzał na bazę kodu, która nie skorzystała z tego, pozostawiłbym w ustach zły smak.

Krótka odpowiedź: tak.

Uczenie się jest prawie w całości dobre.
Filtruj z dobrym rozsądkiem, dobrą radą.

WRT uczy się profesjonalnego programowania, tak.
Co masz na myśli?
Konferencje, seminaria, certyfikacja, dyplom?
Każdy ma swój koszt / korzyść.
Kiedy ROI jest dobry, jeśli masz zasoby, idź po nie.

Zważyć porady dotyczące stopni, biorąc pod uwagę źródło: osoby z / bez nich mają własne interesy.
Porozmawiaj z pół tuzinem każdego z nich.

Czy środowisko akademickie jest odizolowane od przemysłu? Często.
Czy stopień jest bezwartościowy? Trudno się kłócić o dolary.
Grads prawie zawsze zarabiają więcej pieniędzy, ale uważaj na kredyty studenckie.

Pod względem wiedzy? Może.
Jeśli nienawidzisz szkoły, nie dostaniesz więcej niż wkładasz.

Jeśli uważasz, że dyplom jest dla ciebie godnym celem, prawdopodobnie tak jest.

Kop głębiej i dowiedz się o programie studiów, kosztach i środowisku. Upewnij się, że masz zainteresowanie, zaangażowanie, czas i zasoby. Prawdopodobnie chodziłeś do szkoły przez trzynaście lat, więc jakie są kolejne cztery? Będą one najdroższe, a główną osobą, na której będziesz polegać, aby uczynić je najcenniejszymi, jesteś ty.

Koszty mogą być dość przerażające, ale opowiadają tylko część historii, ponieważ istnieje wiele grantów i stypendiów za zasługi, potrzeby i sto innych powodów.

Jeśli pójdziesz, wybierz inteligentne profs i pąki.

Drugie pytanie - czy mogę używać własnego stylu?

Masz dwa pytania.

Pierwszy jest w twoim tytule. Proszę zobaczyć moją wcześniejszą odpowiedź.

Drugi jest szczegółowo opisany w około pięciu akapitach, w których scharakteryzujesz, w jaki sposób twój styl różni się od profesjonalnego, za pomocą poniższych punktów:

• 100% samoukiem.
• Różna technika i organizacja.
• Mieszanka funkcjonalna i obiektowa.
• Mniej skomplikowane.
• Wiele zamknięć.
• Kilka komentarzy.
• Brak testów jednostkowych.
• Kilka podkreśleń.
• Brak MVC.
• Brak backbone.js.
• Brak aplikacji szablonów.

Podsumowując, myślę, że pytasz, czy to w porządku, że używasz podejścia Franka Sinatry - „Zrobiłem to po swojemu”. Wyczuwam ambiwalentność, gdy nazywasz się kodem innych ludzi profesjonalistą, ale nie jesteś z nim w zgodzie. Styl jest lepką sprawą osobistą, a debata na temat dobrego kodu jest niekończąca się i często jest stratą czasu. Niektóre problemy mogą być łatwiejsze, jeśli twoja grupa stosuje pisemną konwencję kodowania. Proszę się wymeldować:

http://en.wikipedia.org/wiki/Coding_conventions

Istnieje etykieta polegająca na zabiciu czyjegoś kodu i to kolejna rzecz, nad którą powinieneś popracować ze swoim zespołem. Załóż grubą skórę i miej nadzieję, że nie będą zbyt brutalne, ale cokolwiek zrobisz, nie idź na wojnę.

Skomentowałeś obawy, że inni zobaczą Twój kod. Przygotuj się, bo nie tylko go zobaczą, ale przepiszą i powiedzą ci, co jest nie tak z twoim stylem. Twoi współpracownicy mogą być elastyczni lub sztywni. Tak czy inaczej, zalecam, aby nie przepisywać kodu pod kątem stylu ani nie ustalać każdego punktu stylu jako negocjacji.

Powodem posiadania jednolitego kodu (i jednolitego szkolenia) jest zwiększenie szybkości i produktywności rozwoju oraz, w jakiś sposób, zinstytucjonalizowanie uczenia się najlepszych praktyk. Problemy takie jak camelCase lub use_underbars mogą wydawać się trywialne i drobne, ale spójność ma wiele zalet.

Bądź otwarty na testy jednostkowe i rozwój oparty na testach. Kiedy jesteś sam, a nie bierzesz udziału w projektach odpłatnych, jest to raczej hobby. Twoje rzeczy nie muszą łączyć się z tym, co robią inni ludzie. Jeśli Twój kod ulegnie awarii, nic wielkiego. Ale kiedy jesteś zaangażowany w zespół, kod, który piszesz, może wpłynąć na cały zespół, szczególnie jeśli dotrze do klientów.

Podobnie, jeśli Twój zespół korzysta z MVC, dowiedz się o tym, miejmy nadzieję, z tych samych źródeł, do których się odwołują. Metody strukturyzacji programów mogą mieć ogromną różnicę, jak wykazano w eksperymencie. Ponownie weź przykład i przywództwo ze swojego zespołu.

Jeśli twój zespół używa backbone.js, ty też go używasz. Twój zespół jest jak kaczki latające w szyku. Zestawienie razem pomaga im zużywać mniej energii, czyni je bezpieczniejszymi i pomaga im skuteczniej dotrzeć do celu. Analogia załamuje się, jeśli mocno ją popchniesz, ale korzystanie ze wspólnych narzędzi, technik i dostosowanie się do decyzji zespołu ma wiele zalet.

Podane porady są dość przydatne, ale staram się pamiętać, że moim głównym celem jest stworzenie „działającego oprogramowania”, które byłoby użyteczne dla moich użytkowników. Moi odbiorcy zwykle NIE są grupą programistów - są to ludzie biznesu, którzy chętnie płacą pieniądze za zautomatyzowane rozwiązanie (użytkownicy nie dbają o metodyki OO, struktury, testy jednostkowe, komentarze kodu itp., Więc nie dostań się zbytnio rozłączyłem się.)

Uważam, że ideały Manifestu Zwinnego są przydatne w mojej karierze (www.agilemanifesto.org)

• Osoby i interakcje dotyczące procesów i narzędzi
• Działające oprogramowanie w obszernej dokumentacji
• Współpraca z klientami w zakresie negocjacji umów
• Reagowanie na zmianę po wykonaniu planu

Całkowicie odnoszę się do tego pytania. Mam dokładnie takie same uczucia i bardzo podobne pochodzenie (ale nie dokładnie takie same). Powinienem zostać przeszkolony profesjonalnie (a raczej naukowo), więc powinienem wiedzieć o programowaniu OO itp. Programowanie nie było moim głównym tematem, ale zrobiłem to. Nauczyłem się OO na niektórych moich kursach i w ogóle nie rozumiałem powodu. W rzeczywistości, jedyny raz zrozumiałem OO, kiedy wykonywałem prace komercyjne i zostałem do tego zmuszony przez dwóch wielkich mentorów.

Jestem pewien, że mój profesor był równie genialny, ale widzisz prawdziwą korzyść w praktyce w środowisku komercyjnym w porównaniu z programowaniem funkcjonalnym, ale nie masz szansy zobaczyć go na kursie, który ma uruchomić i uczyć i kończyć w ciągu kilku miesięcy . Nie miałem okazji pracować nad strukturą opartą na MVC, ale jestem pewien, że będzie tak samo, tzn. Będę mógł wybrać koncepcje z książki, ale zrozumiem jej zalety, gdy zobaczę, że jest używana w środowisko komercyjne. I całkowicie się z tobą zgadzam, dlaczego używaj OO, MVC i innych skomplikowanych struktur, jeśli możesz rozwiązać problem w prostszy sposób. Moja rada: nie bój się pracy, bo wystawi cię to na inną sytuację i pozwoli ci zrozumieć te same rzeczy w innym świetle.

Pewnie nauczyłem się składni i pojęć na moim tle akademickim, ale to w świecie komercyjnym zacząłem uczyć się programowania.