Proces tworzenia softu

0

Dzień dobry.

Jestem już trochę starszy, niż osoby dopiero co po studiach. Pracowałem w kilku miejscach jako programista. Obecnie nie pracuję w zawodzie. W firmach, w których pracowałem, nie miałem żadnego mentora ani zespołu. Miałem napisać konkretną rzecz (czy to grę na Andka, iOSa, czy generator kodu kreskowego, etc.) i już. Pracodawcy nie interesowało jak to zrobię. (Nawet nie zawsze interesowało go kiedy, bo szybko pracowałem). Jednak to podejście ma negatywny wpływ na mnie po latach. Nie wyrobiłem sobie dobrych nawyków projektowych i teraz mam często chaos w kodzie, jako, że piszę "na żywioł".

Jak, z Waszej perspektywy przebiega proces projektowania softu? Od czego zacząć i jak sprawić, by miało to ręce i nogi, by łatwo wprowadzać zmiany i nie utonąć w chmarze nieużytecznego kodu?

I drugie pytanie. Czy Waszym zdaniem, w wieku 30+, z 2 letnim doświadczeniem komercyjnym w Lua, C#, MSSQL, VBA dla Excel, C++, a prywatnie także JS, Java, PHP, i wiele innych, jest sens szukać pracy w zawodzie? To co spowodowało, że odszedłem, to niska kultura osób w firmach, w których pracowałem, a także stres z tym związany. Jednak wiem, że jakbym dołączył do sensowniejszej firmy, to może będzie inaczej? (Nie mam skończonych studiów, ale jestem się wstanie nauczyć dowolnego języka, bez większych problemów)

3

Żeby nie trafić znowu jako rzeźbiarz w agencji reklamowej to lepiej poznaj jedną technologie + całą jej otoczkę ale dokładnie. Sama znajomość np. javascriptu nie da Ci pracy, bo za tym kryją się frameworki, może backend w node, bazy danych i inne cuda. Backend z kolei to też frameworki, orm, wzorce projektowe, testy. Coś co jest do wszystkiego jest do niczego, a na naukę wszystkiego nie starczy Ci życia. Rozsyłaj póki co cv i ogarniaj to, co Cię najbardziej interesuje, bo wiek nie ma znaczenia, a na naukę od podstaw firma też nie może sobie pozwolić. Poza tym jeśli będziesz mieć wartość rynkową, to zmiana firmy na inną również nie będzie problemem

3

Jak, z Waszej perspektywy przebiega proces projektowania softu? Od czego zacząć i jak sprawić, by miało to ręce i nogi, by łatwo wprowadzać zmiany i nie utonąć w chmarze nieużytecznego kodu?

Napiszę tu o dość małych apkach, których nie robią duże zespoły w kilka lat

  1. Spisanie wymagań - krótki dokument z funkcjami, jakie chcę. Dobrze czasem sobie przypomnieć jaki miałem plan :) .
  2. Struktura projektu - katalogi, w których mają zostać rozmieszczone pliki z klasami, np. dla komunikatora byłoby coś takiego gui, logi, komunikacja sieciowa, kontakty, archiwum wiadomości, ustawienia
  3. Interfejs - klasy, które reprezentują konkretne funkcje, ale nie implementację, np. klasa klasa Message reprezentująca wiadomość na czacie
  4. Implementacja interfejsu - realizacja powyższego punktu z użyciem interfejsu biblioteki albo API systemu operacyjnego

Klasy? To już SOLID i te sprawy. Chyba nie ma sensu tu tego opisywać.

I drugie pytanie. Czy Waszym zdaniem, w wieku 30+, z 2 letnim doświadczeniem komercyjnym w Lua, C#, MSSQL, VBA dla Excel, C++, a prywatnie także JS, Java, PHP, i wiele innych, jest sens szukać pracy w zawodzie? To co spowodowało, że odszedłem, to niska kultura osób w firmach, w których pracowałem, a także stres z tym związany. Jednak wiem, że jakbym dołączył do sensowniejszej firmy, to może będzie inaczej? (Nie mam skończonych studiów, ale jestem się wstanie nauczyć dowolnego języka, bez większych problemów)

Sens jest, ale z opisu niewiele możemy wyczytać. Teraz na rozmowach trzeba się bardzo postarać, bo jest duża konkurencja. Może się okazać, że na rozmowie potencjalny kierownik będzie zasypywał Cię pytaniami z głębin odbytu demona a w samej pracy będziesz walczyć z tasiemcami.

2

Według mnie pierwsze i najważniejsze, to siąść i jasno spisać wymagania, tak żeby każdy zainteresowany je rozumiał. Ze swojego niedużego doświadczenia mogę powiedzieć, że często tu jest bardzo duży problem.

4

Ja bym powiedział nie tyle wymagania, co specyfikacje testów akceptacyjnych, czyli jasne, testowane(!) wymagania, z dokładnie określonymi warunkami początkowymi, końcowymi i oczekiwanym zachowaniem.

1

Piłka nożna różni się od tenisa ziemnego m.in. tym, że zawodnik na boisku nie musi (i nie powinien) gonić przez całą murawę jak pies za każdą piłką.
Pilnuje swoich zadań.
Podobnie jest z tworzeniem oprogramowania.
Praca zespołowa oznacza z zasady, że nie musisz zajmować się całym procesem, np. definiowania formalnych wymagań, bo od tego jest już ktoś inny.
Najważniejszy element nauki to przestawienie się na pracę w zespole - komunikacja i koordynacja pracy.
Trudno wytrenować te umiejętności kopiąc piłkę samotnie na trawniku pod domem ("jak już będę umiał, zgłoszę się do klubu").
Możesz wyciągać pewne wnioski, oglądając mecze - np. przestudiować, jak przebiegają code review w porządnych projektach na GitHubie; spróbować samemu się gościnnie poudzielać.
Nieglupim pomysłem byłoby także wrzucać swój kod do oceny: czy to tutaj, czy na przykład na https://codereview.stackexchange.com
I angielski. Może poćwiczymy angielski?

A docelowo musisz po prostu znaleźć dobrą firmę, gdzie mógłbyś liczyć na kogoś w rodzaju mentora. Zacisnąć zęby i zacząć od dolnych szczebli drabiny.
Twoje dwuletnie doświadczenie, bez względu na jego jakość czy charakter, daje ci sporą przewagę nad przeciętnym kandydatem na juniora, który nie ma nawet tego.

W odpowiedzi na druzgocący problem pt. "mój wiek to 30+" można tylko uprzejmie odchrząknąć, co niniejszym czynię

2

Kilka pozycji od menadżera IT:

Powodzenia!

2

Nie wyrobiłem sobie dobrych nawyków projektowych i teraz mam często chaos w kodzie, jako, że piszę "na żywioł".

Możesz poczytać o Clean Code, SOLID, DRY, OOP, programowaniu funkcyjnym, wzorcach projektowych, o pisaniu testów, o refaktoringu itp.

Problem tylko, że jak się za dużo naczytasz, to będziesz to wpychał na siłę i twoje projekty staną się przekombinowane, więc też nie będzie dobrze. Możliwe, że przez jakiś czas przejdziesz etap overengineeringu i możliwe, że będzie ci się wydawać, że piszesz dobrze, bo książkowo, a w rzeczywistości dalej będziesz tworzyć potworki.

Tylko, że na to chyba nie ma rady, jak praktyka (liczona raczej w latach) i stosowanie KISS (keep it simple stupid) i YAGNI (you ain't gonna need it), żeby robić coś dobrze, ale żeby było to dalej proste.

1 użytkowników online, w tym zalogowanych: 0, gości: 1