3 różnice w programowaniu: hobbystycznie vs. komercyjnie

[Komentator]

W pewnym momencie każdy programista musi przestawić się z hobbystycznego kodowania na bardziej profesjonalne podejście do tematu. Czym różni się komercyjne pisanie programów na mikrokontrolery od podejścia stosowanego przez hobbystów i studentów? Jakich narzędzi wspomagających warto zacząć używać?

UWAGA, to tylko wstęp! Dalsza część artykułu dostępna jest na blogu.

Przeczytaj całość »

Poniżej znajdują się komentarze powiązane z tym wpisem.

[Treker (Damian Szymański)]

Cieszę się, że Maciek (@GAndaLF) zechciał podzielić się swoim doświadczeniem na temat komercyjnego programowania mikrokontrolerów, bo nie było u nas wcześniej zbyt dużo informacji na ten temat. Koniecznie dajcie znać w komentarzach, jeśli chcielibyście, aby taka "poważniejsza" tematyka pojawiała się na Forbocie częściej - zobaczymy co da się zrobić 😉

[SOYER]

Miło poznać Panie Macieju. Fajnie wiedzieć, że Gandalf to Pan. Dobrze mieć takiego fachowca do pomocy 😉 Zawsze lepiej się pisze do kogoś kogo znamy trochę "bliżej". Właśnie słucham wywiadu z Panem na devsession.pl. Ze zdziwieniem stwierdzam fakt, że programistów nie zrzucają kosmici z latających spodków, tylko rodzą się jako zwykli ludzie 😉

Co do artykułu to trochę nie dla mnie. Jeszcze 🙂

Pozdrawiam.

[Nawyk]

Daję znać, bardzo fajny artykuł. Gdyby prezentowane przez Kolegę podejście było powszechne (wśród menedżerów, a nie tylko senior developerów), to za zaoszczędzony czas można by było pojechać na niejedne wakacje, i to w godzinach pracy. Przydałby się jeszcze artykuł na temat długu technologicznego, w kontekście embedded, napisany w taki sposób, żeby można go było podesłać osobom średnio albo wcale-nie-technicznym 🙂

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Treker (Damian Szymański)]

24 minuty temu, SOYER napisał:

Miło poznać Panie Macieju. Fajnie wiedzieć, że Gandalf to Pan. Dobrze mieć takiego fachowca do pomocy 😉 Zawsze lepiej się pisze do kogoś kogo znamy trochę "bliżej".

Na forum mamy całkiem sporo osób, które mogłyby zaskoczyć swoim doświadczeniem zawodowym - tylko nie zawsze publicznie się do tego przyznają. Może artykuł GAndaLFa zachęci innych doświadczonych kolegów, aby czasami napisali tego typu artykuł - zainteresowanych zapraszam do kontaktu 😉

[deshipu]

Mnie także miło było przeczytać ten artykuł, ale oczywiście nie byłbym sobą, gdybym nie dodał czegoś, więc chciałem tylko zauważyć, że głównym celem przeglądu kodu nie jest wyłapywanie błędów stylistycznych, jak mógłby wywnioskować ktoś czytający ten artykuł na szybko, ale właśnie rozwiązanie pierwszego problemu, czyli komunikacji. Bo jeśli na każdą wprowadzaną zmianę musi spojrzeć jeden lub wielu innych członków zespołu, zanim zostanie ona włączona do repozytorium, to automatycznie też więcej osób wie co się z kodem dzieje, w jakim jest stanie, w którym kierunku się on rozwija. Łatwiejszy jest także transfer wiedzy, bo zarówno gdy mniej doświadczona osoba czyta kod napisany przez bardziej doświadczonego członka zespołu, jak i kiedy bardziej doświadczona osoba sugeruje poprawki mniej doświadczonym kolegom, w głowie pozostaje praktyczna wiedza na temat zastosowanych rozwiązaniach, a to bardzo dobry sposób nauki.

Jeślibym miał wybrać tylko jedną rzecz spośród wymienionych w artykule, to właśnie przegląd kodu uznałbym za najważniejszy element profesjonalnego programowania.

[GAndaLF]

@SOYER bez przesady z tym panem 🙂 Jeżeli dopiero zaczynasz, to faktycznie narzędzia i praktyki o których wspomniałem będą Cię rozpraszać od nauki programowania. Natomiast jak już poznasz podstawy to pierwszym krokiem powinna być nauka kontroli wersji, najlepiej w gicie.  

@Nawyk  święte słowa z tym zaoszczędzonym czasem. Wiele z tych technik powstało jako odpowiedź na wcześniej popełnione błędy. Ale jeżeli ktoś samemu ich również nie popełni to chyba się nie przekona 🙂 Z długiem technicznym dobry temat i w embedded chyba nie aż tak przeanalizowany, szczególnie aspekty związane z hardwarem.

@deshipu dla mnie review to miejsce wyłapywania bardziej ogólnych i trudnych problemów niż stylistyczne (te zostawmy automatom) przykładem mogą być np. problemy ze współbieżnością, wydajnością, późniejszymi modyfikacjami. Ale faktycznie komunikacja też potęguje dobre efekty - po kilku takich uwagach autor sam zaczyna zwracać uwagę na problem, rodzą się wartościowe dyskusje i buduje się zespół.

[tomcat65]

Ciekawy artykuł. "Idąc za ciosem" przydał by się artykuł/kurs(ik) używania/instalacji systemu kontroli wersji np. w darmowym Atmel Studio. Sporo osób używa, a nawet amatorsko - jak ja - byłby pomocny. 

[deshipu]

11 godzin temu, tomcat65 napisał:

Ciekawy artykuł. "Idąc za ciosem" przydał by się artykuł/kurs(ik) używania/instalacji systemu kontroli wersji np. w darmowym Atmel Studio. Sporo osób używa, a nawet amatorsko - jak ja - byłby pomocny. 

Systemu kontroli wersji nie używasz "w atmel studio". To jest osobne narzędzie, którego używasz na plikach źródłowych. Zazwyczaj różnego rodzaju IDE tylko w tym przeszkadzają, choć są takie, które próbują się z narzędziami kontroli wersji w jakiś tam ułomny sposób integrować. W praktyce przyjdzie ci używać linii poleceń, jak zawsze.

[Treker (Damian Szymański)]

11 godzin temu, tomcat65 napisał:

Ciekawy artykuł. "Idąc za ciosem" przydał by się artykuł/kurs(ik) używania/instalacji systemu kontroli wersji np. w darmowym Atmel Studio.

Pewnie, też jestem tego zdania i postaram się zadziałać w tym kierunku. Jednak tak jak napisał @deshipu "nie warto" uczyć się tego na przykładzie konkretnego IDE.

Zanim takie teksty powstaną na pewno trochę czasu jednak minie. Na zachętę polecam poniższy artykuł, z którego można poznać ogólny mechanizm pracy z takimi systemami: Systemy kontroli wersji – Mercurial 😉

[tomcat65]

Zgoda, że nie należy się ograniczać do jednego IDE. Jest to słuszne dla osób młodych, mających przyszłość w tej dziedzinie.

Dla amatora, w podeszłym wieku (jak ja), który do końca życia zostanie przy jednym IDE i rodzinie uC 😀 wygląda to inaczej.

Ale nie o mnie tu chodzi. W którejś z książek mam opis instalacji/używania takiego systemu, a jednak nie zadziałało. Dlatego wspomniałem o kursie/artykule.

[Treker (Damian Szymański)]

Dnia 4.12.2018 o 16:46, tomcat65 napisał:

Dla amatora, w podeszłym wieku (jak ja), który do końca życia zostanie przy jednym IDE i rodzinie uC 😀 wygląda to inaczej.

Tylko później projekt IDE umiera, albo aktualizowane jest GUI, przyciski mają inne nazwy lub są w innych miejscach i robią się już problemy. Niektóre tematy naprawdę lepiej opanować w bardziej uniwersalnej wersji 😉

[Harnas]

@tomcat65 dużo lepsza opcją jest nauczenie się systemu kontroli wersji jakimś GUI. Możesz spróbować z https://www.sourcetreeapp.com/ tylko chyba wymaga założenia darmowego konta.

[tomcat65]

Dnia 7.12.2018 o 13:09, Treker napisał:

Tylko później projekt IDE umiera, albo aktualizowane jest GUI, przyciski mają inne nazwy lub są w innych miejscach i robią się już problemy. Niektóre tematy naprawdę lepiej opanować w bardziej uniwersalnej wersji 😉

Oczywiście, pełna zgoda. Poczytam i popróbuję przedstawionych propozycji.  Poczekam też na ewentualny artykuł 🙂

W znanej mi wersji - z książki - było zakładanie serwera plików na własnym komputerze. Dla osób przemieszczających się to nie wyjście, ale dla wielu tak, gdyż jedynie w zaciszu domowym coś tam tworzą.