Hacker pełen jest prognoz i porad na temat tego, co robić w nadchodzącym roku — jakie języki się uczyć, na jakie sektory się przestawiać, jak dbać o zdrowie. Brzmi inspirująco! Ale każda moneta ma dwie strony, a my potykamy się nie tylko w czymś nowym, ale głównie w tym, co robimy na co dzień. "Dlaczego nikt mnie nie ostrzegł!" — wołamy zirytowani, zazwyczaj zwracając się do samych siebie. Przypinamy ogień na siebie — zebraliśmy dla was listę rzeczy, których NIE warto robić w 2020 roku (a może i zawsze).
A grawitacja nie zapytała.
Bardzo chcielibyśmy uporządkować antyrekomendacje w kolejności od najważniejszej do najmniej znaczącej. Ale są one tak powszechne, równorzędne i znane praktycznie każdemu, że będziemy pisać bez ładu. Co, sprawdźmy listę?
Nie należy wchodzić do IT, jeśli wszystko jest w porządku.
Nie ucz się nowej technologii, aby zmienić zawód lub zacząć od nowa. Nasz czas jest wspaniały, ponieważ można się uczyć, zmieniać pracę, całkowicie zmieniać branżę — i tak aż do emerytury. To świetna, kusząca sprawa. Ale jeśli masz więcej niż 28-30 lat, nie rzucaj wszystkiego, aby wejść do IT lub zmienić stos (na przykład, jeśli piszesz wysoko obciążone systemy w Javie i nagle postanawiasz przejść do sieci neuronowych na Pythonie). Powód jest prosty: będzie ci trudno. Po pierwsze, konkurencja ze strony specjalistów, którzy „siedzą” na tym stosie od początku swojej kariery, jest wysoka, po drugie, będziesz musiał znowu zostać juniorem z niską pensją, po trzecie, moralnie będzie ci ciężko stać się podwładnym najniższego szczebla hierarchii. Dlatego jeśli chcesz iść w inną stronę, staraj się to robić albo w ramach obecnej pracy i bieżących zadań, albo rozwijaj nową wiedzę jako hobby, pracuj nad projektem pobocznym, aby przyjść do nowej pracy już nie jako junior.
Zmiana stosu technologii to tylko strata czasu.
Nie skacz między stosami technologii w swojej pracy. Jeśli piszesz projekt w jednym języku, używasz określonego frameworka i bibliotek, nie rzucaj wszystkiego i nie przepisywuj na Dart tylko dlatego, że to wydaje ci się interesujące. Przyjmij za zasadę, aby znaleźć uzasadnienie dla zmiany technologii — nie tylko na poziomie „chcę-nie mogę”, ale także na poziomie finansowym i inżynieryjnym.
Nie trzeba obstawać przy swoim i zdrętwieć.
Przywiązywanie się do jednego języka lub technologii i ignorowanie nowości jest tak samo skrajne, jak zmiana stosu z każdą nową technologią. Zawsze ucz się nowych bibliotek i frameworków, nie bądź uparty, myśląc, że wszystko co najlepsze zostało wymyślone przed Tobą i ulepszone wyłącznie przez Ciebie. Dla prawie każdego języka regularnie pojawiają się aktualizacje, które mogą znacząco poprawić Twój projekt. Nie bądź leniwy, śledź dynamiczność swojego stosu i w momencie, gdy znajdziesz coś fajnego i przydatnego, śmiało wprowadź to do projektu!
Własna głowa to dobrze, zawsze dobrze
Nie myśl cudzymi myślami, twoje są lepsze. Niestety, niektórzy programiści siedzą i czekają, aż dostaną zadanie, aby pisać od poprzedniego błędu do końca, nie próbując wnieść czegoś swojego do projektu, opracować nową funkcję, przetestować i zaproponować do produkcji. Po co się trudzić, skoro jest głowa team leada lub kierownika firmy, który sam wszystko załatwi? Jeśli się w tym rozpoznajesz, to mamy złe wieści: pasywna postawa nie pomoże ani w karierze, ani w rozwoju. Masz szansę spróbować swoich sił jako inżynier programista, a nie jako programista w prawdziwym projekcie i zrozumieć, w jakim kierunku iść, czego brakuje, ale wolisz spędzić swój czas na czymś innym, robiąc dokładnie „od do”. Tacy w nowoczesnej IT przetrwają coraz gorzej, wyjdź z anabiozy.
Użytkownicy to straszni ludzie
Nie przeceniaj użytkowników swojego oprogramowania: jeśli piszesz nie dla programistów, przygotuj się na to, że program spotka się z nieprzeniknionym niezrozumieniem. Przez pierwsze kilka dni lub tygodni użytkownik będzie nienawidził twojego oprogramowania, ponieważ „stary nie był taki głupi”. Aby tego uniknąć, stwórz świetną dokumentację i materiały szkoleniowe. Przy instalacji lub zakupie bardzo nachalnie zasugeruj, że instrukcje warto przeczytać przed rozpoczęciem pracy z programem, a nie po załamaniu bazy danych, utracie hasła i samokontroli.
Nie należy lekceważyć użytkowników: są sprytniejsi, mądrzejsi i ciekawsi, niż myślisz. Jeśli sądzisz, że błąd związany z formatem zmiennej i wyjątek przy 138. naciśnięciu Enter co sekundę nie wystąpią, mylisz się — pojawią się i wpłyną na działanie Twojej aplikacji w najbardziej nieprzewidywalny sposób. Działa zasada amatora: to on najlepiej radzi sobie z testowaniem. Jednak użytkownicy w jakiś sposób nie lubią znajdować błędów w produkcie — nie ma w tym żadnej solidarności IT. Generalnie, im bardziej jesteś pewny swojego oprogramowania, tym lepiej. W końcu lepiej opóźnić wydanie niektórych funkcji, niż dodać je do działającej aplikacji i nagle sprawić, że będzie niedopracowana.
Dość googlowania!
Przestań polegać tylko na Google. Nawet nie będziemy się spierać — w dziedzinie programowania można znaleźć bardzo wiele za pomocą bezpośredniego zapytania do wyszukiwarki. Im głębiej zagłębisz się w poszukiwania informacji, tym więcej „pobocznych” danych zdobędziesz i więcej się dowiesz, ponieważ poznasz coś nowego, niezwiązanego z Twoim zapytaniem, ale prawdopodobnie przydatnego w przyszłości. Korzystaj z pełnowartościowych materiałów, książek, artykułów itp. Języki i biblioteki mają specyfikacje, społeczności, poradniki i w ten sposób zdobywasz najbardziej niezawodny sposób rozwijania umiejętności programisty — po prostu czytając dokumentację, a nie szukając cudzych lokalnych rozwiązań i fragmentów kodu. A nuż Twoje rozwiązanie będzie bardziej optymalne, szybsze i lepsze?
Ufaj, ale sprawdzaj
Nie korzystaj z bibliotek i frameworków stworzonych przez zewnętrznych deweloperów, nie sprawdzając kodu i nie dostosowując go do swoich celów. Nie masz żadnych podstaw, by bezwarunkowo ufać temu autorowi, którego w ogóle nie znasz. Tak, różne celowe złośliwe elementy w zewnętrznym kodzie występują niezbyt często i nie ma powodu do paranoi, ale ślepe kopiowanie gotowych fragmentów oprogramowania do swojego projektu może prowadzić do nieprzewidywalnych konsekwencji. Dlatego zawsze czytaj i analizuj kod przed użyciem oraz przeprowadzaj testy po wdrożeniu kodu.
Twórz kopie zapasowe!
Przestań nie robić kopii zapasowych lub trzymać ich na tych samych zewnętrznych serwerach, na których hostowany jest twój projekt. Myślisz, że to zabawna i niepotrzebna rada? A jednak ponad 700 uczestników czatu na Telegramie, którzy znaleźli się w trudnej sytuacji z powodu przerwy w pracy jednego znanego Data Center, tak nie myślało — co tam się działo: od projektów osobistych po duże strony instytucji państwowych oraz korporacyjne bazy 1C i systemy billingowe. Znaczna część — bez kopii zapasowych lub z kopiami w tym samym miejscu. Dlatego rozdzielaj ryzyko i przechowuj kopię zapasową przynajmniej na głównym hostingu, na jakimś niezawodnym VDS i u siebie na lokalnym serwerze. W końcu będzie to znacznie tańsze.
Dość przynosić swoje na szkodę projektu
Nie rób w projekcie roboczym tego, co chcesz, ale rób to, czego potrzebują klienci. Tak, stworzenie własnej sieci neuronowej, przeszkolenie jej i wdrożenie w swoim oprogramowaniu jest niezwykle interesujące i fascynujące, ale jeśli twoim klientom potrzebny jest prosty menedżer kontaktów, to będzie to niepotrzebny wydatek. Zobacz, jak działa projekt, przeczytaj dokumentację, przeczytaj opinie i zapytania od klientów i wdroż to, co nada projektowi wartość biznesową. Jeśli chcesz tworzyć coś naukowego lub nadmiernie skomplikowanego, rozpocznij od swojego własnego projektu.
Nie kod, a zbiór nerwów
Nie pisz nieczytelnego i niedokumentowanego kodu. Znamy ten kawałek: programista pisze kod jak mu dusza podpowiada, specjalnie go nieco myli, aby żaden z kolegów nie mógł się w nim odnaleźć — taka swoista prewencyjna zemsta zanim coś się wydarzy. Narażasz jednak nie tylko firmę (która płaci ci za pracę), ale i siebie samego: prawdopodobnie nie przypomnisz sobie, co chciałeś przekazać w tej niezamierzonej obfuskacji. To samo dotyczy niedokumentowanego kodu: polegając na swojej logice nazewnictwa zmiennych i funkcji oraz dobrej pamięci, po kilku latach możesz nie pamiętać, dlaczego wybrałeś ten konkretny cykl, metodę, wzór itd. Dokumentowanie kodu i jego dobra struktura to wspaniała usługa dla kolegów, pracodawcy, a przede wszystkim dla samego siebie.
Keep it simple, stupid
Nie komplikuj kodu, rozwiązań i projektów. Nie ma potrzeby budować skomplikowanej struktury i mnożyć byty bez specjalnego znaczenia. Im bardziej złożony jest twój kod, tym bardziej stajesz się jego więźniem — znacznie trudniej będzie ci go utrzymywać i rozwijać. Oczywiście, słynna zasada KISS („Keep it simple, stupid”) nie zawsze się sprawdza, ale została stworzona nie bez powodu: prostota i elegancja kodu to klucz do jego skutecznego zastosowania i ponownego wykorzystania.
Zabezpiecz się
Nie ignoruj bezpieczeństwa — w 2020 roku to dosłowna zbrodnia. Nawet jeśli twoja firma, rozwój i ty nie interesujecie przestępców, mogą cię dotknąć problemy związane z atakiem na jakiś segment sieci, dostawcę hostingu, atakiem na centrum danych, kradzieżą haseł e-maila i niebezpiecznym zachowaniem pracowników, którzy mogą ukraść dane z firmy, odebrać klientów lub kod całego projektu. Jeśli możesz i należy to do twojej kompetencji, postaraj się zabezpieczyć te projekty, nad którymi pracujesz. No i sam przestrzegaj bezpieczeństwa informacji, to nikomu jeszcze nie zaszkodziło.
Nie pluj w studnię
Nie szkodź swojemu pracodawcy. W dzisiejszych czasach komunikacja osiągnęła taki poziom, że na przykład wszyscy HR-owcy w mieście znają się nawzajem i mogą wymieniać wszelkie informacje w czatach i zamkniętych grupach (jak pomóc w znalezieniu pracy, tak i napisać „Wasilij Iwanow, architekt systemów, przed odejściem zabił wszystkie konta, zatarł kopie zapasowe i wyłączył sieć, przywrócenie zajęło 3 dni. Nie zatrudniaj go” ). W ten sposób twoje zachowanie zagraża tylko tobie — i czasami nawet relokacja do innego miasta lub stolicy nie pomoże. Nawet jeśli odchodzisz z urazą, nie ma lepszej zemsty niż bycie użytecznym i świetnym pracownikiem konkurencji 🙂 A przede wszystkim, bezkarnym.
Także tego robić nie warto. Ale, jak pokazuje doświadczenie, nie przestaniemy
A w ogóle, przyjaciele, czytajcie rady, ale róbcie tak, jak wydaje się wam najlepiej — bo prawdziwe odkrycia dokonują się wtedy, gdy wątpi się w już odkryte prawdy. Życzymy wam Szczęśliwego Nowego Roku, niech wasze projekty będą udane, kariera — ciekawa, koledzy i przełożeni — adekwatni, a życie w ogóle udane. Ogólnie, za Nowy Rok i za nowy kod!
Z miłością,
zespół RegionSoft Developer Studio
W nowym roku nadal będziemy pracować dla Ciebie i rozwijać potężny system CRM na komputer stacjonarny oraz prosty i wygodny helpdesk i system zgłoszeń .
Źródło: habr.com
